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