Usability

Reimagining Deskbar

Following Deskbar redesign proposal is based on discussion in the 3D-Accelerated Haiku Desktop RFC comment thread. One problem that came up was that current menu designs do not support good organization.

Only ways to organize a cascading menu (or variant like Deskbar and Windows start menu) is to use subcategories and separator lines. One good thing about subcategories is that you have a short description (i.e., folder name) attached to the group of items in the category, but those items are hidden most of the time and inefficient to use. Using separator lines for grouping does not affect efficiency, but does very little to aid usability. They have no describing properties and they do not visually connect items between them.

My proposal for Deskbar design that attempts to support both good organization and efficient use, is essentially a new way to visualize subcategories.


The image is from an interactive prototype I made to test this idea. The prototype requires an SVG capable browser (up-to-date versions of Firefox, Safari and Opera work). Please note that the categories and applications shown are just for illustrating functionality and not a proposal for default Deskbar organization.

If your browser supports SVG, please explore the prototype a bit before reading further.

Explanation of the proposed menu visualization and behavior

  • Instead of having to click category name to show its content, we have the content listed below the category name. For example, “Browsers” catagory in the image above.
  • Often everything in a category is not equally important. To solve this, we add ability to limit which items of the category are shown below its name. A complete list of items can then be accessed by clicking the category name. For example, complete content of “Internet” category, show in the image above.
  • Finally, since categories can include subcategories, any item in a lower category can be shown below the name of the higher level. For example, “Firefox” and “BitTorrent” are shown below “Internet” category name in the image above.

To the best of my knowledge, exactly this type of menu has not been used anywhere. It is a combination of cascading menu and index menu that hopefully has the best qualities of both. Names and icons of items are equally well presented. Items are arranged to vertical list, which are easy to skim trough. Grouping of items should be visually obvious. Etc. There is some research results about efficiency and user preferences to vertically arranged cascading menus and index menus here

Visual appearance of this prototype is close to my idea of how this could be done, but contains some rough spots. E.g., how to visualize case where some applications do not belong to any subcategory (see “Productivity”category in the prototype).

Prior art of grouping, showing and hiding menu items

The idea of not always showing complete content of a menu has been used before by Microsoft, but their way was to “intelligently” hide items. There is also a feature in Windows XP start menu that tries to “intelligently” put often used applications to the beginning of the menu. Both of these “intelligent” features are essentially usability bloopers because they implicitly chance the interface. Although my proposal has some similarity to these, I believe it would work, because there would not be any “intelligence”. All decisions to show prominently or hide to sub level would be done explicitly by the user or have default setting that the user can chance.

OS X system preferences has some similarity to my proposal. There is grouping, but it is not visually clear in my opinion. Plus, horizontally arranged large icons with small text may look good but are not easy to skim trough, and place too much importance to the icon.

Blender's button groups interface is a clear source of visualization ideas in my proposal.

Comments?

All comments welcome. Is it appealing or an eyesore? Does it violate known usability principles? If you tried the prototype before reading the explanation, was it hard or easy to figure out how it works?

Rethinking scrolling

The way scrollbars work is pretty inefficient - especially for novice computer users. They offer three (!) methods for scrolling relative to the current position and none of them offers comfortable scrolling speed for all document sizes.

The arrows in the corners are very small compared to the scrollbar's overall size and they are too slow in most cases. Still, a lot of people use the arrows to scroll rather large distances in a document.

The scroll thumb (slider) is too small in big documents and requires too much aiming although it is the fastest and - for moderately-sized documents - a sufficiently accurate way to change your relative position. For very big documents this way of scrolling becomes nearly useless because it moves areas bigger than the visible region.

Scrollbar  basic lookScrollbar basic lookA third alternative is to scroll page-wise by clicking on the non-highlighted area. This is often too coarse-grained and sometimes collides with the thumb which may suddenly appear under the mouse cursor, so you have to adjust your mouse position to continue scrolling that way. Inexperienced users sometimes click on the non-highlighted area to quickly get to a specific location.

The following proposal should be more effective, but it requires an initial training phase because it's different from the current way of scrolling.

The arrows at the top and bottom are not buttons, anymore. Also, they are bigger to make it more obvious that they are part of the scrollbar background. The scroll thumb lights up when the mouse is moved anywhere on the scrollbar (not just the knob). The general appearance of the scrollbars is very similar to that of the current mainstream operating systems.

Left-click scrollingLeft-click scrollingPress and hold the left mouse button on any place on the scrollbar and you get into relative scroll mode. To clarify, you can click on the thumb, or on the arrows, or anywhere else on the scrollbar and it will have the same effect. By moving the mouse you can scroll a proportional amount of screen area in the same direction. The mouse movement causes the thumb to be moved at comfortable speed which is independent of the document size. Mouse movement has no effect on the cursor's position (i.e.: it works as if you could move beyond the screen borders).

Right-click scrollingRight-click scrollingRight-click (tablet users will prefer ALT+left-click) on any place on the scrollbar and you immediately jump to that location in the document. By keeping the mouse button pressed and moving the mouse the thumb will move directly with the mouse pointer as if you had right-clicked there.

When moving the mouse over a scrollbar the cursor becomes a double-arrow (up/down or left/right), so it becomes more obvious that by left-clicking you can move the scroll knob.

Pressing ESC with the mouse button held will bring you back to the last position before scrolling.

This proposal has the disadvantage that the right-click scrolling function is non-obvious and users would have to learn it, so it's not perfect and it could need more work.

Sorting Chute

The means of having the operating system automatically sort, file and perform actions on filesystem objects based on user-configurable criteria should be provided through the use of a "drop target" replicant known as the "Sorting Chute".

Details

The sorting chute would be comprised of three main components:

  • Replicant
  • Preference Applet
  • Drop Folder

Replicant

The replicant would act as a space on the desktop, designated by an appropriate visual representation, whereby filesystem objects can be dropped to have actions invoked upon them based on a set of user-defined rules.

Preference Applet

The preference applet would act as a means of configuring the rules against which the replicant would compare dropped objects. For each rule, the user should be able to specify the criteria matching objects must exhibit, and the actions to be carried out on those objects.

Drop Folder

The drop folder would simply be a folder monitored by the replicant for incoming files. This would enable direct saving or downloading of files to the "sorting chute" for immediate filing.

Rules

Rules should be constructible in much the same way as queries today. The main difference being the ability to set actions to be performed on matching files.

Actions

The available actions for a given rule should be comprised of standard filesystem actions (Copy, Move, Delete, Rename) as well as actions provided by Tracker Add-Ons able to operate on files matching the specified criteria.

Example

The following rules have been setup by the user:

  1. Name: Compressed Files
    Matches: [Type==application/x-compressed]
    Actions: Unzip to "/home/desktop", Move to Trash
     
  2. Name: Photos
    Matches: [Type==image/*] AND [EXIF::Manufacturer==Canon] AND [EXIF::Model==Ixus]
    Actions: Thumbnail, Move to Folder "/home/photos/%year/%month"
     
  3. Name: Install Applications
    Matches: [Type==application/x-bundle]
    Actions: Install for All Users

The user downloads a zipped file from the internet and chooses the Drop Folder as the download location. The replicant is notified of the creation of a new object and matches it against the Compressed Files rule. The file is unzipped to the desktop (Tracker Add-On) and the compressed file is moved to the trash.

The user connects their camera, which is mounted by the OS as a removable media device. The user drags the photos from the camera to the Sorting Chute replicant which matches each individual file against the Photos rule. The icon of each photo is set to a thumbnail of the photo, created by the Thumbnail action (Tracker Add-On), and the photos are moved to a folder based on the current month and year.

The user has downloaded an application bundle, used the application, and decided that it's worth installing for all users of their computer system. They drag the application to the Sorting Chute replicant which matches the bundle against the "Install Applications" rule and performs the action "Install for All Users" (Tracker Add-On)

References

State Save

Additional methods should be added to all applications which would act to save the current state of each application. All relevant information including (for example) current document edits, window positions and data stream positions should be saved in a standardised way. This would enable easy save, hibernate and start functionality.

Details

Single Application

Each application should have the ability to save its state at any instant to a predefined file. This snapshot style file could be used during application startup to restore the previous session's state in a standardised manner. More importantly it would allow more useful coordinated loading/saving algorithms (See Global State).

Information saved would include items such as:

  • Data stream information
  • Window locations, sizes
  • Widget states, contained data

Triggering the save could be achieved through additional hooks in BApplication. Return codes would indicate the level of success.

Global State

There is the possibility for state saves to be triggered automatically by the operating system at certain points, including:

  • Shutdown
  • Log off

Additionally sets of applications, sessions, could be loaded at points such as system startup. Interesting sets of applications include:

  • Those running at last shutdown
  • Predefined work modes
    • 'At Work'
    • 'At Home'
  • Special constant set for startup

Using the 'previous shutdown' session we would automatically have a hibernate option. Note that there should be a mechanism to bypass the state save and, for example, have a 'real shutdown' command (potentially in a hidden place like CTRL-ALT-DEL).

Security / Stability

State files require extra attention from security perspective. They allow an extra entry mechanism for malware, virii and other dubious software. It would be a convenient mechanism for such software to load each boot.

Care must be taken to save a valid and usable state each time. If a system critical application saved an invalid state, or a state in which a crash is inevitable, the state becomes unusable. Supposing this application is set to automatically load from the state the system would require a mechanism for a 'clean' boot or 'clean' loading of applications (This was evident in OS/2 with the saving of unstable system states causing continual rebooting).

Issues

  • Some things such as streaming data are once only occurrences. How do we save state there?

Related

Pre-Shutdown Message

Currently in BeOS there does not exist a thorough method for shutdown notification and procedures. It is proposed a new standard message and response system be introduced. Additionally, mechanisms will be introduced to ensure needed services and applications remain open for use until dependant systems are closed.

Current System

When a shutdown occurs currently each application is sent a B_QUIT_REQUESTED message in order to terminate it. As this message does not indicate that it must quit in the near future or be killed the application may choose to ignore it, unaware of the impending shutdown.

If the application decides to quit at this point there could be problems with relying on other currently running applications in order to implement some feature used in the quit process. Thus, there could exist some scenarios where the dependency breaks when one of the applications depended upon quits before the first has a chance to handle the quit message themselves. e.g. an application may rely on functionality of Tracker or Deskbar in order to save an object.

Details

In order to prepare all applications for an upcoming shutdown it is proposed that a new message be introduced which is used to notify applications of the approximate shutdown time. This would enable all applications to have sufficient time to save all data and settings without incident.

Immediately before the shutdown is finally carried out a second message should be passed to all applications to ensure they are ready for the event. If an application is unready it should send a response accordingly. In this way the system will not inadvertently shutdown an application needing user intervention.

It would be possible to present the user with a list of running applications and the state of readiness they report when shutdown time arrives. This would continue the idea of allowing unresponsive applications to be 'force quit' but would allow for some idea of readiness of the application in question.

The period of time between the two messages should be used in order to ensure all data is saved and all actions depending on other services finalised.

Issues

  • Should there be some mechanism to ensure needed apps kept up? Hard coded? This was referenced in the original thread but never solved adequately.

References

Related

Fusing Tabs

The tabs on BeOS windows have been well known for their distinctive sliding ability. This could be extended by allowing extended areas for sliding, sticky tabs and fusing tabs.

Details


Sliding

Tabs should be allowed to slide all the way around the perimeter of any window, including hugging the corners of the window.

Movingtabs.gif

Sticking

When placed in close proximity tabs in different windows will snap together, bringing the windows together. When this occurs on the side edges of tabs this would result in an arrangment similar to general tabbed interfaces.

Stickingtabs.gif

Fusing

When placed on top of each other tabs would combine together and in that fashion couple the two windows together.

Fusingtabs.gif

Combinations

The strength of this technique lies in the ability to combine multiple windows in a manner more useful to the user.

Fusingtabs-example.gif Stickytabs-example.gif

Issues

  • How easy is this for the user to actually work with? Is it more coherent? Or just cool?
  • How are tabs separated once stuck or fused?

References

Drag and Drop Save

The current standard system of saving files from all applications should be replaced with a drag-and-drop mechanism combined with tracker windows.

Details

While the current standard for most operating systems, the use of save dialogues can be considered an inconsistant design providing a seperate method for navigating the filesystem. The core uses for a save dialogue can be summarised as follows,

  1. Providing a filesystem browser
  2. Filtering displayed files to a specified type
  3. (Often) remembers last save location
  4. Target filename specification

However, many of the above uses can be filled through the system Tracker or extensions to Tracker. Hence, browsing and filtering can be handled trivially. It is proposed that Haiku drops support for save dialogues and instead uses a drag-and-drop method as standard, thus utilising the existing pervasive drag-and-drop mechanisms in the operating system in tandem with the Tracker.

In order to specify an application's current document filename the user could edit the window's titlebar. This however will not save a file directly, merely providing a mechanism by which to specify the final filename. After the filename has been specified the user will now be able to clickand-drag the window title onto any Tracker window thus specifying the target path in addition to the filename.

As a convenience measure the ability to recall the most recent save location can be handled at the application or system level, possibly by using an "Open Last Used Location" menu time which opens a Tracker window.

Issues

  • Does specifying the filename in the bar save? Changing the filename after saving copy the file? Move the file?
  • Is this more intuitive, and easier to use than current methods?
  • Keyboard control?
  • Takes longer to open a file manager window in the right location, switch back to the application and drag the icon. Method described in last paragraph could counter this.
  • Becomes more distant from the mainstream methods, creating an even steeper learning curve.
  • New (although something similar was used in RISCOS). Not tested, not known to be effective.
Syndicate content