Usability review

From Qubit Toolkit
Jump to: navigation, search

This page captures discussion related to usability features. Usability refers to the ease with which users can use software to accomplish their tasks. From Wikipedia,

"Usability is a qualitative attribute that assesses how easy user interfaces are to use. The word "usability" also refers to methods for improving ease-of-use during the design process. Usability consultant Jakob Nielsen and computer science professor Ben Shneiderman have written (separately) about a framework of system acceptability, where usability is a part of "usefulness" and is composed of:

  • Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
  • Efficiency: Once users have learned the design, how quickly can they perform tasks?
  • Memorability: When users return to the design after a period of not using it, how easily can they re establish proficiency?
  • Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
  • Satisfaction: How pleasant is it to use the design?" wikipedia:Usability

The following issues relate to reviewing the usability of Qubit for release 1.1, scheduled for April 2010. The issues linked to below are mainly new features and enhancements, not known bugs which affect usability.

Contents

[edit] Buttons and icons

[edit] Button block design

From left to right: edit, delete, upload digital object, link physical storage, add new

Problem: Current button block design is cluttered because it contains buttons with a lot of text (e.g. "Upload digital object" and "Link physical storage"). Replacing text buttons with icons would be cleaner and would also be useful in multilingual installations because the button block's appearance would remain consistent across different languages.

  • Chosen solution:
    • Change labels on button block so that they are icons instead of text, issue 872
    • Alt text tags would be used to indicate what each icon means
    • This is a very rough draft of what the button block might look like for an information object view screen. We may want to make these monotone/greyscale instead of color

[edit] Floating button block

Title bar with button block functions added to it

Problem: Floating button block can hide some fields when the user is entering or viewing data, issue 1181.

  • Chosen solution:
    • Move the "action" div and add its functions to the title bar, see image
    • "Cancel" and "Submit" buttons will stay at bottom of form, but won't float
  • Option 2: move the buttons in a bar along the top of the context menu box
    • The plan is to move everything that is not "context" out of the context bar (like the "export XML" links below)

[edit] "Add new" button

Problem: "Add new" button not obvious. From LAC review of 1.0.8, "The button for adding new records is very small and poorly placed. It is not obvious to new users how to add new records.", issue 1155

  • Chosen solution:
    • The "add/edit" menu is being replaced with an "add" menu item (e.g. selecting "Add > Archival description" will go directly to the information object create page). There will no longer be "list" page with an "add new" link, see Object landing pages
    • The "add child" button will be in the button block as an icon, but shouldn't need particular emphasis

[edit] Spacing between edit and delete icons

  • Add some space between edit (pencil) and delete (x) icons so that users don't accidentally delete when they're trying to edit, issue 770

[edit] Delete icon appearance

  • Inconsistent delete icon appearance. For multi-value auto-complete fields the delete icon is to the left of the data and appears as a circle which turns into an X when the cursor is moved over it; for non auto-complete multi-value fields the icon is a grey X; in admin > settings > i18n languages the delete icon is a blue X, issue 1170

[edit] Pager links

Problem: the "<" and ">" characters used as paging options in the list templates are reserved characters so they prevent W3C compliant violation

  • Option 1: replace with graphical icons
  • Option 2: Use safe entities ("&gt;", "&lt;") [1]

See issue 1305

[edit] List of required icons

  • add new
  • edit
  • delete
  • upload digital object(s)
  • edit digital object
  • link physical storage
  • XML export (clicking icon exports default format for that template, an arrow next to the XML icon presents a drop-down menu with other XML export options)
  • print
  • reports (arrow beside icon, clicking shows list of report options, as per xml export. Default option?)
  • duplicate
  • pager icons, |< << >> >|

[edit] Digital object upload

[edit] Button/icon

Problem: there's no option to add multiple digital objects to an information object that is already linked to a digital object (it only displays an "edit digital object" button option instead of "upload digital object"). See discussion

  • Chosen solution:
    • Show "upload digital object" (icon) if no linked digital object, and "edit digital object" (icon) if one is linked at current level
      • User:David I think the icon for both functions should be the same, just different "alt text"
    • Importing multiple digital objects as children of current information object is a separate button
  • Option 2: Keep "upload digital object" as an option that is always available and then also show "edit digital object" as an option if the information object is already linked to a digital object
  • Option 3: Show "edit digital object" button if a linked DO already exists, and allow users to delete and/or replace the image from that page (i.e. all digital object functionality happens on the same page)

[edit] Upload page

Problem: how to present the three options, 1) upload single object and link to current information object, 2) upload multiple digital objects and add as children to current information object, 3) link information object to an external URL which resolves to digital object resource. See related discussion and issues 344, 1097, and 1053

  • Chosen solution: Split upload/link digital object from import digital objects. Have a separate button for each from show screen. If information object is already linked to a digital object then "upload/link digital object" will take user to edit template for that digital object. This also leaves the door open to use the import option to upload XML files in addition to digital objects (e.g. import an EAD or DC XML file and add them as children of the current information object)
  • Option 2: Only show Flash upload option if user has JavaScript/Flash support. Can use the uploader for both single and multiple uploads. Show external link upload in a separate fieldset
  • Option 3: Show each option in a separate fieldset (fieldset 1) Upload a digital object (fieldset 2) Link an external digital object (fieldset 3) import multiple digital objects. Hide fieldset 3 if JavaScript/Flash support is absent

[edit] Reporting

[edit] Printing finding aids

Print

[edit] Selecting reports

Problem: as more report options are added, can't have a UI button for each one

  • Chosen solution:
    • Keep report icon contextual (e.g. "File/item list" and "Physical storage list" on information object show layout, "Search results" on search page)
    • Add "arrow" icon next to report button, clicking it show a list of possible reports for user to select
    • Default action for 'report' icon (i.e user doesn't click arrow)?
  • option 2: have a "print screen" button to print info on current template. Have a separate "reports" button which navigates to a reports landing page (using the object from which the user navigates as the object to load into the report)
  • option 3: add a separate reports section to the admin menu. The problem with that is the select/filter to decide which objects to run the reports on
    • creates the same scalability issues we had before with parent select & digital object import
    • Options 1 and 2 use the idea of starting with the object, then choosing an action for it

[edit] View screens

[edit] Limit field display length

  • Limit display length of history field in archival description view screen; possibly add ellipses to allow the user to expand and collapse the field, issue 537
    • Can we do this in a generic way to allow the same behavior for all field values over a set length?

[edit] Physical storage in context menu box

  • Currently physical storage locations for all levels of description are shown as a list in the context menu box at aggregate levels of description. This causes page-loading delays for descriptions with a large number of child records (issue 1131). It's been debated whether it is useful to have this list in the context menu box and it has been suggested that a pager be added like the holdings pager in the context menu for the repository template (issue 652).
  • User:Evelyn I favor removing physical storage from the context menu box at aggregate levels of description. The ability to print lists of physical storage locations should instead be a reporting feature, see Reporting#Physical storage locations
  • User:Richard I agree with Evelyn. Showing the storage locations at the higher level isn't too important for us, but being able to print a list would be very useful

[edit] Automatically switch between templates

  • If a description was created using a given template the view screen for that description should automatically switch to the correct template. For example, if a user does a search and the results are mixture of Dublin Core and ISAD descriptions, clicking on a Dublin Core description should take the user to a Dublin Core view screen and clicking on an ISAD description should take the user to an ISAD view screen. This is important because some institutions are combined archives/libraries and will want to use ICA-AtoM for both types of materials, issue 135
    • User:Richard Agree. Even when the same type of material is being described, it's good to know whether the archivist used - e.g. RAD or ISAD(G) - because the elements between the two don't always map cleanly, good to know which template was originally used
      • User:Peter Could use the informationobject.rules element for this. This is what it was intended for. Right now its free text. Can change to a taxonomy that consists solely of the available templates. Auto-populates when creating a new record (e.g. set to Dublin Core when using DC template, RAD when using RAD etc). Then use this value to determine which view template to show to user by default. If a user subsequently decided to change the description (e.g. going from DC to RAD) leave source option configurable so they can decide whether to change it from DC (original) to RAD (revised)
        • This is also needed to support import/export crosswalking issues, e.g. we may need some separate mapping rules or even templates if exporting RAD->EAD than ISAD->EAD or DC->EAD. We can then also use the @encodinganalog values of EAD imports to set the source standard and display the correct template post-import

[edit] Hide fields from unauthenticated users

Problem: Some institutions want to hide some fields from unauthenticated users because they are likely to contain donor information, draft notes or other information of use only to archivists, issue 1254

  • Chosen solution
    • Rather then make an arbitrary decision about which fields in each standard should be visible or hidden, add a separate "Internal notes" field that is not visible to unauthenticated users (?) (User:David We need to decide on exact privilege required)
    • Make a wiki page/tutorial on how to manually remove fields from a template (i.e. with a text editor).
  • Option 2:
    • In ISAD view screen, hide archival history; immediate source of acquisition or transfer; appraisal, destruction and scheduling information; notes
    • In RAD view screen, hide custodial history; immediate source of acquisition; physical condition note; conservation note; general note
    • See the discussion thread at http://groups.google.ca/group/ica-atom-users/browse_thread/thread/6343bb928f2ee13d?hl=en#.
    • There's always going to be the issue of which fields to show and hide for a particular institution (e.g. User:Richard definitely wants Custodial history and Immediate Source of Acquisition visible to everyone.)
  • Option 3: make displayed fields configurable, i.e. the Administrator can choose which fields to turn on/off.
    • The preferred option would be to make it configurable, but this is not feasible for 1.1. Hiding certain pre-specified fields is a compromise
    • User:Peter: Our experience over the past 3 years tells us that each institution might have a slightly different policy on which field(s) they want to hide from public, so Option 3 is definitely preferred: namely, some type of UI from which the Administrator can decide which fields should be hidden from public view. This should be possible on a per form basis (e.g. viewRAD, viewISAD, viewDC) Just to clarify; for ACL we are talking about adding one new permission: "view restricted fields" rather than create a "view field" ACL rule on a field by field basis (that could end up being a performance hit not to mention an ACL permissions configuration nightmare). So the 'view restricted fields' permission can be assigned to all authenticated users by default while still allowing the administrator to then further refine access by assigning or not assigning the permission to specific user groups.

[edit] Replace fullscreen layout with modal popups for images

  • Currently master images are shown with a specific layout for fullscreen. We prefer modal popups like lightbox, thickbox, shadowbox. See issue 1295 and qubit-dev

[edit] Sorting in information object treeview

  • When sorting by identifier in information object tree view, numbers sort alphabetically instead of numerically, so the user ends up seeing, e.g. 1, 10, 100, 11, etc. issue 1145

[edit] Menus

[edit] Main menu scalability

Problem: the current design of the main menu does not allow for the additions of new menu options once all the horizontal room is occupied, issue 1309

  • Chosen solution: using a pure list/CSS layout, convert the menu to horizontal drop-down
    • Limit to two level hierarchy to avoid "fly-out" arrows and UI problems associated with them
    • Menu levels beyond two go into template (e.g. themes vs. plugins)
    • Make both users and groups second level menus (have more room for this with this layout)
    • Design ideas:
      • "works in all modern browsers including IE6 without the need for conditional comments, tables, hacks, extra markup or javascript." [2]
      • This one looks even better [3]. Updated as late as Dec 2009. Valid css/html, no javascript, cross-browser tested (incl. IE 5.5-8)
      • Smashing magazine: horizontal menu best practices (2009/09)
      • Smashing magazine: the case against vertical menus (2010/01)
      • Relatively tasteful example: Digg.com
  • Option 2: using a pure list/CSS layout, move the main menu to a left vertical column and convert it to a vertical drop-down, [4]
    • Because this introduces a new left-hand vertical column to the layout it would require further logical re-organization of the global layout. So it's a more obtrusive change than option1
    • A 3-column layout (menu, content, context bar) is going to really limit our main content width
  • Option 3: Increase vertical nesting. Less options on any one level. We already have a few spots where 3rd level menus have been used (themes plugin, users/groups), but they are not integrated into the menu layout yet
    • This assumes that the final set of menu options is static. However, it is difficult to predict what menu options will be added in the future and whether these will fit into a tightly defined hierarchy

[edit] Admin menu organization

Problem: menu options under Admin are not grouped logically, issue 743

Chosen solution: Break "settings" menu into smaller, more specific, better defined menus

  • Settings is only "Global Settings"
  • Languages
  • Group "Site information" and Themes > configuration together
  • UI labels & default template - "Site Defaults"?
  • "OAI"?

[edit] Seperate admin pages for themes and other types of plugins

Problem: Themes are mixed in with other plugin types on the admin page. The difference between the two is not obvious Option 1: There should be two seperate plugin admin pages. One for theme plugins and one for all other plugins

See issue 1307, also related issue 1308

[edit] Breadcrumbs

Problem: With horizontal collapsible menus the current navigation context is not obvious to the user

Chosen solution: Implement breadcrumbs for release 1.1 to replicate current menu functionality (i.e. "single path" to page)

  • Replace large text template names (e.g. "View archival description") with small text breadcrumbs (e.g. "add/edit" > "view archival description"). This also wins back some vertical screen real estate
  • In future, add "history" functionality to track multiple navigation paths to a page and correctly display the navigation path (e.g. "search results > view archival description" or "browse results > view archival description")
  • As part of "history" upgrade (post 1.1) make the "search results" breadcrumb node hyperlink link to the actual search results query (this addresses the return to search/browse results issue)

[edit] Object landing pages

[edit] Data entry

[edit] Duplicate records template

  • Add ability to create record templates for creating large numbers of similar records, issue 411
  • Desired behavior is as follows:
    1. In information object show screen, user clicks "Duplicate" button
    2. Duplicate of current object opens in edit screen
    3. Green text above title bar reads "This is a duplicate of record NYZ..." (NYZ would be the reference code of the original object?)
    4. Identifier field in duplicate record is blank, preventing the user from saving an exact duplicate of the original record
    5. User edits data
    6. User clicks "Save" button
    7. Show screen for duplicated record is opened. Note that there's no longer a warning that this is a duplicate record

[edit] Deleting repositories

  • Deleting archival institution should give option of deleting all associated archival descriptions, issue 403

[edit] Changing parent level

Problem: Users can only change the parent level by dragging and dropping within the treeview, which only shows the current fonds/collection. This means that users can't make a child-level description a top-level description or move a child from one top-level description to another, issues 1042 and 1011 and discussion

Chosen solution: Restore "parent level" as an autocomplete field, with a "empty" value which makes description top-level. Limit the possible options to top-level descriptions only (i.e. not the whole information object hierarchy)

[edit] New vs. revised descriptions

Problem: In recent updates, no distinction between new descriptions and ones that have just been revised, issue 1167

Chosen solution:

  • For users show the "recently added" descriptions (e.g. sort by "date added" instead of "date modified") as default for browse results
  • For administrators make "recent updates" a management tool, with additional options, see below

[edit] List all draft status descriptions

Problem: The only way for admin to see only draft descriptions is to search for "publicationStatusId: 312"

Chosen solution: For administrators make "recent updates" a management tool, with a filter for publication status.

  • Perhaps add filter for sorting by "new" vs. "revised" (see above)?

[edit] Editing and translating notes

  • Make note fields editable and translatable. Currently the user cannot edit a note; s/he has to delete it and enter a new one to make a change. Also, because they're not editable, notes are also not translatable, ssue 568

[edit] Selecting related resources

Current behaviour in ISAAR and ISDF Related resources dialogue box

In ISAAR and ISDF relationships area, title of related resource auto-complete list shows all levels of description, issue 1204

  • The user cannot distinguish between different descriptions with the same title - e.g. multiple series across multipe fonds entitled "Correspondence"
  • If there are more than 10 descriptions in the system with the same title, the user will be unable to select some of them, because the auto-complete list shows only the first 10

Possible solutions:

  • Add reference code to results in auto-complete list
  • Add all levels of description preceeding the level of description in the auto-complete list. For example, instead of "Correspondence" the auto-complete field would display "Park Board fonds/Office of development and integration/Correspondence"
    • Would be helpful to add date to that too: "Park Board fonds/Office of development and integration/Correspondence - 1959-1982"
  • If more than 10 descriptions in the system have the same title, expand the auto-complete list to accommodate all the choices

[edit] Disable or remove navigation and context menu

Problem: During the CSS update the navigation menu (revision number?) and treeview (revision number?) were removed from the edit templates to avoid users accidentally navigating away from the edit form, losing data. There was concern that this would be disorienting for users [5]

  • Chosen solution: keep main menu and context menu on edit templates
    • "Grey out" or increase opacity of main menu if easy, quick win with CSS
  • Option 2: keep navigation menu and treeview hidden to reduce the number of navigation options when using the edit template.
    • reduces context for current object, which can be disorienting
  • Option 3: create a modal effect where the other menu options are greyed out and only the edit form is active
    • less disorienting than removing menus
    • do we have time in release 1.1 schedule?

[edit] Search/browse

[edit] Return to search/browse results

  • Add a "return to search results" button and "return to browse results" button to the archival description view screen. Otherwise, the user does a search or browse, checks out one of the results and has no obvious way to return to the search/browse results. They can do it by using their browser's "back" button but this is not intuitive and may be problematic if they have navigated to various levels of description in an archival description, issue 573

[edit] Search results screen

  • Add reference code, date range, level of description and name of creator to search results screen. Date range and level of description help users understand their search results better; reference code allows them to tell the archivist exactly which records they want to, issue 1135

[edit] Distinguish search options

  • From DAF review "On most pages there's a general search box at the right hand side, and in some cases more restricted search boxes feature at the bottom of the screens (e.g., limiting queries to authority records or institution records). The difference between these two boxes is not immediately clear."
  • User:Evelyn Could put a label over top the search box in the classic theme: "search archival descriptions"

[edit] Ability to filter search results by language

  • Users should be able to limit search results to one language in multi-lingual systems if desired, possibly by adding a boolean operator followed by a language filter: for example, "Lamontagne & sourcelanguage=fr", issue 1297

[edit] Browse results display

  • Archivists and public end-users expect to have browse available as a navigation/scoping option, even if the results are not scalable
    • From Google Analytics: MemoryBC top content (Nov 1, 2009 - Feb 15, 2010)
      • 1. homepage (5113)
      • 2. name browse (1797)
      • 3-5. create subject term, create place term, create repository
      • 6. repository browse (1216)
      • 7. create actor
      • 8. subject browse (1195)
      • 9. information object list (from 'Add/Edit' menu) (995)
      • 10. place browse (964)
      • 29. keyword search (185)

[edit] Browse examples

  • World Digital Library Browse is a primary navigation option, browse result pages broken down into sub-categories
  • Online Archive of California Browse is a primary navigation option (browse collections, institutions, and map). Alphabetic option provided for browse collection by title (returns one long, unpaged list of all hits)
  • Getty Museum Browse is a primary navigation option, alphabetic browse used for artists. Large browse results sets returned with pager, sorted chronologically by creation date
  • Smithsonian Air & Space Museum Browse is a primary navigation option. Large browse results returned with pager, sorted alphabetically
  • Canadiana Discovery Portal in BETA Browse is a primary navigation option.
  • Last FM Long browse list presented with pager, sorted by "popularity", "hyped"

[edit] Configurable browse options

  • Make browse options an admin setting, since different institutions will want to browse by different filters. For example, many of them may not want to browse by media type, issue 480

[edit] Browse option select method

Problem: Using two different methods (HTML list vs selection option form) to present browse options is not very maintainable across different themes

Chosen solution: Use HTML lists to output browse options

  • Most recognizable interface for users (some found the select box confusing)
  • If browse list is too long, user can remove browse options through the admin interface (see above)

[edit] Layout wireframe

Qubit-layout-wireframe.png

[edit] Links

[edit] Theme design ideas and resources

[edit] Open source icon libraries

[edit] UI standards and guidelines

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox