Smalltalk › Cincom › VisualWorks

[vw771] dead in the water

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

51 messages Options

123

Boris Popov, DeepCove Labs (SNN)

Re: Home Context Button [was: [vw771] dead in the water]

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: [hidden email] [mailto:[hidden email]] 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" <[hidden email]>
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
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Julian Fitzell-4

Re: Home Context Button [was: [vw771] dead in the water]

Re: [vwnc] Home Context Button [was: [vw771] dead in the water] 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@...> 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@... [[hidden email]] 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@...>
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@...
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
vwnc@...
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Boris Popov, DeepCove Labs (SNN)

Re: Home Context Button [was: [vw771] dead in the water]

Re: [vwnc] Home Context Button [was: [vw771] dead in the water]

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.

-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.

From: Julian Fitzell [mailto:[hidden email]]
Sent: 03 September 2010 12:22
To: Boris Popov, DeepCove Labs (SNN); stephane ducasse
Cc: VWNC
Subject: Re: [vwnc] Home Context Button [was: [vw771] dead in the water]

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@...> 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@... [[hidden email]] 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@...>
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

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@...
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
vwnc@...
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Andres Valloud-6

Re: Home Context Button [was: [vw771] dead in the water]

In reply to this post by Boris Popov, DeepCove Labs (SNN)

+1...

On 9/3/2010 4:10 AM, Boris Popov, DeepCove Labs (SNN) 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
>
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Cesar Rabak

Re: Home Context Button [was: [vw771] dead in the water]

In reply to this post by Julian Fitzell-4

Em 3/9/2010 08:21, Julian Fitzell escreveu:

> 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.
>

+1

For a more thorough argumentation:
http://en.wikipedia.org/wiki/index.html?curid=14872453

--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Michael Lucas-Smith-2

Re: Home Context Button [was: [vw771] dead in the water]

In reply to this post by Boris Popov, DeepCove Labs (SNN)

I think it's reasonable to expect to be able to extend the debugger toolbar the way we can extend the RB menus and launcher menus. The debugger should probably call the same augmentMenu code as those other tools do. That would allow configurability and avoid overrides without the investment in to a fancy toolbar editor.

On Sep 3, 2010, at 4:10 AM, Boris Popov, DeepCove Labs (SNN) 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: [hidden email] [mailto:[hidden email]] 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" <[hidden email]>
> 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
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Terry Raymond

Re: Home Context Button [was: [vw771] dead in the water]

Michael

However, that means we have to manage additional tool patches.

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI 02878
(401) 624-4517 [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Lucas-Smith
> Sent: Friday, September 03, 2010 11:28 AM
> To: Boris Popov, DeepCove Labs (SNN)
> Cc: VWNC
> Subject: Re: [vwnc] Home Context Button [was: [vw771] dead in the water]
>
> I think it's reasonable to expect to be able to extend the debugger toolbar the way we can extend the
> RB menus and launcher menus. The debugger should probably call the same augmentMenu code as those
> other tools do. That would allow configurability and avoid overrides without the investment in to a
> fancy toolbar editor.
>
> On Sep 3, 2010, at 4:10 AM, Boris Popov, DeepCove Labs (SNN) 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: [hidden email] [mailto:[hidden email]] 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" <[hidden email]>
> > 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
> >> [hidden email]
> >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
> >
> >
> > _______________________________________________
> > vwnc mailing list
> > [hidden email]
> > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
> >
> > _______________________________________________
> > vwnc mailing list
> > [hidden email]
> > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Travis Griggs-4

Re: Home Context Button [was: [vw771] dead in the water]

In reply to this post by Julian Fitzell-4

On Sep 3, 2010, at 3:44 AM, Julian Fitzell wrote:

> On 10-08-26 12:14 AM, "Martin McClure" <[hidden email]>
> 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.

Well put. Which is why I posted and said "in the absence of a lab, a
little screen cast showing me what you're doing and what you're
struggling with, is a cheap/quick first approximation of such an
experience."

I've not received any screencasts yet, or even screenshots yet. Except
from people who I cited before as already doing it anyway.

--
Travis Griggs
Objologist
"An idea, like a ghost, must be spoken to a little before it will
explain itself." - Charles Dickens

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Karsten Kusche

Re: Home Context Button [was: [vw771] dead in the water]

In reply to this post by Mark Plas

not sure if i already said that i miss that button, in the previous thread, but i've also patched my debugger to bring it back. it's just way too useful :-)

Karsten

Am 26.08.10 09:19, schrieb Mark Plas:

I'd like to have the 'Home Context' button back too. I already patched the vw7.7 debugger to put it back on the toolbar, but I'd rather have it there by default (=one override less).

From: [hidden email] [[hidden email]] On Behalf Of Alan Knight
Sent: donderdag 26 augustus 2010 2:51
To: Martin McClure
Cc: VWNC
Subject: Re: [vwnc] Home Context Button [was: [vw771] dead in the water]

Indeed, I had forgotten about the previous thread. So it seems like there are enough people who use it frequently that it's worth considering putting it back, or making the ability to find the home context more easily available in some other way.

At 07:14 PM 2010-08-25, Martin McClure wrote:

On 08/25/2010 10:18 AM, Alan Knight wrote:

[...]

The home context button was removed from the toolbar
in 7.7 development as part of updating the debugger icons and removing
some of the less frequently used options. Perhaps that was overly
aggressive, but I believe this is the first complaint we've had about
it.

Reinout is at least the fourth person to complain about removal of this button. See the VW-Dev thread "home context button restored to its position of prominence?" starting on July 6, 2009.

In addition to the public discussion, Travis and I exchanged some email about it, and I was quite vocal in my opposition to removing it.

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.

Regards,

-Martin

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

-- 
Karsten Kusche - Dipl. Inf. - [hidden email]
Georg Heeg eK - Köthen
Handelsregister: Amtsgericht Dortmund A 12812

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Karsten Kusche

Re: On UI Feedback

In reply to this post by Travis Griggs-4

Am 26.08.10 04:57, schrieb Travis Griggs:
> I can personally vouch for dropbox for sharing screenshots and other
> files. It's free and easy. I'll put a plug in for Jing, free for both
> OSX and Windows as well, a great way to record a quick video, with or
> without audio, and make it shareable. There's probably other similar
> free services.

just out of personal interest I'd like to point out Snapplr for that
purpose. It can be found at snapplr.com and it's only available for the
mac. The idea behind Snapplr is to make sharing Screenshots dead-easy.
It's shareware, but if you'd like a free license, just send me a mail
and I'll send you a license.

Kind Regards
Karsten

--

Karsten Kusche - Dipl. Inf. - [hidden email]
Georg Heeg eK - Köthen
Handelsregister: Amtsgericht Dortmund A 12812

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Richard Kulisz

Re: On UI Feedback

In reply to this post by Travis Griggs-4

On Wed, Aug 25, 2010 at 10:57 PM, Travis Griggs <[hidden email]> wrote:
> UI's are largely about "telling stories." Each UI tells a story, and
> invites the user to participate in it. There's lots of ways to tell a
> story, some better than others. UIs are picture rich stories.

Maybe it's because I'm a UI paradigm designer, but I don't think of
UIs as telling stories.
Reflecting on it, I realize that this can be seen as true but it seems
to be trivially true only.
So I question, do you get any currency out of this perspective or is
this metaphor just a
misguided way of seeming "deep" to the uninitiated?

Chris Crawford in The Art of Interactive Design (notice the namedrop
to make myself
sound more authoritative) wrote that UIs are *interactive* and that
interactivity is a cycle
of speaking - thinking - listening. But he didn't stop there and more
importantly, the term
"dialogue" in no way implies "narratization".

Just because you like to narratize, as humans are wont to do, doesn't
mean there is
any story to tell, let alone that story-telling is a good thing. Just
because *you* are
human doesn't mean anything about UIs at all.

Interaction is actually a good term for everything that goes on in
that part of the operating
system. Interaction is right there in Human-Computer Interaction, or
Computer-Human
Interaction, as the researchers prefer. But interaction is not a good
or even useful way to
describe a UI.

If I think about a UI, I don't ask myself "is it interactive enough?"
or "what can I do to
make it more interactive?" Interaction has entirely the wrong
connotations for that.
I much prefer the term 'living', in the same sense as "Smalltalk has
live objects".

I don't want to be telling a story with Smalltalk objects, nor do I
want to interact with
them, I want to have them there to build things with. And if the
objects are THERE
then they are in a PLACE. A Place is a Medium (means of communication) which
one _mentally enters_ and which holds _persistent artifacts_. IRC channels are
places, TV channels are not. Either way, the UI constructs this place
out of nothing.

And speaking of places, the question immediately comes to mind: is this place a
*space* in the sense of a mathematical space with mathematical
properties such as
a metric, continuity, dimensionality? And the answer to this is 'yes,
yes of course'.
And that's what I think about when I look at a UI: what kind of space is it? How
many dimensions does it have? Is it continuous or discrete? What kind of place
is it? Is it navigable? Are locomotion or wayfinding problems in it?
Is it habitable
and commodious?

No I'm sorry, I do not think that "every UI tells a story" line of
crap is even remotely
as useful as thinking of spaces and places. Something which should be obvious to
every architect and most graphics designers. But perhaps not UI designers since
you won't find my (yes, mine!) insight in The Art of Interactive
Design. What you will
find in that book (which I still recommend) is an excellent example of
how metaphor
(pixels as buttons to click on, electronic documents having "pages")
will derail all
of your analysis. And this "tells a story" thing you're selling is a
metaphor, isn't it?

Cheers,

Richard Kulisz
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck-2

Re: [vw78] dead in the water (again!)

In reply to this post by Reinout Heeck-2

Well, that is rather disappointing:
we try to upgrade from 771->78 and run into this exact same issue
again....

The various menu items on store artifacts named 'compare with image' do
not do what they say, instead they do 'compare with image version'.

We (really-really-really) need the functionality 'compare with image'.
In 771 we created an extension package to add (and/or override) this in
all relevant places.
We cannot load that package into 78 because the Store browser structure
changed. *And* we cannot compare this package with the image, so we need
to basically reimplement it from scratch with an old image alongside
(manual comparison).

Cincom, please bring back and maintain the 'compare with image'
functionality.
(And rename the current menu items to 'compare with image version').

Reinout
-------

On 8/25/2010 12:25 PM, Reinout Heeck wrote:

> We are trying to upgrade from vw7.6 to vw7.7.1.
> Part of this operation entails porting the various patches we have on
> the base visualworks, the tools and various libraries
>
> For instance: Trippy /still/ has no resizing splitters, so one of our
> patches packages has overrides on the various #windowSpec methods in the
> Trippy package.
> In the 7.7.1 image we created an empty package 'Tools-Trippy patches'
> and reconciled it against our 7.6 version of this package.
> I want to compare the #windowSpec methods in the image (which live in
> the 'Tools-Trippy' package) against the 7.6 version of our 'Tools-Trippy
> patches' package.
>
> In 7.6 I can use the Store versions list to select the version of the
> 'patches' package I want to compare with and then use the menu item
> 'Compare with image'. In the ComparisonBrowser I can then select a
> method and it will show a differator view showing in red the changes
> between one method (in the 'Tools-Trippy patches' package) and the image
> method (in the 'Tools Trippy' package).
>
> In 7.7.1 we cannot find the equivalent operation, so we cannot proceed
> with porting our patches to 7.7.1 --> show stopper!
>
> Does anybody know how I can easily open a differator showing the changes
> between the method in a package version in store and that same method in
> the image (but in a different package)?
> I really need an *easy* way to do this because I have to go through 90+
> of these 'patches' packages.
>
>
>
> TIA,
>
> Reinout
> -------
>
>
> --
> *********************************************************************
>
> Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).
>
> Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.
>
> Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368.
> Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.
> **********************************************************************
>
> This e-mail message is intended to be exclusively for the addressee.
>
> If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.
>
> Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368.
> Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189
> **********************************************************************
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Travis Griggs-4

Re: [vw78] dead in the water (again!)

On Oct 26, 2011, at 1:36 AM, Reinout Heeck wrote:

Well, that is rather disappointing:
we try to upgrade from 771->78 and run into this exact same issue
again....

The various menu items on store artifacts named 'compare with image' do
not do what they say, instead they do 'compare with image version'.

We (really-really-really) need the functionality 'compare with image'.
In 771 we created an extension package to add (and/or override) this in
all relevant places.
We cannot load that package into 78 because the Store browser structure
changed. *And* we cannot compare this package with the image, so we need
to basically reimplement it from scratch with an old image alongside
(manual comparison).

Cincom, please bring back and maintain the 'compare with image'
functionality.
(And rename the current menu items to 'compare with image version').

I'm confused. I compare with image frequently.

Is the complaint that you have to use the browser to do this? Rather than the package versions thing?

Travis Griggs

Objologist

I multiply all time estimates by pi, to account for running around in circles.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Alan Knight-2

Re: [vw771] dead in the water

In reply to this post by Reinout Heeck-2

Is this the sort of thing you're looking for?

http://alanknightsblog.blogspot.com/2011/05/checking-overrides-when-upgrading.html

I'd hope that you could tweak that for the particulars of your situation
and just have it automatically loop over all your patch packages, or put
it onto a menu item, or something of that nature.

Reinout Heeck wrote:

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck-3

Re: [vw78] dead in the water (again!)

In reply to this post by Travis Griggs-4

On 10/26/2011 6:11 PM, Travis Griggs wrote:

I'm confused. I compare with image frequently.

Below you are comparing with the image *version*, not with 'the image'

Here's the situation:

I have a package in my store repository that patches (overrides) various definitions of the base system (Core, Kernel, Store and such).
This package is created for 771 and loading it into 78 will break the image for sure.

How do I select the package (that is only present in Store and not in the image) and compare it with the code in the image that it will override?

Multiply above problem by about 100 such 'patches' packages to be ported forward...

Up to 7.6 the store version lists had a 'compare with image' item that would show additions and alterations relative to all code in the image (that is, irrespective of which package the image code lives in).
We need that functionality when upgrading to a newer VW version.

Is the complaint that you have to use the browser to do this? Rather than the package versions thing?

Since the package is not in the image this would be possible /only/ from the version lists.

Thanks,

Reinout
-------

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck-2

Re: [vw771] dead in the water

In reply to this post by Alan Knight-2

On 10/26/2011 6:24 PM, Alan Knight wrote:
> Is this the sort of thing you're looking for?
>
> http://alanknightsblog.blogspot.com/2011/05/checking-overrides-when-upgrading.html
>
Indeed, this addresses my use case but in a rather primitive way.

This use case was covered up to vw76 in the form of a 'compare with
image' menu item on the Store version lists.

This functionality has disappeared but given that it is needed to
upgrade VW version I would like Cincom to bring it back.

> I'd hope that you could tweak that for the particulars of your
> situation and just have it automatically loop over all your patch
> packages, or put it onto a menu item, or something of that nature.

No thank you, we'll bring back our 771 additions that open in the new
differences views ;-)

R
-

>
> Reinout Heeck wrote:
>> We are trying to upgrade from vw7.6 to vw7.7.1.
>> Part of this operation entails porting the various patches we have on
>> the base visualworks, the tools and various libraries
>>
>> For instance: Trippy /still/ has no resizing splitters, so one of our
>> patches packages has overrides on the various #windowSpec methods in the
>> Trippy package.
>> In the 7.7.1 image we created an empty package 'Tools-Trippy patches'
>> and reconciled it against our 7.6 version of this package.
>> I want to compare the #windowSpec methods in the image (which live in
>> the 'Tools-Trippy' package) against the 7.6 version of our 'Tools-Trippy
>> patches' package.
>>
>> In 7.6 I can use the Store versions list to select the version of the
>> 'patches' package I want to compare with and then use the menu item
>> 'Compare with image'. In the ComparisonBrowser I can then select a
>> method and it will show a differator view showing in red the changes
>> between one method (in the 'Tools-Trippy patches' package) and the image
>> method (in the 'Tools Trippy' package).
>>
>> In 7.7.1 we cannot find the equivalent operation, so we cannot proceed
>> with porting our patches to 7.7.1 --> show stopper!
>>
>> Does anybody know how I can easily open a differator showing the changes
>> between the method in a package version in store and that same method in
>> the image (but in a different package)?
>> I really need an *easy* way to do this because I have to go through 90+
>> of these 'patches' packages.
>>
>>
>>
>> TIA,
>>
>> Reinout
>> -------
>>
>

--
*********************************************************************

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).

Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368.
Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.
**********************************************************************

This e-mail message is intended to be exclusively for the addressee.

If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368.
Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189
**********************************************************************

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Paul Baumann

Re: [vw78] dead in the water (again!)

In reply to this post by Reinout Heeck-3

Reinout,

The way I manage this is by saving the methods that I override into a #overridden_* prefixed method. When an override needs to work for multiple overridden versions then prefix it with methods like #overridden_vw76_* and #overridden_vw771_*. I usually implement new behavior in an #override_* prefixed method (that can also be version specific when necessary). The actual method overridden calls the appropriate #override_* method. This naming technique makes your overrides more manageable because they you can compare them when you need to upgrade. The #overridden_* methods are also directly executable when you only need to execute something before or after the original behavior.

The problems with the naming technique mentioned is when you need to override a VW method that is executed to load code. VW installs methods from a Set that is ordered by a hash value that is not predictable. The override methods can be added to the method dictionary before the #override_* methods that they attempt to call. In that case, you still use the naming techniques for documentation, but the actual override method is a copy of the #override_* method instead of message sent.

When I port code a framework to work for a new release I discover problems in the release I want to move towards, but apply the workarounds in the version that I use. I get my code to work for both versions until the transition is complete. Performance can be compared. This approach has the least risk because your effort will not be lost when upgrade plans change.

Paul Baumann

From: [hidden email] [mailto:[hidden email]] On Behalf Of Reinout Heeck
Sent: Thursday, October 27, 2011 04:02
To: [hidden email]
Subject: Re: [vwnc] [vw78] dead in the water (again!)

On 10/26/2011 6:11 PM, Travis Griggs wrote:

I'm confused. I compare with image frequently.

Is the complaint that you have to use the browser to do this? Rather than the package versions thing?

Since the package is not in the image this would be possible /only/ from the version lists.

Thanks,

Reinout
-------

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck-2

Re: [vw771] dead in the water

In reply to this post by Reinout Heeck-2

On 10/27/2011 10:28 AM, Reinout Heeck wrote:
> No thank you, we'll bring back our 771 additions that open in the new
> differences views ;-)

We got something working today with the new comparison tool chain :-)
When its code stabilizes we'll hand it over to Cincom.

R
-

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Travis Griggs-4

Re: [vw78] dead in the water (again!)

In reply to this post by Reinout Heeck-3

On Oct 27, 2011, at 1:01 AM, Reinout Heeck wrote:

> On 10/26/2011 6:11 PM, Travis Griggs wrote:
>>
>>
>> I'm confused. I compare with image frequently.
>
> Below you are comparing with the image *version*, not with 'the image'

No, I respectfully/apologetically think you are mistaken. Or… I'm not understanding the semantics and terms you are using. Do the following steps, all from the browser:

a) Make a package ZZZ
b) add a class FooBar to ZZZ
c) Publish ZZZ, version 1
d) add an instance variable to FooBar, call it 'slot'
e) Publsh ZZZ, version 2
f) remove the instance variable 'slot' from FooBar
g) At this point, you should have a "dirty version of ZZZ 2"
h) compare with… pick version 2. The result should be that it shows the difference between the live image with the inst var gone and version 2 where it was not there

For your assertion to be true at this point, it would need to be that that showed no changes

i) now compare with… pick version 1. The result should be "no changes"

Again, for the assertion as I understand it to be true, it would need to show the difference version 2 and version 1, rather than what it does which is to tell you that the code in your image, though it started life as version 2, is now the same thing as 1.

Or… is this really all about overrides? In which case, I think it would be helpful to scope the statements and frustrations along those lines.

--
Travis Griggs
Objologist
"I did not have time to write you a short program, so I wrote you a long one instead."

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Samuel S. Shuster-2

Re: [vw771] dead in the water

In reply to this post by Reinout Heeck-2

Reinout,

> We got something working today with the new comparison tool chain :-)
> When its code stabilizes we'll hand it over to Cincom.

If I understand, this is an example of what you would like:

So, let's say you created a new package, call it OverridesIsUs, and then overrode a lot of code from the base and put all those overrides in that new package, now you publish it.

Now, you start a brand new image that doesn't have OverridesIsUs loaded in it, and you want to know "What is the difference between the code OverridesIsUs and what is loaded in the image"

I don't believe we have ever had that, but it is interesting.

And So It Goes
Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, Store Project
Smalltalk Enables Success -- What Are YOU Using?

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

123