Unified menubar/titlebar

• The main menu is divided into sections, which are the analogs of the top-level menu categories of today's window apps, e.g. File and Edit. (There's a lot to say about menu sections, described in a later section, but here they are just seen as placeholders. Also, the Portal menu organization recommendations diverge from traditional menu organization, but for simplicity, the traditional categories are shown here.)
• The menu is brought down by clicking anywhere on the title bar. If you hold on to the button when clicking the title bar, you can drag to scroll the menus back and forth.
• When the menu is visible, you can click and drag the titlebar again to scroll, or you can click and release (without dragging) to dismiss the menu.
• Unlike the scrollbars in Windows, you don't have to stay on or near the scrollbar to continue scrolling, so you can move your mouse vertically as much as you like when scrolling. This way you can position the cursor over an item as you scroll.
• The scroll bar seen is draggable, but it's not really meant to be grabbed as it's just a visual indicator of where you are in the menu scroll field and how much more there is to scroll through.
• If you're wondering where are the rightside buttons for minimize, maximize, and close, there intentionally aren't any. First, there's no concept of minimizing and maximizing in a tile-based layout (as explained later, this doesn't mean you can't arbitrarily position and size applications). Second, if you want to close an application, simply use the standard menu item to do so. (Closing applications and dismissing windows is not something you should need to do as often as free-floating window systems like Windows and OS X encourage you to get in the habit of doing. You especailly should never close an application just because you want to get at the thing underneath, but that's exactly what free-floating window systems encourage).
• The furthest left section of the menu is always the application switching menu, which is demonstrated down the page.

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:

• For visual seperation, the main menu casts a drop shadow.
• Clicking on any area outside the menu and the titlebar dismisses the menu.
• Unlike traditional application menus, releasing the mouse over a menu item never selects it. You must always click the item you want. Yes, this makes every menu operation a two-click affair, but in my experience, most users have two menu behaviors: 1) when they know which top-level menu they want, they usually click on it directly, drag down to the item they want, and release; 2) when they don't know which menu, they click on a top-level menu, release, browse left and right, then click on the item. The first method is faster, but I think it's much more common to click the menu before you even start thinking about what you want specifically, so the two-click method ends up being the most common method anyway. (This sums up what I find wrong with today's standard application menubars: they're calibrated for speed, but they can't be all that quick to use if every application has toolbars with shortcuts to menubar items.)
• The title bar can have "convenience buttons" placed on it by the user, as demonstrated later. These buttons will always be positioned such that the top edge of the title bar is always exposed all along the top, allowing users to grab it without thinking by just throwing their mouse up to the top of the screen (assuming that this application's portal touches the top edge of the screen, which in fact is the most common portal placement).

Issues:

• If the user brings down the menu by clicking on the far right or left of the title bar, that doesn't leave them room to drag in one direction. One solution would be to tie scrolling to mouse motion once the mouse hits a barrier: though the cursor wouldn't be seen to go off screen (assuming it wasn't dragged onto a different display), it would still scroll as the user moves in that direction as if there were virtual space there.
  
  (Another solution is to have the scrollbar jump to a location based upon where you click on the titlebar, like normally happens with scrollbars. I don't like this solution, however, because it's nice to have the menu always appear in the same condition, allowing the user to dismiss and resummon the menu as a reorientation tactic.)
• Currently, moving the mouse horizontally scrolls the menus faster than is desirable, making it too easy for the user to overshoot if they leave the button down while trying to position over a menu item (e.g. if, while holding the button down, I see that the item I want is to the left of my cursor, I'll want to move the cursor left that full distance, but the item will slide right as I do so, and so I overshoot my target). This behavior is exasperated when an application's menu is particularly wide such that there's a lot of horizontal scrolling to do (and generally speaking, a well-designed app would keep the number and width of its menu sections in check).
  
  Ideally, users should learn to let go of the button once they see the item they want on screen, but if the scrolling didn't happen so fast, I think the problem would be greatly mitigated and maybe even feel kind of neat. So the solution is to tie the scrolling directly to horizontal mouse motion and acceleration, not to the position of the cursor in relation to where you initially click. This would mean that the scrollbar position indicator (the orange bit of the scrollbar) is not tied directly to the mouse position as is usual in scrollbars. (Perhaps the position indicator should be made a bit thicker so that you can grab it and get the traditional scrolling behavior when desired, which would help when there's a lot to scroll though, though the best and simplest solution is probably just to discourage menus from getting too wide.)
• Here's a thought: rather than having the menu reset its slide position when you dismiss it, perhaps it should retain the position and the position indicator should always remain visible so that it shows up in the same spot next time you bring it up and you won't be surprised or disoriented.

Portal layouts and the layout bar

• A "portal" is a piece of screen real-estate which displays a program window. As seen in previous demos, each portal has a titlebar menu, which includes the menu of open programs which is used to choose which program to display in the portal.
• Portals cannot overlap with each other.
• Portals are not moved or resized individually. Instead, users change screen configuration by selecting from a list a "portal layout", a predefined arrangement of portals.
• Each portal in a layout can be given a number; this number is unique among the portals in that layout but need not be unique to just that layout. The idea is that, when a user switches between one layout with portal N to another layout with portal N, the application displayed in portal N is the same for both layouts. (If a a portal in a layout doesn't have any number, it is independant of all other layouts---the program displayed there won't change portals in other layouts or be changed by other layouts.)
• Users can add and edit layouts, but it's expected that most users will stick to the small set of default layouts. (The use cases of having many small-window programs that need to be on screen simultaneously is addressed by the applet panel feature, discussed in a later demo.)
• To switch between layouts, click the triangle in the top corner of the primary display to bring up the layout bar. Clicking the background of the layout menu dismisses it.

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:

• In the menu, the currently selected layout is given bright highlighting, while the previously selected layout is given fainter, different color highlighting.
• When hovering over a layout, you'll see a preview of that layout on the desktop, but the selection is not made until you click the layout.
• The background of the layout menu should likely be transparent rather than solid.
• To edit a layout or create a new layout, the Portal Layout Manager application is used. (Unlike the Program Manager or File Manager, the Portal Layout Manager is not always open, so you have to start it from the Program Manager.) If this approach is too undiscoverable or just too inconvenient to access, an alternative is to have the layouts in the selection menu be right-clickable: clicking 'edit' on a layout brings up a layout editing interface; clicking 'duplicate' on a layout adds a copy of it to the layout list which could then be edited as desired.
• On a dual-display system, you might want to swap your right screen for your left, so there's an exchange-left-for-right button on each layout in the layout bar. (For single-display systems, obviously each layout would have only one display and you wouldn't have the exchange-left-and-right-displays button in the middle of each layout.)

Issues:

• I'm not sure exactly how the layouts are arrayed on the layout bar. Does a row have to be full before starting a new one, or is it done by columns? Should placement of a layout be something users should configure for themselves? Does the layout bar extend onto multiple displays? If the number of layouts is too many to be seen in one screen, should the triangle and the top bar act as a scroll bar with the same behavior as application titlebars seen in the menubar demo above (except with the menu always starting scrolled to the right extreme, not the left)?
• I'm not sure yet whether users should be able to drag the borders between applications. While the ability to drag the border between sub-windows (windows within an application) is clearly needed in many apps, I suspect it's best to disallow it. (After all, a primary aim with Portals is to stop users from non-productively fidgeting with their windows to maximize screen-space usage.)
• As shown, on a two-display system, when you want to change the layout of just one display, you actually pick a layout for both displays that happens to keep one display the same. This solution should work fine for two displays, but this facsimile of changing displays individually doesn't scale well: when you add displays, the number of layouts needed to allow you to change just one display individually grows exponentially (factorially, to be more precise) for every display you add.
  
  It makes sense then, on systems with more than 2 displays, to have each layout define only what is seen on one display, such that you pick an individual layout for each display independently. (Maybe this would mean you'd have a portal-layout picker in the corner of each screen.) Such a scheme would be a bit trickier to grasp and use (it raises the question of whether the same layout can be seen on two displays at once), but I'll punt on the details of a solution for now because only a very small number of advanced users have more than 2 displays.
• Some particularly complicated apps have a legitimate need to distribute their subwindows onto other displays (or, less legitimately, possibly onto non-contiguous tiles of the same display). If a layout could be defined to have non-adjacent sibling portals, it would likely require special handling on the part of the application in the portal(s) to decide how its multiple portals relate to each other. Again, this may get a bit undiscoverable, but I think I'll punt on this issue for now because it's another area only of concern to advanced users. (I think it's safe to assume that if you can use an app that needs multiple windows, you're an advanced user).
• Users will wish to jump to not just a particular layout but to a particular set of programs displayed in that layout. Users could do this by setting up a layout with portals that are un-numbered and thereby unique to that layout; however, they might alternatively make a layout that is identical to another layout except for the portals having different numbers; this second approach gets confusing and ugly for a few reasons:
  
  
  1. Users would be polluting their list of layouts.
  2. Not only would the number of layouts increase, but the set of portal numbers would increase and quickly become bothersome to keep track of.
  3. The layout list would contain many near choices---layouts that are quite close but not obviously so---so the users's would need to expend a greater mental effort to make finer-grain choices.
  4. Reusing portal N in many layouts would discourage the user from changing the program displayed in portal N freely, as they would be worried about what affect it would have upon their other layouts.
  To mitigate this behavior, what's needed is a mechanism in the layout bar to select not just a layout, but a particular 'snapshot' of programs for that layout. Perhaps rather than letting users define their own snapshots (too much bother), a new snapshot for a layout is created every time the user switches away from that layout with an array of programs in it that is different than the last time they switched away from that layout. So each layout would have a history of snapshots. Selecting a snapshot would be much like selecting a 'perspective' in Eclipse. When you moused over a layout in the layout bar, the history of snapshots for that layout appear in a vertical column below it. (Though I suspect having only the last snapshot for each layout would be sufficient for 99% of use cases.)
• I'm not certain what should happen when you select an open program to display in a portal that is already in another portal. The simplest solution might be just to allow a program to be displayed in multiple portals. However, having two visible windows of the same app would be confusing, so, if, say, you have an instance of Firefox visible in one portal of your visible layout, but then you select the same instance of Firefox for another portal in your visble layout, then the original portal with Firefox should be grayed out and not interactive (aside from allowing you to change the displayed program there) until you switch it to another program or it is once again the only visible portal with that instance of Firefox on screen.
• Occasionally, an app will invoke another app, e.g. opening a .html file in a file browser will open the file in the users's default web browser. In portals, one way of handling this situation is having the application which invoked the other applicatoin be replaced in its portal by the program it opens, e.g. the portal showing the file browser switches to showing the newly invoked program. This could be annoying in some cases, so it is up to the invoking app to decide what to do; the app may decide to just open the other program in the background.

Application alerts and system-wide alerts

• Focus-stealing pop-up messages and dialogues are mighty obnoxious and notoriously abused---e.g. click me---but in some cases they are still necessary. If such pop-ups weren't presented as independently (or pseudo-independently, in some cases) free-floating windows, they'd be much less irritating.
• An application message/dialogue window pop-up should be clearly associated with its application by appearing contained within its application's window. This pop-up is not really a window but more like a semi-transparent, rectangular overlay stretching over the whole application portal.
• For system-wide alerts, a similar idea is used, except system-wide pop-ups overlay the whole display(s) and use a few different visual cues to distinguish them (such as perhaps stretching from top-to-bottom rather than side-to-side).

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.

Show application alert.Show system alert.

Not shown:

• Because the application can't precede without user feedback, the application below the overlay is shaded and not interactable (this excludes the titlebar: users should be able to switch away to other apps without dealing with the pop-up).
• While it may be fine for system alerts to steal focus, application pop-ups should never steal focus from other programs; for cases when an app needs to notify users while they use other programs, a small, non-interactive message alert in the corner could momentarily appear, as with Thunderbird message alerts.

Issues:

• It could be very useful to have a general alert-logging mechanism. The basic idea of a message log is simple enough for anyone to grasp; the only danger here is that most users wouldn't want to see anything cryptic, so there should be some way of filtering the messages by audience.

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

• With only a few adjustments, the idea of portal-based layout can be used for complex applications which use many subwindows, e.g. Photoshop and Eclipse.
• To give an idea what this might look like, I'll use the Eclipse IDE.

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:

• A subportal titlebar needs to be easily distinguished from an application portal titlebar, so I've used different colors, but probably something more distinct should be devised.
• Just like an application titlebar, the subportal titlebars can have their own array of convenience buttons.
• Clicking a subportal's bar brings up a menu particular to the window currently displayed in the portal; not all subportals will likely have anything to put in their menu, but at the very least, a subportal's menu includes the window-switching section on the far left, just like an application menu does.
• Most apps would probably have all of their subwindows 'running' at all times, so there wouldn't be a subportal analog of the Program Manager for starting subwindows because you'd always see every possible subwindow in the window-switching menu.
• Rather than having an omnipresent button to bring up the portal layout menu the way the desktop does, an application's subportal layout is changed via the application's main menu (in the section immediately to the right of the application switching menu); the layouts are displayed in the menu arrayed vertically rather than horizontally as they are in the desktop's layout menu.
• Notice the text editor windows have been consolidated under one subwindow and are now presented as document tabs thereof. This does keep down the number of tabs, but it raises the question of how you'd be able to see two text documents side-by-side; this could be achieved by allowing the text editor to be displayed simultaenously in multiple subportals.
• Not all applications have use of a subportal system, and in many applications, treating the main content area as just another subwindow seems wrong (because the content area is supposed to be always seen and because giving the content area its own titlebar is redundant with the application's main titlebar). Aside from the main content area, other interface elements may need to be fixed aspects of the screen, such as status bars or the url bar of a web browser.
  
  Some applications, however, may contain both fixed regions and subportals. In these cases, each subportal layout of the application must reserve places for these elements.

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

• Portals' applet/panel feature is not terribly different from GNOME's. However, I have a few problems with GNOME's version:
  
  
  1. Standard features of Portals denecessitate the most commonly used GNOME panel applets (e.g. the program launcher, the window taskbar, and the workspace viewer), so I think of Portals' applets as analogues to OS X's widgets and Vista's gadgets---they're geared towards small but general uses, not desktop management.
  2. GNOME's panel applets are a jumble of styles---both looks- and interface-wise: some are small icons that act like Windows tray icons; some applets, like clocks, are basically just information displays; some have their own unique interface, such as the taskbar; and so on. This jumble of styles leaves no clear, consistent deliniation of borders between the applets.
     
     This design makes sense when each applet is an attempt to stuff functionality into as small a space as possible so that it won't waste space if made a permanent part of the desktop, but I don't think Portal's applets need to be visible on screen at all times the way GNOME panels usually are. If the panel's presence on screen is only momentary, it's fine for applets to take a up a bit more space; therefore, each Portal applet has its own border, and each has a small, standard button that brings up the applet's menu (which appears much like the titlebar menu of a full-window app, except the menu should never be large enough to need to be scrolled).
• The panel is not a portal: it is attached to a side of the screen (user configurable as to which) and is independent of layouts (so a layout cannot include the panel). The panel can be displayed as a temporary slide-out that overlays the current portal layout and goes away when you mouse away; the panel can also be pinned open, in which case the layout gets scrunched to make room and the panel must be explicitly dismissed by the user.
• Applets on the side panel are strictly layed out top-to-bottom, never side-by-side. The panel's default width is about the same as Vista's gadget bar.
• In addition to the side panel, some users may want to have a bottom-edge panel, for some applets just work better horizontally (such as, say, newstickers). This panel would be viewable (and pinnable) independantly of the side panel. This horizontal panel should always go on the bottom, never the top (interferes with titlebars, both visually and clicking-wise).

Not shown:

• The panel can be resized horizontally by dragging its edge.
• When the applets on a panel exceed the vertical space, a scrollbar appears.
• An applet's height is generally fixed: if an applet needs additional vertical space, it can have a vertical scrollbar (though applets generally shouldn't need more than about 1/4 of screen height in the first place: past that point, the applet probably should just be a full-window app). If an applet's width exceeds the width of the panel, its full width pops out when you give that applet focus. (In some cases, it may make sense to have the height grow along with the width.)

Issues:

• I'm not entirely sure if there are really legitimate use cases for having more than one panel, the way GNOME has it. Nor am I certain there's a real need for horizontal panels. It seems better to me to have all applets on one panel rather than having to manage which applet is on which panel, and I just have a hard time imagining someone needing more than a screen's height of applets visible at all times. For now, it seems reasonable to include an optional, additional bottom panel. (It does seem, though, that the Windows taskbar's minimum height is too tall; many users would probably want a thinner bar.)
• For many users, small informational widgets (newstickers, whether reports, clocks, etc.) can be hidden away from view until the user decides to see them by quickly revealing the panel and then dismissing it again. However, there are a few legitimate cases I can imagine where a user wants a small applet that displays constantly, but they don't want a whole strip of screen space lost to a sidebar (or bottom bar) for information that should only take up a small corner. For such cases, the user doesn't want to miss information updates, and they don't trust themselves to actively check on the information.
  
  One solution for such applets is to have them, when out of view, give small, non-confirmation-seeking pop-up alerts on a regular basis in a corner of the screen (Thunderbird new message alerts on Windows is a good example). Some information, however, unlike messages, doesn't come in discrete updates but instead comes in a constant stream. For these cases, alerts would come at some user-set interval particular to the applet. (This covers the case of a user not trusting themselves to watch the clock: the clock should give alerts at a user-set interval.) Another solution for these use cases is to allow small, perhaps transparent, permanent message boxes in the bottom corner of the screen, such as for a clock; these boxes would vanish when the mouse gets near them so you can get at the application space underneath.
• Some applets may wish to invoke window apps, in which case there must be a rule about how to bring apps to the foreground at the request of an applet. The simplest solution is to open the application in the largest window adjacent to the panel. Like with window apps which open other window apps, an applet may open a program without bringing it to the foreground.

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