Mockups for Application Browsing

This page includes additional rounds of iteration based on this previous iteration

These are based on and in respose to the info originally posted here

June 2 - Summary of Changes

Here are some changes to round 2 in response to some feedback and further thinking

Search box to top of left column, better connection to the results and items below
Applications section has a header like the other sections
Collapse Places and Devices into one section.
Recent Items more than just docs (web history is shown but might be overloaded too easily)
Consider more useful "titles" in recent items - if we can intelligently choose a better title than filename we should

View with an active search

Not shown - I think it would be very nice to highlight any matches in the left column with a background color as well. I mention this below in the Application states.

Application states indicated in the shell

Behaviors for multi-window applications:

Clicking on an application icon launches the app if it is not running
When hovering on the icon for a running app, highlight the associated windows in the workspace preview
When a running app has 1 window, clicking on an application icon goes directly to the app and workspace
When a running app has 2 or more windows, there are two possible behaviors
1. Just take the user to the last used window for that application.
2. Give the user a choice. In this case, clicking on the application displays a list of current windows to choose from, with an option for a new window. New windows should be created in the same workspace as the most recent window.

original SVG

May 13 - Round 2 Summary of Changes

Based on feedback and pushing further

Moved search box to more primary position
Moved application category browsing as a secondary action
Space made available for places and devices
Refinement of the overlay. Now includes a filter-type UI that lets users limit a list of items based on attributes; user can open/launch with one click, but can also get info on any item.

Mockups

Interaction with workspaces is not changed or described further in this revision, so the mockups focus only on the new aspects of this design revision

Default View

One notable change to the shell is the location of the search box. There are a few reasonable spots for this box, but the position in the top tray offered a good compromise in use of space and hierarchy. The find box could be visible any time, or only when the user is in the new shell mode. Another possible home for the find box is above the applications, but this can interrupt the visual flow from the tray to the favorite applications.

Favorite Applications Well

Drag icons into favorites well to populate; Re-arrange via drag and drop.
Drag icon out of the well onto a workspace to launch in that workspace
Drag out to remove? Possible if we have "dead" areas to drop the app and we indicate drag status via the cursor during drag.
Single click to open the app or switch to it if already running.
Right click context menu for actions, including Open, Quit, New Instance, Remove from favorites, App-specific actions like "Check for new mail" and "Next Track" if available.
Special "More" button always in the list at the end, this toggles the app browse overlay (next screenshot).
Non favorites dock - running non favorites are staged on the dock below, and can easily be added to favorites via drag and drop or context menu.
Ideas not shown - apps could have emblems/badges indicating status, like overlay "3" badge on a mail app icon when there are 3 unread messages.

Places

Pre-populated with places users would use often
User can add shortcuts to folders, servers, documents, etc.
Browse button opens the browse overlay to the right

Devices

Similar to places. Temporarily connected devices show up in the same list but after fixed devices

Browsing applications

The overlay for browsing apps is opened by clicking the fixed More button in the favorites well.

One click on app name and description to launch
Use filters to browse with a specific category; limit or sort by other attributes
Click on info to see details
Right click actions could be available - similar to Favorites well.
User can drag apps icons to take action
Dismiss the overlay by clicking again on the More button, clicking the X, or clicking elsewhere outside the overlay.

Browsing recent documents

Users toggle the browser on and off for the recent documents section with the arrow button.

Filters for time, type and tags. See thoughts on filter-based UIs at the bottom of this page.

Search results

As a user types in the box, results are suggested and shown in the overlay. Not shown here, but a very nice feature would be to also highlight matches in the left column with a background change

Results are mix of docs, directories, apps, and potentially other info like browser history
Filters for these results are necessarily more general. See thoughts on filter-based UIs at the bottom of this page.

Getting item detail

This image shows a follow-on to the previous image. The user has clicked the info icon for one of the search results. Now we see the item details. A slide left animation could tie these two scenes together nicely.

This is a rough example of what could be shown here, plenty more thought could go into the layout and content.
Different types of items would show different details and actions. For this image we see tags, a fullscreen control, some actions, the location on disk (click on any directory to go there), and metadata
A button at the top marks the way back to the list (slide right animation)
up/down buttons let the user navigate the results list without paging back and forth

Notes on filter-based browse UIs

We will have to think more about how to handle scale issues. If there are many filters, we could show only the first few, then click for more.
possibly allow user to customize which facets they want to use.
There are a number of variations on how filters are selected. This model shows a single required selection in each filter. We could look at opt-in style selection where the filters are selected with checkboxes. This could vary from case to case.
Some filter UIs include an indicator, usually a # of results, that indicates how many hits apply to a given facet. For example, this might help users see which categories are hot for thier search, and which are not.
Some sophisticated filtering UIs change the facets as you drill down. For example, in a set of mixed search results, I select Documents filter. Now I only see documents. The facets could now update to show me filters specific to documents, allowing me to get more specific.

Projects/GnomeShell/Design/Iterations/AppBrowsingAlternative02 (last edited 2013-11-22 17:00:07 by WilliamJonMcCann)