Monday, April 10, 2006

icons

the funny thing about icons for files is that they are pervasive and yet the most complex thing on our desktop. you can left click them, right click them, select them, open them, perform actions on them, drag them .... all on a little patch on the screen that has no documentation or helper information. to add insult to injury most desktops expect the user to master double clicking. oooh, what fun!

so while working on plasma today i decided to see what a pet idea of mine might look like. i was building the start of what might become the desktop and panel areas on top of qgraphicsview when i decided to create an icon item that supports a mouse over interface. i looked at some mockups ken wimer did last year after we had discussed this concept in berlin and started hacking.



here's how it works: when you pass the mouse over an icon (as oppose to whip the mouse over the icon) the icon blurs slightly as an overlay fades in smoothly (takes <.2s, though it's instantly interactive). this results in a self-documenting, single mouse button interface being displayed. selected icons show their status by keeping a "clip-board" version of the overlay showing. dragging an icon hides the interface, but keeps the overlay to make it obvious which icon you're working with. on moving the mouse off the icon the overlay fades away. it's all anti-aliased, translucent, flicker-free, organics goodness. focus is obvious, selection is obvious, action options are obvious. note that it also solves the "single click is great, but sucks for selection" problem.

right now the "interface" is text only. next will be to provide action icons so that it's not just three lines of text (2 lines of text, one line of actions; on selected icons i might put them on the top "folded" tab as well). it should also be trivial to add things like tagging via icons or overlay/outline colouring.

to really appreciate it, it has to be experienced since interaction and non-static feedback is such a big part of it. i was going to make a screencast until i discovered how crappy screencast creation tools on linux are =/ so a static crappy screenshot it is =P

if this works out, people shouldn't really notice all the tricks and come away feeling pretty unchallenged but content. i have yet to do actual user testing (though i have showed it to a few people locally), that'll follow in the coming weeks as it comes together a bit more. we'll see how it goes. maybe it becomes one more experiment gone nowhere. the challenges i see are that it is different from what people are used to and it does require larger icons, though that's not really a bad thing (esp when zooming enters the picture)

even if the mouse-over icon interface idea doesn't go far, it has provided a testing ground for several of the graphical features that plasma items will need common access to.

these will join other items in group items which, via qgraphicsview's zooming support, allowing for some zooming interface concepts to be worked in. zack's working on getting qsvg rendering to a qgraphicsview, which will help close some of the remaining open issues.

i've run into a few bugs in qgrahpicsview, have done no optimization work yet (waaaay too early for that =) and there's still lots of work to be done such as a global animation tick, further interaction work and tons of more features =)

unfortunately, qgraphicsview isn't widely available yet so i'm kind of stuck working on this privately at the moment. but it certainly seems to be the right tool for this job, even in the beta state the copy i have is in. as soon as qgraphicsview enters the world at large i'll be committing this stuff ...

will be interesting to see how far zack and i get on things by the end of zack's visit (another week or so). post-zack i'll go back to working on kconfig for a bit to get that wrapped up for kdelibs.

btw, "zatoichi - the blind swordsman" is an amazing movie. even in spite of the semi-random scenes that make the occasional appearance art-movie-style, this movie has it all: a great story, awesome swordsmanship, good cinematography and some rather interesting ideas on life and whatnot. maybe not the best date flick, but goes well with nachos.

25 comments:

Janne said...

I really like the idea. But... What if I just want to quickly open the file? Right now I just move the mouse over the icons and click/double-click (depending on the settings). With this system I would have to carefully place the pointer on a specific area on the icon in order to open it. Or does your comment about "whip the mouse over the icon" cover this area? The "actions" above the icon would only appear if the user moves the pointer to the icon "smoothly"?

What if double-click automatically opens the file/folder, whereas hover+single-click could work like you suggest? The user could still open the file/folder with hover+single-click, but double-click would work as well.

bobuse said...

Nice usability enhancement.
I want it for my family/folks !

Aaron J. Seigo said...

> What if I just want to quickly
> open the file?

"Open" is the item at the top of the icon, and with these larger icons that hit zone is larger than many people's icons are.

i've found while playing with this that hitting "Open" is really easy. "Select" being in the middle feels harder but there are many ways to select (e.g. rubber banding)

Ismail Onur Filiz said...

It's a very good idea. But for years, what I have been waiting for was pie menus ( http://en.wikipedia.org/wiki/Pie_menu )
They would be even more suitable in the context you described, and quite innovative. Do you think it is feasible?

Janne said...

""Open" is the item at the top of the icon, and with these larger icons that hit zone is larger than many people's icons are."

True, but people are still accustomed of being able to open the file/folder from anywhere in the icon. Of course, they might learn to target the top of the icon in order to open it.

And if we use bigger icons, we will have fewer of them ;). Bigger can be better yes, but what about situations where there really are lots of icons? Think of some folder with lots of files in it. If we use huge icons, we will have only few files visible at a time, requiring the user to scroll around.

Things like this are never easy :)

Anonymous said...

Leaving the topic of icons... Have you seen Alias Maya "Hot box" (I think it's called that). Basically you hold down a button for a period of time and a menu pops up showing menus of everything.

Haha.

Aaron J. Seigo said...

> pie menus

@Ismail
pie menus have been tried in various interfaces; they have scalability problems but can work out ok. they don't, however, solve the issue that i'm looking at, which is a combination of discoverability and limiting interaction complexity (e.g. only requiring hover + single click)

@Janne
> but people are still accustomed

yes, it's different. how people take to it will be a very interesting thing to find out. i'm lining up both basic computer users and advanced users here in calgary to try these things out.

> but what about situations where
> there really are lots of icons?

one can always fall back to list views. in practice, however, such situations seem to be the minority.

as an interesting trend example: media apps these days tend to limit the number of actively visible entries. look at the iPod interface or most photoalbum apps with their large thumbnails.

a fun exercise is to get a bunch of paperclips (or other small thing) and experiment with throwing them on a desk and counting them visually. start with 3 or 5, try 10, 8, 15 ... at what point do you start to sequentially scan versus "snapshotting" the number? how does time increase? it's pretty revealing about information density and our (in)ability to handle large collections of items as individual things.

i really don't think the average human being is really more productive with 100+ icons on their desktop.

> Think of some folder with lots of
> files in it. If we use huge
> icons, we will have only few
> files visible at a time,
> requiring the user to scroll
> around.

i see a few possibilities here:

- scrolling may not be that bad of a problem
- zoom-n-sort displays may help limit the problem, particularly on the desktop (as opposed to the file manager)
- 2 dimensional sorting matrixes may be employed to increase search efficiency (more a file manager thing than a desktop thing)
- the trusty listview can come to the rescue in dire situations

but yeah, it's still an open question. putting these things in front of users will help us find out.

Anonymous said...

Hi,

this is a nice idea. I'd like to make some proposals on the topic. Especially the "select icon"-problem may be solved by this kind of interface, also I would like to see a one click mechanism for renaming files, but any other interaction possiblities should preferably be integrated into some kind of interactive tooltip to prevent overcrowding of the icon interface.

Let me specify this a bit more. When I first used KDE3.5, I noticed the new tooltip appearing when moving the mouse over the desktop-switcher applet in kicker. Intuitively, I moved the mouse over the tooltip with the intention to select one of the windows listed there. Unfortunately, the only effect was the disappearence of the tooltip.

The same thing about the tooltips which appear when pointing with the mouse on an icon. They show some information about the file but they also could be more interactive and offer some actions like "print", "send to" or simply "actions", "what is this?", "what can I do with this" to assist users who are less familiar to using computers.

Just an idea...
Greets, Alex

Anonymous said...

This looks like a great idea! The icons don't normally do anything but look pretty.

--texnofobix

Anonymous said...

Hey, that's a cool thing! Now I guess the real challenge is to solve single clicking for list views with 16x16 icons :-P And don't tell me it's a power user thing! Think of episodes of a tv series or multiple versions of document, these are a lot easier to grasp in a list, than side by side with squeezed labels. Not sure how feasible it is to zoom icons up to 64x64 on mouse over...especially if you want to go on selecting and the list moves around because of zoomin and unzooming...

Greets Michael

Anonymous said...

Hello,
It's a great concept I think. I can imagine the mouseover effect and it must be very slick :D
It may convince me to use single clik (which I never use cause of the selection problem...)

A little question out of subject... on what Linux distro do you develop KDE? I may wanna give a try to KDE SVN and wonder which distro would be best suited for building it...

Bye bye

jayKayEss said...

I live for these little glimpses into KDE4...

I think this is a great idea, but I share the worry that it'll make it harder to quickly open a file. Maybe make the open action take up more space, say 50% of the icon, and the other two actions each get 25%?

gabriel said...

What I'd really want to see in KDE 4 icons, is the ability to redimension them according to user will.

I do have severan icons placed in my desktop (not that much, but some), and I notice there are some of them I'd like to give preeminency over the others (maybe because are the ones that are most frequently used ...or just think of a quick text note placed in the desktop after a phone call that I want to be really big, so to see it more clearly and not forget it).

So I think that by just being able to easily scale icons to their will, icons would serve better and also contribute to a more personalized look of the desktop.

Thanks for listening. :)

gabriel said...

"So I think that by just being able to easily scale icons to their will, icons would serve better (...)"

well... I meant "user's will" not "icons' will", now that would be pretty awesome! ;)

Anonymous said...

As bobuse said, "I want it for my family". I think the discoverability is great, and I have observed that many older folks have trouble with double clicking properly.

Unfortunately, this is another thing that I will have enabled for only a few minutes, and then go back to the default behaviour. It's a cool idea, but for someone that already knows how the current icons work, it will only slow down their interaction with these icons. If I want to open a file/application, I double click it, if I want to select it, I click, or see the menu, I right click. Now I have to wait for the animation and then click the right area. I'm sure it's not much of a delay, but 0.15 seconds is enough to be annoying.

That doesn't mean this is a bad idea though. It's a great idea, just not something I can see myself using at the moment. Perhaps I will change my mind when I actually see it in action.

-leo

Anonymous said...

I don't know how much real-estate is available on the icon ( I suppose it's dependant on whether it's zoomed ) but I would like to see more space provided to 'open' since it is often the common case. Basically my rationale is similar to what janne said, most often you want to just open the file and I think that task should be easiest.

Aaron J. Seigo said...

as for Open being the most used, that's why it's at the top. i'm hoping that being the top third of the icon will be enough. if not (user testing will reveal that) then it can be made larger quite easily.

as for it being something for new/average users only, i do think it will help those people the most, yes. the vast majority of people are remarkably poor at right click, double click, etc...

the real question is if it really is any slower. single click is definitely faster (and less physical strain) than double click, so if one can do away with the need for double click that is a win.

but will everything be "fast enough". well, how fast do we interact with our icons right now? playing with it here, i actually don't notice it being any slower because i don't actually sit and wait for the interface to completely appear... it's quite each to skate over the icons and go "click, click, click". there's also still rubber banding for large multiple selections, etc..

dragging is no slower (just zoom, click, move ... on drag the glass overlay is there but no interface)...

in fact, with enough polish this actually might turn out to be -faster- than the current mechanisms... we'll see, in any case =)

Anonymous said...

Zatoichi is a cool film.. In The Mood For Love and Infernal Affairs are two other recent Asian films that I really love too.

And the icons are neat!

Bille

AlfredNilknarf said...

I find that I prefer using the scroll wheel to moving the mouse very small distances. What about a "dialing" feature to accomplish the same thing: When you pause over the icon a circular menu appears. You dial the scroll wheel until the desired function appears. If it is a multiple level menu than the same thing would happen with the selected item. And add some clicking sound effects to top it off!

sinewalker said...

If what you are describing is the same as I am imagining, then I love this idea.

right now the "interface" is text only. next will be to provide action icons so that it's not just three lines of text…

You want want meta-icons instead of text? This is a nice idea. I was going to experiment in GIMP and post some suggestions for you, but after a bit of playing, I discovered that meta-icons can get visually cluttered, with little icons popping up on your icons.

To throw yet another idea on the table: what about morphing the icon in standard ways instead? e.g. moving your mouse into the Open area at the top third of the icon could make the icon do an animated page-flip (or if it's a package-box icon, or a folder, it could actually open); in the Select area, the overlay changes colour to be your Selected colour, and in Actions, I don't know—makes it jiggle sideways or bounce?

I would be inclined to leave the text there too, so that these moving icons aren't too obtuse (or, do the useal Unix cop-out and "make it an option", like tool-tips).

The mechanics of implementing this could be interesting. Instead of having the Oxygen artists draw different icons for each of these options (yikes!), why not use the SVG technology to morph the vectors programatically? I don't know if this could work or not, but simple things like a page-flip or jiggle could work, if the SVG icons are built with standardised named elements (e.g. the page outline part of file icons could be called "page" or "paper" or something), and then plasma could animate the well-known elements in a standard way. Or, have an SVG routine that does the animation however the artist designed and then Plasma just calls that.

I also like gabriel's idea of user-sized icons. I was most impressed with this idea when I was using IRIX, because I could make important documents on my desktop bigger. Again, if we are rendering the SVGs directly in Plasma, insteady of converting to bitmaps, then the mechanics of implementing a scaling into the icon render should be fairly straight forward. As for the UI to scale, maybe another hot spot in the floating overlay? But that would clutter the overlay too much. Perhaps a Zoom option in the Action menu, that operates on all selected icons would be better, as I expect icon resizing is probably not a common operation.

My main concern (which from reading stuff on the Appeal and Plasma sites I'm sure you share) is that it should be appealing, and not weird. The icons' behaviour should be fairly familiar to an experienced user, while the nice extras are easily discovered and become second-nature, so that they are missed when going back to MS-Windows, OS-X, GNOME, or whatever. But I'm sure with careful user testing, the right balance can be found.

Anonymous said...

I'd like to remind the idea for full-featured icons.
http://www.e-gandalf.net/wiki/index.php/KDE4_Features/File_icons

Icon could became sth more than pure eye-candy block with and image, but also present some data like in this example:
http://img314.imageshack.us/img314/4498/kgetvorschlag3ot.jpg

It could be extended and for example present "Open / Edit / Launch" actions at the bottom of the icon.

Janne said...

Well, I have confidence that you will "get it just right". So I'm looking forward of seeing this in KDE4 :)

Anonymous said...

Definetly the right aproach when used on Tablet/handheld/other-stylus-controlled pc.

Anonymous said...

seems like a very good idea to me!

Jordan Klassen said...

Genius! For me, it would definitly be a good transition since I'm alredy caught in between the windows double click and the KDE default single click.