View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0007072 | Anastasis | anastasis-webui | public | 2021-11-04 23:20 | 2022-09-26 20:50 |
Reporter | Florian Dold | Assigned To | sebasjm | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | Git master | ||||
Target Version | 0.3.0 | Fixed in Version | 0.3.0 | ||
Summary | 0007072: browser history integration | ||||
Description | There are various possible behaviors here: (a) The navigation inside the anastasis SPA is independent from the browser navigation, and the back button always goes to the page visited before the anastasis SPA (b) the browser back button always goes back "hierarchically", i.e. it's always like pressing the back button inside the SPA (c) the browser back button always goes back "historically", i.e. when in the UI we press "next", "back", "next", the browser history will record each of these steps We should discuss these possibilities with Belen. | ||||
Tags | No tags attached. | ||||
|
One simple way I can think of is allowing the user to navigate free between state, two things can happen: 1.- is loading an upcoming state before is ready: instead of showing an "invalid state" message we can assume a "preview" screen to explain what the user will do when it reaches this state and how the previous state is needed to this become available. 2.- is loading an previous state: show a readonly state with a button "jump into this state" which will call a "goto" action in the reducer and a "go back where I left" button which will sync the history with the reducer current state. pros i can think of: * from (1) we use screen to show more information on how anastasis works for the curious one * we allow random access to any state from the side bar * from (2) if there is any validation to be done it can be placed into the "goto" action and add a notification "no you cannot go back into this action because XXXX" * free navigation through almost all screen is possible Side note: The screens that I'm thinking as navigable are the one that can be accessed from the sidebar, lets call them "principal screens". Others, like authorization method setup or a policy editing, are internal state from the principal screen and will be not reachable from links/history. IMHO I think this is ok for now. |
|
@belen what do you think? |
|
Belen is gone. Based on what I recall, she'd suggest (b) and possibly suggest that the "Back" button be removed, as the browser already has one ;-). But, you may keep the back button for now if you like it, but implement (b). Florian is also OK with doing (b). |
|
fixed in bf3e0111..a2e8ab94 |
Date Modified | Username | Field | Change |
---|---|---|---|
2021-11-04 23:20 | Florian Dold | New Issue | |
2021-11-04 23:20 | Florian Dold | Status | new => assigned |
2021-11-04 23:20 | Florian Dold | Assigned To | => sebasjm |
2021-11-09 14:49 | sebasjm | Note Added: 0018467 | |
2021-11-09 14:50 | sebasjm | Note Added: 0018468 | |
2022-04-12 22:53 | Christian Grothoff | Note Added: 0018864 | |
2022-04-14 21:27 | Christian Grothoff | Product Version | => Git master |
2022-04-14 21:27 | Christian Grothoff | Target Version | => 0.4.0 |
2022-04-14 22:09 | sebasjm | Status | assigned => resolved |
2022-04-14 22:09 | sebasjm | Resolution | open => fixed |
2022-04-14 22:09 | sebasjm | Note Added: 0018881 | |
2022-04-14 22:48 | Christian Grothoff | Fixed in Version | => 0.3.0 |
2022-04-14 22:48 | Christian Grothoff | Target Version | 0.4.0 => 0.3.0 |
2022-09-26 20:50 | Christian Grothoff | Status | resolved => closed |