Keyboard shortcuts ideas

[tona monjo]

Hi Arash,

Thanks for sending us your explorations! In addition to Colin's comments, I
come with some more thoughts:

- In case the device has not physical keyboard, can the reference to
specific keys (C, V, etc) lead to confusion? I imagine, for instance, a
kiosk with no physical keyboard but with a touch-screen or a pointing
device. George (our persona) wants to copy/paste text, so when he selects
the text, shortcuts panel indicates that he can tap C to Copy. Then he must
move his finger or the pointing device to the virtual keyboard and tap on
"C". I mean, in case there is no physical keyboard, should we keep an
indirect interaction (using the virtual keyboard), or should we offer other
kind of more direct shortcuts? (like those that appear iBooks or Kindle
when we select some text, e.g.).

- Using keys directly as shorcuts, can conflict with some other functions
in the system, like writing or editing the selected text? I mean, should we
always use a keystroke?

- Personally, I think that the idea of gestures can be very interesting
when more developed, but it should always complemented by another kind of
shortcut, because it requires certain level of precision from the user.

Cheers,

Tona





On Tue, Jan 22, 2013 at 11:00 PM, Colin Clark <colinbdclark at gmail.com>wrote:

> Hi Arash,
>
> Thanks for sharing your idea. I'm wondering if perhaps you can elaborate a
> bit more on the specific problems you're endeavouring to solve, and for
> what uses cases? It feels a bit abstract--like a solution searching for a
> problem. Often looking at specific examples--a type of application and a
> particular user--can help refine a concept like this.
>
> Some specific comments below...
>
> On 2013-01-22, at 11:26 AM, "Sadr, Arash" <asadr at ocadu.ca> wrote:
>
> >>> I tried mapping my research on different types of keyboard shortcuts
> in this mindmap. What I realized was that keyboard shortcuts ( for example
> ctrl+c, ctrl+v) are designed for computers with keyboards, and if the user
> wants to perform the same task in other devices, they would interact in a
> different alternative way. I believe that is because the architecture and
> interface of those devices are different. One of the things I found out
> with this mind map was that most of the keyboard shortcuts used in
> computers is also used in other devices with alternative shortcuts.
>
> One of the things to keep in mind is that keyboard shortcuts are closely
> aligned with, as you say, commonly-used actions. What's interesting is the
> fact that these commonly-used actions are often not very common across
> different types of devices. Some of the examples you have in your concept
> diagrams are like this; for example, Open and Save.
>
> These are typically only relevant as shortcuts within an environment where
> filesystem and document-oriented interactions are commonplace. So on my
> desktop computer, I use a lot of programs where I need to open and save
> files (like, say, Microsoft Word or Keynote). On the other hand, when I'm
> using the Web or listening to music or sending a text message, there are no
> documents--nothing to save or open.
>
> So, before you can go very far with an idea about cross-device shortcuts,
> you need to think about which actions are useful and common to users across
> a broad range of devices, platforms, and goals. Interestingly, I suspect
> you'll find that there are really only a handful of actions that are
> common, which might lead you to a very different kind of design solution.
>
> The second issue to aware of is that often shortcuts are combined with
> other actions. For example, cutting and pasting: the user needs first to be
> able to select something (say, some text), and then execute the action on
> that selection. So in both of your diagrams, there are subtleties to think
> consider.
>
> Does your gesture system potentially conflict with other gestures on the
> system? How does it recognize the difference between a scroll, a select,
> and an action gesture? We might be able to explore modal interactions (eg.
> the timing distinction between "press, hold, then drag to select" vs.
> "swipe immediately to scroll"), but it gets pretty awkward fast. I suspect
> this is why it took Apple so long to introduce cut and paste on the iPhone
> at all.
>
> I hope this helps,
>
> Colin
>
> ---
> Colin Clark
> http://fluidproject.org
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>



-- 
Tona Monjo
LATENT, User Experience Design
http://www.latent-design.com
T (+34) 654 402 387
Skype: tona.monjo
Twitter: tona_monjo
Blog: *http://tonamonjo.net/*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20130123/ee52a149/attachment.htm>