[vw771] dead in the water

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

I agree entirely with your basic sentiment: whereas before Store
browsers had too many menus, now they have too few, and important
operations are missing. The common factor between old and new - sadly -
is that what operations are available in a given menu varies across
tools, and the choices are tuned to one particular developer's or team's
approach, so not necessarily good for others.

I took a quick look to see if I could add some old commands back to the
new menus, and also some of my own old commands, but it looks like the
new UI is once again fiendishly clever in its implementation, rather
than simple, extensible, and based on the "standard" approach given in
the manuals. The new comparison tool's window doesn't even have a model
or application.

Of course, none of this means the situation is irreparable. It may well
be easy for Cincom to correct these problems, and the new code is at
least fiendishly clever rather than fiendishly complicated because of a
lack of cleverness. I have great hopes for 7.8 finding the best of both
worlds!

For now: What about loading the 7.6 patch package, Browse | System,
select patch package, pop-up menu Browse | Overrides of Others...?

Or select a method in a System Browser | pop-up | Store | Browse
Versions? The list of published versions now shows the package where
that version was first published, and you can select "Compare with
Image" from the popup menu.

HTH,
Steve
90+ Haag 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

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

Steven Kelly wrote:
> [...]
>  
> For now: What about loading the 7.6 patch package, Browse | System,
> select patch package, pop-up menu Browse | Overrides of Others...?
>  
I haven't tried, but experience from previous upgrades tells me that
will take out my image or essential tools.
I'm a bit loath to even try this given the amount of packages I have to
go through.


> Or select a method in a System Browser | pop-up | Store | Browse
> Versions? The list of published versions now shows the package where
> that version was first published, and you can select "Compare with
> Image" from the popup menu.
>  
Ah, so at least we have a compare tool :-)
The problem here is: which methods do I browse to to do this operation
(again considering the shear volume I have to work through).
I'd rather select the methods to compare at package level, since that is
only a small hundred selections over time -> less error prone ;-).
> HTH,
> Steve
>  


Thanks!

R
-


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

The new Store browsers are just subclasses of the Refactoring Browser, so precisely the same fiendishly clever mechanisms should work for menu extension. So to add a "compare with image" menu item for a method, you'd do something like
StoreForGlorpNavigator>>compareWithImage
         <menuItem: 'Compare with Image'
                 nameKey: nil
                 enablement: #isSelectorSelected
                 indication: nil
                 menu: #(#selectorMenu)
                 position: 55.765>

        | method target |
        method := self definition method.
        target := method definition correspondingImageMethod.
        target ifNotNil: [MethodDifferenceBrowser
                 compare: method definitionString
                 with: target getSource asString
                 protocol: method protocol
                 with: target protocol]

The implementation there is borrowed from the MethodListPane, used when you browse versions of the particular method, and which (as you mention) does have a Compare with Image menu item. And I agree that it ought to be on the package browser as well. We may have paid more attention to pruning out things from the Refactoring Browser in general that were inappropriate than to adding in things that would be useful on a database browser.

At 07:34 AM 2010-08-25, Steven Kelly wrote:

I agree entirely with your basic sentiment: whereas before Store
browsers had too many menus, now they have too few, and important
operations are missing. The common factor between old and new - sadly -
is that what operations are available in a given menu varies across
tools, and the choices are tuned to one particular developer's or team's
approach, so not necessarily good for others.

I took a quick look to see if I could add some old commands back to the
new menus, and also some of my own old commands, but it looks like the
new UI is once again fiendishly clever in its implementation, rather
than simple, extensible, and based on the "standard" approach given in
the manuals. The new comparison tool's window doesn't even have a model
or application.

Of course, none of this means the situation is irreparable. It may well
be easy for Cincom to correct these problems, and the new code is at
least fiendishly clever rather than fiendishly complicated because of a
lack of cleverness. I have great hopes for 7.8 finding the best of both
worlds!

For now: What about loading the 7.6 patch package, Browse | System,
select patch package, pop-up menu Browse | Overrides of Others...?

Or select a method in a System Browser | pop-up | Store | Browse
Versions? The list of published versions now shows the package where
that version was first published, and you can select "Compare with
Image" from the popup menu.

HTH,
Steve

> -----Original Message-----
> From: [hidden email] [[hidden email]] On
> Behalf Of Reinout Heeck
> Sent: 25. elokuuta 2010 13:25
> To: 'VWNC'
> Subject: [vwnc] [vw771] dead in the water
>
> 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

_______________________________________________
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

Joachim Geidel wrote:
>
> I don't have 7.7.1 on the computer in front of me, therefore I may be
> wrong. Try loading RBStoreExtensions from the public repository, use
> the latest version from the branch I published there. IIRC, it has a
> "compare with image" menu item in the context menu for package version
> figures in the "Version History" tool.
>


Ah, that sounds like it will do the job!
 
I'll try this later this week.



Thank you,

R
-

_______________________________________________
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

Thanks. I didn't mean at all to suggest that you should just do it our way. I agree that that the "Compare with Image" menu item ought to be there in the Store browser, and that in general, the menu items and other UI characteristics are not consistent between the different tools, and they ought to be. I hope we will improve that in the next release. And having input on the processes people are using is very valuable in doing so. But I'll leave discussion on it to the people involved in the work.

I will say that yes, I believe the 7.6 comparison browser is still there in the current release, and if you want to use it, it might actually be sufficient to simply change #comparisonBrowserClass. It rather looks like RBStoreExtensions menu items, as also mentioned in this thread, are likely to bring up the old comparison browser.

At 10:48 AM 2010-08-25, Steven Kelly wrote:

Thanks Alan, I’m sure that code will be a useful example.
 
Perhaps I ought to explain our process, rather than just expressing my frustration that it’s different from yours – sorry!
 
The product we’re building is a metatool, so most code changes have wide-ranging effects that are not always easy to predict: the final behavior depends on our code plus the customer’s own “schema” (to make an analogy with GLORP), provided as data. We thus have a strong need to know why each code line is what it is, why it changed etc., and so we use version comments (blessing notes) extensively when publishing packages. Those comments also form the basis from which we create upgrade documents for customers when releasing a new product version.
 
We work in the RB (+RBTabbedToolsets), with occasional Senders/Implementors windows. We very rarely use the Store Browser windows. We try and publish frequently, so a single package version doesn’t add too many new features, bug fixes etc. In 7.6, we used RB’s package list’s Store | Compare with Parent, and from that window we checked that all changes were:
-          desired (rather than just temporary hacks we had forgotten to reverse; revert or remove as necessary)
-          in the right class/package (moving or changing into an override if necessary),
-          completely implemented (using senders/implementers to make sure other call or receive sites had also been updated)
The remaining list then served as an aid to memory as we wrote the version comment; we could open the publish dialog straight from the compare tool.
 
In 7.7.1, most of these functions are missing from the compare tool. For each change I have to click several times to get to it and select it, open its pop-up menu, Browse Image, and only then can I open a pop-up menu to perform the operation I want. After that I have to close the Browse Image window, which only contained a single method and had little or no extra information compared to the compare tool, was missing the context of the change (e.g. other methods in that class or package – which would be visible from the RB, diff with old method – which would be visible from the compare tool), and yet adds the menu items I need.
 
It seems like quite a lot more work and context switching to handle our publishes now. The new text diff view is nice, but I miss the ability to choose to compare by source or by code. I don’t really see any benefit to being able to have multiple method diffs open in the tree of changes, indeed I find it disturbing the way that the list of classes jumps around when opening and closing changes (using space to avoid having to click each method shut before opening the next).
 
Overall, I find I’m significantly slower with the new compare tool, and the reasons seem to be structural rather than just getting used to a new tool. 7.7.1 has an “old compare tool”, but that’s not the 7.6 version, and is also missing the same functionality as the new one.
 
I wonder if it’s possible to use the 7.6 compare tool in 7.7.1? With all its faults, it still beats the new one for our process.
 
Cheers,
Steve
 
From: Alan Knight [[hidden email]]
Sent: 25. elokuuta 2010 15:58
To: Steven Kelly; Reinout Heeck
Cc: VWNC
Subject: Re: [vwnc] [vw771] dead in the water
 
The new Store browsers are just subclasses of the Refactoring Browser, so precisely the same fiendishly clever mechanisms should work for menu extension. So to add a "compare with image" menu item for a method, you'd do something like
StoreForGlorpNavigator>>compareWithImage
         <menuItem: 'Compare with Image'
                 nameKey: nil
                 enablement: #isSelectorSelected
                 indication: nil
                 menu: #(#selectorMenu)
                 position: 55.765>

        | method target |
        method := self definition method.
        target := method definition correspondingImageMethod.
        target ifNotNil: [MethodDifferenceBrowser
                 compare: method definitionString
                 with: target getSource asString
                 protocol: method protocol
                 with: target protocol]

The implementation there is borrowed from the MethodListPane, used when you browse versions of the particular method, and which (as you mention) does have a Compare with Image menu item. And I agree that it ought to be on the package browser as well. We may have paid more attention to pruning out things from the Refactoring Browser in general that were inappropriate than to adding in things that would be useful on a database browser.

At 07:34 AM 2010-08-25, Steven Kelly wrote:

I agree entirely with your basic sentiment: whereas before Store
browsers had too many menus, now they have too few, and important
operations are missing. The common factor between old and new - sadly -
is that what operations are available in a given menu varies across
tools, and the choices are tuned to one particular developer's or team's
approach, so not necessarily good for others.

I took a quick look to see if I could add some old commands back to the
new menus, and also some of my own old commands, but it looks like the
new UI is once again fiendishly clever in its implementation, rather
than simple, extensible, and based on the "standard" approach given in
the manuals. The new comparison tool's window doesn't even have a model
or application.

Of course, none of this means the situation is irreparable. It may well
be easy for Cincom to correct these problems, and the new code is at
least fiendishly clever rather than fiendishly complicated because of a
lack of cleverness. I have great hopes for 7.8 finding the best of both
worlds!

For now: What about loading the 7.6 patch package, Browse | System,
select patch package, pop-up menu Browse | Overrides of Others...?

Or select a method in a System Browser | pop-up | Store | Browse
Versions? The list of published versions now shows the package where
that version was first published, and you can select "Compare with
Image" from the popup menu.

HTH,
Steve

> -----Original Message-----
> From: [hidden email] [ [hidden email]] On
> Behalf Of Reinout Heeck
> Sent: 25. elokuuta 2010 13:25
> To: 'VWNC'
> Subject: [vwnc] [vw771] dead in the water
>
> 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

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

Steven Kelly wrote:
>
> [...]
>
> Perhaps I ought to explain our process, rather than just expressing my
> frustration that it’s different from yours – sorry!
>
> [...explanation...]
>
Thanks for that, concisely put; a big +1 from here.

I want to emphasize one aspect:

> For each change I have to click several times to get to it and select
> it, open its pop-up menu, Browse Image, [..etc...]
>
After working with 771 for a couple of days I have the sensation that
many important operations moved away from the immediate availability I
was used to in vw76.
for example:

-on a method list I am used to clicking on the 'senders' submenu to get
senders of the method selector, now I have to navigate _into_ the sub
menu and click on the first item there to get the same effect. Seemingly
a tiny difference, but in terms of 'flow' one in the wrong direction.

-the 'goto home context' button disappeared from the debugger toolbar,
while we use that a *lot* to navigate the stack. This one went quite a
bit further away (into the window menu) in 771.
I guess we'll have to add yet another patch to our ever growing set of
patches to keep vw up to the level we are used to.

-the new pundle prerequisites tab in the browser blatantly violates the
established RB idioms: it does not not have the capability to 'accept'
or 'cancel'; something that I find essential for the rather involved
operation of getting the prereqs right. It just stuffs whatever I click
immediately into the system.
Moreover I cannot recover from this in the straightforward way: the
'undo' button seemingly does not work (but of course it performs some
/unrelated/ undo operation when I click it to undo the prereqs change).
I also find the overloading of the plus-in-circle icon's behavior rather
unintuitive, but I surmise muscle memory will kick in on that one.
More in general I would like to remind all of us here that the 'lists
plus edit pane' paradigm has proven to be very powerful, I'm not quite
sure the new 'web style' tools can equal (or improve on) this.


-a big one, because it hurts and because it is 'everywhere':
I cannot deselect in a browser list without reaching for the keyboard.



Reinout
-------

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

Your first and last items are, unfortunately, an example of the tension between various different objectives. Various customers, of whom Steven is one of the more common contributors, point out to us areas in which our GUI deviates from those of the operating system. List selection behaviour was one of the more obvious ones of those. Treating a sub-menu as being an action in its own right was another. I note that there's a keyboard shortcut for senders which will find senders of the selected method without any menu operations at all, though you do have to reach for a keyboard.

There's also a tension between simplicity of the tools and the options people want. It's a common complaint that many of our tools have menus that are too large. 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. 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. All of the stepping options I use the F5/6/7 keys for, which I find very nice.

At 12:28 PM 2010-08-25, Reinout Heeck wrote:

Steven Kelly wrote:
>
> [...]
>
> Perhaps I ought to explain our process, rather than just expressing my
> frustration that it’s different from yours ­ sorry!
>
> [...explanation...]
>
Thanks for that, concisely put; a big +1 from here.

I want to emphasize one aspect:

> For each change I have to click several times to get to it and select
> it, open its pop-up menu, Browse Image, [..etc...]
>
After working with 771 for a couple of days I have the sensation that
many important operations moved away from the immediate availability I
was used to in vw76.
for example:

-on a method list I am used to clicking on the 'senders' submenu to get
senders of the method selector, now I have to navigate _into_ the sub
menu and click on the first item there to get the same effect. Seemingly
a tiny difference, but in terms of 'flow' one in the wrong direction.

-the 'goto home context' button disappeared from the debugger toolbar,
while we use that a *lot* to navigate the stack. This one went quite a
bit further away (into the window menu) in 771.
I guess we'll have to add yet another patch to our ever growing set of
patches to keep vw up to the level we are used to.

-the new pundle prerequisites tab in the browser blatantly violates the
established RB idioms: it does not not have the capability to 'accept'
or 'cancel'; something that I find essential for the rather involved
operation of getting the prereqs right. It just stuffs whatever I click
immediately into the system.
Moreover I cannot recover from this in the straightforward way: the
'undo' button seemingly does not work (but of course it performs some
/unrelated/ undo operation when I click it to undo the prereqs change).
I also find the overloading of the plus-in-circle icon's behavior rather
unintuitive, but I surmise muscle memory will kick in on that one.
More in general I would like to remind all of us here that the 'lists
plus edit pane' paradigm has proven to be very powerful, I'm not quite
sure the new 'web style' tools can equal (or improve on) this.


-a big one, because it hurts and because it is 'everywhere':
I cannot deselect in a browser list without reaching for the keyboard.



Reinout
-------

_______________________________________________
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

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

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

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

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

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.

Accordingly using pictures to describe issues with UIs, really really  
really really helps the discussion a lot.

One of the list denizens I'd like to thank, is Boris Popov, who often  
shares pictures via dropbox of issues he sees. That context is so very  
meaningful to understanding the issues. As a UI designer, I have to  
not only read what you write, and guess what you're doing, but read  
between the lines, to figure out what the real issues are. And  
sometimes, it allows me to see "hey look over here" with a picture as  
a response which results in an "aha!" Michael Lucas-Smith often sends  
me a screenshot when he sees a UI glitch, and it's very helpful.

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.

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

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

Alan Knight wrote:
> Your first and last items are, unfortunately, an example of the
> tension between various different objectives. Various customers, of
> whom Steven is one of the more common contributors, point out to us
> areas in which our GUI deviates from those of the operating system.
> List selection behaviour was one of the more obvious ones of those.
> Treating a sub-menu as being an action in its own right was another.

Perhaps pointing to the historical context will make a possible solution
obvious ;-)

The WIMP UI was invented on Smalltalk and over the years honed to easily
work with Smalltalk (first as operating system and later as application).
Later commercial companies started supplying WIMP UIs and the 'desktop
wars' ensued.

As a result we have to live with various usability deficiencies in the
desktop UIs because the creation process was one of 'design by litigation'.

I agree that our VW end user applications should be (able to be) as
platform faithful as possible, so in that sense I wholly agree with the
direction taken.
However there is also 'the other' audience of Smalltalk developers, as
one of those I would like my UI to stay at the level of usability
as set by the original Smalltalk, and not be dragged down to 'litigation
quality' over time.

So I guess one technical solution could be to provide a 'Classical
Smalltalk' feel in the IDE.
 



R
-

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

Isn't it about time we step back a bit and introduce configurable
toolbars?

-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 Martin McClure
Sent: 26 August 2010 00:12
To: Alan Knight
Cc: VWNC
Subject: Re: [vwnc] [vw771] dead in the water

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

+10


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

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

On 10-08-26 12:14 AM, "Martin McClure" <[hidden email]> wrote:

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

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:


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