Some thoughts after our user testing

[Jenny Mitcham]

Hi,

We have carried out some basic user testing of our new AtoM interface before launch next week and are currently looking at the results. I just had a few things I wanted to get some feedback on - both from Artefactual re what changes might be sensible/possible, and from other AtoM users re whether their users have encountered similar issues and whether you have implemented any workarounds.

Note that this wasn't from a huge sample of users (14) and for many of these points, only one person mentioned the issue/problem. We did also get some really positive feedback and I'll talk about that a bit more in a future blog post.

1) Search box: Several people mentioned that they didn't find the search box very quickly (or in one case at all). One person assumed that the search box in the top bar would not actually search the catalogue data itself but be more like a global search of our website. I can see the benefit of having the search box in the top bar (because it is always visible no matter where you are within AtoM) but I think on the home page, people expect to see a big search box within the page content. Has anyone configured this themselves or are there any plans to include this within AtoM?

2) Left hand navigation: Someone thought the navigation links on the left were too small. We wondered if we could increase the text size of these but concluded that doing this may upset the balance of the page. Much of the text within the AtoM interface is of a similar size and I think this works. Has anyone tried this and achieved good results?

3) Search results: A few users raised the issue of the number of results that appear when you search. This is a problem that has been discussed on this mailing list recently and I know you are already aware of this. One user carried out a search for a personal name and came up with just one result but couldn't see how that result was relevant in any way to their search term. This was because the 'hit' was actually in a related authority record and wasn't actually relevant to their full search term because of the default 'OR' operator. 

Having read the AtoM documentation, I know that searching in AtoM is actually pretty powerful and there are a whole range of things you can do to tailor your search using just the basic search box. We are going to be trying to educate users about this through our help pages but of course can't guarantee that people will read them! One thing that occurred to us was that the behaviour that most of our users expect would be for the default operator to be 'AND' rather than 'OR' when carrying out a basic search and this would increase the relevance of their results. I'd be really interested to know what others think about this.

4) Navigation: A couple of users reported that it is easy to get lost within AtoM. They gave an example of how they had gone to an archival description and then clicked through to the creator and then realised that the creator was associated with lots of archival descriptions and couldn't work out how to get back to the archival description they were reading. I know this could have easily been solved by using the 'back' button on their browser but I thought it was a useful comment. Has anyone implemented any solution to this - for example a breadcrumbs trail so that a user could get back to where they were, or the ability to return to your latest search results list?

5) Filtering: One user reported that they would have liked to have been able to filter their results by date - is this already on the wishlist for AtoM?

6) Attaching pdf finding aids: As we have such a lot of legacy catalogues and finding aids that are not stuctured data, it will take us a while to get all of these into AtoM so as an interim step we are uploading pdf of our finding aids and attaching it to a collection level description so that users can access them easily. Users found this useful but I admit it is probably not what the digital objects functionality within AtoM was designed for. As we add more digital objects to AtoM (born digital archives and digitised content) having these pdf finding aids might be a bit confusing to users as they carry out digital object searches. Is there another way of attaching the finding aids to an AtoM record?

7) Help page: Users didn't necessarily know where to look for the help pages - the 'i' icon in the top menu bar isn't that intuitive. Has anyone created a '?' icon and used this to link to a help page? I think this would be clearer for users. Also, could the help page open by default in a new window - that would be easier for a user who may not want to lose their place in the catalogue?

Let me know your thoughts!

I'll be blogging about the user testing with a more detailed summary of the results so watch this space. We are also going to be carrying out some more detailed user testing with a smaller number of individuals in due course.

All the best,

Jen

--

Jenny Mitcham
Digital Archivist
Borthwick Institute for Archives

University of York
Heslington
York
YO10 5DD

Telephone: 01904 321170

Borthwick Institute website: http://www.york.ac.uk/borthwick/
Digital archiving blog: http://digital-archiving.blogspot.co.uk/

Twitter: @Jenny_Mitcham

Skype: jenny_mitcham

[Dan Gillean]

Hi Jen,

Thank you so much for sharing this valuable input! I hope that other users might also contribute their feedback and experiences in interacting with researchers and other public users who make use of their AtoM installations. I will add a few specific responses in-line below.

1) Search box: Several people mentioned that they didn't find the search box very quickly (or in one case at all). One person assumed that the search box in the top bar would not actually search the catalogue data itself but be more like a global search of our website. I can see the benefit of having the search box in the top bar (because it is always visible no matter where you are within AtoM) but I think on the home page, people expect to see a big search box within the page content. Has anyone configured this themselves or are there any plans to include this within AtoM?

As of right now, no one has approached us about sponsoring changes to the default homepage or AtoM header bar. I can see how a bigger search box could be useful on the main page - do you think there would be a possibility then of confusing users if there were now 2 search boxes when they arrived (the header, and the home page body)?

One thing to remember, which I think applies to many of your initial feedback comments, is that the default Dominion theme in AtoM is intended to provide users with the basic elements - and a lot of elements could and probably should be altered and emphasized via custom theme development. For example, the browse options on the home page are actually quite small in Dominion, possibly easy to miss - but in the themes that MemoryBC and ArchivesCanada are using, they have been given much more prominence on the landing page. In the ArchivesCanada theme, the entire header is much more prominent, and the search box is longer - it seems harder to miss there, to me. I think that there are many usability enhancements you could make to AtoM's default Dominion elements, but much of this might be possible by creating enhancements in theme plugins, instead of in the application itself.

We've added some basic developer documentation to help people start on creating custom theme plugins, here:

• https://www.accesstomemory.org/docs/2.3/admin-manual/customization/theming/#create-a-custom-theme
• (note that this is currently in the Admin manual. Since we now also have the beginnings of a Developer's manual to capture documentation about the new API endpoints that will be included in 2.3, at some point I hope to rewrite the theming page, and move this guide to the Developer's manual, with a link to it on the Admin manual's theming page.
  

I've yet to see an AtoM theme that really changes a LOT in the application - ie. fonts, colors, padding and spacing, etc. Many themes add some custom background colors or custom headers, but leave most textual and navigational elements unchanged. It would be great to see what's possible when someone very versed in design and CSS development spends time with the application!
 

2) Left hand navigation: Someone thought the navigation links on the left were too small. We wondered if we could increase the text size of these but concluded that doing this may upset the balance of the page. Much of the text within the AtoM interface is of a similar size and I think this works. Has anyone tried this and achieved good results?

Again I think this is something that could likely be handled in custom theming. I can't personally think of an example right now, but some users have definitely used color and styling to better emphasize them. You could try taking a look at some of the sites listed on our AtoM Users page in the wiki?

For archival descriptions, I have long wanted to see what would be possible if we changed the default 3-column layout in AtoM, so that on larger screen widths, the left column was given more space - it is often essential for navigation, and giving everything over there more room to breathe when it is available would be awesome. I once did this just by messing with the CSS in my browser inspector, to see how the treeview might fare - I also added more padding between treeview nodes, and subtle line breaks between each node, to better distinguish it:


​

The changes are minor (I'm not a developer, so there is only so much I could figure out), but I think they help the treeview a lot.

If we considered development to add another responsive level to all of the layouts (1-column, 2-col, and 3-col), we could make similar improvements elsewhere. Right now I believe the archival description search/browse page uses a 2-column layout - if the left-hand column had the option to expand further on devices with a larger width, you could give the facets more room - and that might also allow you to consider changing text sizes without breaking everything. The difficulty is of course testing on a large number of devices and screen widths.

 

3) Search results: A few users raised the issue of the number of results that appear when you search. This is a problem that has been discussed on this mailing list recently and I know you are already aware of this. One user carried out a search for a personal name and came up with just one result but couldn't see how that result was relevant in any way to their search term. This was because the 'hit' was actually in a related authority record and wasn't actually relevant to their full search term because of the default 'OR' operator. 

Having read the AtoM documentation, I know that searching in AtoM is actually pretty powerful and there are a whole range of things you can do to tailor your search using just the basic search box. We are going to be trying to educate users about this through our help pages but of course can't guarantee that people will read them! One thing that occurred to us was that the behaviour that most of our users expect would be for the default operator to be 'AND' rather than 'OR' when carrying out a basic search and this would increase the relevance of their results. I'd be really interested to know what others think about this.

We're really hoping that we can review and overhaul the archival description search indexing, as discussed in other threads. Still waiting for confirmation on the development contract we are negotiating, but if it goes ahead, I will be sure to discuss the possibility of changing the default operator to AND, as I agree that it could play a big part in improving the accuracy of search results.


 

4) Navigation: A couple of users reported that it is easy to get lost within AtoM. They gave an example of how they had gone to an archival description and then clicked through to the creator and then realised that the creator was associated with lots of archival descriptions and couldn't work out how to get back to the archival description they were reading. I know this could have easily been solved by using the 'back' button on their browser but I thought it was a useful comment. Has anyone implemented any solution to this - for example a breadcrumbs trail so that a user could get back to where they were, or the ability to return to your latest search results list?

My only concern about this would be the potential performance impacts you might have, generating breadcrumb trails dynamically based on the user's browser session (especially in sites with a lot of data and other permissions checks already going on, and/or with long user sessions) - and how this might get confused with places in AtoM where the breadcrumbs currently exist to get users back to more general pages (e.g. Authority record >> Doe, Jane). Have you seen other solutions in other websites/applications that you have found particularly effective, that we might look at?

 

5) Filtering: One user reported that they would have liked to have been able to filter their results by date - is this already on the wishlist for AtoM?

It's coming in 2.3! Search/Browse has gotten a major overhaul - they are all combined now, and you will be able to use facets and filters at the same time. There is now a Date range filter - note that it uses the internal StartDate and EndDate values (which are ISO 8601 YYYY-MM-DD formatted), not the view page display dates, for its sorting - so if you haven't added start and end date values, you won't get results. There will also be a sort by dates option in 2.3 - it sorts by startDate, and records without a startDate will appear last in the ordering.

 

 

6) Attaching pdf finding aids: As we have such a lot of legacy catalogues and finding aids that are not stuctured data, it will take us a while to get all of these into AtoM so as an interim step we are uploading pdf of our finding aids and attaching it to a collection level description so that users can access them easily. Users found this useful but I admit it is probably not what the digital objects functionality within AtoM was designed for. As we add more digital objects to AtoM (born digital archives and digitised content) having these pdf finding aids might be a bit confusing to users as they carry out digital object searches. Is there another way of attaching the finding aids to an AtoM record?

It's coming in 2.4! We're currently starting development on a feature that will allow users to upload their own PDF finding aids, instead of generating them from existing multi-level descriptions. They will be treated differently than digital objects, so you can still upload a digital object to the related descriptions. Right now, when you generate a finding aid in AtoM, a) there is no way to delete it from the system, and b) the link is only available at the top level of description (and it is not very prominent). With this change, you can delete either your generated or your uploaded finding aids, and the finding aid link, which will appear as a button with a PDF icon in the sidebar now (making it more noticeable), will appear on all levels of description. This is the first feature we know will go in 2.4 - we have now reached a point where we are in the testing and bug fixing phase for 2.3, so we can package and release it in the near future.

 

7) Help page: Users didn't necessarily know where to look for the help pages - the 'i' icon in the top menu bar isn't that intuitive. Has anyone created a '?' icon and used this to link to a help page? I think this would be clearer for users. Also, could the help page open by default in a new window - that would be easier for a user who may not want to lose their place in the catalogue?

I think both of these would be pretty easy to do. We use the Font Awesome icon set in AtoM - it would be possible to change the info "i" icon into the fa-question-circle icon, for example. That might be something we'd want to see done in a custom theme - unless there was strong consensus from community feedback that the default icon should be changed. As for having static pages in this menu open in a new tab - I haven't tried it yet, but I wonder if, as a simple workaround, you could manage this via the user interface by including a target="_blank" as part of the path on the menu link for the page? I will try to find time to play with this myself and report back.

 

I'll be blogging about the user testing with a more detailed summary of the results so watch this space. We are also going to be carrying out some more detailed user testing with a smaller number of individuals in due course.

 

Great! We look forward to hearing more! And to our user community, please feel free to share your experiences and perspective!

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

[Jenny Mitcham]

Hi Dan,

Thanks for your thoughtful responses to all of the points I raised. I was really very encouraged to hear that there are some solutions on the way. AtoM really is evolving fast!

1) yes I too wondered whether a central search box on the front page would lead to usability issues in itself. Useful to know whether anyone has achieved this and whether feedback has been positive

2) your experiments with this are interesting and I think this would be a good way to go in the future. It would be nice if the titles within the treeview had more space on bigger screens. One thing that occurred to me was that navigation within a complex archive would be easier if there was indentation in the treeview. This wouldn't work currently because of the width of that column as it would lead to further truncation of titles.

3) Pleased to see you may consider a default AND operator in the future. It would be useful to know what other AtoM users think about this?

4) Sorry - no examples and no idea whether what I suggest is really practical or not. A link to last search results is probably more practical than breadcrumbs.

5) Great news and yes, we will be making an effort to fill in normalised start and end dates as far as we can.

6) Great news that you are working on this too. Just a quick question around functionality. Currently the search facility searches within the pdf finding aid we have uploaded. This is quite useful (given that we can only get a certain amount of detail within the collection level description). Would the new feature in 2.4 still allow the search to pick up things within the attached finding aid?

7) Thanks for the link to Font Awesome - that is really helpful. We will give this a go within our version of AtoM. Are there any other users that think having the AtoM help page under a question mark icon would be more intuitive?

All the best,

Jen

--
You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZ%2B1XfmNAZDDVR%2Bdv5X3nEjbWWRpmBL_Qu3KbjRe9NcXBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Gillean]

Hi Jen,

A few more responses below:

2) your experiments with this are interesting and I think this would be a good way to go in the future. It would be nice if the titles within the treeview had more space on bigger screens. One thing that occurred to me was that navigation within a complex archive would be easier if there was indentation in the treeview. This wouldn't work currently because of the width of that column as it would lead to further truncation of titles.

Early versions of AtoM had indentation on the treeview, but it was removed because after more than 1 or 2 levels the width of the treeview became practically unusable. With a bit more width, it might be possible to offer minor indentations to help better indicate hierarchies visually without compromising too much space, but we'd definitely want to test it against some real-world large hierarchies.

In the meantime, AtoM 2.3 will also include a second, full-width treeview option - an administrator will be able to choose via the global settings whether to use the new full-width treeview, or the the traditional sidebar one. The full-width treeview displays the entire archival description hierarchy, includes indentation, is keyboard navigable, and the bottom bar of the frame can be dragged down by users to expand it, allowing for easier exploration. It also uses some basic icon types to distinguish lower levels (file, item) from mid (series, sub-series, sub-fonds, and user-created local terms) and top-level (fonds, collection) records. The tradeoffs are:

• The current implentation has not been designed for scalability - so very large hierarchies could break the treeview, or take a long time to load. We're hoping for development in 2.4 that will improve this for users with large record sets and deep hierarchies.
• The identifier is not displayed in the full-width treeview
• There is no drag and drop functionality amongst sibling records when the sort is manual, as there is in the sidebar treeview.
  

The original issue is here:

• https://projects.artefactual.com/issues/6375

I've started on the documentation, here:

• https://www.accesstomemory.org/en/docs/2.3/user-manual/access-content/context-menu/#treeview
  

 

6) Great news that you are working on this too. Just a quick question around functionality. Currently the search facility searches within the pdf finding aid we have uploaded. This is quite useful (given that we can only get a certain amount of detail within the collection level description). Would the new feature in 2.4 still allow the search to pick up things within the attached finding aid?

Yes - in fact there will be a couple new options added to the advanced search interface to support this. Right now we don't index the generated finding aids in AtoM, because all that data is already in the index from the descriptions in AtoM. For uploaded finding aids, we will index it, and add the following 3 search enhancements:

• Add basic search results filter for logged in users to limit to descriptions with uploaded PDFs

• Add ability to limit search to indexed uploaded finding aid text in Advanced search

• Add ability to limit search to just database records - exclude uploaded finding aid text from search results in Advanced search

See: https://projects.artefactual.com/issues/9655

Regards,

[Jenny Mitcham]

Thanks for the extra info on this Dan. The full width tree view option sounds really interesting and something I look forward to exploring when we get our hands on 2.3. Functionality re searching (or not searching) uploaded finding aids sounds good.

Many thanks,

Jen

--

You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZKH0rcBYhpsA5wZqD9Tjuq_peCLpTg0ZEm9hRKr5YPKdg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Jenny Mitcham]

Hi Dan - just one more query around point 6. At the moment we like the fact that our pdf finding aids that we upload to AtoM as digital objects open straight away when you click on them (rather than insisting you first download the pdf file then open). Will this functionality continue once you have implemented a new way to upload finding aids?

Many thanks for your help with all of these questions.

Jen

On 4 April 2016 at 18:06, Dan Gillean <d...@artefactual.com> wrote:

--

You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZKH0rcBYhpsA5wZqD9Tjuq_peCLpTg0ZEm9hRKr5YPKdg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[David]

Hi,

I also have some comments:

1. Level of description order: The archivists I am working for would like to see the levels ordered hierarchically and not alphabetically inside the drop-down selection inside description creation form.
   
2. The possibility to change the separator character between identifier to generate the reference code inside an hierarchy would be nice. refCode = id.id/id instead of id-id-id. A character depending on the level would be really nice.
   
3. Atom 2.3 clipboard - Add: The first time I was adding something I thought the children also get added. A second button or a checkbox to add not only the selected description but also existing children could be useful.

Regards,

David

[Dan Gillean]

Hi David,

Thanks for your feedback! I'll add a few points in response below.

Level of description order: The archivists I am working for would like to see the levels ordered hierarchically and not alphabetically inside the drop-down selection inside description creation form.

This is an interesting possibility, but unfortunately, there are some challenges around this that require consideration. First, it makes assumptions about archival practice that are not necessarily common internationally. For example, the Fonds is often not used at all in Australia as a level of description, with the Series being the highest level of description. Many U.S. institutions still make use of the Record Group in favor of the fonds, which is not even currently a default term in AtoM. Imposing an established order implies judgement about practice that we at Artefactual feel we should not make.

Additionally, the Levels of description are maintained in a user-editable taxonomy - meaning that users can delete or edit terms they don't use, and add new levels as needed. How should we position new terms that are added by default? If you add Record Group as a U.S. user, how to make it a top-level term? If you need to add sub-subseries, or sub-sub-subseries, how do we slot these into the hierarchy appropriately? It starts to sound like you need custom development on the LOD taxonomy so you can add a weight or position to each term... and I'll discuss development and feature enhancement below.

 

The possibility to change the separator character between identifier to generate the reference code inside an hierarchy would be nice. refCode = id.id/id instead of id-id-id. A character depending on the level would be really nice.

Actually, you should be able to do this already, via Admin > Settings > Global > Reference code separator. The default is a dash, but an administrator could change this to a slash via the user interface. Currently this is a global setting - it will not behave differently at different levels (where things start getting really complex in terms of feature design, again). See:

• https://www.accesstomemory.org/docs/2.3/user-manual/administer/settings/#reference-code-separator
  

 

Atom 2.3 clipboard - Add: The first time I was adding something I thought the children also get added. A second button or a checkbox to add not only the selected description but also existing children could be useful.

We too would love to see this in the future! Which is where I must mention how the AtoM project is maintained, and our business model here at Artefactual.

As you are aware, AtoM is released as open source software - in fact, we release it under a strong viral license (AGPLv3) to ensure that the application is not forked by a proprietary company charging for access to the enhancements it adds, as this would bifurcate our already small community, and part of our goal in developing AtoM is to ensure that a robust, standards-based application for archival description and access remains available to as many as possible, and that when it improves, everyone benefits.

To this end, Artefactual (the lead developers and current maintainers of the application) releases the code, our documentation, our webinar recordings, our wiki resources, and even as much free support as we can offer via this user forum, all free of charge. With every major release, we also budget time to review and address many of the bugs reported to use by our user community. To sustain ourselves as a business and be able to continue maintaining and developing AtoM, we also offer additional paid services - including hosting, consultation, training, application theming, data migrations, and of course, custom development. This business model is sometimes known as the Bounty model of open-source development. Every time we are contracted to develop a custom feature for an institution, we work with the client to ensure the feature respects established international standards, and we try to generalize its implementation so it can not only meet the use case of the institution in question, but also be of benefit to the entire AtoM user community. We then include all of these enhancements in the next public release. Whenever possible, we also accept bug fixes and code contributions from our user community, and will handle the review and merging of this code into public releases, as well as its maintenance through subsequent releases, thereby reducing the burden on individual contributors over time. We have a number of resources on our wiki to help users get started.

This means that AtoM, as an application, is truly what our community makes of it - the current version, like all versions before it, has been made possible thanks to contributions large and small from dozens of institutions and individuals. You can see this on the Roadmap part of our wiki for the upcoming 2.3 release - there we try to acknowledge all the different institutions that have helped to make the new features possible. This is one of the joys of community-driven development - seeing what we can accomplish as a community when we are all working towards common goals.

In contrast however, one of the challenges of this approach is that as a small company, we at Artefactual simply don't have the resources to undertake much of the development and maintenance we would like to see happen without community support. We are already in the process of giving away the majority of our core business products via AtoM and Archivematica; the funds we receive from custom development are released back into subsequent releases via code maintenance, documentation, webinars, conference presentations and workshops, bug fixes, user forum support, release testing and packaging and more - anything left over is used to keep the lights on.

Most of the features in AtoM have been developed iteratively, and collaboratively over subsequent releases - one institution will sponsor the base implementation, and then we look to future spondored development to help us refine, improve, and build upon that first implementation. The Clipboard is a brand-new module being introduced in 2.3, and it was funded by Simon Fraser University Archives - in its current form, it meets the base requirements that SFU had, but we also see this initial development as an exciting first step towards an interface for performing many bulk actions via the user interface. We hope it will be useful to the broader community in its current form, but we're also hoping that it will inspire ideas, and generate interest in enhancing its utility further.

So, all of this to say - we agree! And if you'd like to see the Clipboard improved, please consider having your institution sponsor feature development in the future, or contribute code!

[David]

Hi Dan,

Ad 1) I didn't think of the possibility to change the taxonomy. The current ordering makes totally sense to me now.

Ad 2) Thanks. I didn't see that option. Because a reference code with different separator characters for different levels is a requirement I will tell the archivists that they should not use the option to inherit the reference code.

Ad 3) If I need to change the Clipboard I can create a pull request.

Regards,
David

[Nathanael]

We also ran a user survey recently about our web resources. This gave us lots of possible improvements to think about, many of which relate to how we have entered information to AtoM or to other parts of our website. Things which I think our users would like to see which relate to the functionality of AtoM itself include the following:

• An improved treeview (I'm aware a new one is in development)
• The ability to filter out images where the reference copy is restricted due to copyright from a set of search results. I know there is a filter on the advanced search (which I think we have hidden and should probably reinstate), but I think users would like this option as part of the filters that appear down the side of set of search results.
• The full set of filters to appear on a subject or place term browse page e.g. http://catalogue.millsarchive.org/leap-mill-burnopfield
• Regarding the filters, the option of viewing all possible terms to filter by (a 'show all' button), where currently only the ten most commonly used terms are available. The same applies to the 'creator of' and 'subject of' lists in an authority record.
• Default Boolean search to be AND
• The option of selecting the number of results to appear (currently only an admin can change this).
• The thumbnail view currently only available for all digital items (e.g. http://catalogue.millsarchive.org/digitalobject/browse) or by clicking the 'show all' button in an archival description to be an option for a set of search results and for a term browse page (presumably with the filters at the side still visible).

Our catalogue has a large number of digital images which seem to be the things are users are primarily interested in (rather than, for example, searching for records in the archive to order in our searchroom), so this will probably affect which changes users request. I will let you know if we decide to sponsor any of these changes.

[Jenny Mitcham]

This is really interesting - thanks for sharing Nathanael! 

The themes coming out of your user testing are quite different from ours and that is probably largely because we have not yet embraced the functionality within AtoM around digital objects and you clearly have.

On the subject of the default boolean search - we are now looking at getting this changed on our production version of AtoM. We've got the AND operator working on our test server and will be moving it across soon on to the live version. I'm hoping this will have a positive impact on the user experience. Does mean I also need to update our help pages now too!

I agree that allowing users to select no of results would be a useful and welcome feature.

I also agree that being able to view all of the filter lists would be useful. It is a little bit confusing at the moment as you have an 'All' button but when you click this it doesn't show them all.

All the best,

Jen

--

You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/3422597a-312f-447e-b8cc-c88a8b7b9590%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Dan Gillean]

Hi Nathanael,

Thanks so much for sharing this!

I'll add some initial responses in-line, below.

• An improved treeview (I'm aware a new one is in development)

Yup, coming soon! This first iteration will likely need require more development to help its scalability and add more features, but I hope it will help move things in the right direction.

 

• The ability to filter out images where the reference copy is restricted due to copyright from a set of search results. I know there is a filter on the advanced search (which I think we have hidden and should probably reinstate), but I think users would like this option as part of the filters that appear down the side of set of search results.

Interesting. I will be curious to hear how you feel about the advanced search changes coming in 2.3 - you'll now be able to use both filters and facets on the same results - instead of having facets only on search/browse and the advanced search filters exclusive to the advanced search page. However, the panel is still collapsed (hidden) by default on search/browse pages. Users will have the ability to hide the Copyright filter via an Admin setting if they are not using it, so no need to do this via customizations any more. I've completed the initial documentation on the changes, if you're curious to read more and see some screenshots:

• https://www.accesstomemory.org/docs/2.3/user-manual/access-content/advanced-search/
  

 

• The full set of filters to appear on a subject or place term browse page e.g. http://catalogue.millsarchive.org/leap-mill-burnopfield

Also interesting. There are definitely more we could add!

• Regarding the filters, the option of viewing all possible terms to filter by (a 'show all' button), where currently only the ten most commonly used terms are available. The same applies to the 'creator of' and 'subject of' lists in an authority record.

We agree! In fact, I'd love to see the sidebar options behave as filters not facets - so users can select multiple filters in a single category at once if desired. We do have an existing ticket for this in the AtoM Wishlist project:

• https://projects.artefactual.com/issues/5278

That ticket also includes an example of an existing interface we like as a model to consider - the Getty Search Gateway. Try playing around with the filters and facets here - more results can be loaded for each, but it's implemented in a way that can still be performant (e.g. loading 20 results more at a time, but providing users with a search for further facet results, etc): 

• http://search.getty.edu/gateway/search?q=&cat=highlight&f=%22Collection+Highlights%22&rows=10&srt=a&dir=s&pg=1

DPLA also has a nice implementation for showing more options scalably - they page the results:

• http://dp.la/search?utf8=%E2%9C%93&q=coffee

It is of course significant development work to make these kinds of changes, but we're really hoping that our community will prioritize it for future releases.

 

• Default Boolean search to be AND

Good to hear more feedback in favor of this. As I've mentioned to Jen, this is something we are hoping to address in 2.4 - just waiting to see if a development proposal for an Elasticsearch mapping overhaul will be accepted by the potential client. Jen, I see you mentioned that you've implemented this change locally - please let us know how it goes after a while, and if all seems well and you find the results improved, perhaps you could submit a pull request!

 

• The option of selecting the number of results to appear (currently only an admin can change this).

I believe we actually used to have a results per page drop-down in an earlier version of ICA-AtoM, and I think it may have been removed in the 2.x version for performance reasons? Though, I'm not actually sure of the backstory there. I agree it could be a useful feature - we'd just want to make sure that we implement in a performant way.

 

• The thumbnail view currently only available for all digital items (e.g. http://catalogue.millsarchive.org/digitalobject/browse) or by clicking the 'show all' button in an archival description to be an option for a set of search results and for a term browse page (presumably with the filters at the side still visible).

Interesting! I don't think it would be too hard to add a "show results with digital objects" link to the term browse page. One thing worth mentioning as well - we have a proposal out there to combine the digital object browse page into the new search/browse/advanced search page - so essentially, the card view would become a toggle option available for all results, just as the list view could be applied to digital object browse, and all search facets and filters could be used. We could probably do the same for other entity types.

 

Our catalogue has a large number of digital images which seem to be the things are users are primarily interested in (rather than, for example, searching for records in the archive to order in our searchroom), so this will probably affect which changes users request. I will let you know if we decide to sponsor any of these changes.

Please do! Either way, it's always very useful for us to hear this kind of feedback, and it's useful to the broader community as well - others can chime in about their ideal features, or alternative visions for enhancement, and in some cases, you might put an idea in someone else's head who decides to fund a feature you've proposed, as it fits their needs as well! 

Warm regards,

[Nathanael]

Thanks for the feedback Dan.

Regarding copyright, actually I’m not sure that the advanced search filter will give our users what they want. They want to be able to remove restricted images from the search results. The options on the filter allow you to select only items under copyright, but not to select everything except those under copyright - unless we called everything else ‘public domain’, which is technically not true.

Actually it’s not so much about copyright - many of our items are under copyright, but we have the right to make them available. It’s about whether the reference image is visible or not. Users want to remove those results where the reference image is restricted (whether we have done that through adding a rights record or by setting permissions for particular collections by user group). This is obviously because they find it frustrating when they click on a thumbnail and then can’t see the larger size image, so they want to know which ones are available.

Perhaps a better solution might be to add something in the ‘Media Types’ facet, allowing users to select between 'Images (unrestricted)' and 'images (restricted)'?

A few more thoughts on filters/facets:

• Might be useful if users could filter by name of collection. We call all our top-level descriptions 'collections' but others might use 'fonds' or both terms which might complicate this.
• Would be useful to be able to exclude all items relating to a particular term as well as view all items relating to that term
• Would be useful to be able to filter by person/organisation names excluding creators - currently you can filter by the name of creator or by a name which appears either as a creator or access point, but not just by people added in the access points.

[Dan Gillean]

Thanks for sharing this, Nathanael!

I'm glad to hear that there are institutions making use of the PREMIS actionable rights module! There are a number of enhancements coming to it in the 2.3 version, if you're curious - see:

• https://www.accesstomemory.org/docs/2.3/user-manual/add-edit-content/rights/

I agree it would be useful to be able to see only non-restricted digital objects, as well as only restricted ones - this would be useful for archivists managing rights and restrictions.

• Might be useful if users could filter by name of collection. We call all our top-level descriptions 'collections' but others might use 'fonds' or both terms which might complicate this.

Can you use the Top-level description filter for this purpose? It is an autocomplete based on the title of top-level descriptions, regardless of what level is used. In the 2.3 Avanced search panel, this field has been given more space than it had in 2.2 and earlier, where it was hard to see enough of the name to be sure you were selecting the correct top-level description.

All of your proposed filters sound useful, and we would definitely be interested in working with community partners to introduce some of them to future releases. The tricky part is keeping the user interface intuitive to non-experts - too many options can also be a detriment to usability :)

Regards, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--

You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/56567373-1672-46da-8479-2a19b37e5c76%40googlegroups.com.

[Nathanael]

One other question - would it be possible to implement polyhierarchies, so that terms could have more than one broader term? The only disadvantage I can see is that it would complicate the treeview.

[Dan Gillean]

Hi Nathanael,

I do believe that SKOS supports polyhierarchies - which means we have the standards basis to begin looking at treating AtoM's taxonomies more as thesauri. In terms of the data modelling, I would have to discuss with the developers, but I'm guessing that some internal changes would be necessary to create those kinds of relationships.

The UI elements are also interesting to consider - ideally, in the long run perhaps something more graph-based would make sense to visualize complex polyhierarchies - it can certainly do a better job of representing related concepts, something not shown in the treeview at all.

Either way, I think development would be required to implement support for this - how much would probably depend on how robust you wanted the solution to be, and what use cases you were trying to solve.

Cheers,

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

On Tue, May 3, 2016 at 3:15 AM, Nathanael <nathana...@millsarchive.org> wrote:

One other question - would it be possible to implement polyhierarchies, so that terms could have more than one broader term? The only disadvantage I can see is that it would complicate the treeview.

--

You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/fe1aae24-e43d-4317-961a-e927083632e4%40googlegroups.com.

[David at Artefactual]

Hi Nathanael,

Dan is correct that SKOS supports poly-hierarchies, but implementing true poly-hierarchies in AtoM would require significant changes to the current taxonomy data model, access control system and user interface.  The current data model relies on a one-to-many self-relationship between the parent and children terms.  To accommodate poly-hierarchies, the data model would need to be changed to a many-to-many parents to children relationship.  While it is probably possible "fake" polyhierarchies with the current data model (i.e. have a single "true" parent of a term, but allow "alternate" parent-child relations), my hunch is that this would produce unsatisfactory results in the UI and the code architecture.

It would be very interesting to model polyhierarchies using a graph database or triple-store, which I think would be the natural fit for those kind of complex relationships,  but that kind of work is well beyond what we can realistically tackle right now with AtoM.

Cheers,

David

On Tuesday, May 3, 2016 at 10:44:15 AM UTC-7, Dan Gillean wrote:

Hi Nathanael,

I do believe that SKOS supports polyhierarchies - which means we have the standards basis to begin looking at treating AtoM's taxonomies more as thesauri. In terms of the data modelling, I would have to discuss with the developers, but I'm guessing that some internal changes would be necessary to create those kinds of relationships.

The UI elements are also interesting to consider - ideally, in the long run perhaps something more graph-based would make sense to visualize complex polyhierarchies - it can certainly do a better job of representing related concepts, something not shown in the treeview at all.

Either way, I think development would be required to implement support for this - how much would probably depend on how robust you wanted the solution to be, and what use cases you were trying to solve.

Cheers,

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

On Tue, May 3, 2016 at 3:15 AM, Nathanael <nathanael.hodge@millsarchive.org> wrote:

One other question - would it be possible to implement polyhierarchies, so that terms could have more than one broader term? The only disadvantage I can see is that it would complicate the treeview.

--
You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-users+unsubscribe@googlegroups.com.
To post to this group, send email to ica-atom-users@googlegroups.com.

Visit this group at https://groups.google.com/group/ica-atom-users.

[David]

Hi,

users don't have to fill out 'mandatory' fields for new items just because of usability reasons so they can create skeletons and complete them later on?

What do you think about a new settings option to make AtoM 'strict' so the mandatory fields aren't optional any more?
A possible improvement would be that a user can define which fields are mandatory (like defining visible elements).

Regards,
David

Am Donnerstag, 5. Mai 2016 19:19:49 UTC+2 schrieb David at Artefactual:

Hi Nathanael,

Dan is correct that SKOS supports poly-hierarchies, but implementing true poly-hierarchies in AtoM would require significant changes to the current taxonomy data model, access control system and user interface.  The current data model relies on a one-to-many self-relationship between the parent and children terms.  To accommodate poly-hierarchies, the data model would need to be changed to a many-to-many parents to children relationship.  While it is probably possible "fake" polyhierarchies with the current data model (i.e. have a single "true" parent of a term, but allow "alternate" parent-child relations), my hunch is that this would produce unsatisfactory results in the UI and the code architecture.

It would be very interesting to model polyhierarchies using a graph database or triple-store, which I think would be the natural fit for those kind of complex relationships,  but that kind of work is well beyond what we can realistically tackle right now with AtoM.

Cheers,

David

On Tuesday, May 3, 2016 at 10:44:15 AM UTC-7, Dan Gillean wrote:

Hi Nathanael,

I do believe that SKOS supports polyhierarchies - which means we have the standards basis to begin looking at treating AtoM's taxonomies more as thesauri. In terms of the data modelling, I would have to discuss with the developers, but I'm guessing that some internal changes would be necessary to create those kinds of relationships.

The UI elements are also interesting to consider - ideally, in the long run perhaps something more graph-based would make sense to visualize complex polyhierarchies - it can certainly do a better job of representing related concepts, something not shown in the treeview at all.

Either way, I think development would be required to implement support for this - how much would probably depend on how robust you wanted the solution to be, and what use cases you were trying to solve.

Cheers,

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

On Tue, May 3, 2016 at 3:15 AM, Nathanael <nathana...@millsarchive.org> wrote:

One other question - would it be possible to implement polyhierarchies, so that terms could have more than one broader term? The only disadvantage I can see is that it would complicate the treeview.

--
You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.

Visit this group at https://groups.google.com/group/ica-atom-users.

[Dan Gillean]

Strict mode is a great idea, David - we would likely need to make it behave differently at different levels however - not all item-level records will have a scope and content, though you might want to make it mandatory at the top level of description.

I'm away at a conference this week with limited access - I'm hoping that in my absence one of the developers will respond to your questions on the other thread. I'll follow up when I return if they have not.

Cheers,

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/17949c5b-dbf6-490e-9f1d-6035f705029b%40googlegroups.com.