Pre-Release of musdb’s New UI

For the last months, a new, fully reworked user interface for musdb has been in the works. Two previous blog posts discussed the reasons and the scope of the overhaul (1, 2). The latter of these also came with our target timeline for the release. Which is to say: It is time for the first pre-release.

Starting tonight, an overlay will appear, guiding users of musdb to try out the new UI. Which begs the question: Is the new UI ready for general use. Realistically there can be no general answer to that question. We have tried to prioritize the development of commonly used functionalities, while many less commonly used sections of musdb are still entirely missing in the new UI. Before a (nearly) comprehensive list and categorization of the features that are thus far missing in the new UI is presented, let’s look at a few key new features and benefits of the new UI.

New Architecture, New Possibilities

As has been outlined in the previous blog posts multiple times, the most challenging and yet basic aspect of musdb’s UI rewrite is the move to a different architectural approach. In the old UI, each page is its own script, with all these scripts using the same functions in the background. Opening a page – or e.g. saving a form – thus requires a full page reload, including a reload of all the data that remains unchanged. On the face of it, this sounds inefficient in terms of performance and bandwidth use. It is. It is also noticable in immediately perceivable characteristics like the view jumping back to the top of the page when a form is submitted.

Refactoring musdb’s backend code to a more reusable, testable and logical structure is an endeavour that has been ongoing for over half a decade now. The occassional references to musdb’s growing API in the blog were the immediate benefits of it – functions that were used to provide the regular, human-readable user interface were also made available for machine-to-machine communications.

The new UI is then the result of the final completion of that refactoring: It is a Typescript application built entirely on top of musdb’s API. On the one hand, this means that potentially any action that users can perform using musdb’s graphical UI will also be available for automated use using the API. On the other hand, it simplifies things in development: As we are ourselves using the API everywhere, good maintenance is simplfied a lot (see also).

Given this new architecture, the user interface is entirely processed in the browser. If forms are submitted, only the changed values are transmitted to the server. The required bandwidth is thus reduced greatly, once the application has loaded. Similarly, navigating only reloads those sections of a page that actually change, reducing computing load for server and client alike (and thus increasing performance).

Automation via Webhooks

Only possible due to the new architecture has been the addition of a webhook system in musdb, which offers a simple way to react to updates in musdb in an automatic way. Webhooks can be configured in the institution-level settings pages of the new UI. Note that, as the webhook system requires the use of the new architecture, webhooks configured in the new UI will not take effect when one continues to work in the old one (while both are available). See also: Wikipedia on webhooks.

Design Overhaul

Doing a re-design from the ground up naturally allows for the creation of a much more streamlined user interface. Going by the (albeit limited) feedback we have thus far received on the new UI, we have indeed succeeded in creating one. Similar functionalities that were spread over different sections of a page or different pages altogether have been moved into the same section of a page; redundant or confusing options have been removed. Where things could remain as before – as even the old design received its fair share of praise despite its shortcomings – they remain roughly the same.

The previous blog posts have already provided some in-depth glances into the new UI. Importantly for this post, the design overhaul will include the removal of some redundant, badly thought-out or effectively counter-productive funtcionalities.

List of Features Not Yet Implemented

In the following, a simple list – in some cases with further remarks – of the features the old UI offered, that are not or not yet implemented in the new UI will follow. If some feature is not to be found in the list, it is most likely already implemented.

Features That Will Certainly Be Implemented, But Are Not Yet

Whole Pages

• The general search page for object images has not been implemented yet
• Visitor counting

Navigation

• Notification system

Misc Tools

There can be accessed in the old UI using the “Tools” subsection of the dashboard or the similarly named “Tools” submenu of the navigation.

• QR-code generator
• Calendar
• Process list
• To-Do list
• Knowledge management / mini-wiki
• Hyperlink checker
• URL Shortening
• Consistency checks for migrating data from free text fields to controlled ones

Features Available in Multiple Sections of musdb

• Notes (for any page)
• Nextcloud integration
• UI for users with less permissions
  The UI should hide submission buttons etc. where a user has no permissions to perform the relevant action. This is by far only implemented in very few cases (while permissions are enforced in the backend).

Object Pages

• Overview pages
  • Sorting menu
  • Watch list
  • List view / editing most fields in a tabular view
• Sidebar
  • Warning if an object is currently reserved
  • Object record editing status (e.g. open, locked, archived)
  • Export settings for XML exports; quick exports work
  • Improvement suggestions
• Basic data tab
  • Editing translations
  • Tag suggestions based on the object image
  • Tag suggestions based on the object description
  • Ability to add sources / citations for events
• Addendum tab
  • Data field-specific setting for publication status
• Administration tab
  • Deaccession (administration tab)
• Location tab
  • Links to loan management
• Most of the restoration / conservation tab
• Data history tab
  • Versioning UI
• Custom / user-defined object editing interace
• Comparing objects

Institution pages

• Institution editing page
  • Tab for self-categorization of institutions / survey
• Institution-level settings
  • Configuration of scheduled, automatic generation of exports

Collection pages

• Hierarchy & sorting
• Editing page
• Tagging for collections

Series

• Series editing pages
  • Hierarchy
  • Sorting objects of the series
  • Sidebar
    • Setting for visibility of the series on the public institution page
    • Option to group related vocabulary entries for revision in nodac

User Settings

• Editing pages for other users
  • Configuration of user permissions
• Own account settings
  • Export of own account data
  • WebDAV settings (for preparing independently run data imports)
  • Notification settings

Contacts / Address Book

• Contact editing pages
  • vCard export
  • List of linked literature entries (to be implemented on the literature search page)

Spaces

• Hierarchy
• Editing pages
  • Sensor data display

Exhibitions

• Editing pages
  • Tab for publications linked to the exhibition

Vocabularies / Backgrounds

• Unreleased catalogue raisonne feature
• Statements

Features That Are Implemented But Certainly Need to Get Better

• Object editing page
  • Linking recently linked entities on base tab

Features That Will Be Removed

• General page features
  • Bookmarks
    Browsers are much better at bookmarking than musdb. And musdb runs in a browser anyway.
• Object page
  • Tab: Provenance research
    Feedback from provenance researchers (and common sense and experience) informed us that the current implementation is altogether ill-conceived. A whole separate, general section of musdb for managing research projects might eventually be added to actually do what we aimed to do here.
  • Entering free text data from an appropriate prepared QR-code
  • “Ask an expert” tool
• Article section (never really used)
• Podcasting features (never published)
• Series page
  • Offline HTML catalogue
    This solution has not been properly maintained in a decade. With a generally wider availability of internet connections, API-based solutions are also much more flexible.
  • Configuration for display modes of published series pages
• Chat
• Setting for the start page of a user upon logging in
  The primary and most reliable means by which we can communicate updates to musdb (and other museum-digital tools) is the blog, whose feed is embedded into the dashboard. Making sure that everybody occassionally visits the dashboard thus also means that the likelihood that users know about updates is increased. On the other hand understanding users’ bug reports regarding login and startup is simplified if there is a more unified workflow around logging in.

Features to be Discussed

• Object page
  • Social media buttons setting. With the selection of available social media buttons and current usage trends, it might be wiser to simply scrap the option.

What Does That Mean For the Roadmap?

As one can quite easily see, a lot is left to be done. But the bulk of the work has been done and we are perfectly on schedule. For anybody who relies on the features that are still missing, the old version will remain available until around November 22. For the majority of users, the current state of musdb should actually already support most or all of their requirements better than the old UI.

Until November 22 both versions are available for users to slowly transition over to the new version. We are curious for feedback and continuously push new updates to the new version.

(Post image generated using Anima Base v1)