This exactly describes our navigation within apps. If you open a page in an app, it usually covers the whole viewing area and shows a back button, so you can only access the topmost item. This is the a10f59e2<\/abbr> stack navigation paradigm<\/strong>.<\/p>\n\n\n\n Based on many assumptions app designers make, they infer that the user only needs one page of information at a time. Compared to the old-school desktop program, it reduces possible ways an otherwise professional program can be interacted with, facilitating interactions that are prescribed to be useful, but also strongly claiming creative interactions useless, as they intend to only allow these prescribed series of interactions for prescribed scenarios. (d852084c<\/abbr>.<\/strong>)<\/p>\n\n\n\n Can we allow this creativity? Here I propose an \u201caxiom\u201d about navigation schemes, which will serve as a foundation for all reasoning about navigation. All kinds of navigation can be expressed within this system.<\/p>\n\n\n\n Preceding this thesis is a convention at the operating system level governing all GUI programs: all information is presented through small \u201cframes\u201d that are a less committed, less contentful version of what we currently know as windows. Consider embeddable COM frames, Android Fragments, Android Slices, Android rich notifications, Picture-in-picture, widgets, widgets, widgets, or Mercury OS Modules<\/a>. If you cannot imagine these, just think of windows without their gross 80-pixel shadow. The reason for a new concept of frame here is that we need small units of interactive content to meaningfully speak of navigation. (4d96d48d<\/abbr>, Frame.<\/strong>)<\/p>\n\n\n\n Thesis 690b981d<\/abbr>. Permissive navigation.<\/strong> The most permissive navigation scheme is one where any navigation act does not inhibit any other navigation act that could have taken place. This expresses a maxim: that navigation is the act of accessing new<\/em> information, but not necessarily discarding previous information.<\/p>\n\n\n\n I can think of at least the following concrete designs. Any of them can be immediately implemented in today\u2019s GUIs if beneficial to the user.<\/p>\n\n\n\n In the future, I will write more to explain why I want some version of this to happen. It primarily has to do with user freedom and creativity. But here, let me state what<\/em> it is that I want happen. I am proposing a very generalized theory of GUI navigation, so instead of thinking about pages, bars, go-here-buttons, go-there-buttons, back buttons, bottom tabs, bottom sheets and so on, they are described as special cases under one system of navigation. This is also not an argument for regressing to the situation before apps, namely desktop programs with complicated detachable panels.<\/p>\n\n\n\n Let us visit an example: a digital geography map.<\/p>\n\n\n\n Google Maps will only ever let you view details of one location at a time, as with most map programs. Occasionally, I found myself in need of comparing multiple places. Suppose you are given the task of comparing user comments on three bars. Before a certain Google Maps update, I had to do this:<\/p>\n\n\n\n The \u201cmap + one information panel\u201d scheme is an improvement from a total stack, but really just one map view with a stack laid over it. The extended details for a location can expand to the full panel and show you a back button. You know you can access the comments section of each, but you cannot see them side-by-side. You know this can be done in principle because you have seen that information, but the interface does not allow you to do it.<\/p>\n\n\n\n Later, Google Maps added a Recents feature to alleviate this problem. I will write more about history below. Here presumably, a feature allowing multiple location detail frames can also help, so I demonstrate how Design 4f6daf5c<\/a> works. The program happily opens a small frame for a location you visit, and lets you Pin it so it becomes persistent; otherwise, when you visit the next location, the previous volatile frame is overridden. Unsurprisingly, this sounds like something a professional GIS will do, but I have not personally encountered such a design in any program, and it might not be immediately useful<\/em>.<\/p>\n\n\n\n It is easy for a designer to come up with a page that scrolls or pans. Usually, the app does not save the scrolling position. That is considered an extra, ad hoc<\/em> feature for the designer and programmer, but it can in fact be subsumed in the framework derived from the permissive navigation thesis<\/a> with an additional provision for indexes.<\/p>\n\n\n\n What about panning the map? Often the geography itself is of interest, not the small pins on it. Panning is also a form of navigation, yet there is no Recents for it, obviously because the computer cannot precisely tell if you have reached a place of interest. What about jump-browsing in a timeline that is one kilometer long? Do we need a search bar, or a fast-scrolling bar where you must spend a few seconds precisely controlling your finger? Here we face situations where things must be handled in parallel. It appears that an index is a \u201cspace\u201d to the user, and it always makes sense to bookmark a place in a space. Maps, timelines, and almost all indexes are spaces.<\/p>\n\n\n\n Thesis 923af141<\/abbr>. Property of the index.<\/strong> An index always warrants a button to duplicate the current view at its viewing position or bookmark it.<\/p>\n\n\n\n Did you know that many browsers will keep the scrolling position when you duplicate a tab? This demonstrates the current principle.<\/p>\n\n\n\n Permissive navigation<\/a> can be seen as equipping any navigation scheme with a visiting history, so things can stay unchanged in view and wait for future interactions. This availability has more than navigational importance. These elements are available so that<\/em> they can be used to derive further actions, including user-defined automation (9382a99c<\/abbr><\/strong>). Obviously, for any subsequent creativity to happen, the user must gather all necessary information, and in GUIs this is always done by showing all of them on the screen. The role of history, as it accompanies any navigation, appears to be paramount in light of user creativity and flexibility.<\/p>\n\n\n\n Take a look at a different program, the File Explorer on Windows as an example of a certain navigation paradigm 6e21678b<\/abbr>, the Back-Forward-Recents Paradigm<\/strong>. The File Explorer has a Back<\/em> button everyone uses, but I doubt even one tenth of us are comfortable using the other three buttons: Forward<\/em>, Recent Locations<\/em>, and Go Up One Level<\/em>. Note, this File Explorer Back<\/em> button is to be distinguished from a Stack Back<\/em> button.<\/p>\n\n\n\n As an example, I performed these navigation steps:<\/p>\n\n\n\n If after step 6 I go somewhere that is not in Recent Locations<\/em>, then all Recents<\/em> newer than \\Pictures are deleted and replaced with my new navigation. This works the same way as a standard (linear) undo\/redo history. After the user performs a few undo steps, if the user proceeds to make a change in the document, then all history newer than this point are deleted and replaced with new changes.<\/p>\n\n\n\n Did you know that your browser probably follows a paradigm similar to File Explorer? In many browsers, the Recent Locations<\/em> menu does not have a button, but is accessible by right-clicking on the Back<\/em> and Forward<\/em> buttons.<\/p>\n\n\n\n A Back-Forward-Recents<\/a> navigation becomes functionally equivalent to permissive navigation<\/a> if everything is equipped with an \u201copen in new frame\/window\/tab\u201d button, so the user does not lose any history when attempting another direction. This is fortunately the case with File Explorer and popular browsers. I call this negative permissive navigation (f227c545<\/abbr><\/strong>)<\/strong>, because although the users are able to complete all navigation that could have taken place, they are only able to do that by explicitly visiting history. The original three formulations of permissive navigation are now examples of positive permissive navigation (37a2ecd7<\/abbr><\/strong>)<\/strong>.<\/p>\n\n\n\n We can easily see that negative permissive navigation causes more friction when the user needs to access history, but it takes up less space on the screen. On the other side, positive permissive navigation has the opposite properties, simply because \u201chistory\u201d content is already in view. How does a designer choose one over another, if their difference is rather arbitrary? Extrapolating from current cases, a pattern seems to hold:<\/p>\n\n\n\n Thesis 1bc07b93<\/abbr>. Homogeneity determines negative permissive navigation.<\/strong> If navigation involves homogeneous content (such as directories and web pages), then negative permissive navigation is preferred. If navigation involves heterogeneous content (such as different parts of an app), then positive permissive navigation is preferred.<\/p>\n\n\n\n Written 2024-06-18<\/p>\n\n\n\n Permissive navigation has discrete navigation steps<\/em>. Not all things do well with discrete steps. For example, consider a chat session with your friend. In its miniature form, it could be your friend\u2019s name only. If you allow it to be a little bit larger, it can show one line of message preview, then perhaps a date, then perhaps an input bubble. In all these cases, the chat is a real chat, itself, in the sense of Alexander Obenauer. There is no clear way to specify at which point the user has navigated to<\/em> the chat, as it is not very discrete.<\/p>\n\n\n\n There is a solution: Zoom and Detach<\/em>. The user will be able to zoom on an object, creating an easily dismissible bubble on top of it, to reveal more aspects of the item. The bubble can be interactive. If the user wants the full interface to persist, then they will detach the bubble, declaring that view independent.<\/p>\n\n\n\n Ultimately, you can see this as a special version of map zooming. Duplicating a view is the remedy to any non-discrete navigation.<\/p>\n\n\n\n Information is not supposed to proliferate without discretion. It is a bad idea to keep all information (history) regardless of its significance; that would scarcely be manageable. This is why a perfect lambda calculus machine was found impossible.<\/p>\n\n\n\n The navigation scheme is often determined by the UI framework and operating system. They have extremely profound influence on the ecosystem and design philosophy. Consequently, most GUIs are programmed totally within a stack architecture.<\/p>\n\n\n\n There are many established paradigms in navigation design. Stack navigation is one of the most important consequences of Steve Jobs\u2019 mobile operating system. It reduces possible ways a program can be interacted with, facilitating interactions that are predetermined to be useful, but also strongly claiming creative interactions useless<\/strong>. Usability, done to the extreme without truly considering the user capacity, degenerates into tyranny as too many decisions are made to please the users in the short term. (d852084c<\/abbr>.<\/strong>) In fact, we are already seeing the shortcomings of \u201cusable design\u201d under complex workloads, as users end up needing software products specifically designed for<\/em> a particular workflow<\/em>, rather than a generic tool waiting for a workflow to be abstracted at user capacity. If users cannot know and recreate their tools to a large extent, they are effectively alienated from their working process.<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" The back button is perhaps the most ubiquitous element in app GUIs. It has been the go-to solution for both designers and users in many situations. The great importance of the back button has naturally resulted from the stack navigation paradigm seen in apps. However, contrary to popular opinion, I am arguing against it on […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9],"tags":[7,19],"class_list":["post-604","post","type-post","status-publish","format-standard","hentry","category-ux","tag-en","tag-ux"],"_links":{"self":[{"href":"https:\/\/www.tebibyte.io\/~yihanwu1024\/wp-json\/wp\/v2\/posts\/604","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.tebibyte.io\/~yihanwu1024\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tebibyte.io\/~yihanwu1024\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tebibyte.io\/~yihanwu1024\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tebibyte.io\/~yihanwu1024\/wp-json\/wp\/v2\/comments?post=604"}],"version-history":[{"count":0,"href":"https:\/\/www.tebibyte.io\/~yihanwu1024\/wp-json\/wp\/v2\/posts\/604\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.tebibyte.io\/~yihanwu1024\/wp-json\/wp\/v2\/media?parent=604"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tebibyte.io\/~yihanwu1024\/wp-json\/wp\/v2\/categories?post=604"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tebibyte.io\/~yihanwu1024\/wp-json\/wp\/v2\/tags?post=604"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Permissive Navigation<\/h2>\n\n\n\n
\n
An Example<\/h3>\n\n\n\n
\n
On Index<\/h3>\n\n\n\n
The Role of History<\/h2>\n\n\n\n
Back-Forward-Recents Paradigm<\/h3>\n\n\n\n
![\"\"](\"https:\/\/www-users.tebibyte.io\/~yihanwu1024\/wp-content\/uploads\/2024\/04\/image-2.png\")
<\/figure>\n\n\n\n\n
![\"\"](\"https:\/\/www-users.tebibyte.io\/~yihanwu1024\/wp-content\/uploads\/2024\/04\/image-1.png\")
Positive and Negative Permissive Navigation<\/h3>\n\n\n\n
Problems<\/h2>\n\n\n\n
Non-discrete Navigation<\/h3>\n\n\n\n
Too Much History<\/h3>\n\n\n\n
Critique of the Status Quo<\/h2>\n\n\n\n