1.       Open clean visual.im

2.       Load the attached parcel

3.       Execute “EnterButton open”

4.       Hitting “Enter” key now does not invoke the default action

The issue is on line 17 of CompositePart>>client:spec:builder:

Current,

  aBuilder window == nil ifTrue: [aBuilder setWindow: self topComponent].

Fix (attached),

  aBuilder window == nil ifTrue: [aBuilder window: self topComponent].

As a side note, if SubCanvas is obsolete, UIBasics-Components should not be defining another implementation of #client:spec:builder: there.

-Boris

--

DeepCove Labs Ltd.

+1 (604) 689-0322

4th floor, 595 Howe Street

Vancouver, British Columbia

Canada V6C 2T5

http://tinyurl.com/r7uw4

PacNet Services (Europe) Ltd.

+353 (0)61 714-360

Shannon Airport House, SFZ

County Clare, Ireland

http://tinyurl.com/y952amr

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments.

Thank you.

My point was to say that even if you go through all the UX testing and settle on a subset of items you think would serve the majority of your clients, you’ll still have a subset of clients who would like to configure it to their own personal liking. Configurability of toolbars is long overdue and my suggestion was to use these types of discussions as a motivator to just get it done. If you wanted to be real fancy about it, you could then add opt-in reporting of individual users’ choices back to the mothership and use that data to come up with a default order as per majority’s preference.

Actually, I think that configurability of toolbars is almost never the right answer. It’s usually a cop out to avoid doing the user testing that would tell you the right answer. But if what your usability testing tells you is that you should have configurable toolbars, then I’m all for it. :)

Or let me put it another way. If you get to the point where you have, say, two “right” answers (maybe there are two kinds of users), maybe it makes sense to provide a choice between them. Until you have at least one “right” answer, however, configurability is only going to make the problem more complicated.

Julian

On 10-09-03 12:10 PM, "Boris Popov" <boris <at> deepcovelabs.com> wrote:

I'll say it again... making toolbars configurable you can save yourself
an endless discussion on trying to come up with something that works for
everyone, because it's simply impossible in this context.

-Boris

--
DeepCove Labs Ltd.
+1 (604) 689-0322
4th floor, 595 Howe Street
Vancouver, British Columbia
Canada V6C 2T5
http://tinyurl.com/r7uw4

PacNet Services (Europe) Ltd.
+353 (0)61 714-360
Shannon Airport House, SFZ
County Clare, Ireland
http://tinyurl.com/y952amr

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message header.
Unless otherwise indicated, it contains information that is private and
confidential. If you have received it in error, please notify the sender
and delete the entire message including any attachments.

Thank you.


-----Original Message-----
From: vwnc-bounces <at> cs.uiuc.edu [mailto:vwnc-bounces <at> cs.uiuc.edu] On
Behalf Of stephane ducasse
Sent: 03 September 2010 12:05
To: Julian Fitzell
Cc: VWNC
Subject: Re: [vwnc] Home Context Button [was: [vw771] dead in the water]

a good and cheap way to debug UI is the following
        - take three typical users
        - ask them to speak aloud about the hypothesis that they are
building when interacting with the UI.
        - listen and fix

Stef

On Sep 3, 2010, at 12:44 PM, Julian Fitzell wrote:

> On 10-08-26 12:14 AM, "Martin McClure" <martin.mcclure <at> gemstone.com>
wrote:
>
>> On 08/25/2010 10:18 AM, Alan Knight wrote:
>>> Actually, I never even knew that option was there. Personally,
>>> although I know that people's usage styles vary a lot, I very rarely

>>> use the debugger toolbar at all. The options I use from there are
>>> restart from the beginning of the context, return a value, and
terminate.
>>
>> Those are all useful, and I use them all, but I use the Home Context
>> button far more frequently than any of those. In fact, I use the Home

>> Context button more often than "Step Over".
>>
>> If there is any truth to the idea that Home Context is an
>> infrequently-used button, I believe that it's only because folks
>> don't know what it does. Which is a problem, but the solution should
>> be more along the lines of "let's make it more prominent so people
>> will know it's there" not "let's hide it in a menu". It's far more
>> useful than many of the buttons still on the bar.
>>
>> Maybe the thing to do is instead of a button on the toolbar, put a
>> button on every block context in context list that will select its
>> home context, with that button dimmed if that particular block
>> context does not have a home on the stack.
>
> The problem is that the expectations of a product's engineering team
> do not necessarily align with those of its users. Obviously, as
> developers, we are all aware of this fact in theory, but we rarely
> assign it the significance it deserves in practice. Getting even half
> a dozen users into a "usability lab" scenario would very quickly
> provide data to test hypotheses and guide this type of ongoing UI
> refinements (this could even be just users with a webcam and a screen
sharing program).
>
> The book "Don't Make Me Think: A Common Sense Approach to Web
> Usability" by Steve Krug, while a bit specific to the web in places,
> provides a good description of how this sort of testing can be easily
> set up. Well worth a quick skim for anyone who is interested in the
topic.
>
> Julian
>
> _______________________________________________
> vwnc mailing list
> vwnc <at> cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
vwnc <at> cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc