unity-design team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxxxxx>]

On 22/02/11 13:28, John Lea wrote:
> I think there are two different interactions we can implement here,
> one that is mostly additional functionality and a second that needs
> further thought and visual design treatment.
>
> ---------------------------------------
> 1)  Find all apps that can open a specific file type.
>
> In this interaction, when a user starts dragging a file (or files) the
> 'App Lens' is one of the Launcher icons that highlighted indicating it
> is a valid drop receptacle.  Dragging the file over the app lens
> launcher icon reveals the app lens showing only the applications which
> can open the specific file type(s).
>
> Use Case 1 - Continued drag and drop
>
> The user then continues dragging the file and drops it on a
> application icon in the app lens.  The action closes the app lens and
> opens the file in the selected application (installing the application
> first if necessary).

We can't just install an app with such a lightweight signal. We need to:

 * clearly distinguish between apps which are installed, and apps which
are not
 * provide an intermediate "do you want to install this" confirmation en
route to *s*a*t*i*s*f*a*c*t*i*o*n* :-)


> Use Case 2 - Drop then select
>
> The user drops the file on the app lens icon. They then click on the
> application in the app lens they want to use to open the file.  The
> action closes the app lens and opens the file in the selected
> application (installing the application first if necessary).

I think dropping content on a lens is a concept we should explore in
more detail for Natty+1. I can see it being relevant for lenses which
might also be storage interfaces - think a Flickr lens. But because a
lens is intrinsically open-ended, I find dropping on the lens itself a
little mysterious. Gliding *through* the lens, to some more obvious
destination, is better, as might be  a quicklist-target.


> Use Case 3 - Abandon action and exit
>
> If the user decides to abandon the action they can either:
> a) drag the file back on to the launcher, this closes the app lens
> b) drag the file outside of the dash area (only applies to the desktop
> dash)
> c) drop the file in any area of the dash that is not a application icon

We do need to think through the general case of "abandoning a
drag-through". Similarly in the drag-through-an-app-spread story.


> Considerations:
> a) In the use cases described above, the app lens should display two
> category headers.  These should be "Installed Apps that can open .jpg
> files" and "Apps Available for Download that can open .jpg files". 
> Both of these categories should be expanded by default.

+1

What about cases where there are too many of them?

> b) For use case 1 (continued drag and drop) dragging the file to the
> bottom or top of the app lens should initiate a auto-scroll behavior

+1 too :-)


> ---------------------------------------
> 2)  Display the currently installed default app that can open the
> specific file type in the Launcher (if it is not there already).
>
> While I like the interaction because it increases the vocabulary of
> drag and drop launcher behavior, it is essentially a *slower* way of
> performing exactly the same action as double clicking or tapping on
> the file.

It is, however, explicit rather than implicit.

Mark

Attachment: signature.asc
Description: OpenPGP digital signature