Series with arrows and series without arrows

Skip to first unread message

Feb 22, 2024, 8:30:51 AMFeb 22

Dear colleagues,


I hope this finds you well!


I would like to ask you why, in the AtoM collection hierarchies, some descriptions of the same level appear with arrows and others without. Please have a look below.



Bbest regards,




Maria Papanikolaou

Archives and Records Manager

EMBL Archives and Records Management,

Office for Scientific Information Management (OSIM),


European Molecular Biology Laboratory
Meyerhofstraße 1
69117 Heidelberg Germany
+49 (0)6221 387-8719



Dan Gillean

Feb 22, 2024, 8:57:29 AMFeb 22
Hi Maria, 

Short answer: it means there are lower level descriptions available beneath that record. 

Full answer
AtoM has two different treeviews - the sidebar treeview, which is shown in your screenshots, is more condensed, does not show all records at once, and lives in the left-hand sidebar (or "context menu) of an archival description view page. 

The other option is the full-width treeview, which will show all records in an archival unit's hierarchy at once, and is displayed in the central body of the archival description view page, just below the description title. Here is an example of this version, from our documentation: 

You can read more about the two different treeview types and how to change which is used in your application in the Settings documentation, here: 

As for your question: 

I would like to ask you why, in the AtoM collection hierarchies, some descriptions of the same level appear with arrows and others without.

The caret icon (or "arrow") indidates that there are lower level descriptions available below the current selection, i.e. child records - for example, it might indicate that the current series description has item-level descriptions available below it.  When displayed to the side like this: > it means you can click on that caret icon to show the initial child records nested below the selection. When displayed vertically like a V, it means the caret has already been expanded and is displaying the first of the immediate children available below. 

For example: 

In your screenshot, the Fonds is selected. The fonds is already "opened" and is displaying the Series-level records below it - or at least the first 5 series, after which we are given the option to show 3 more if clicking the link at the bottom. 

I can also tell from this screenshot that Series A and B have no child records currently (such as files or items) - or at least, none that are accessible to the current user. It could be that there are draft lower-level descriptions and the screenshot was taken by a public user, but from this perspective, nothing further is available. 

Meanwhile, Series C, D, and E do have their own lower-level records available. You can click on the > caret to shift the tree, and see the first of these descendants. 

As to why it operates this way?

This is a longer story. The sidebar treeview has a long and varied history in AtoM, and was frequently changed early on based on feedback. In early (ICA-AtoM 1.x) versions, each lower-level would be indented to better represent the hierarchy, like so: 

However, for deep hierarchies (for example, Fonds > Subfonds > Series > Subseries > Sub-subseries > File > Item; etc), the treeview would get so narrow, it would be unusable. 

Additionally, the tree would regularly freeze and break for larger hierarchies, as it was very resource-intensive to represent the whole thing at a time when (ICA-)AtoM was still new and its primary user target was small-to-medium archives with modest collections. 

Several different iterations were tried across subsequent versions, but users were generally not happy. In version 1.3, to deal with the performance issues as well as the lack of visible real-estate in lower levels, we introduced the first version of the current sidebar treeview. In this version, all records are NOT shown at once. Instead, only a subset of records is ever shown, with a  "X more" button provided to further expand the tree. When users click on a specific level of description with descendants, other levels are  "closed" to give as much viewing room to the selected level as possible. 

In the end, users didn't like this option either, and wanted something radically different. However, people were divided as to the best solution, and Artefactual would require sponsorship to be able to implement any of the proposed solutions. 

In the end, I collated a list of all the suggestions and feedback we had recieved, designed a couple different possible solutions for each issue, and had the developers provide estimates for implementing these changes. We then made a wiki page on the original qubit developers wiki (a separate, now-defunct wiki where we kept development documentation), and made it public. Any additional users asking for treeview changes were directed to that page. 

Once 2.x was released, the World Bank Group Archives contacted us to say they wanted to use AtoM, and would sponsor one of the options - the addition of a full-page treeview option. This is where the origins of our second (and now much more popular) treeview came from. 

The main information from the original wiki page was migrated and preserved on our new wiki - if you are interested, you can see it here: 


Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
he / him

You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Feb 23, 2024, 8:43:59 AMFeb 23

Thank you Dan for your immediate response and assistance!


Best regards,



Reply all
Reply to author
0 new messages