Portals mockup

Mockup demonstrations of Portals

by Brian Will (blog)

Only tested in Firefox 2.0. Will not work in IE.

These mockups demonstrate features of what I'm calling Portals, a collection of ideas for a tile-based window manager and for a rethinking of some desktop fundamentals, such as standard application menus and dialogue windows.

The big ideas:

Unified menubar/titlebar

Demo #1: Menubar

Click the titlebar below to bring up the menu. Hold and drag to slide the menu. Click without dragging to dismiss the menu.

Not shown:

Issues:

Portal layouts and the layout bar

Demo #2: Portal layout menu

Click the triangle in the top right corner to show the portal layout menu. Select a layout, or click the menu's background to dismiss the menu.

Not shown:

Issues:

Application alerts and system-wide alerts

Demo #3: Pop-up alerts

Click the buttons to show an application or system alert. Click OK in the pop-ups to dismiss the alerts.



Not shown:

Issues:

Program switching

Demo #4: Program Switching

Click the portal's titlebar to bring down the menu. The list of open programs is in the leftmost section.

Program Manager

The Program Manager is an application that is open all the time and always listed at the top of the open-programs list. The user is presented with a list of applications; clicking on a program in the list opens it in the same portal (the context menu lets you open it in the background).

I don't know the precise details of how the applications are presented---a number of layouts come to mind---but I don't think it need be much fancier beyond a simple list. As long as apps are presented in a pretty much flat manner (no subcategories within subcategories), it should work just fine.

Issues:

  • It seems to me that there's an unwarranted amount of focus in desktop UI upon making applications quick to launch. I, for one, just don't open applications often enough to care whether it takes me 1 second or 5 seconds. What I do care about, is the amount of mental effort involved. So, beyond avoiding the mistakes of the (pre-Vista) Windows Start menu, it's really hard to get program launching too wrong.

    (The mistakes of Windows' Start menu include: 1) allowing programs to aggravatingly be grouped by the name of their makers, as if that helps users; 2) giving groups all the same icon, making each one look the same; 3) allowing groups within groups; 4) the whole point of grouping gets defeated by every single program having its own group; 5) using a drill-down submenu system, which makes layout hard to recall; 6) allowing non-program items in the menu (if a program really wants to make certain documents and related programs more accessible to the user, such things should be presented in a splash menu or some other interface element of the program, not in the start menu).)

    If users really insist on some analog of Window's recently-opened programs list or quicklaunch bar, such things can be added easily enough to the Program Manager or to an applet (applets are discussed later).
  • Menu sections

    [I had a lot to say about just what is wrong with our current application menus, but I lost that stuff and don't feel like recreating it, so here's the short version:]

    The conventional menus of today's applications are too limited, resulting in most interface complexity getting shunted into pop-up dialogue windows, which hinders navigability and burdens users with extra free-floating windows.

    To overcome this, each menu section should be more like a web page, with all of the program's complex dialogues presented directly in the menu itself. (Each section can be basically as tall and wide as necessary: if the vertical space alloted to the menu section is exceeded, the section becomes vertically scrollable; however, menu sections should generally remain narrow, so perhaps width should be capped. To keep a crowded menu section sane, dialogues can be presented as collapsed menu items.) Submenus (menus that pop out to the side) are replaced by collapsed menus that expand.

    Issues:

  • Putting complex-interaction elements nested within other complex-interaction elements is not without its problems. For example, scrollbars within scrollbars are problematic:

    1. When scrolling the inner bar, it's possible to be prevented from scrolling the whole length by the inner bar being partly out of view. This can be fixed by having the outer scrollbar track along with the inner scrollbar.
    2. While hovered over the inner scroll area, using the mousewheel scrolls that area, but this can be surprising. This surprise can be minimized by giving some visual indication of the region which currently has mousewheel scroll focus as the mouse pointer is moved.
    3. When scrolling the inner area with the mousewheel, the inner area scrolls until the upper or lower bound is hit, at which point the outer scroll area scrolls; this is not the desired behavior: the outer area should not scroll at all when inside the inner region.
  • Convenience buttons

    Application subwindows/subportals

    Eclipse as currently seen running in Windows:

    Eclipse makes a good example because it already uses a tile-based layout scheme which I find particularly clever: each open subwindow is it's own tab, and you can control the layout by dragging the borders and by dragging tabs onto regions of the existing subportals (which may make a good basis for a portal-layout editing scheme); Eclipse also has 'perspectives', which are very much like portal layouts.

    Still, when using Eclipse, I find myself annoyed by the clutter of all those window tabs and the system of 'opening' windows. I think these aggravations would be considerably allieviated by the portals style. (Eclipse is also a great example of an application that would greatly benefit from a reduction in the complexity of its menus and its number of complex pop-up dialogues, but that's a matter covered elsewhere.)

    Eclipse remade in Portals style:

    Application sidebar and dialogue subwindows.

    When should a form be be placed in a pop-up dialogue or in a subwindow? There are two criteria: 1) does the user might want to see the application's content area (or subwindows) at the same time as using the form?; 2) does the user perhaps want to put their interaction with the form on hold so they can interact with other parts of the app? If the answer to either or both of these question is yes, then a subwindow is preferred to a dialogue because pop-ups obscure the content area and prevent all other interactions. Placing dialogues in the menu rather than in pop-ups mitigates these problems, but they are still inferior to subwindows.

    The Portals solution here is to allow all menu dialogues to be opened as subwindows. The user right-clicks a dialogue heading in the menu, selects 'open as subwindow', and then switches a subportal to that subwindow as desired.

    As discussed earlier, however, some applications aren't well suited to the subportal paradigm and so this method is not suited well for apps where subportals are used infrequently or not at all. In general, it simply requires too much setup on the part of the user; while the mechanism could be great for configuring a frequently used app for one's needs, it's too heavy for occasionally used dialogues which the user simply wants to see side-by-side with the main content area.

    For lighter use, there's the application sidebar. The sidebar is a hideable panel that takes up the left (or perhaps right) side of an application window and contains a vertically scrolling array of user-selected dialogues. The sidebar is summoned and dismissed by an item in the layouts menu (but the sidebar is independant of any layout). A dialogue is added to the sidebar by right-clicking its heading in the main menu and selecting 'open in sidebar'; to remove a dialogue from the sidebar, right-click the dialogue heading in the sidebar and select 'remove from sidebar' ('open as subwindow' is also an option). The sidebar's width is resized by dragging, but it may often contain dialogues too big for it, so giving focus to a dialogue that is too big for the sidebar causes it to temporarily assume its full size, overlaying the area next to the sidebar.

    Because dialogues may appear as subportals and the sidebar, it's important that dialogues make a reasonable attempt to accomodate different sizes and aspect ratios. Also, note that adding a dialogue to the sidebar or as a subportal does not remove it from the main menu.

    (The thought occurs that the dialogues/subwindow distinction should be eliminated: all dialogues and subwindows should appear as part of the menu, all dialogues and subwindows can be added to the sidebar, and all dialogues and subwindows can be viewed as subportals.)

    The applet panel

    Not shown:

    Issues:

    Demo #:

    System configuration

    You may have noticed there's been no mention of ways to access system configuration dialogues. Just like the Program Manager turns program launching into basically just another application, system configuration should be presented via ordinary applications as much as possible.

    (In contrast, Windows XP is a bad way of presenting system configuration. In Windows XP, most every system configuration screen can be found in the Control Panel, but then there is a strangely random assortment of shortcuts to a few of those screens, e.g. the display configuration screen can be gotten to via right-clicking the desktop background. Worse, a number of important dialogues are in Computer Manager, which is gotten to by right-clicking the My Computer icon, and then there are several configuration programs under Accessories->System Tools, Accessories->Communication, and Accessories->Accessability. I'm sure [I hope] Vista straightens out this situation; still, XP does make a good example of what not to do.)

    Application search/help/command textbox

    System-wide scripting

    System-wide key binding

    Menu guidelines

    Standard desktop applications

    Panic button

    Embrace context

    There are only two problems with context menus. First, they aren't always discoverable, e.g. 'I didn't know I could right-click on that!'. The solution would be something like that right-clicking in an application would highlight all areas that are right-clickable.

    Grab and drop and the expanded clipboard

    File Manager