Difference between revisions of "Development/Treeview/Historical"

Latest revision as of 12:57, 20 July 2015

Main Page > Development > Development/Treeview > Development/Treeview/Historical

On this page you'll find an overview of the some of the history, early development considerations, and analysis undertaken when designing the treeview for ICA-AtoM, some of the changes and enhancements introduced in later versions, and user feedback and development suggestions received at that time. For more current information about the Treeview in AtoM, please see the following pages:

• Treeview - 2.x development
• Treeview - future development

Introduction

The Treeview is a graphical representation of the current resource hierarchy (ascendants and descendants). The Treeview structure is used with archival descriptions and taxonomy term pages. In the archival description page, the Treeview gives a graphical representation of the description hierarchy, revealing the relationship between parent-level description (e.g., fonds or collection) and lower child-level descriptions (e.g, series, file, item). On the archival description page, the Treeview is included within the Context menu area, which includes hyperlinks to the related archival repository, creator's authority record, related physical storage and the Cover flow viewer graphically representing related digital objects. In the term page, the Treeview gives a graphical representation of the taxonomy hierarchy, revealing the relationship between taxonomy type (e.g., subject, places) and broad and narrow terms.

Background

The Treeview has been a feature since early beta versions of the software. The following is a review of the Treeview feature and its functionality in ICA-AtoM 1.2 and 1.3, as well as in AtoM 2.0. The purpose of providing Users with the background of Treeview is to demonstrate the developments of this feature in response to User's feedback, software performance and scalability.

1.2 ICA-AtoM Treeview

• Treeview in Archival description view page
  • Presented within the context menu for a selected fonds/collection
  • Nested presentation
  • Plus and minus signs are used to indicate if a level includes descendents and can be opened further to reveal additional descriptions
  • All levels open for viewing
  • Highlight is used to indicate specific archival description being viewed
  • Users can move archival descriptions within a fonds via drag-and-drop in the treeview

1.2 Treeview in Archival description view page

• Fonds/collections with descendent and numerous siblings are displayed in a single page and Users need to click on hyperlink number to view siblings. See "XX...link" discussion below for additional information.

1.2 Treeview showing numerous descendents

• The +XX or "See all" button in the treeview received reports of performance and usability issues, as parent level descriptions with numerous children would result in loading errors or long wait times. This is best summed up in User Feedback Issue 1943, and related discussions (linked in the issue).
• In response to the issue, changes are made to how ICA-AtoM handles archival descriptions with numerous siblings and a separate browse screen is added, which the user is redirected to when viewing child records beyond the initial 10 treeview records loaded.

1.2 Treeview browse function for numerous siblings

• Treeview in Terms view page
  • Nested presentation

1.2 Treeview in Terms view page

User responses to 1.2 Treeview improvements

• Though the improvement to performance has been welcomed, user response to the redirected browse page when seeking to view all children in the treeview was mixed. Users felt that the difference in sort order and visual style between the Treeview and search results was disorienting, and removed necessary context. Uniquely identifying the parent description in a human-readable manner in the search query also proved to be difficult - the description title is the natural choice, but titles are not unique in many collections. In addition the search results page is not hierarchical so it cannot be used to descend or ascend the description hierarchy.
  • To encourage design discussion on a dedicated hierarchy browser page, a separate wiki page was created for discussion on how best to proceed. Currently the page holds one suggestion for a Miller column view; community users are encouraged to offer further suggestions and wireframes/mock-ups.
• Problems have also been identified with nesting multiple child levels in a visual display with limited screen real-estate, as the treeview currently exists on the right or left hand side of the screen (depending on the theme selected). As users drill down to lower levels, the nesting provided for less and less room to display label information (such as title, identifier, etc.).

1.3 ICA-AtoM Treeview

In response to community feedback and known performance issues in 1.2, further changes to the treeview were made in the 1.3 release.

Treeview in Archival description view page

• All fonds in the database are shown in the context menu. Users have an option to Show All or view only one Fonds
• Vertical presentation is added to resolve nesting display issues reported in 1.2 - all levels of description are given equal screen real-estate in the context menu, and the treeview alters the view in response to the record selected.
  • Arrows are used to indicate if a level includes descendents and can be opened further to reveal children
  • Parent and immediate descendent are open at the same time, all other descendents and siblings are closed until selected
• Highlight is used to indicate specific archival description being viewed
• Users can sort descendents within a level by using drag-and-drop. See the "Natural Sort" discussion below for additional information.

1.3 Treeview in Archival description view page

• In response to usability feedback about description titles being truncated in the treeview, a hover pop-up is added to reveal full description title
• In response to user feedback about being redirected to a browse page when clicking "see all" in the treeview, users are now able to see all descendants without leaving the treeview
  • As in 1.2 a set number of child descriptions is loaded (10)
  • Ellipses at bottom of treeview enable User to open additional descendents
  • As the user scrolls, the list will auto-populate with further results

1.3 Treeview with float function and ellipses for expanding list of descendents

Treeview in Terms view page

• Vertical presentation

1.3 Treeview open in Terms view page

Next Steps

• A review of Treeview functionality in ICA-AtoM 1.3, identified two key problems to be fixed and released as a 1.3.1 Patch:
  • Issue 2406: Displaying all fonds in the database in the Treeview is confusing
  • Issue 2409: Default Treeview should present entire hierarchy with all descendents

• Additionally, problems with viewing archival descriptions in treeview while working in languages other than English have been reported by users of 1.3:
  • Issue 4409: Treeview shows duplicate entries in language other than English
  • Issue 4410: Title of archival description dropped from Treeview in Language OTHER than English
• Further community consultation on future improvements and changes to Treeview will be implemented as well (see below):

Use Case Reviews and Possibilities for Treeview Development

In an effort to remain transparent, responsive to user feedback, and to better outline the challenges and opportunities that further Treeview development presents, Artefactual Systems (lead developers of the AtoM application) has prepared the following table, based on comments and suggestions received via the AtoM user discussion forum. In each case, Artefactual's systems analysts have attempted to outline a summary of the feedback received, the requirements for an ideal outcome that would resolve the issues noted in the feedback, and several potential solutions that might be incorporated into the development roadmap. Artefactual developers will then review the possible solutions and post commentary on what is feasible given the coding structure, as well as an estimate of development costs associated with the proposed improvement.

As the chart is developed, Artefactual intends to invite further user feedback on the proposed solutions, as a means of garnering a community consensus on the development roadmap for Treeview in AtoM's 2.x releases and beyond. Artefactual is exploring the best means to gauge community interest on these possible solutions, and may incorporate the use of simple user polls via Survey Monkey or similar public services. Users are also invited to submit wireframes and mockups for potential solutions - either via freely available, web-based wireframe programs such as Moqups, or through personal wire-frame software design submissions. These will be hosted on the Treeview wiki page, and users will be encouraged to discuss the solutions via the User Discussion Forum.

Tell us what you think in the ICA AtoM User Discussion Forum: we have a discussion on Treeview already started, and would love to hear from users about their preferred solutions from the chart below!

Developer Discussion (1.x)

+XX .. link

• As part of the Scalable UI controls upgrades the total number of resources shown in the Treeview was restricted. In cases where there are more than ten (10) resources at any level of the hierarchy, only the first 10 resources will be displayed, with an +XX... link showing the number of hidden resources at that level. Clicking the link will expand that branch to show all descriptions at that level.
  • Original discussions on this requirement can be found in issue 1068, and more specifically, issue 1303.

• Behaviour:
• The +XX .. button appears only when there are more than 10 children or more than 10 siblings for the current branch on the show screen (see Figure 1);

• Any object that has more than 10 children displays the first 10 children followed by a number indicating how many children are hidden (see examples in screenshots - + 23..., +126 ... etc.)
• The +XX .. button shows a spinner as soon as you click it indicating some activity that an AJAX request is being processed
• When the Ajax response is returned, then the treeview is dynamically expanded, and all resources in that branch are shown

Figure 1:Series show screen: this series has 33 files. Note that clicking the "+ 23 ..." link would show all 33 files in the series

• When viewing an information object that is sorted further down the sibling list than the first 10 siblings, show the first nine objects in the list, then the current object as the 10th item in the sibling list (See Figure 2)
• Reloading the page or clicking a link to another resource in the current hierarchy resets the Treeview to the default state

Figure 2:Show screen for file 18 out of 33

Natural sort

Sorting the treeview by title or identifier+title (available in the Admin > Settings > Global) often produces unexpected results because they are not sorted in "natural" order.

For instance, identifiers:

• IMG 1
• IMG 2
• IMG 10
• IMG 11
• IMG 100

Currently sort as:

• IMG 1
• IMG 10
• IMG 100
• IMG 11
• IMG 2

See http://www.codinghorror.com/blog/2007/12/sorting-for-humans-natural-sort-order.html for a description of natural sort vs. "ASCII" order (though note that MySQL is case-insensitive for sorts).

Adding Natural sort to SQL

MySQL [1] and PostgreSQL [2] do not support natural sort natively.

A web search for "MySQL natural sort" brings up numerous posts on how to do natural sorting in MySQL, but they are mostly too simplistic (i.e. they sort by length of string, then by string, which only works in some cases).

There is a fairly robust natural sort for MySQL/PostgreSQL using stored procedures http://drupalcode.org/project/natsort.git/tree/refs/heads/5.x-1.x but the README indicates that this procedure is quite slow, and thus it uses a hash table to compensate. This raises issues of trying to maintain the hash table when data values change. Using stored procedures also has administrative and security implications.

Pre-sorting

Another option is to do the sorting on the backend

1. Administrator would select a fonds, series, etc.
2. There would be a "sort" button that would allow sorting the fonds, series, etc. children by title or identifier+title
3. Clicking the "sort" button would re-order the children permanently by updating the Nested set values or by populating a hash table

Pros:

• Front end sort is fast, because it's using simple nested set sort, or hash table
• Can be slow on the backend, if it only needs to be run occassionaly
• Can use existing PHP natsort() functions, instead of writing our own in MySQL
• Administrator can tweak arrangement afterwards if there are anomalies with Drag-n-drop sorting feature

Cons:

• Sorting I18n values is impossible with nested set sort, but possible (if complicated) with by introducing a "culture" column to a hash table
• Hash table maintenance issues?
• Sort table + Nested set is somewhat redundant and may conflict

---

• Back to the Treeview page
• Back to the Development section
• Back to AtoM wiki home