Sakai 'More' Tab Design

Owned by Allison Bloodworth
Last updated: Jul 17, 2009Version comment
28 min read

(relocating from http://confluence.sakaiproject.org/display/UI/Sakai+%27More%27+Tab+Design as Sakai is planning to delete this page. It was originally created on Oct 18, 2007.)

Project Goals

Project Goal: "The goal of these changes is to make the interface a little easier to read, have it take up less screen real estate, and make it more conventionally recognizable to users. We'll also add accessibility semantics and test it with some assistive technologies." - Colin Clark
The 'More' tab in Sakai has long been a known usability issue.  Indiana University has implemented a new design to allow users to see all their sites at once.  The general consensus in the community is that the concept is good but there are several usability and accessibility issues with the current implementation.  The Sakai community it currently voting on including the implementation in the 2.5 trunk.  By default it will be turned off and institutions interested in it can turn it on.  The conversation in the Sakai community has mostly happened in Jira and on the email lists:

A screencast is available which shows this feature (styled as a div which pushes the rest of the page down) in use in Oncourse (seek to 3:15min):  http://tinyurl.com/2b5fs5

"Out of the box" Sakai w/SAK-10448 patch: http://wiki.fluidproject.org/download/attachments/1706420/more_sites_before.png?version=1

Georgia Tech's implementation of SAK-10448 (styled as a floating div which floats over other content): (server no longer available)

The Fluid team is beginning to look at the new design with the goal of continuing improvement by making needed usability and accessibility changes.

Work Plan

1. Short term: in time for 2.5 Code Freeze:

  • Goal: just mitigate the worst problems
  • Focus on presentational improvements
    • Explicit tab metaphor
    • Drawer into drop-down menu
  • Wording changes to Customize Tabs
  • Accessibility improvements to 10448
  • Clearly articulate the current weaknesses, and our plan for later changes
  • Decide if we can squeeze some helpful new behaviour in as well

2. Medium term: Emphasizing thoughtful use of Tabs and addressing related UI issues (Customize Tabs, Worksite Setup)

  • Rework Customize Tabs and Worksite Setup accordingly
    • including customized interfaces for osp portal
  • Determine whether we can make More Sites the default
  • Accessibility tweaks; make portal-friendly
  • Display "All Sites" as a separate page when there are a large number of sites.
  • Deep linking from tab nav to customize tabs

3. Long term: questioning basic assumptions in the portal and the framework

  • Is the concept of tab navigation best for Sakai?
  • Is a portal the best solution for Sakai?
  • Is the concept of Sites ideal?

Project Plan

2.5

  • Confirm final wording and layout for text changes on Customize Tab & implement in mock-up
  • Add link to Worksite Set-up in My Workspace mock-up
  • Fix Documentation bug
  • Consider doing usability testing on 2.5 changes
  • Accessibility evaluation of JS drop-down and tabs to make sure there aren't any major problems
  • UofT will implement changes to Customize Tabs and fix any accessibility bugs

2.6

  • Create mockups for "variable tab number" scenario (Beth/Michigan)
  • Finalize changes to Worksite Setup in mock-up
  • Finalize design for "All Sites" page ('many many sites'). Can we roll this into the Worksite Set-up changes?

Bugs We Are Currently Working on

Mock-ups of Suggested Designs

  • Working instance of Sakai: http://build.fluidproject.org/portal; use user ID & password: demo
  • HTML/CSS Mock-up:  http://www.fluidproject.org/work/SAK-10448/ (Tested in Firefox 2.0.x Win & Mac, IE 6/7 Win)
    • Known Issues with HTML Mock-up:
      • The mock-up should be seen as an example of visual design and functionality only. Implementation details and specific markup are expected to change in the actual implementation.
      • The mock-up has been tested in Firefox 2.0.x in Windows and Mac OSX and IE7 for Windows.
      • ARIA Markup and other accessibility semantics were left out of the prototype but will be added in the final implementation.
      • Screenshots have been used to represent the left navigation and content area. Thus, they are not clickable or able to interact in any way.
      • Select boxes on "customize tabs" page for Option #1 are disrupting drop-down layout because a known bug in Firefox for OSX.

User Scenarios

* Explore this scenario in the prototype by clicking the link to Option #1 *

1) It is Joe Smith's second day of his sophomore year at his university (Fall 2007). He logs into Sakai and sees that he's landed on the "My Workspace" tab. He is presented with 5 other tabs after "My Workspace;" two of them are courses he attended earlier in the week, there are two projects he worked on over the summer, and one tab is called "All Sites." He would like to find the sites for his two courses which begin today, but doesn't see tabs for them.
2) Joe clicks on the "All Sites" tab to see what is there. He sees a list of all the courses he's taking this semester along with those he's taken in the past, as well as his project groups and portfolios. He sees another course he's registered for this semester, "Another Course," which is meeting today, clicks on it, and reviews the site for this course.
3) Joe wants to view the site for the other course he's taking this semester. He goes again to the "All Sites" tab and clicks on "Big Course Name." He reviews the information for this course.
4) Joe notices the "Customize Tabs" link and wonders what that would do. He clicks on it.
5) Joe sees that there are three different categories that his sites may fall into: Favourite Sites, Active Sites, and Archived Sites. He notices that one of his current courses and two the projects that have been completed are listed in Favourite sites. He decides to move the two project sites to "Other Active Sites" by using Shift and his mouse to select them all, and then move them over using the arrow between the two lists. Now only four tabs are displayed: "My Workspace," "Course Name," "Big Course Name," and "All Sites." (This functionality is not available in the prototype.)
6) Joe then tries to move his other three current courses to "Favourite Sites" by using Shift and his mouse to select them all, then the left arrow button to move them from the "All Active Sites" box to the "Favourite Sites" box. He receives an error message saying, "You may only specify three Favourite Sites. If necessary, move a site or sites to 'All Active Sites' or 'Archived Sites' in order to make room for new Favorite Sites." (This functionality is not available in the prototype.)
7) Joe decides to use the "Control" key along with his mouse to just select "Another Course Name" and "Big Course Name." He then uses the right arrow button to successfully move these sites into Favourite sites, and the up and down arrows to select the order of the tabs. Now six tabs are displayed: "My Workspace," "Another Course Name," "Course Name," "Big Course Name," "Big Course Name," and "All Sites." (This functionality is not available in the prototype.)
8) Joe wonders why "Big Course Name" is displayed twice in the tabs. He would like to see the other course he is taking this semester, so he goes to the "All Sites" tab and selects "Last Course Name" from the drop-down. Now six tabs are displayed: "My Workspace," "Another Course Name," "Course Name," "Big Course Name," "Last Course Name," and "All Sites." (This functionality is not available in the prototype.)
9) Now Joe needs to review information in the "Course Name" site so he clicks on that tab. The same six tabs are displayed, but the "Course Name" tab shows as the "active" tab.
10) At the end of the day, Joe logs out. The next day when he logs back in, the same six tabs he saw at the end of the day yesterday when he logged out are displayed: "My Workspace," "Another Course Name," "Course Name," "Big Course Name," "Last Course Name," and "All Sites." He wants to review his portfolio, so he clicks on the "All Sites" tab, then clicks on "A Portfolio" in the "Portfolios" category. He now sees the following six tabs: "My Workspace," "Another Course Name," "Course Name," "Big Course Name," "A Portfolio," and "All Sites." He realizes that the first three tabs after "My Workspace" remain the Favourite tabs he's specified, and the tab right before "All Sites" seems to rotate based on what he selects from the "All Sites" drop-down.

* Explore this scenario in the prototype by clicking the link to Option #2 *

1) Sally Jones is an instructor teaching several courses who is also working on several projects, the members of which use Sakai to collaborate.
2) When she logs into Sakai, she is in My Workspace, and sees 4 tabs across the top: "My Workspace", "Courses", "Projects" and "Portfolios"
3) She would first like to update an assignment in a course she is teaching, so she clicks the "Courses" tab, and sees a list of her courses in alphabetical order.
4) She finds the course she is looking for and clicks its name.
5) Now she is at the homepage of the course.
6) After completing her task within the course, she decides to check the status of one of her projects.
7) She clicks the "Projects" tab, and is presented with a list of her projects ordered alphabetically.
8) She notices that a few of the projects on the list are very old, and decides to archive them so that they don't show up in this list in the future.
9) She clicks "Manage Sites," which brings her to a page with a list of her archived and active sites in two select boxes.
10) Using the arrow buttons, she moves the old projects over to the "Archived Sites" box (this functionality is not available in the prototype.
11) She clicks on the "Projects" tab to return to her list of projects and notices that the sites she just archived do not appear anymore.
12) She finds the project she was originally interested in, and clicks its name.
13) She is now on the homepage of the project.

Analysis of Other Tab Implementations

Screenshots of various examples of tabbed navigation is available here: http://www.jakeo.com/words/tabs.php. Note that the Amazon and Wal-Mart examples (neither of which are active on their site any longer) show tab implementations which solve the problem of handling more tabs than fit horizontally on a page in a similar fashion to the proposed Sakai solution. However, these are obviously (not sure how much) older versions of their sites.

On the current version of Amazon.com a single box drops down on rollover for the "See all 41 product categories" tab, showing a categorized list of the tabs from which the user may select. The box does not go away when the user removes their mouse from the tab, which makes it easier to use/more accessible. This design may be more intuitive than the currently proposed Sakai solution. It makes sense for the rollover box to disappear when the user selects a tab, as opposed to the disorienting effect produced when the whole page moves up when a course/project is selected. Care would just have to be taken to make sure the tab appears in a logical place for the user -- probably on the right just before the "More" tab.  Also,  "More" isn't really a logical name for this tab because it shows all the available tabs, not just what isn't currently visible in the "favorite" tabs.  Another potential name for it might be "Show all tabs" or "Show all sites."

The Amazon solution appears to be accessible, as when the user actually clicks on the "See all 41 product categories" tab (instead of just mousing over it), they are taken to a page showing all the tabs. Though most users probably wouldn't use this page, I do find going to a page whose function is just selecting a tab more logical than moving the whole page down and adding it as a function to a "regular" page. Is there a situation where the user may need to see the available tabs while looking at a page in the currently active site? I find it confusing that Amazon doesn't show the "See all 41 product categories" tab as selected when the user is on that page. We'd want to show that tab as active if we used a similar solution. The main question I have about this solution is whether it would accommodate a drag-and-drop implementation for moving the tabs around as is mentioned on the Oncourse screencast. However, I'm not sure if selecting a tab and changing tab order/favorites should actually share the same interface.

iGoogle (http://www.google.com/ig) also has a "More" "drop-down"at the top of the page  which it appears may also be implemented in a floating div. They also allow users to add as many tabs as they'd like to their customized interface, though it appears that users can add tabs until it "breaks" the layout. Interestingly, each tab also has a similar floating div "drop-down" which gives users the ability to take an action on each individual tab.

On the other hand, it seems that the general consensus is that tabbed navigation may not be the right metaphor when you have more than 6-10 tabs. (See Yahoo! Design Pattern Library's Navigation tabs pattern, Welie's Tabs pattern, UC Berkeley's Web Patterns site Navigation Tabs pattern, and Using Tab Patterns with Web Applications). If we agree that that is the case, we may want to consider other options. One option would be to consider putting all navigation in the left nav and allow users to drill down to the selected site then the choose from the available tools. See the IST Staff Website which uses the Drupal Content Management system as an example. This may also help orient users when there is a hierarchy of items within a tool, but it seems that it would be better for the left nav to remain stable as much as possible (which would not be the case with this solution) so users have a consistent experience across sites.  Alternatively, Firefox 2.0's scrolling tabs or Internet Explorer 6.0's shrinking tabs are other possible solutions to consider. Here is an interesting discussion about Firefox's tabs. I am unsure, however, if it would be confusing or work as well to use the same metaphor as a browser in a web application. Will the user have any trouble understanding where the browser ends and the web application begins? I am guessing this type of solution would also be more difficult to implement.

As is mentioned in the Oncourse screencast, it may also be helpful to think more about how the "favorites" tabs will be presented and selected. Perhaps only sites specifically selected as favorites should be shown as tabs (if it is made obvious during the site addition process that this is an available feature that must be set up specifically). As users do not often discover that they have the ability to modify the order of their tabs (as well as which tabs appear), it is likely that we should also consider adding a "Customize tabs" (or similarly named) button.

After a review of other solutions, we have discussed implementing a DHTML "More" Dropdown:

Design Notes from Mailing List Discussions

Here are some design points from the mailing list discussions, we can use these as a general guide for our new design. Especially relevant emails have been collected in this Email Summary.

Changes to Tab Behaviour:

  • There were several suggestions to implement the div as a "drop down" so that it did not push other content down while expanded. Georgia Tech has an implementation which changes the CSS to create this effect. Important to note that this can be customized in CSS.
    • "Also where the div appears on the page layout is configurable per institution via CSS. GATech has already done a custom modification that moves it to the upper right corner of the screen, for example, instead of pushing down the page content." IB
    • "Favorites bars are differentiated from content tabs by their smaller size and appearance; content tabs show current content that is open, rather than all the possible tabs that can be opened. I think there's too much going on. " ME
  • If the new UI is disabled by default, the old implementation should be updated to sort by option group (http://www.netmechanic.com/news/vol4/html_no20.htm)
  • If we are using the tab metaphor, the "click should continue to behave as expected (i.e. you 'go to' that tab) - if the tab is to become more like a menu, then we should consider using onMouseOver instead.
  • The maximum number of tabs which can be displayed is should be a configuration option

The "All Sites" Contents:

  • Changing the wording from "More" to "All Sites" make the menu contents less confusing
  • The list of sites should be separated by type - "Project", "Course", and "Other" to help users locate a specific site.
  • The list of sites should be sorted in a reasonable way
    • I'd like a default ascending sort on terms instead of an undetermined order.
    • I'd also like a switch to have terms display off, for both 2.4 and new layout.
    • How are the courses sorted?
  • Give users a way to get to "Customize tabs". This link should be within the context and visually linked to the tabs (i.e. as part of the "all sites" menu, or as a link in the tab bar itself (see google "igoogle" example for "Add a Tab")
    • "Most of our users don't think "how could I customize to do things better in general" but more "I wish this thing I'm trying to do now didn't suck.."" JS
  • Users often collect large numbers of sites, and the menu would have to be able to scale to accomodate them. What happens when the sites won't all fit on the screen? Scrollbars?

Changes to Preferences:

  • Users can't find preferences, perhaps move the link out of "My Workspace" and into the top level nav (with "Logout")
    • "I think it makes sense to focus My Workspace on content-tools and associate preferences with login/logout" DP
  • Suggestion to re-organize the Preferences section using a "Closable Panels" pattern:
  • One suggestion was to move Account under Preferences since it doesn't contain much information DP
  • The "Customize Tabs" section might be reworked so that it is clear which sites will appear in the tabbed area.
    • Future enhancements might be to allow users to create 'cluster-tabs' through the Customize Tabs interface
  • The page that appears when you click "My Workspace -> Preferences" is actually the first subtool "Notifications", but there is no visual indication that this mode is active. Subsequently, many users miss the rest of the subtools because there is no visual indication of different modes. An intial "splash page" with links to all the subtools could also reinforce the idea of the subtools.

General guidelines:

  • be flexible to allow for large number of sites
  • provide affordances for 'add', 'remove', and 'change order' (or a link to an area where these functions are possible)
  • visually distinguish "home", "projects", and "courses"
  • visually connect the current active site with it's content (i.e. tab connection, etc)
  • visually connect the current active site with it's available tools (i.e. "these tools apply to this site")
  • the order of the tabs, and the layout of the "more sites" list should be something makes sense to users (right now we think it appears in reverse order of when the site was joined)
  • the new design should not use too much screen real estate by default
  • provide keyboard-accessibility and semantic markup for ATs


Additional discussions:

  • Creating new types of sites (not Project or Course)
    • Consequences for our project: we may want to create a web interface for institutions to define new site types

Previous Work in Sakai

In at least the current 2.4 version of Sakai (and perhaps previous versions), users can change their tabs to display the site types instead of actual sites by changing "portal" in the URL to "osp-portal." My Workspace  and Administration Workspace (which, strangely, is re-named to Administration in the tabs but not the breadcrumbs) are both considered their own site types and have their own tabs. The list of matching sites appears in the main content area for each tab.

On the 8-3-07 Fluid User Experience call, Kathy Moore from BU suggested that perhaps the tab metaphor needed to completely go away since it wasn't scalable. She re-iterated this in the 8-6-07 Sakai Design Patterns Working group call, saying that she thought that was something that others in the Sakai community might strongly support. She also pointed us to this mock-up of a proposed design change to the tabs from the Sakai screenshots page which would result in only three tabs: "My Workspace," "Courses," and "Projects." Interestingly, this basic structure is similar to the osp-portal version. The one addition to this, the floating div list of sites that appears below each tab, looks very similar to the Amazon solution we were considering above. They also suggest additional functionality, such as customizable tabs which users can use to organize their sites in whatever manner they choose. I contacted Steve Lux about this to find out whether they ever implemented this design, but determined that they hadn't.

The University of Michigan also looked at the tabs problem about 5 years ago. Per Daphne Ogle, "The main ideas we were working with were:

  1. Tabs become categories of types of sites and the sites themselves become a 2nd level of navigation either as links just below sites or a page of their own. Neither of these ideas really worked for various reasons (this was before the days of DHMTL so the Texas state idea seems pick up on this with better interaction)
  2. Allowing users for customize what sites show in tabs (a stripped down version lives in preferences now)
  3. The piece that got dropped was customized ordering of tabs and the ability to archive sites (the idea here is that I may want to access very old sites from time to time but don't want them in my tabs or more dropdown at all. Users would need another way to access them)."

Design Questions & Rationale

Tabs

  • Would it be more logical to have the tabs map to the categories of sites (e.g. projects, courses (perhaps broken out by term), other) rather than to a list of "favorite" sites?
    • Against:
      • students may only have course sites and staff may only have project sites, making it less useful to use tabs for only two categories (e.g. My Workspace and Projects). However, Courses could also be organized by term to alleviate this problem. Students & instructors who create project sites and departmental administrators are more likely to have sites of multiple types.
      • might be more site types than tabs available (e.g. if courses are separated by term, or there are many site types at an institution)
      • there is no way for users to see all their sites at once, unless we added a link to "see all sites" at the bottom of each drop-down which takes the user to a separate page
      • although this would help make the drop-down(s) have fewer sites, someone who has many many sites (e.g. professors, students) will probably mostly have sites of one type so reducing the number of sites in the drop-down may not be that helpful.
      • question: how would the tabs change or how would you indicate when a particular course was selected? Breadcrumbs? Some sort of sub-nav? (Answer, yes, this is already implemented in osp-portal with breadcrumbs)
    • For:
      • It would be easier to handle a list of items in one category in a drop-down list (because it would require a smaller window), and likely easier for users to process since there is less information. However, visual design could be used to make it easier to see the different categories when they are in a single div, so this may not be a huge issue.
      • The problem with putting conceptually unrelated Favorites and More tabs together would be alleviated.
      • Every piece of navigation (the tabs) would work the same way
      • The problem that "Favorites" is kind of a misnomer since they aren't selected by the user would be alleviated.
  • If we go with a single "All Sites" drop-down activated by the "All Sites" tab, how should it be styled?
    • The page should not move down to accommodate the list of sites as this can be disorienting for users and also takes up valuable screen real estate. Instead a floating div should be used to show all the sites.
    • The button which allows all sites to be seen should be called "All Sites" to indicate that it also includes the "favorite" sites already displayed in tabs. It should look much like the rest of the tabs to indicate it performs a similar (though not exactly the same) action. It should not have dashes on either side. Instead it should have a down arrow to indicate more items will open below it. This is becoming a standard affordance (see Google, Flickr) and mirrors the arrow on a standard drop-down.
    • We like the close box, and it it appears it must be added to 10448. We would like to style it in the standard manner for this type of close boxes throughout Sakai.
    • idea: color-coding the tabs as well as the labels inside the drop-down menu - however, there might not be enough different types of tabs to make this very helpful
  • Should the drop-down/floating div open on mouse-over?
    • Against: We believe this would be the better option because it could be disorienting, especially if the floating div is large because there are lots of sites, if the user mouses over it by accident. Users will be able to understand and discover its differing functionality from the other tabs when they see the down arrow.
    • For: This will make it easier for the user to discover its functionality. Seamus Byrne/UC Berkeley said in his usability testing users were unable to either understand or discover the drop-down's functionality. This also allows users to select two different modes of viewing the sites, as you can show them the floating div on mouseover, and go to an actual page with all the sites by clicking on the tab. However, screen readers seem to be able to access the div fine so there doesn't seem to be a need for the page with all the sites listed.
  • Even if we can't have the drop-down open on mouse over (so on-click must activate it), should there be a way to get to a page with a list of all the sites?
    • For: This would allow users with a large amount of sites to have a more manageable interface to view them in which is not navigation. It may even be a place to take users with too many sites to fit into the drop-down div. This would also be a good interface for drag and drop ordering of sites if that was implemented in the future.
  • In order to allow the floating div to be as large as possible, should how should it be justified?
    • It seems that right justifying it on the right edge of the "All Sites" tab would be the best because:
      • Tying it in some way directly to the tab makes it clear that the tab is what controls it (as opposed to right justifying it in the page so that it can move as far right as possible and potentially not be connected to the tab).
      • Center justifying the div on the tab would be hard, if not technically impossible.
      • Since the majority of the screen real estate on most sites should be to the left, underneath the tabs, this would give the div the opportunity to grow horizontally the most
      • Allow the div to expand downward, perhaps to the bottom of the page?
  • What do you do when there are too many sites to fit comfortably in each column or too many columns to fit horizontally. Should there be a limit on the number of columns? Should we limit the number of categories (e.g. Course by term, Project, etc.) or the number of sites in a category? Can we limit it to the number of categories that can fit in the window? Should we allow courses to be organized by term, or is that too complex? How are the courses being categorized by term? Is that in the 10448 patch?
    • Ideally, if the floating div were larger than a certain size (e.g. more than 5-6 categories, or more than 15-20 sites in a category), it should be displayed as a new page. However, we think this may be difficult functionality to implement. If this is indeed too difficult to implement, we could recommend that the div expand to a maximum size of , e.g.,75% (question) height and width of the screen and implement scrollbars to see the content within it. We would only want to do this under the assumption that most users would not have enough sites to see this interface.
    • Another option would be to get rid of the floating div and take all users directly to a page with all their sites on it. Although this is more clicks, needing to make fewer clicks doesn't matter if the user has trouble figuring out what the right click is/what each click means.
      • Ask the community how many sites a typical user has/what are the most sites a user has.
        • Sean Keesler, Syracuse University - "At SU, we have 5 different types of sites, so its a real nice feature to see your "Courses", "Portfolios", "Goals", "Programs" and "Field Placements" across the top as opposed to a jumbled list."
  • Should the columns in the div be fluid width (expand and contract as the window size changes)?
    • Against: this may be difficult to implement, is likely only helpful with a very large number of categories, and be disorienting to users in a floating div.
    • For: If the way the columns wrap underneath each other when there are lots of categories doesn't make sense (e.g. the terms are put out of order) this could prevent that problem by locking the order of the categories.
  • How would the tab selected from the "All Sites" tab be displayed? Would it just replace the last tab before the more tab as it does in the current system? Or would users prefer a rotating (e.g moving from right to left as new tabs are selected) list of tabs?
    • A rotating list of tabs wouldn't work with the Favorites paradigm, unless we wanted to define "Favorites" as the last tabs access by the user.
    • Having an extra tab appear when something currently not available in tabs is selected is the way it is done on Amazon. Every time a new site is selected, it replaces the tab currently displayed in this location.

Customize Tabs

  • Should we add an edit button or icon to the right of the tabs allowing access to Preferences -> Customize tabs?
    • Yes, we would like to use a phrase styled as a link, like the "Add a tab" link is on iGoogle. This shows users that the action is conceptually different than those the user will be performing on the tabs. All the tabs show either sites or lists of sites, and this link will allow users to perform an action on the tabs.
    • "Customize Tabs" may not make sense for users because the out of the box Sakai doesn't even have them styled as tabs. We recommend that as part of our styling changes, we style the out of the box version of Sakai to look more like tabs.
  • Should we bring the Preferences link up to the upper right next to the login?
    • Against: adds visual noise. It also may confuse the users' mental model since none of the other items in My Workspace have links available from all screens. We've already made customize tabs more visible by adding a link on the tab row to it so this may be unnecessary.
    • For: This is a standard location for Preferences and may allow users to find it more easily. It would also allow users to find other preferences more easily.
  • Should we change the way Preferences is organized to make Customize Tabs more visible?
    • Options:
      • Fix action links so that users can tell which subtool they are on. We don't know enough about users to determine whether Customize tabs would be used so much that it should be moved to be the first item in Preferences where users land by default, above Notifications. We'd welcome input on this.
        • For: Currently there is no way to tell which subtool you are on by looking at the Action Links bar. This makes it even harder to tell that the Action Links are what is determining what subtool the user is on.
        • Issue: inconsistent styling of currently active global action links as well as inconsistent interactions of global action links (sometimes current link can be activated, sometimes not, sometimes you are going to a page, sometimes taking action on the current page)
        • idea: add css class to currently active tool nav item to allow additional styling beyond just styling text (the currently active tool nav item) vs. links differently
      • Create a "splash" page listing all the Preferences tools
        • For: Using the web metaphor, it also doesn't make sense to have the user land on the first subtool when they have chosen to go to the overall Preferences page. Additionally, especially in view of of the inability of the Action Links to tell the user which subtool they are on, it would make it easier for users to discover the other subtools if there was a "splash" page listing all the subtools.
        • Against: We'd want this to be implemented consistently throughout the site, and are not sure if there are other instances we'd have to fix where the default is to land on the first tool.
      • Put all Preferences subtools on a single page in closeable panels
        • For: the back button doesn't work, and the closeable panels would reduce the likelihood of users wanting to use the back button to access another Preferences subtool. Also, it takes the same number of clicks to get to the first subtool either way, but the user can more easily get to other Preferences subtools if everything is one page.
      • We believe that we might want to think about re-organizing the subtools in Preferences in general (are they all really preferences?), but we have decided to scope this out for this round.
  • Does Customize Tabs need to be changed to reflect the new design?
    • Change instructions in Customize tabs to explain that only the first 2-3 tabs selected will be shown in actual tabs and that the 3rd or 4th tab will change based on what is selected from the "All Sites" tab. Basically all other tabs in the list will be categorized by the system. It may be a good idea to consider an entirely new interface which allows the user to specify the 2-3 "favorite" tabs as well as the sites which aren't shown in tabs at all (e.g. archived sites) and then explain that everything else will be sorted by the system. (3 list boxes?)
    • Consider allowing the user to specify the order of the sites in each category of the "All Sites" drop-down
    • Consider moving "Sites visible in tabs" to the left and "Sites not visible in tabs" to the right

Other

  • Do institutions need to create their own site types (e.g. is Projects, Courses (maybe by term), Other enough? Are portfolios a site type?)?
  • Do we need to improve the interface for join-able sites (e.g. Membership & Worksite Setup) as part of this project?

 Initial Recommendations

Immediate (for 2.5)

Short-term (for 2.6)

Option #1 (More work): Keep 2 or more "Favorite" site tabs, and make the More/All Sites drop-down into a tab which accesses a list of all sites in a floating div 

  • Keep favorites paradigm/tabs, where the tabs correspond to sites, not site types (except My WorkSpace, the More/All Sites tab itself, and the last tab before More/All Sites which appears and rotates when an additional site is selected).
  • The 2 or more (this number depends on the total # of tabs the institution allows) "Favorites" sites can default as they do now to the first (I think) tabs created, but users should be able to specify these top-level "favorites" tabs in Customize Tabs (see below).
  • The first time in a session that a site is selected from the More/All Sites tab which is not one of the "Favorite" tabs, an "extra" tab should appear directly to the left of the More/All Sites tab. This tab will then rotate to show each new site which is not a Favorite as it is selected.
  • More/All Sites tab should look like the other tabs (thought it may look slightly different than the site tabs, e.g. different color), but it only shows up when you have more than the default amount of tabs which can be shown (seems to be the way GA Tech is doing it)
  • Floating div containing sites organized by type
    • Sites are currently organized by type in the 10448 patch, but we are unsure if courses are further organized by term
    • Add an "open/close" arrow on the tab itself (e.g. iGoogle) which opens and closes the floating div
    • If the user has too many sites to display properly in the div (TBD: how to determine that the user has too many sites), they are taken to an page which contains the same contents as the drop down (styled differently to accommodate larger screen space).
    • Ensure that the floating div doesn't cover the tabs when they wrap
    • Ensure that despite the fact that the site type groups are floating divs, when they will wrap underneath each other the order will remain the same (columns/divs do not need to be fluid with unless it's necessary to keep them in the proper order)
    • Currently each column in the floating div is the length of its longest item. We want to set a max-width on the site titles so that site titles wrap when they get too long.
  • Change Customize Tabs so that there are three list boxes which read from left to right: Favorite sites, Active sites, Archived sites. Users should only be able to put the number of sites each Sakai implementation allows in the Favorite sites (e.g. total # tabs allowed minus My Workspace minus Administration Workspace minus More/All Sites tab). Users should only be able to order the sites in the Favorite sites box. Change instructions to reflect the new way tabs are managed.

Option #2 (Less work): Make the tabs correspond to site categories (e.g. Projects, Courses -- perhaps by term, Portfolios) instead of sites

  • Assumption: users don't switch directly between sites (including My Workspace) often enough for the extra click to be troublesome
  • Much of this is already implemented (though perhaps not with the organization of Courses by term) in the osp_portal version of Sakai and thus developmentally would be very simple to implement
    • Tabs correspond to site types
    • Breadcrumbs which show the user exactly where they are are already implemented
    • Splash page for each site type with all sites of each type already implemented
  • Re-format splash page for each site type. No need for a floating div since we have this page (see Assumption above).
  • Change Customize Tabs so that there are two list boxes which read from left to right: Active sites, Archived sites. Remove ability to order sites. Change instructions to reflect new method of organizing sites.

Other work to be done (with either option)

  • Put a link to Customize Tabs on the right site of the tab row which deep links to the Customize Tabs page of Preferences. It should be styled similarly to the links in iGoogle's "Add a tab" link.
  • Keep Preferences as is organizationally, but make it more obvious which page the user is on
    • info on how to do this in the action links is not in the style guide, but it appears the convention is usually to have the currently active page not be a link, and the other choices are links, but even this is broken in several instances
    • idea: add CSS class to currently active action link to allow more styling of it
  • Modify out of the box skin so that the tabs look more like tabs, with rounded corners and the extra line around the active tab which is in the UC Berkeley bSpace skin

Long-term

  • Allow users to specify their own categories for organizing their sites
  • Allow users to order their sites (in either option #1 or #2) via drag-and-drop ordering, as long as it is done on a page suited to that purpose
  • Allow institutions to specify whether sites are grouped by type and whether headings should appear if there is only one type of site
  • To make the My Workspace items more easily parseable, they should be in the same order as they are on sites (it looks like Resources & Announcements are reversed), most-used items should be moved to the top and conceptually similar tools should be next to each other (e.g. Membership & Worksite setup).
  • Consider moving Worksite Setup from My Workspace into the individual sites. It would seem to make more sense to make changes to a particular site in that site.
    • Daphne Ogle says, "On the suggestion to move worksite setup, it's a little more complicated than this.  Worksite setup is basically the same tool as Site Info except also includes the functionality to create sites and shows a list of all sites.  So, users can make changes to the site from within the site. It's pretty confusing for users to know where they should go to make changes.  For one, site info should probably be renamed to something that fits the user's notion of it better (during the heuristic work it was suggested to add the site type in from of the title (Course site info or Project site info).  Making it "Course site administration" could make it even more clear.  Marc B and I created some design last year in the course management project that moved site setup out of worksite info.  Unfortunately, they never got implemented but a combo of revisiting it along with the new design for site tabs would take away the need for the additional functionality I mentioned worksite setup has and thus it seems the tool could just go away."
  • Intra-Tool Navigation (e.g. in "Customize Tabs: sometimes you are navigating to a page (e.g. in the navigational hierarchy) and sometimes you are taking an action (either on data in the existing page, or adding new data). It seems these metaphors are mixed and should have different designs. Perhaps whenever an action is taken on the current page (e.g. Remove or Delete), it it should involve a button at the bottom of the page instead of using intra-tool navigation. There does seem to be a precedent for this on p.8 of the Style guide which shows how removing item should be handle
  • Create a web interface for institutions to define new site types
Design Process At a Glance

Powered by a free Atlassian Confluence Open Source Project License granted to Sakai Foundation. Evaluate Confluence today.
Powered by Atlassian Confluence 2.9.2, the Enterprise Wiki. Bug/feature request - Atlassian news - Contact administrators