[Appeal] a proposition for new file icon interaction mechanics

[Aaron J. Seigo]

(i've attempted to mock up some of what i describe below but all i managed to 
 accomplish was prove to myself that i have no business ever being a graphic
 designer. so instead i will just use words. =)


DESCRIPTION OF THE PROBLEM

designing a file manager view raises so many questions. 

single click or double click? what should appear in the context menu? and how 
many of those items should appear in the easier to discover toolbars and 
menus? how do we show which icons are selected? how big should the icons be? 
thumbnails? do we show mimetype specific interfaces?

many of these questions are either complicated by or arise directly from the 
most fundamental representation we have: the humble icon. it represents an 
object, and one selects that object by performing an action on it. one 
launches it by performing another similar action. one performs actions on it 
by selecting it and then choosing from a number different possibilities 
spread out around the interface. this is a highly complex interface that must 
be taught because none of it is obvious and the various possible actions are 
very similar.

the very idea that within a small space (by default 32x32 in KDE IIRC and 
64x64 in MacOS X) we require people to perform all these intricate actions is 
a bit silly. when screens were 9 inches on the diagonal and a resolution of 
640x480 was "breathtaking" these small icons made sense. and the size of the 
icons put restrictions on interaction possibilities.

PROPOSAL

my proposal is simple: let's use larger icons and take advantage of that extra 
real estate to create a small interface the user can directly act upon.

look at a window. the window bar has buttons one accesses to accomlish the 
common tasks and serves as a way to "select" a window. draging and growing 
windows can be done using the borders, which often _look_ grabbable and 
draggable. (well, not so much in KDE, but more so on MacOS =). taking a cue 
from this, icons should have an interaction interface.

when the mouse pointer hovers over an icon (min .25-.3 seconds to avoid "hover 
over spasms" when just moving the cursor across a window to a destination) an 
overlay will appear on top of the icon or thumbnail. this overlay should be 
pretty, e.g. a tinted, translucent sheet with nice soft edges and corners. it 
should "melt" in and, on the cursor leaving,  "melt" out. on this overlay 
sheet a set of interface zones with interactive elements will appear. each 
zone will provide for a distinct interaction operation and should appear 
distinct from other zones.

by using 128px icons each zone could be larger targets than our current icons 
are. the overlay would be slightly larger than the icon itself.

the "Select this object" zone: this element would appear at or near the top of 
the icon interface, much in the way that window title bars appear at the top 
of windows. it would _say_ "Select this object" or perhaps just "Select" for 
brevity and have a checkbox or some other commonly used interface item that 
says "toggleable". click on this area would result in selecting the icon. 
once selected, when the mouse moves off the icon the rest of the icon 
interface will disappear except the "Select this object" zone and the 
translucent overlay. this will make it obvious the object is selected. 
additionally, an object pile for the "selected items" will reflect it's 
membership in a sidebar. 

(jan was going on about "object piles" the other day, but they are generally 
out of scope here; still, i couldn't help but mention them. i think they can 
be quite useful. i envision them having a similar interface to the one i'm 
describing here as they are just another "object")

the "Use this object" zone: this is a simple "button". this replaces what 
single clicking on an icon in KDE does or double clicking in other interfaces 
does. it would be interesting to experiment with having a "View" and an 
"Edit" area in this zone, but that may be making it too complex?

the "Actions" zone: this is where all the action is. a drop down list of 
possible actions appears here that will act upon _this_ object. to operate on 
_all_ selected objects the object pile should be used (i'm unsure of this one 
yet, but there you go anyways ;). this would include all those special 
actions we currently have in the context menu as well as some of those 
scattered elsewhere in the traditional file manager interfaces.

for certain file types a "mini interface" may appear here as well. e.g. for 
media files a small "play / pause / stop / progress slider" combo.

the "Information" zone: this zone is also a simple clickable area which would 
"slide out" a drawer containing addition information for this object that one 
doesn't usually need but may want on an object-by-object basis. this could 
include things like file permissions or context information.

these zones wouldn't need to be stacked vertically. they could be layed out in 
a grid, though complexity should be avoided.


IMPLICATIONS

using larger icons lowers information density and in the common case makes it 
quicker to find files. the overlays allows us to offer a "one button, once 
click" interface for managing information in icon views. by appearing on 
hover, the user simply has to indicate their interest by moving the mouse 
cursor to where they want to act and all possible common interactions are 
immediately and plainly available, making the interface discoverable and 
apparent.


NEXT STEP

a set of story board mock ups showing what an overlay might look like, the 
transition effect, what a selected object would then look like, etc.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/appeal/attachments/20050409/945fdc53/attachment.pgp