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
Related - see the corresponding design for Alt-tab switching
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
- Just take the user to the last used window for that application.
- 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.
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.
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
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.
- 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
- Similar to places. Temporarily connected devices show up in the same list but after fixed devices
- Show the 10 most recent documents
- Browse button opens the browse overlay to the right
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.
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.