UI Design - add resource window more gesture oriented

[Aaron J. Seigo]

On Tuesday, September 13, 2011 18:43:20 Fania Bremmer wrote:
> Hi there,
> 
> While I am documenting the UI Design for Plasma Active, I came to the
> point to have a closer look at the add resource window.
> 
> For me it has currently a very "oldschool" interaction, as known from
> the pc with a mouse. Marco and I had already discussions about how to
> make it more touch-friendly and easier in interaction.
> 
> I made up my mind and designed the following ideas (maybe not for
> version 1.0, but the next relases will follow soon :) ...). Please
> consider the following screens as wireframes, not as final design
> specifications.
> 
> http://share.basyskom.com/contour/UIDesign/1-addResource_window.jpg
> #1: The Add content window (wording "content" sounds better then "items"
> in my opinion):
> Here the user can either search for content (like it works already now)
> and/or select categories (a dropdown instead the current icons, that
> rather confuse then show the filtering function).

given that the user can add applications/widgets as well as 
documents/contacts/etc (two different "kinds" of things: one is a tool, the 
other is information), would these be shown altogether in your design? if so, 
how do we deal with the issue of applications/widgets being a (more or less) 
fixed size of items that will be non-small -> do we show them in the list 
after all documents, before, interspersed?

other open question for me:

* do people find it easier to find specific things (e.g. "that photo of the 
mountain" or "george, the guy i met at the conferene yesterday") if they are 
given categories first or is search purely enough?

* how does this scale to larger numbers of items?

* will it seems like a jumble of items to a person using the device?

there's also the issue of time-to-show. with the fixed set of icons, we can 
show the dialog almost instantly in a finished state. if we start having to 
load large numbers of entries right at the start, the time to show will 
increase, particularly "time to show until it is ready for use". hopefully 
this time will remain low given fast enough systems for retrieving and 
displaying the entries (esp asynchronous load+show)

one idea that occurs to me is that we could show each "kind" of content 
(image, document, contact, etc) as a page with all the items for that type 
shown in a vertical grid. the different kinds of content would be represented 
by a row of icons at the top, one for each type (similar to how we do today) 
with the currently selected icon larger than the rest. you could then either 
swipe between the pages to move sequentially between the types of content or 
select an icon from the list above to move directly to the page in question.

see attached mockup...

> #3: Now I start dreaming :) Instead of an add-button, the user simply
> drags the selected content into the activity area behind the window. The
> background area gets a highlight color as soon as the fingers reach a
> dropzone. If the user releases here, the new resources are loaded in its
> boxes. If the user releases within the add-content-window, nothing
> happens. If the user simply touchs in the background, the window closes
> (=cancel).

i'm cool with the no-cancel button, but highly sceptical that people will 
quickly figure out and feel comfortable with the idea of dragging to add. this 
is the kind of interface i come across every once in a while and end up 
grumbling about when i do because it expects me to magically know what to do 
without any hints. the biggest issue for me, however, is that a drag is more 
time consuming and motion-sensitive than a simple one touch button. imagine if 
you had to drag the button in an elevator to some zone on the wall instead of 
just touching the floor you want to end up on? :)

the other thing with drag (and hit-outside-to-cancel) is that we then must 
leave margins around the dialog big enough for this. currently we do ... but i 
always wonder if we can't use more of the screen space to show bigger or more 
entries at once.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mockup.png
Type: image/png
Size: 17679 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/active/attachments/20110914/2e1ac72c/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/active/attachments/20110914/2e1ac72c/attachment-0001.sig>