3 ms·

On the first entry: >Drill-down navigation is stateless I've been encountering this a lot lately, but: this seems the opposite to me, it's deeply stateful as

by Groxx 3y ago

On the first entry: >Drill-down navigation is stateless I've been encountering this a lot lately, but: this seems the opposite to me, it's deeply stateful as screen N depends on what you did before, and you can go back to it. It literally keeps track of some internal state in order to be useful at all, i.e. the list contents depend on state N-1, because if it didn't it would be awful. A stateless UI would be, like, a one-step modal. It exists or it doesn't. Particularly strongly "stateless" if it's transient and you have no way to "resume" it. I've been in and around quite a few discussions using the term "stateful" to mean WILDLY different things through the years, and in a giant burst lately, and it has largely led me to conclude that almost nobody agrees with anyone else what it means and few are aware of this. What does "stateful UI" mean to you all? I find the variation fascinating.

deleted 3y ago
[deleted]
bruce343434 3y ago
To me, stateful UI means that the front end is using variables to manage its behaviour.
- Groxx 3y ago
  This would mean it's strictly an implementation detail then? Since any state can be turned into configuration / construction / just make infinite views, each one customized to show one state.
  - asoneth 3y ago
    Implementation differences are certainly a part, but people do interpret them differently. For example, I'm working on an application that is transitioning some of our stateful navigation to be more stateless to hopefully address some end-user confusion. We have an overlapping hierarchy where many objects have multiple parents, and the same object would display different breadcrumbs depending on which path someone took to the object. This made people confused about whether they were looking at the same object.
asoneth 3y ago
I agree the use of "stateful UI" is ambiguous in general, but with respect to navigation I typically hear hierarchies referred to as stateless and activity stacks as stateful. With a hierarchy like iOS every child is supposed to have exactly one parent so you only need to know the current page to know what the "back" button will do -- it will go up one level in the hierarchy to the page's parent regardless of how you arrived at the page. With an activity stack like Android, it is not sufficient to know the current page, you must know how you got to that page because the "back" button refers to going back in the history. Many websites support both -- the browser's back button is stateful and navigates your personal history, whereas on-page navigation like breadcrumbs are often stateless and do not depend on the particular path you took to get to the page. There are exceptions of course, many search interfaces are stateful in that drilling into an item and going back using the in-page navigation will return you to the prior query rather than the page's parent.

by Groxx 3y ago

deleted 3y ago

[deleted]

bruce343434 3y ago

To me, stateful UI means that the front end is using variables to manage its behaviour.

Groxx 3y ago
This would mean it's strictly an implementation detail then? Since any state can be turned into configuration / construction / just make infinite views, each one customized to show one state.
- asoneth 3y ago
  Implementation differences are certainly a part, but people do interpret them differently. For example, I'm working on an application that is transitioning some of our stateful navigation to be more stateless to hopefully address some end-user confusion. We have an overlapping hierarchy where many objects have multiple parents, and the same object would display different breadcrumbs depending on which path someone took to the object. This made people confused about whether they were looking at the same object.

asoneth 3y ago

I agree the use of "stateful UI" is ambiguous in general, but with respect to navigation I typically hear hierarchies referred to as stateless and activity stacks as stateful. With a hierarchy like iOS every child is supposed to have exactly one parent so you only need to know the current page to know what the "back" button will do -- it will go up one level in the hierarchy to the page's parent regardless of how you arrived at the page. With an activity stack like Android, it is not sufficient to know the current page, you must know how you got to that page because the "back" button refers to going back in the history. Many websites support both -- the browser's back button is stateful and navigates your personal history, whereas on-page navigation like breadcrumbs are often stateless and do not depend on the particular path you took to get to the page. There are exceptions of course, many search interfaces are stateful in that drilling into an item and going back using the in-page navigation will return you to the prior query rather than the page's parent.