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?
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.
--
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.
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.
I've started on the documentation, here:
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?
See: https://projects.artefactual.com/issues/9655
Regards,
--
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.
--
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.
Regards,
David
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.
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.
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.
--
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.
- 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.
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):
DPLA also has a nice implementation for showing more options scalably - they page the results:
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
- 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.
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:
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.
--
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.
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.
Cheers,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.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.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.
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.
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:
Cheers,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.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.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.
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/17949c5b-dbf6-490e-9f1d-6035f705029b%40googlegroups.com.