[cap-talk] Granting access to web services

Kenton Varda kenton at google.com
Tue Feb 16 14:29:53 PST 2010


On Sat, Feb 13, 2010 at 4:44 PM, Mark Seaborn <mseaborn at chromium.org> wrote:

> On Fri, Feb 12, 2010 at 11:18 PM, Kenton Varda <kenton at google.com> wrote:
>
>> Maybe we should be thinking of it as the power box providing links to
>> sites which might be used to obtain the desired resource.
>>
>
> You can just use bookmarks for that:  your "take a photo" web app can be a
> regular bookmark.
>

Well, it's useful if the powerbox can provide relevant links based on the
type of resource desired, rather than make you dig through bookmarks.  (Hmm,
this could even be an interesting search problem.)

Also, to be clear, I do think it makes sense for the power box to tell the
linked site that it is being called to request a resource, and for the
linked site to pass that resource back to the power box.  So maybe my
thoughts end up basically equivalent to yours in the end.


>
>
>>
>> So for example, if a requester wants a picture, the power box would
>> present the user with:
>> - Use blank picture.
>> - Use your avatar picture.
>> - Link to paint app, which you can use to create other pictures.
>>   - List of previous pictures created with this app.
>> - Link to camera app, which you can use to take pictures.
>>   - List of previous pictures created with this app.
>> - Link to filesystem app, where you might find pictures.
>>   - List of recently-opened picture files.
>>
>
> So this doesn't need a powerbox, it's just a file browser with links to web
> apps for creating new files.  (I don't mean "just" in a bad way; this is a
> fine way of doing things.)
>

It is very analogous to a file browser.  But I imagine the same interface
working for active content as well, not just static file-like objects.


>
> For example, in the camera case, the user would use the camera's web
>> interface to take a picture, then drag and drop *just the picture* onto
>> the requester.
>>
>
> I am fine with supporting this mode of interaction.  It's just that it's
> less discoverable.  For example, to grant geolocation access to a maps app,
> you would have to open a geolocation app (from your bookmarks) and drag and
> drop its geolocation object to the maps app.  How can the maps app indicate
> that it expects you to do this to enable its use of geolocation?
>
> I think we should support both types of interaction.  Which is preferable
> depends on your workflow.  If you are starting from a tab containing the
> service, drag-and-drop or copy-and-paste is preferable.  If you are starting
> from the requester tab, the powerbox dialog is preferable.
>

Absolutely.  This is exactly what I was suggesting: provide both interfaces.


>   Consider the case of uploading a file:
>
> 1) Suppose I'm writing an e-mail in Gmail (actually, I am...).  I want to
> attach a file quickly.  I select "Attach file" and "Browse filesystem", and
> it takes me to a directory browser (an interactive provider) in a new tab.
> This is much like the interaction in current browsers for uploading a local
> file.
>

Incidentally, I almost always use the drag-and-drop approach for this,
because I find "file open" dialogs to be far less usable than the system's
dedicated file browser, and I often have shortcuts in my taskbar to all the
folders I care about.  If I want to attach a file "quickly", a file open
dialog is exactly what I don't want.

But this is because I am a power user who has taken the time to learn how to
do things quickly.  Most users are far more comfortable with "file open".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100216/47f7daf0/attachment.html 


More information about the cap-talk mailing list