Redesign SaveState Functionality

[aeschylus]

Here is how the current saving system works:

This fulfils the requirements of restoring state when the user reloads the page or returns from navigating back and forth, but leaves much to be desired.

Relevant Google Draw Document for fixing this

Pain Points

• The point at which the saving system does the saving is whimsical. Sometimes it saves before things have loaded properly, and a session is overwritten with a blank configuration object, meaning future visits will not have any manifests included.
• Loading a new set of initialisation options from the same domain does not overwrite the existing localStorage. If it did do so, the user might be annoyed by losing their last session. Perhaps they should be prompted to save it.
• The browser history will not reflect this distinct station in their history, because (whether the mirador instance is running from within an embedded instance, or has "taken over" the page) it is still running from within the same page. Perhaps push state should be implemented to rectify this situation. However, it would require saving a lot more states than before (which may not be a problem considering the configuration object is rather small). This may require a new pushState event for every time they add in new manifests to the existing session, presuming we make dynamic loading of manifests possible.

Having noted these things, it may help to remind oneself of the basic requirements.

Basic Requirements

• Reloading should not lose the present state of the user's session.
• Going back in history should not cause the user to lose work.
• The user should be able to easily export their session, perhaps with a method to send data to a database.
• Ability to dynamically add a manifest from a URL or the desktop, or the exterior search environment.

Nice to Haves

• Perhaps someday, there should be a way (webRTC?) to allow multiple people to change things in the same session (Multiplayer).
• Autosaving to the user's actual filesystem would be good at some point (on supported browsers.

In general, the redesign needs to address the realities of existing in a somewhat unpredictable host environment and adapting accordingly, with instance-level state saving and intelligently allowing the user to escape. What follows is an outline of some of these issues.

Integration/Environment Concerns

MOOCS

Individual Scholars

University Courses

Embedded Discovery/Display Viewer

[azaroth42]

Perhaps a unique key associated with a mirador instance to avoid the
multiple miradors in a single domain overwriting each other? So the
localstore would become {domain: {key: {configs}, key2: {configs}},
domain2:...}

I think prompting to save the state is a good idea, rather than autosaving.
Or an option to switch to manual save.

Regarding the requirements:

• What are the use cases that involve "losing work", when we don't have any
  input functionality, and the projected annotation functionality will be
  external to the mirador save state?
• It seems like the save state is good for freezing a display and reloading
  it. For this the localstorage doesn't seem like the right approach -- it
  will only work within a single system and browser. Either a server side
  session id, or client side interpretation of some #!state=(longstring)
  would be able to be easily bookmarked. This also fixes the multiple
  miradors issue as the key would be against the mirador instance, not just
  the domain.

WebSockets are another interesting technology for RTC, and widely
supported.

On Wed, Mar 5, 2014 at 1:44 PM, aeschylus notifications@github.com wrote:

Here is how the current saving system works:

[image: image]https://f.cloud.github.com/assets/145874/2338213/95012672-a4a6-11e3-9e02-5f689116049b.png
This fulfils the requirements of restoring state when the user reloads the
page or returns from navigating back and forth, but leaves much to be
desired.

Relevant Google Draw Document for fixing thishttps://docs.google.com/drawings/d/1H3kCrM5vLdg-uAYzxhyZuJp9qN_WpNZy_Sw8vtkaYfU/edit?usp=sharing
Pain Points

• The point at which the saving system does the saving is whimsical.
  Sometimes it saves before things have loaded properly, and a session is
  overwritten with a blank configuration object, meaning future visits will
  not have any manifests included.
• Loading a new set of initialisation options from the same domain
  does not overwrite the existing localStorage. If it did do so, the user
  might be annoyed by losing their last session. Perhaps they should be
  prompted to save it.
• The browser history will not reflect this distinct station in their
  history, because (whether the mirador instance is running from within an
  embedded instance, or has "taken over" the page) it is still running from
  within the same page. Perhaps push state should be implemented to rectify
  this situation. However, it would require saving a lot more states than
  before (which may not be a problem considering the configuration object is
  rather small). This may require a new pushState event for every time they
  add in new manifests to the existing session, presuming we make dynamic
  loading of manifests possible.

Having noted these things, it may help to remind oneself of the basic
requirements.
Basic Requirements

• Reloading should not lose the present state of the user's session.
• Going back in history should not cause the user to lose work.
• The user should be able to easily export their session, perhaps with
  a method to send data to a database.
• Ability to dynamically add a manifest from a URL or the desktop, or
  the exterior search environment.

Nice to Haves

• Perhaps someday, there should be a way (webRTC?) to allow multiple
  people to change things in the same session (Multiplayer).
• Autosaving to the user's actual filesystem would be good at some
  point (on supported browsers.

In general, the redesign needs to address the realities of existing in a
somewhat unpredictable host environment and adapting accordingly, with
instance-level state saving and intelligently allowing the user to escape.
What follows is an outline of some of these issues.
Integration/Environment Concerns MOOCS Individual Scholars University
Courses Embedded Discovery/Display Viewer

Reply to this email directly or view it on GitHubhttps://github.com/ProjectMirador/mirador/issues/129
.