Start with a short user story. ( e.g. kbd focus) (from refactoring morphic thread)

refactoring morphic


Hi Lukas, hi Enno

I like that this its short. And I think I'll have to
add
"Now, the biggest annoyance about morphic is that ..."
to my sentence starter list.

I usually start out with the motivation of a morphic
annoyance. If I'm not annoyed enough by something I
won't spend time trying to fix it.

After the annoyance as I start to want to fix it. I
need to focus on the positive side of the user story.

What should morphic do instead?

>Unfortunately changing this is a not so small step,
as it propagates
>trough the whole system :-(
>
 At the user story stage negatives don't count.
 
How does the user indicate he wants the keyboard focus
to attend to a particular place?
What moves it?
What would not be allowed to move it?

One of the things I've wanted for a long while is a
sub-keyboard focus.
Arrow keys and cmd keys don't necessarily belong to
the same focus point as text insertion keys.

Can you come up with a user spec for what you want?


Yours in curiosity and service,

Jerome Peace


>Lukas Renggli renggli at gmail.com
>Thu Dec 14 06:12:31 UTC 2006 wrote:
>
>> Start with a short user story.
>>
>> Finish a sentence like.:
>> Morphic should ...
>
>Now, the biggest annoyance about morphic is that I
cannot use my
>keyboard properly, e.g. I have to point my mouse to
an input box
>before typing.
>
>Unfortunately changing this is a not so small step,
as it propagates
>trough the whole system :-(
>
>Lukas
>
>--
>Lukas Renggli
>
>To which Enno Schwass adds: +1
>


 
____________________________________________________________________________________
Any questions? Get answers on any topic at www.Answers.yahoo.com.  Try it now.

> How does the user indicate he wants the keyboard focus
> to attend to a particular place?
> What moves it?
> What would not be allowed to move it?

I would stick with existing practices of common operating systems,
such as Mac OS X [1] or Aero [2]:

- there is at most one focused element at a time.

- tab: moves the focus to the next item in a sequence (except for
text-oriented controls that want tab characters, where alt-tab should
be used to move to the next one).

- shift-tab: moves the focus in reverse direction (except for
text-oriented controls, where alt-shift-tab should be used to move to
the previous one).

- ctrl-tab: moves to the next window.

- shift-ctrl-tab: moves to the previous window.

- enter: presses the default button (e.g. accept a method).

- esc: presses the cancel button (e.g. cancel a method).

Of course the exact keys to be pressed should be discussed (maybe
freely configurable), this is just an example. These stories
(features) would already increase my productivity in Squeak heavily.

Lukas

[1] http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGUserInput/chapter_11_section_3.html
[2] http://msdn2.microsoft.com/en-us/library/aa969768.aspx

--
Lukas Renggli
http://www.lukas-renggli.ch

Lukas,

Well said.  Another common shortcut is control-enter for multi-line
text fields.  I agree that the exact key sequences should be
configurable; the goal is to match the expectations of the user, which
will vary with OS and time, if not other factors.

Squeak's lists are far too eager to grab keyboard focus.  I am
(slowly!!) working on a fix (see MouseOverMadness.cs on Mantis), and
Doug Way (IIRC) provided some very useful constructive criticism of the
first draft.  Feel free to beat me to it, or to organize a larger effort
to get this right.

One thing that MS does that I actually think is smart is to direct
mouse wheel messages to the top view at the cursor location, regardless
of focus.  A user turning a wheel is probably doing it deliberately and
expecting the effect to apply at the cursor location, but a user typing
is not necessarily expecting the keyboard focus to follow a mouse cursor
that has been "moved out of the way".

Bill


Lukas Renggli wrote:

> How does the user indicate he wants the keyboard focus
> to attend to a particular place?
> What moves it?
> What would not be allowed to move it?

I would stick with existing practices of common operating systems,
such as Mac OS X [1] or Aero [2]:

- there is at most one focused element at a time.

- tab: moves the focus to the next item in a sequence (except for
text-oriented controls that want tab characters, where alt-tab should
be used to move to the next one).

- shift-tab: moves the focus in reverse direction (except for
text-oriented controls, where alt-shift-tab should be used to move to
the previous one).

- ctrl-tab: moves to the next window.

- shift-ctrl-tab: moves to the previous window.

- enter: presses the default button (e.g. accept a method).

- esc: presses the cancel button (e.g. cancel a method).

Of course the exact keys to be pressed should be discussed (maybe
freely configurable), this is just an example. These stories
(features) would already increase my productivity in Squeak heavily.

Lukas




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

> Squeak's lists are far too eager to grab keyboard focus.  I am
> (slowly!!) working on a fix (see MouseOverMadness.cs on Mantis), and
> Doug Way (IIRC) provided some very useful constructive criticism of the
> first draft.  Feel free to beat me to it, or to organize a larger effort
> to get this right.

Great to hear that there are people working on improving the
usability. Continue!

If you need a tester, I can help.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Squeak has the old X windows style by default.

_________________________________________________________________
Share your latest news with your friends with the Windows Live Spaces
friends module.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk