
| Key: |
SAK-8115
|
| Type: |
Feature Request
|
| Status: |
Closed
|
| Resolution: |
Duplicate
|
| Priority: |
Major
|
| Assignee: |
Unassigned
|
| Reporter: |
Peter A. Knoop
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Duplicate
|
|
This issue duplicates:
|
|
SAK-737
Sakai remembers state - optional?
|
|
|
|
|
|
This issue is duplicated by:
|
|
SAK-8026
Legacy tools should not save state.
|
|
|
|
|
Relate
|
|
|
|
|
|
|
User need a consistent model for what will happen when they "go someplace else" within Sakai.
Currently, when you move between tools sometimes the tool the user left remains in the same state so when the user returns, they are dropped in the middle of a tool. For other tools, the tool resets itself when a user leaves it so when the return to the tool they arrive at the main page.
There is similar inconsistency with navigating within a tool. Sometimes, moving away from a page (but staying within the tool) saves the users data on page (a form for instance) until they come back. And in other tools, if the user moves away from a page without saving, the data will not be saved and the next time they visit that page it will be refreshed.
Original requirement below before combining this one with another:
Currently Sakai saves the state of a tool when you navigate away from it. For instance, if you are part way through creating a Resource and you click on the Schedule, when you come back to Resources, you'll find yourself right where you left off creating a new Resource, which can lead to confusion if you do not want to resume the process, are looking to do something different in Resources now, and are not familiar with the reset button for tools. Another approach is to reset a tool, and not save its state, when you navigate away from it, which means when you come back, if you want to resume your process, then you've lost everything you've done up to that part and have to start over. (Some other aspects of Sakai's behavior, which may compound the problems experienced here, include lack of support for the browser's back button and the percieved expectation that clicking on a tool in the left-hand menu, when already viewing the tool, should reset the tool, as opposed to learning about the little reset-icon in the top-left of the tool.)
There has always been a lot of debate over which model to adopt. The choice of saving state or not should be a system-wide configuration option.
|
|
Description
|
User need a consistent model for what will happen when they "go someplace else" within Sakai.
Currently, when you move between tools sometimes the tool the user left remains in the same state so when the user returns, they are dropped in the middle of a tool. For other tools, the tool resets itself when a user leaves it so when the return to the tool they arrive at the main page.
There is similar inconsistency with navigating within a tool. Sometimes, moving away from a page (but staying within the tool) saves the users data on page (a form for instance) until they come back. And in other tools, if the user moves away from a page without saving, the data will not be saved and the next time they visit that page it will be refreshed.
Original requirement below before combining this one with another:
Currently Sakai saves the state of a tool when you navigate away from it. For instance, if you are part way through creating a Resource and you click on the Schedule, when you come back to Resources, you'll find yourself right where you left off creating a new Resource, which can lead to confusion if you do not want to resume the process, are looking to do something different in Resources now, and are not familiar with the reset button for tools. Another approach is to reset a tool, and not save its state, when you navigate away from it, which means when you come back, if you want to resume your process, then you've lost everything you've done up to that part and have to start over. (Some other aspects of Sakai's behavior, which may compound the problems experienced here, include lack of support for the browser's back button and the percieved expectation that clicking on a tool in the left-hand menu, when already viewing the tool, should reset the tool, as opposed to learning about the little reset-icon in the top-left of the tool.)
There has always been a lot of debate over which model to adopt. The choice of saving state or not should be a system-wide configuration option. |
Show » |
|
UI group done with this one.