You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we load asynchronously and don't sort unless configured to load in the order they are provided to Mirador. Also, the last opened sort could be problematic because where is this information stored? This feels like a specific use case if Mirador is part of a larger application with a database that powers it and not part of the core Mirador
The text was updated successfully, but these errors were encountered:
Currently we load asynchronously and don't sort unless configured to load in the order they are provided to Mirador.
It might require some additional programming to explicitly manage the display order of the manifests in the catalog but shouldn't we be able to consistently display manifests in the order they are listed in the catalog source, rather than just in the order they load? In other words, if the catalog source lists manifests A, B, and C in that order, couldn't we ensure that the catalog shows card A first, card B next, and card C third, even if manifest C loaded first? This seems important also because we'd like to give the user an indication of the loading state of manifests in the catalog; if manifest B is not loading (source server is down, for example), rather than not showing it, we'd rather show card B and provide some indication of its non-loaded state. This will address confusion we've heard about people not knowing why a given manifest doesn't always show up in the same catalog at different times (when the source server is not available, for example).
Also, the last opened sort could be problematic because where is this information stored?
Couldn't we store it in the client browser (e.g., local storage)? Even if this is not guaranteed to persist as it would if we had a non-local database for storage, it would probably be sufficient?
Currently we load asynchronously and don't sort unless configured to load in the order they are provided to Mirador. Also, the last opened sort could be problematic because where is this information stored? This feels like a specific use case if Mirador is part of a larger application with a database that powers it and not part of the core Mirador
The text was updated successfully, but these errors were encountered: