WIP: Something to play with on iOS, for navigation.

[chrisbobbe]

EDIT: Huh, not sure why I named the branch "notification" ideas instead of "navigation" ones. 🤷

@gnprice @ray-kraesig

Following discussions here and here, here's something concrete to play with, made especially for iOS.

I think it would have been a good idea to settle some of those discussions before I moved the conversation to hypothetical "a -> b -> a -> b" sequences, etc., so hopefully this WIP PR can help toward that. 🙂 I don't think the concerns of a large stack building up are more urgent right now than fixing the unexpected "back" and "up" behaviors, which I still find really confusing and unhelpful after a lot of time with the UI.

I think we've found that Apple doesn't have a strong, consistent rule that would require the "up" button/action, so I've left it out here, hopefully without too much controversy. The concern I raised in my long story about the #consciousness stream is resolved by putting the topic list button in the topic nav, not just the stream nav.

I think some disagreement remains on the question of the "up" button/action on Android, which I'll quote here.

Greg said:

• to pop the history stack: Left-arrow nav-bar button.

This is, IIRC, the opposite of the recommended behavior on Android; this button should take you "up", rather than chronologically "back".

The "back button in a browser" functionality is explicitly the purpose of the system Back button/gesture.

So, it's absolutely right that that's the doctrine in the Android docs.

I've grown skeptical that that's actually a great UI choice, though. I've also found it hard to locate real examples of apps seriously following that design.

So I think it may be the right choice for us to leave that left-arrow in the nav bar as a "back" navigation. (Like the status quo, and like in the dictionary I described above.)

(See also Greg's example with a diagram.)

Ray said:

Hmm, and with which behavior? Do you mean having it go "back" on iOS, but "up" on Android?>
Exactly so.

I think an "up" icon wouldn't greatly help. Nobody who hasn't been an Android developer knows about the contrasting terms "back" and "up" -- at least I'd never heard of them, or put together the concepts quite that way, in my years as an Android user before starting to develop for it.

Yes, that's why the different icon. :slight_smile: At least on the topic screen, being located next to the stream-name-over-topic-name construct should be a strong hint to its behavior. I'm less sure about the stream screen, though.

Before resuming this directly, I think it may help to return to my analysis of that Japanese dictionary app, and, from it, some guidelines I've offered to help reduce confusion for Zulip users. Greg, it looks like you agree with them. Ray, you responded to an implementation idea that followed them, but I'm curious to know what you think about the guidelines themselves. They seem broad enough to be a good place to explore any disagreements before moving forward, perhaps in the "navigation" topic on CZO.

I said:

A) It lets you navigate by the static structure of the pages, which I think you've called "the DAG of the overall navigation."
B) It lets you navigate back through the user's history as it's created by some (maybe all) A-type navigation actions.
C) A- and B-type navigation actions have distinct interfaces, so you're never unsure where a button or swipe will take you.

It seems to me that the Android diagrams we've discussed observe these.

I may have misunderstood, but some of the recent discussion on how many (2, N, 2N, etc.) routes would accumulate in the stack may be influenced by differing assumptions, with one being that a single back or up button could fulfill both A and B, which violates C. If I'm jumping to conclusions here, please let me know, but after you've responded to the above. 😉

[rk-for-zulip]

Well, I mostly agree; and in particular, I agree that this is an ideal that should be striven for. However, C) is really two propositions...

C1) A- and B-type navigation actions have distinct interfaces[...].
C2) [...] you're never unsure where a button or swipe will take you.

... and C1 is not quite sufficient to guarantee C2, because:

B) It lets you navigate back through the user's history as it's created by some (maybe all) A-type navigation actions.

... the complexity of the rule determining which A-type actions are not invertible by a B-action is pretty much the degree to which proposition C2 fails to hold for B-actions.

Unfortunately, there are some pretty compelling technical and usability reasons not to let a stack of A-type actions build up indefinitely; and preventing that requires either 1) a structurally-guaranteed maximum navigation depth or 2) some non-invertable A-type actions. (Most apps are happy with option 1, but I don't think anyone thinks it's an appropriate choice for Zulip.)

[chrisbobbe]

Thanks for this helpful analysis, Ray! I've replied here.

[chrisbobbe]

Closing; let's revisit these issues with a clean slate and fresh eyes.