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)

This content is licensed under a Creative Commons Attribution 4.0 International license.

Recap: Scope and Reasons of the Rewrite

musdb as a tool has been around since sometime around 2009 or 2010 – soon after the wider inception of museum-digital. Back then, its scope was to provide an input interface for the recording of publishable museum object data. Since then, the basic architecture to the user interface has remained largely unchanged. While the scope grew to musdb aiming to be a full-featured collection and museum management system, many features that were added were only added “on top” – far enough out of the way to not disturb legacy users or to break existing workflows. In a nutshell: musdb in its current form is quite good, but it’s an application whose user interface has grown without a clear roadmap and a systematic reconsideration and streamlining of the user interface for over a decade.

Since 2009, web development has changed. We do not need to worry about the Internet Explorer anymore, browser compatibility is much better, and web applications can be much more interactive with modern browsers and hardware. To fully make use of these larger advances in the development of musdb, a general change to its architecture is necessary however.

As the architecture changes from a traditional web site with many independent pages to a single page application, the rewrite is indeed that: Instead of generating pages on the server and only displaying them in the browser, musdb’s user interface will be fully generated in the browser, with only the relevant data being queried from the server using dedicated, documented APIs. Even to keep the same functionality, we would need to re-implement its presentation. This means that the rewrite is also a perfect opportunity to streamline the user interface and to reconsider previously unused or overseen functionalities.

On the other hand: With the new user interface changing everything display-related on a technical level, that does not mean that much has to change on a conceptual level. The rewritten musdb will feature the same basic division of pages – lists, editing pages, and pages for adding new entries -, it features the same idea of a tabbed editing pages and – with few exceptions – the same data fields and order thereof.

A Sneak Preview

Where much stays the same, taking a small glimpse into things that will change might be in order. In the following there are a few such previews with small screen casts. Most of these focus on overview / list pages, which are already in a release-ready form.

Navigation

New Filter Options

Display Modes of Overview Pages

Batch Editing On All Overview Pages

Interactive Overviews

Timeline

Now, when will the new UI be done? And when will it be released?

As of now, the development is progressing smoothly and the required building blocks for almost all functionalities are there. Depending on what features one uses, the new UI can already replace the old for most common use cases. To fully do so for common use cases means that at least object editing pages need to be implemented fully. This should be the case as of late September. In the following, seminars and a time period where both versions can be used side-by-side will be had to ensure a somewhat smooth transition from the old to the new UI.

This content is licensed under a Creative Commons Attribution 4.0 International license.

(Post image generated using Anima Base v1)

Over all that time however, the basic architecture of musdb remained basically unchanged, with new functionality fit in or added on top where it seemed suitable. Additionally we have been struggling with the duplicate implementation of several functionalities at different times, where one implementation offers a very simple access to the respective data (e.g. a free text field), while the other offers a representation of the same data in a much more fine-grained, precise, and more interlinked way, whose requirements are however harder to fulfill during imports and that requires a more thorough documentation generally.

We routinely get very positive feedback from colleagues working in museums, that musdb is comparatively easy to use and logical. The age of the architecture as well as the many small inconsistencies in terms of the user interface that have crept in over time however suggest that it is time for a more radical reimagining of what musdb looks and works like.

This post is a first small preview to what musdb should look like starting in the third quarter of 2026. After a more thorough discussion of the reasons for rewriting significant parts of the publications, some first glimpses into the new version are provided at the end of this post.

Reasons

Technical

musdb is primarily a PHP application. As such, the internal logic as well as most of the user interface rest on the server. Almost all of the user interface is rendered into HTML on the server and then sent to the browser to generate what a user can view. Some functionalities that require additional interactivity, are presented in overlays, etc. are implemented in JavaScript and processed directly in the browser, with the JavaScript drawing its data both from the HTML as well as APIs (some internal, some documented for internal and external use).

Speaking in modern web development terms, PHP covers model, view, and controller on the server, with JavaScript extending the view somewhere half-way. Logically, this is problematic. In brutal practicality, it means that musdb’s JavaScript components are a collection of small scripts always dependent of some external (PHP/server-side) preparation and not logically interacting with each other. This prevents lots of the benefits of a more structured programming from being used altogether.

Our aim with the technical architecture of a reimagined musdb is to design musdb as a modern single page application with all data being provided by clearly documented APIs. This will come with several benefits:

• The view layer is entirely processed entirely in the client, providing a clear logical division between the different tasks
• With a modern build infrastructure, code can be reused much more than thus far, providing a better maintainability in the long run
• musdb will come with barely any browser-level page reloads. If an API is queried, the application can clearly communicate what is being loaded and for what purpose.
• As musdb’s UI will be entirely built based on the same API as can be used by external developers, that API will be fully feature-complete by the end of the process.

User interface

The general structure of musdb’s user interface has proven itself to be quite good. However, as musdb has grown over the years, a lot of small inconsistencies and opportunities for improvement have crept in.

Take the navigation alone:

• To access object groups, one can always hover over the three dots sub-menu of the navigation section on the very top right. If one enables the menu option “object group” in the personal settings (accessible by clicking on one’s name), one can also quickly access it via the quick access navigation (the second line of the navigation). As such, simply accessing a central part of musdb is spread over three different sections of the navigation.
• There are two question mark icons in the navigation. One, in a speech bubble, links to communication channels and contact persons that one can use to seek help. The other provides links to the handbook. On the one hand, there is a clear logical differentiation between the two. On the other, both look similar and follow rather similar aims. That the two sub-menus are divided rather than being merged into a single sub-menu is not intuitively apparent.
• Clicking on the page title or the colored circle at the right of the navigation opens the context-independent search function. Both bear no resemblance to an icon associated with searching and actually follow entirely different primary aims by themselves.

Many similar issues exist around musdb. In most cases, these somehow make sense and are logical in themselves – but they still contradict a seamless, intuitive use of the application.

Additionally, there are some functionalities that in themselves contradict a more streamlined use of musdb. One such example also accessible via the navigation is the option for users to set their preferred page to be referred to right after they log in. musdb has been built more and more on the premise, that users will start their use of the application on the dashboard, and thus some features – like requiring users to enable two-factor authentication for regional administrators – can be bypassed by selecting any non-dashboard start page. The option to select a non-standard start page will hence almost certainly be scrapped in the new version of musdb.

Preview

For now, only the basic scaffolding, most of the navigation and some of the overview pages have been implemented in the new version. Screenshots of these can be seen below. Importantly and yet missing, each different section of musdb is planned to come with an icon representing it in the navigation (top left).

Note also, that nothing about the new UI is set in stone. These are first drafts. More will follow soon.

musdb

Object overview

In the default tile view of the object overview page, hovering over an object image thus far revealed the object’s name. As object names are often too long to display fully and inventory numbers are the primary means of identifying an object in most museums, this preview text has now been extended to include the inventory numer.

User management

New Options for Managing User Accounts: Disabling Accounts & Setting Account Expiry Dates

Two new options on user editing pages allow disabling logins on an account and setting an expiry date for the account. Both can be useful for administration: If a new worker joins the museum for a project with a clear-cut limitation on funding and time, one can now set the account expiry at the beginning of the project to the end of it. The accounts will then automatically be deleted when the project ends. Similarly, colleagues that leave service temporarily but for a prolonged time (e.g. for a sabbatical) and will not need to use their accounts for that time can have their accounts disabled.

List of Terms of Use

A new tab on a user’s (own) account settings page provides the option to list all usage agreements / terms of use a user has agreed to in the context of their use of museum-digital / musdb and when they agreed to them.

Imports

Limiting Report Mail Size

When a user runs imports themselves using the WebDAV upload, the end of the import process – no matter if it is successful or fails – is marked by the sending of a report via mail. This report usually contains a list of noteworthy operations that happened during the import, e.g. which objects of which inventory number were imported to which object in musdb, identified by its ID. As imports grow, this list of operation grows. To not encounter issues sending the report, it is henceforth limited to a maximum of 2 MB or 10000 lines.

Dry-run Mode

Sometimes it is useful to try running an import to see if it will actually work but not actually process any data. This option has been available in the importer command line interface for a while, among others powering museum-digital:qa. It is now available in the import configuration for self-run imports as well using the setting dry-run. Enabling the setting accordingly stops the importer from actually writing the data into the database and changes the behavior if values that need to be mapped to values in controlled lists at museum-digital are encountered. Usually an import stops the moment such data is to be imported and not yet mapped. During a dry run, the error is collected and the import proceeds. All unmapped entries are listed together at the end of the import, allowing for a simpler mapping (possibly aided by concordance.museum-digital.org).

Dashboard

The first page of the dashboard, which for almost all users also means the start page of musdb right after the login process, was significantly reworked during the last month. The almost entirely unused notetaking features and discourse integration were removed in favor of a feed of recent blog posts. See also the section “Communications” in the respective blog post.

Annotations for the Vocabulary Editing Team

Each event, displayed as a tile on object editing pages, featured speech bubble icons behind each time / actor / place to provide additional comments and hints for the central vocabulary editing team. This positioning of the annotation feature led to confusion over the years, with some users using the feature to comment on the relationship between the entity and the object (for which the event notes should be used). We hence repositioned the links and moved them to the respective entity’s page (e.g. a place page for giving hints and comments on a place entry). The hinting / commenting feature for times has been altogether removed, as providing comments to clarify the meaning of e.g. a year never made much sense.

Smaller Updates and Bugfixes

• Fixed a bug in the HTML generated for listing other objects linked to an object. Links to the other object were broken and are not anymore.
• Image editing pages now embed the image directly instead of using the IIIF API. This reduces resource usage and increases stability at no cost.
• Removed option to manually trigger the rewriting of EXIF and IPTC metadata of object images. Rewriting takes place in the background whenever an image or a linked object is updated, making user-triggered updates obsolete.
• Re-introduce option to repeat linking to the last used linked object
• Updated Swagger UI to version 5.30.3

Frontend

As stated above and lengthily described in the previous blog posts (here, here, and here) we struggled with stability over the last month. This means that most changes in the frontend are aimed at improving stability.

Reworked Default Image Page

Thoroughly described in Updates, AI scrapers, and Resilience, we replaced the default view for single object image pages. While the default view was previously built around the IIIF viewer Mirador, the new default view uses OpenLayers and the unmediated image file for capabilities such as zooming. The new view also brings with it some new features, such as an option to reference specific sections of an image.

Serving Resource-Intensive Pages / Functionalities Only When Resources Are Available

PDF generation, the IIIF Image API, and the suggestions for alternative search queries on failed search pages are now limited to reduce their impact on the overall system stability. This follows two strategies:

• Suggestions on failed search pages and PDF generation will only appear if the overall load on the system is low. The threshold for when or when they are not provided is influenced by the user’s browser language: If a user uses a browser set to the primary language of a given instance of museum-digital (e.g. German in Hesse, Hungarian in Budapest), the threshold is much higher, meaning users will be able to access the pages at a medium server load. In the case of PDFs, high server load will forward users to the print dialogue for object pages instead of receiving a PDF generated on the server side.
• PDF generation and the IIIF Image API are served with a different PHP configuration and set of processes than the rest of the frontend. This configuration significantly reduces available resources for these two functionalities.
• The option to generate PDFs featuring all images of an object with between 10 and 40 images has been entirely removed. Given its constraints, the feature was hard to explain and rarely accessible anyway. The primary “users” were noticeably AI scrapers.

Image Search

The image search feature was refactored and reduced to further separate it from the primary object search. The number of available search options has been reduced to be more easily explainable and reduce possibilities for very resource-intensive queries.

Batch Export of Object Metadata / OAI

Updated the LIDO API to almost entirely match the LIDO as generated during exports from musdb

Smaller Updates and Bugfixes

• Improved performance of object search by tags and places by filtering searched entities to those who are actually linked in the given instance of museum-digital.
• Object groups with only one object are henceforth not displayed and linked on object pages anymore
• Fixed link in footer: Clicking on “museum-digital” should lead to the home / start page of the given instance of musdb.
• Updated Swagger UI to version 5.30.3

nodac

• User-provided comments / hints have been removed for times (see above)
• Tooltips for linked objects now display which institution an object belongs to
  • This is particularly important for vocabulary editors who do not have access to the museums’ data. This way they get a limited preview with the required information for unpublished objects despite their otherwise lacking permissions.

This content is licensed under a Creative Commons Attribution 4.0 International license.

Frontend

• Significantly reworked the display of transcriptions on object pages
  • Titles of transcriptions are now displayed
    • If none is set, the type of the transcription (original or translation) is used as a replacement
  • Transcriptions are sorted by their titles
  • Improved the display of transcriptions in tiles
    • Problems with vertical scrolling are now solved
    • If only one transcription has been recorded, it will be displayed on the full width of the page
    • If there are more than two transcriptions for an object, they are folded in by default and can be unfolded later on
• Batch export of object metadata via the API
  • Thus far available in JSON & LIDO
  • API documentation
  • See also
• Dots as a separator in floating point numbers for object measurements are replaced with a comma in languages that require that
• Collection-specific ISIL IDs are used in the LIDO API

musdb

• Added a field for recording titles / names of transcriptions
• Added the option to set collection-specific ISIL IDs
• Setting object type tags via the improvement suggestions now correctly classifies the thus created link between object and tag
• Additional shapes are now available
  • E.g.: round, square
• Object groups can now be filtered by whether they have a superordinate one or not

Dissemination

• 2025-10-08: Presentation at the Autumn Conference of the Working Group Documentation of the German Museum Association: “Interoperabilität schaffen – Geschichten aus 1001 Importen”
  • PDF
  • ODP
• 2025-10-14: Talk on a workshop of the project CiVers (Citation of Versioned Web Pages by PID)
  • PDF
  • ODP
• 2025-10-17: museum-digital Usertagung 2025

This content is licensed under a Creative Commons Attribution 4.0 International license.

New Developments

The last month has been an exceptionally slow month in terms of technical development around museum-digital. There are however some newsworthy tidbits.

musdb

Recording external IDs for museums

Museums, like all of us, are present in more and more databases. For linking different databases, it is useful – sometimes necessary – to know the ID of the same entity in both databases. Hungarian law thus mandates collection management systems, which are to be accredited for fully paperless use in museums, to allow storing a museum’s ID with the Hungarian Statistical Office. musdb can now do exactly that: Store external IDs of museums in a given list of external source repositories / databases.

The list of available external databases and the regular expressions to validate IDs in them are available here. For now, the list only contains the Hungarian Statistical Office, but the more options there will be in the future, the better.

More fields covered by “list results” and Excel export

The “list results” page (a.k.a. table view) for object search results offers the option to view the selected objects’ data in a customizable tabular format. Mainly because of that exact tabular format, it is not possible to display everything a full database view of the object offers using the “list results” page. Over the last month, we have nevertheless extended the list of displayable fields in the “list results” table.

Thus, it is now possible to display all translations for the object type, object name, descriptions, etc. of an object. Similarly, it is now possible to list all Weblinks linked to the object as a compiled (comma-separated) field. As the automated report generation and the Excel export tools build upon the same basic code as the “list results” page, these new fields are now also available in those cases.

New field for objects: “Last change of permanent location”

It is now possible to manually record the last date, the permanent location of a given object has been updated. This obviously makes sense for tracking relocations and re-organizations within the museum. Importantly, the field needs to be manually filled out, as the date of the last change of the permanent location may be far in the past or frankly unrelated to the database, even if there is one (say, the museum moves the depot to a different place, but the date is only later updated in the database via a batch editing process).

User interface

After there were some reports of people not seeing the difference between a valid form in musdb and an invalid / incomplete one, we updated the design of submit buttons. Submit buttons in incomplete forms are now blurred out, to add another hint at the incompleteness of the form.

Frontend

Improved performance and decreased bandwidth usage: serving images in webp

Over the last years, there have been a number of new image formats seeking to combine all the features of older and well-established formats like JPG and PNG with an improved compression. The most established format of that newer generation of image formats is webp, which is by now well-supported by all modern browsers and most local image viewers.

To save bandwidth and improve loading speed, we now store and serve full-sized webp versions of newly uploaded object images along with the regular jpg versions. If possible, the webp version is served on object pages. An additional benefit is the aforementioned support for features jpg files do not support, such as transparent image backgrounds.

iFrame embedding now only possible from whitelisted sources

If a museum wants to embed their data from museum-digital into their own website, there are traditionally two ways to do so. The better, but much more complicated option is to use the API to fetch the relevant data and present them in any way one wants. Much easier (and cheaper obviously) is embedding the museum’s data using iframes.

Unfortunately, iframes can also be used for attacks on users’ login data. We have thus now restricted this option to only allow embedding from whitelisted sources. If a museum wants to embed their data this way, this means that they now need to notify their regional administrators beforehand.

Importer

The importer now supports imports for exports from Startext’s HiDa in the configuration of the Saxon State Agency for Museums.

Other News

In other news, the Youtube channel has picked up steam, with some new tutorials both in German and Ukrainian.

General

YouTube channel

There now is a museum-digital YouTube channel. For now, one can find some German-language screencasts on different features in musdb and nodac there.

New sections on project page (www.museum-digital.org)

As already described in the previous post, the project page www.museum-digital.org now features a calendar. Since then, we have also added a small page listing people working on museum-digital – e.g. some of the coordinators and developers – as well as power users. The list will obviously always be more than incomplete, but if you want to be listed, just send a mail.

Development

musdb

Allow batch editing of photographers on image list

Running batch updates on the ownership, license status and photographer of a set of objects can be done either via the institution-wide settings page or via a selection on the image list page. The batch updating functionality of the institution-wide settings page works by replacing the given entries in one of the fields for all objects of the museum – it is thus not suitable if one is to only update the photographer field for a list of objects from a single collection (rather than the whole museum).

Batch updating images’ legal information from the image list (click on an image in the list and drag it to activate selection mode, then update by selection) was only possible in the case of image licenses and rights holders. With a small update, it is now possible to also batch-update the images’ photographers field that way.

The API can now update object event

Thus far, the API could only be used for adding wholly new object events (who did what, when, and where, with the object) or deleting them. With the updates of this month, now possible to directly update events.

This is already actively used in customizing musdb using a Tampermonkey script by some of the norm data editors. They can thus add a custom button to transfer incomplete actor or place information to the object’s description. This button, on the other hand, would not be useful for regular users at all.

UI improvements for the object search interface and new sort option

After a very fruitful discussion and feedback from Hungarian colleagues, we got around to some user interface improvements in the object overview and search interface. A lengthy discussion can be found in a dedicated blog post in German. To sum up: there are now headlines for each subsection of the sidebar and tooltips explain the different buttons and search and sort options upon hovering one’s mouse over them. Additionally, a new sort option was added to sort objects by the number characters within the inventory numbers of the searched objects.

Two bugfixes: Navigating to the previous or next object in a selection

It is a very simple but similarly useful feature: One runs an object search and thus creates a result list of objects. After viewing or editing one of the objects, one can then proceed to the next one in the results list by clicking at the arrows at the top of the sidebar.

Unfortunately, musdb had two bugs preventing this navigation for some of the available sort options. On the one hand, newer sort options required manually adding the search fields to a list specific to the previous/next navigation thus far – and had not been covered yet. Navigating to the next object after sorting by e.g. the length of the searched objects was thus impossible so far. The specific list of sort fields has now been removed in the previous/next navigation. Instead, the main list of sort options from the main object search class is directly used – in effect preventing such issues of “forgotten” values from ever appearing again.

A second issue concerned string-based sort options. For an improved performance, the previous / next navigation works by querying the underlying search index for the next object where e.g. the object ID is lower than the current one (`WHERE id > 20000`). The same search logic is straight-out not possible with string-based sort options, as search queries for values greater than or smaller than a given one cannot be executed with string-based fields.

Fortunately, the issue came up just after we had implemented an option to search and sort objects by the numeric components of their inventory numbers. Thus, the previous / next navigation can fall back to that sort option if a user wants to navigate to the next object after sorting by inventory number. As stated back when we introduced the new search and sort option: It should work for most museums. Unfortunately, there is no such option to mitigate the issues of string-based sorting when sorting objects by their names. The best we could do in this case is displaying a clear error message, stating that the previous / next navigation is not available when sorting by the object’s names.

“Home location” can now be selected as a required field when adding new objects

On the institution-wide settings page, museum directors (or those holding the same user role within musdb) can determine which fields are required when adding new objects. The list of selectable fields automatically covers all free text fields linked to the object. Repeat fields and references to other sections of musdb need to be manually implemented however. As the home or permanent location of an object is a most logical and common field to be required for all object, it was only consequential to prioritize making it available as a required field. We have done so now.

Major performance improvements in “list results” page

The “list results” page provides for a table view of object search results, allows the export of search results to Excel, and is – under the hood – also used for generating custom reports. We managed to achieve a considerable improvement in the page’s performance by bulk loading data and simplifying the code of the HTML page. Both adjustments should not really be noticable when one tries to list or export only some objects. Exporting some thousand objects should work considerably faster now however.

frontend

PDF metadata for main object PDF export

XMP metadata are now written into exported PDF files. Thus, users can more easily identify authorship, titles etc., especially when using specialized software like e-book readers.

Linking from collection descriptions

Collection descriptions are now being parsed for the existence of URLs. If one, starting with https:// (http:// is ignored) exists, the URL is automatically transformed into a clickable link.

nodac

We added some translation variables on the start page.

themator

The “themator” has received a small user interface improvement for mobile devices. The topic-specific navigation or table of contents is now moved below rather than above the main content of a page in the regular “topic” viewing mode on mobile devices.

Importer

Importing GIFs

To simplify the handling of images, museum-digital internally only uses JPG image files (webp versions are generated for a faster loading, but are optional). While they lack some support for features like transparency, JPGs provide for a much better compression with images of three-dimensional things and subjects not featuring solid colors. Newer formats like AVIF and Webp unfortunately still lack the support among locally installed image viewers for us to fully switch over to them.

The importer handles input PNGs by converting them to JPG files. Starting this month, the same can be done with input GIF files.

Improved handling of blacklisted actors, places and times

One of the key issues with imports is what happens after imports. Specifically, museum-digital uses controlled vocabularies for actors, places, times and tags that can be linked to an object directly or via events. When people enter new such entries using musdb, there are a number of safeguards and nudges to ensure productive inputs. Adding a new actor, for example, requires one to enter at least 10 characters of a description for the actor. Input fields for the date of birth and death are also provided. If possible, one can enter a Wikipedia or Wikidata URL (or ID) and directly fetch the relevant information from there.

During imports, there is no space for asking questions to the importing institution. Incomplete or false actor, place, time and tag names (for example, if two actors are linked as one; “John Doe and Jane Doe” is not one single actor!) are given, these are necessarily imported into our controlled vocabularies by default. Depending on the import, this puts a significant burden on our volunteer group of vocabulary editors.

To eventually get to a solution, we have added options for automatically rewriting terms (e.g. “Berlin, Germany” will be autocorrected to “Berlin”) and blacklisting them completely (“Good morning …” is no actor”). Thus far, blacklisted terms were simply ignored by the importer.

“Unknown painter” is not an actor, but the information that it is a painter may still be useful. To allow us to blacklist more and keep the controlled vocabularies “clean” without losing such data, the importer now imports blacklisted terms in event components (“who painted it?”) into the event annotation. If the only known information on the whole event is blacklisted, the event cannot be created – an event always requires at least one linked actor, place or time. The event annotation of “empty events” is hence moved to the object description automatically.

This content is licensed under a Creative Commons Attribution 4.0 International license.

• A pixel (px) is – in theory – fixed to the single dot of a screen. It thus depends on the resolution of the screen primarily, at least in grey theory.
• A point (pt) is a single point on a printed sheet of paper. Its roots lie in the DPI setting of the print job.
• em are relative to the font size. If nested elements come with font sizes determined in em, the scaling is appropriate nested (a headline in a generally enlarged section will be further enlarged than a headline in a regular section).
• rem is relative to the primary font size of the document.
• vh and vw are relative to the total screen height and width respectively. 10vw are, e.g., 10 percent of the total width of the screen.
• Some others, like cm or mm exist, but are less used – especially when working outside of print contexts.

Being relative to the font size and nest-able, em values are a great fit for setting sizes of page elements and we thus use almost exclusively use em and rem values for borders, font size, etc.

To make a website responsive, CSS offers a functionality called media queries, with which one can check for characteristics of the browser window. This, obviously, concerns primarily the size of the window, but can also extend to issues such as the activation of a dark mode (if you see this page with white text on a black background, that is the consequence of a media query).

Now, we had also been using em values for probing screen properties using media queries, and the results were far from ideal. Especially phones from different manufacturers provide very different em values even at roughly similarly sized screens. Thus, it becomes hard to determine, if a user really is using a phone, a tablet, or a full sized PC.

Ironically, it is exactly pixel values, that work much more reliably. In theory, a media query asking if a screen is less than 768 pixel wide should definitely be answered negatively in the case of a current flagship phone with roughly 1400 pixel width. In reality, browsers scale down the page and will answer positively, accepting that phones should be presented to CSS as less than 768px wide.

We have now switched to using pixel values for running the media queries to determine the target page layout. And the results are much better, than when we used em values.

See also

W3C: Web Style Sheets – CSS Tips & Tricks: em, px, pt, cm, in…

This content is licensed under a Creative Commons Attribution 4.0 International license.