System Browser UX analysis - double key shortcuts

I happened to be back using a Squeak image to run the VM simulator and
wanted to report my experience that it was a *joy* to again be able to
use <ctrl-x> to delete methods from the System Browser.  Over the past
>12 months rather than complain about the double-key shortcuts, I've
given myself time to adapt - but in practice I've adapted by always
using the context menu rather than the double key shortcut.  I don't
understand the advantage of the double-key shortcuts here and why the
same <ctrl-x> shortcut can't work in each of the four System Browser
panes, since the "context" is provided by which pane is selected.

I do recognise the value of double-keys for global shortcuts, since
you need the first to select the tool to provide context for the
second key.

It would be nice to get some UX stastics for the System Browser about
the predominance of shortcut versus menu usage for different people.

cheers -ben

Hi ben

I never liked the double keys, but when they got introduced by camillo
and ben the goal was to be able to fully

navigate wihout having to touch the mouse. So from this goal point of
view it was a nice attempt.

Now we should be able

     to let user decide

     to have the same double keys in the other pane to avoid to create a
mode.

Stef

Le 10/6/16 à 03:33, Ben Coman a écrit :

well… supposedly a revamp of the shorcuts mechanism will happen sometime during 6.0 development (if I find the time to work on it, or someone jumps in, of course :P)

the idea with this is to centralise actions (using command pattern) and then users just declare what they will be using… then *all tools* in system with same shortcuts will share actions.
external packages should also have the possibility of install their actions… this can create collisions, but well… (btw, same “user install/declare” idea should be taken for icons and others, as a way to avoid the stupid coupling of packages we have now)

Esteban

On Fri, Jun 10, 2016 at 2:34 PM, stepharo <[hidden email]> wrote:
> Hi ben
>
> I never liked the double keys, but when they got introduced by camillo and
> ben the goal was to be able to fully navigate wihout having to touch the mouse.

If its all new code pouring out of your head with two hands
permanently on the keyboard, maybe this may make sense.  But most of
my time is browsing to understand how to solve bugs, and my hand is
usually on the mouse.

> So from this goal point of view it was a nice attempt.

I'm happy with the attempt.  It sounded like a reasonable philosophy.
It just didn't pan out for me.

> Now we should be able
>
>     to let user decide
>
>     to have the same double keys in the other pane to avoid to create a
> mode.

I'm not clear on what you consider a "mode" here, but I'd distinguish
it from "context". When I right-click the method pane I get one menu
of actions, and when I right click on the class pane I get a different
menu of action.  The same action has a different response because of
different context - and the shortcuts are attached to these contextual
actions, so maybe its okay for the shortcut to be contextual.

I would consider a "mode" getting different commands within in the
same context - like hitting <esc> in a text editor like vi.


On Fri, Jun 10, 2016 at 2:47 PM, Esteban Lorenzano <[hidden email]> wrote:
> well… supposedly a revamp of the shorcuts mechanism will happen sometime during 6.0 development (if I find the time to work on it, or someone jumps in, of course :P)
>
> the idea with this is to centralise actions (using command pattern) and then users just declare what they will be using… then *all tools* in system with same shortcuts will share actions.

But when I right-click on the method pane, I don't get a first level
menu [package;class;protocol;method] and select one of those first,
then select my action.  It *knows* I'm concerned with the method pane
and I'm shown the context.

Perhaps a single-key shortcut <ctrl-x> has its context ("M" in the
method pane) added to convert it to a double-key shortcut before it is
looked up centrally.

> external packages should also have the possibility of install their actions… this can create collisions,

Maybe the single-key shortcuts should be limited.  Its specifically
<ctrl-x> that I miss, and this one I think has a broadly accepted
meaning across domains, and would be rare for an App to redefine it.

cheers -ben

> but well… (btw, same “user install/declare” idea should be taken for icons and others, as a way to avoid the stupid coupling of packages we have now)