Context menu "see all" links are not useful for a large number (100+) of children
|Assignee:||Jesús García Crespo||% Done:|
|Category:||Performance / scalability|
|Target version:||Release 1.3|
|Google Code Legacy ID:||atom-1943||Tested version:|
Originally reported by Erica Hernandez (22-Feb-2011)
To reproduce this error:
1)View a Series (or Fond, File, etc.) -level description that has 1000+ children
2)Click the "+ xxxx..." link to view all child descriptions
Displays "Loading..." with the animated icon idefinitely.
The AJAX response is:
Fatal error</b>: Allowed memory size of 134217728 bytes exhausted (tried to allocate 83 bytes) in <b>/home/haft/hosting/ica-atom.org/unbc-test/trunk/lib/QubitQuery.class.php</b> on line <b>365<br />
The desired behavior isn't clear - we'll have to discuss what makes sense from a usability standpoint. It is clear that trying to load 1000s of items into the treeview is not very useful.
[g] Legacy categories: Usability, Information object
#1 Updated by Tim Hutchinson over 9 years ago
There is a similar issue if there are too many descriptions linked to a single authority record, e.g. item-level photograph descriptions where the item is the highest level. I don't have an example handy since we changed the test data to work around this issue.
#4 Updated by David Juhasz over 9 years ago
I think the best solution is for the "+ XXXX ..." (treeview) and "See all" (imageflow) links to return the search results for the appropriate description (e.g. "Series - photographic material" in the Mary Fallis Fonds).
This would provide paging and the ability to refine the search criteria within the found set.
The imageflow link could include a flag to show only descriptions with a digital objects; the treeview would show all descriptions, whether then include digital objects are not (in this example both would return the same results).
#9 Updated by David Juhasz about 9 years ago
- Status changed from Verified to In progress
The fix in r9055 is unsatisfactory because the treeview sort order (controlled in the admin settings) and the search index sort (by relevancy) are different. As well, the visual styling of the Treeview and search results are very different. These differences make the transition from Treeview to search results very disorienting and confusing for users.
Please see http://www.qubit-toolkit.org/wiki/index.php?title=Hierarchy_browser for a discussion of possible solutions.
#13 Updated by Anonymous over 8 years ago
- Status changed from Verified to In progress
- Target version changed from Release 1.2 to Release 1.2.1
User feedback has been provided that challenges the usability of this enhancement/new feature. Issues raised include: missing descriptive level and numerical designation (e.g., Item01) from browse screen and "alphabetic" sort order option changes the order and confuses which item or file to view.
See below for suggestion to improve:
A temporary fix would be to add the Level and Numerical designation (e.g.,Item01) to the browse screen for +10 descriptions.
[g] Labels added: Milestone-Release-1.2.1
[g] Labels removed: Milestone-Release-1.2
#14 Updated by Anonymous over 8 years ago
Use Case Scenario, submitted below:
When creating lower level descriptions within an already-existing level of description I use the Add Child Levels part of the Title and Statement of Responsibility area. I enter the identifier, the level of description and the title. I might create 20 or 30 or even more files within a series description this way. Keep in mind that I usually have the box with the actual files in it right next to me while doing this.
Then I save the record.
Then, I head over to the Menu Context Bar and click on each file (listed numerically by identifier) and add in dates of creation, physical description and any other information for my description. I keep going down the list in the menu context bar until it reads "+X" (X=a number). I click on "+X" , a new window opens up and I and keep working through the list until I'm done. I've entered over 1,100 files this way and it worked very well.
In 1.1 the order for the files in the new window would be the order I established when assigning identifiers (i.e. file numbers) within the series description and also the order in that box that's right next to me while I'm entering the information.
In 1.2 the file number does not appear in the new window and the order isn't the same as the identifier number so suddenly I'm hunting around for file entries. It's time consuming and illogical (for my work anyway). It's also one extra click for reference work too - I have to click on a file to find the number so I can go to the correct box in the archives.
[g] Labels added: Component-Archival-Description
[g] Labels removed: Component-SearchBrowse
#16 Updated by Anonymous over 8 years ago
- File memorybc_expanded_treeview_1-2_release.pdf added
Feb 28, 2012: I just experienced this new treeview look when clicking "+8 ..." in Series 1 of http://www.memorybc.ca/burquest-jewish-community-association-fonds;rad
This view is completely useless because there's no longer the required context and the order of the records is reversed from how they're supposed to be listed in the description itself.
I've attached a screenshot (PDF) of what I'm seeing. I'm expecting there will be complaints about this.
If you're going to be making major changes like this in future, pleased ensure you consult with provincial network administrators such as myself! I would have said no to this as it is presently implemented.
#17 Updated by Anonymous over 8 years ago
Thank you for fixing this for the MemoryBC implementation of ICA-AtoM 1.2. Here is my suggestion for a possible solution to the issue of a large number of child level descriptions.
Set a max display of 90 after the first default of 10, so if there were 1,000 item level descriptions as the children of a file level description, the user will see the first 10 followed by "+990..."
Clicking the "+990" will only, however, bring up the first 100 within the existing treeview. There will be another link at the bottom of this display for "+Next 100..." (or however it's best to phrase this).
If a user clicks that link they will only see items 101 to 200. A "+Previous 100..." will be at the top of the tree view for the item-level descriptions and a "+Next 100..." will be at the bottom of the tree view listing.
And so on ...
Hope this makes sense!
#24 Updated by Jesús García Crespo about 8 years ago
- Status changed from In progress to QA/Review
Fixed. 1.3 introduces a complete redesign of the treeview with a new navigation system that should be solve this problem. Feedback is welcomed since 2.0 will also include this new system and new improvements could be done during the development phase.