Gestures on OSX

Jon,

 

List behavior is now more in-line with the OS feel, i.e. try Ctrl+Click on the selected item to unselect it on Windows.

 

HTH,

 

-Boris

 

From: [hidden email] [[hidden email]] On Behalf Of Jon Paynter
Sent: Wednesday, August 24, 2011 1:30 PM
To: Reinout Heeck
Cc: [hidden email]
Subject: Re: [vwnc] No longer MODERN ????

 

+1 on the noise

On Wed, Aug 24, 2011 at 5:49 AM, Reinout Heeck <[hidden email]> wrote:

On 8/23/2011 9:15 PM, andre wrote:
>
> I'm glad about the route Travis is taking now. Hopefully he will not
> let anyone stop him.

Hmmm, that depends very much on what we are talking about.

It also depends on whether we are really talking about Travis our rather
about how the Cincom process decides on what ends up in my toolset.

Seeing the messages Travis wrote about the ParagraphEditor hierarchy he
gets my full vote of confidence (but I'll have to see the results before
I can judge usefulness).

Seeing what Travis did to the look of the system I am very confident he
has an eye for graphics.

Seeing wat Cincom has done to my toolset however does not induce such a
vote of confidence.
To name a few:
  -standard color mappings are used in non-standard ways (red means
failure for western users, however in the differator tools it means
something else)
  -more and more 'stuff' (particularly icons, method counts) is
rendered in my tools, seemingly 'because we can' and not for some
specific workflow reason).
    This way my brain is being trained to ignore icons...
  -in contrast the places where workflow would be helped by 'more' seem
to get skipped
     (e.g. showing number of shareds in the shareds _tab_ of the RB
would really help,
      instead we do get number of methods in a protocol which happens
to be just cognitive noise because in the workflow it is only
interesting whether a protocol is non-empty, not by how much it is
non-empty).

It would be nice to have somebody from cincom come in and explain why this feature was added.
And in my opinion it would MUCH nicer to have cincom publish an (optional) patch that removes this functionality.  Im with Reinout here -- I dont want the extra "noise" in my browser.
 

  -my tools are replaced by glitzier onces that show less (at least
until I'm done clicking on a gazillion triangles to disclose the
developer information),
   and can do less (context menus not aligned with workflow like in the
differators)
   and dont 'take' our ParagraphEditor extensions.
   and mask our useful extensions (like our in-house icons showing the
semantics of a method tag are now displaced by a generic 'this method
has a tag' icon -- why exactly do I need to know a method is tagged?).
 -'undo' in the paragrapheditor has been a problem for how long?

I havent seen the undo change since vw5i
 

 -menu item placement has been inconsistent for how long? for example:
      -- shareds get a submenu way low in the rb list context, but
other artifacts like methods get treated differently.
      -- rb package list has *two* submenus for opening browsers
('browse' and 'spawn')
      -- 'find methods with strings matching' in the RB but not in the
launcher where most of our method finders are found

So I guess in the dev tools I have seen too much UI development (new
icons! again!) and too little tool development (semiotics anybody...).

I'll add one item to the list here:  the ability to select "nothing" in lists.  This was one of my major beefs after upgrading to vw77 and vw78.
in vw76 and earlier, when I click on something in a list (ex: method category in browser), it selects whatever I clicked on, and the tool updates as expected.  Then wen I click on the Same item again, it selects "nothing".

so why is this a problem?
in the class browser:  i click a class, in vw76 and before, it displays the class categories and all their methods.  I can quickly scan the method list to look for something.  If I want just 1 category, I click that.  If I need to see all methods again, I click the same category, its unselected and im back to the previous list.

In vw77 and beyond, I click a class, and I get all methods as expected, and if im interested in just 1 category, I can click on that.  but this is where things break.  If I want to go back to the full method list.. there is no way to unselect the method category, and im forced to go through some highly annoying gyrations to get this to happen.  (click on a diff class w/o the method category) A single click operation in vw76 turns into 5-20 clicks in vw77 and beyond.

The same applies to inspectors.  I open an inspector on something, and the top entry "self" is selected.
in vw76 and before, if I want to do something with the object, I click whatever is selected, the selected text vanishes and I start typing.
in vw77 and beyond, the "unselect" ability is gone, so I have to get rid of whatever was displayed before I can start typing.  Again a single click operation from vw76 turns into multiple clicks.

Now - im sure its possible to go into the image, find this ability and change it to my liking.  but I would rather be using my tools than trying to fix them.

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

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

I'm not sure how the list behavior hobbles anything, to be honest.

 In our shop, we spent a fair bit of time hacking datasets and listboxes (datasets are really awful in 7.6) to get the more platform "normal" behavior.  As it happens, users had been complaining about the old behavior for years.

I guess ymmv...

On Aug 25, 2011, at 4:32 AM, Reinout Heeck wrote:

On 8/24/2011 7:56 PM, Boris Popov, DeepCove Labs wrote:

Jon,

 

List behavior is now more in-line with the OS feel, i.e. try Ctrl+Click on the selected item to unselect it on Windows.

I forgot about the lists.
We patched our system to bring back the old list selection behavior, this is because the UIs we sell depend on it in a critical way (deselection indicates the the user wants an editor to add an item instead of editing an existing one) and using the ctrl-key to achieve this is not easily discoverable (semiotics again).

An other thing I didn't list was the loss of default menu action in context menus. Browsing 'senders of' now requires more intricate gesturing then it used to :-(

These two changes led to something akin to mutiny in my shop, and the new list behavior did not survive for even a day in the dev tools.

Now I can understand that Cincom can get to a decision to align the UI behavior with other systems,
 what I don't understand is how it ended up in the final product since it hobbles the workflow so much. The Cincom developers _must_ have noticed these problems, didn't they vocalize a complaint?



R
-

 

HTH,

 

-Boris

 

From: [hidden email] [[hidden email]] On Behalf Of Jon Paynter
Sent: Wednesday, August 24, 2011 1:30 PM
To: Reinout Heeck
Cc: [hidden email]
Subject: Re: [vwnc] No longer MODERN ????

 

+1 on the noise

On Wed, Aug 24, 2011 at 5:49 AM, Reinout Heeck <[hidden email]> wrote:

On 8/23/2011 9:15 PM, andre wrote:
>
> I'm glad about the route Travis is taking now. Hopefully he will not
> let anyone stop him.

Hmmm, that depends very much on what we are talking about.

It also depends on whether we are really talking about Travis our rather
about how the Cincom process decides on what ends up in my toolset.

Seeing the messages Travis wrote about the ParagraphEditor hierarchy he
gets my full vote of confidence (but I'll have to see the results before
I can judge usefulness).

Seeing what Travis did to the look of the system I am very confident he
has an eye for graphics.

Seeing wat Cincom has done to my toolset however does not induce such a
vote of confidence.
To name a few:
  -standard color mappings are used in non-standard ways (red means
failure for western users, however in the differator tools it means
something else)
  -more and more 'stuff' (particularly icons, method counts) is
rendered in my tools, seemingly 'because we can' and not for some
specific workflow reason).
    This way my brain is being trained to ignore icons...
  -in contrast the places where workflow would be helped by 'more' seem
to get skipped
     (e.g. showing number of shareds in the shareds _tab_ of the RB
would really help,
      instead we do get number of methods in a protocol which happens
to be just cognitive noise because in the workflow it is only
interesting whether a protocol is non-empty, not by how much it is
non-empty).

It would be nice to have somebody from cincom come in and explain why this feature was added.
And in my opinion it would MUCH nicer to have cincom publish an (optional) patch that removes this functionality.  Im with Reinout here -- I dont want the extra "noise" in my browser.
 

  -my tools are replaced by glitzier onces that show less (at least
until I'm done clicking on a gazillion triangles to disclose the
developer information),
   and can do less (context menus not aligned with workflow like in the
differators)
   and dont 'take' our ParagraphEditor extensions.
   and mask our useful extensions (like our in-house icons showing the
semantics of a method tag are now displaced by a generic 'this method
has a tag' icon -- why exactly do I need to know a method is tagged?).
 -'undo' in the paragrapheditor has been a problem for how long?

I havent seen the undo change since vw5i
 

 -menu item placement has been inconsistent for how long? for example:
      -- shareds get a submenu way low in the rb list context, but
other artifacts like methods get treated differently.
      -- rb package list has *two* submenus for opening browsers
('browse' and 'spawn')
      -- 'find methods with strings matching' in the RB but not in the
launcher where most of our method finders are found

So I guess in the dev tools I have seen too much UI development (new
icons! again!) and too little tool development (semiotics anybody...).

I'll add one item to the list here:  the ability to select "nothing" in lists.  This was one of my major beefs after upgrading to vw77 and vw78.
in vw76 and earlier, when I click on something in a list (ex: method category in browser), it selects whatever I clicked on, and the tool updates as expected.  Then wen I click on the Same item again, it selects "nothing".

so why is this a problem?
in the class browser:  i click a class, in vw76 and before, it displays the class categories and all their methods.  I can quickly scan the method list to look for something.  If I want just 1 category, I click that.  If I need to see all methods again, I click the same category, its unselected and im back to the previous list.

In vw77 and beyond, I click a class, and I get all methods as expected, and if im interested in just 1 category, I can click on that.  but this is where things break.  If I want to go back to the full method list.. there is no way to unselect the method category, and im forced to go through some highly annoying gyrations to get this to happen.  (click on a diff class w/o the method category) A single click operation in vw76 turns into 5-20 clicks in vw77 and beyond.

The same applies to inspectors.  I open an inspector on something, and the top entry "self" is selected.
in vw76 and before, if I want to do something with the object, I click whatever is selected, the selected text vanishes and I start typing.
in vw77 and beyond, the "unselect" ability is gone, so I have to get rid of whatever was displayed before I can start typing.  Again a single click operation from vw76 turns into multiple clicks.

Now - im sure its possible to go into the image, find this ability and change it to my liking.  but I would rather be using my tools than trying to fix them.

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

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

James Robertson

http://www.jarober.com

[hidden email]

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

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

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

One thing I learned doing BottomFeeder - having an endless array of settings overwhelms users.  Most of the time, it's better to make things consistent and <not> present a large set of config options

On Aug 25, 2011, at 10:21 AM, Dave Stevenson wrote:

I had an initial reaction similar to what Reinout describes when I had to retrain my brain to the new behavior. But I eventually came to like the consistency with other Windoze apps, somewhat offsetting the additional effort to deselect. 

What I wonder, however, is why such behavior is not configurable? Why not add the behavior as an option, rather than replace the out altogether? Add an option in the settings tool, and for good measure allow changing that setting on a widget by widget basis. There will always be some who are merely grumpy about such changes. There will also always be some who rely on the old behavior, rather than just prefer it. Isn't configurability worth the extra effort?

We have UI feels that change certain behavior, and we can pick one feel or another. Why not separate the various behaviors into separate settings that can be selected ad hoc, with a master setting to restore them all to default for one of the various UI feels? 

Maybe refactoring UI feels is not enough bang for the buck right now, but if one determines a change like list selection is worth making, then I submit it's worth making it configurable.

 

Dave Stevenson
[hidden email]

---

From: James Robertson <[hidden email]>
To: VWNC NC <[hidden email]>
Sent: Thu, August 25, 2011 8:38:43 AM
Subject: Re: [vwnc] No longer MODERN ????

I'm not sure how the list behavior hobbles anything, to be honest.  In our shop, we spent a fair bit of time hacking datasets and listboxes (datasets are really awful in 7.6) to get the more platform "normal" behavior.  As it happens, users had been complaining about the old behavior for years.

I guess ymmv...

On Aug 25, 2011, at 4:32 AM, Reinout Heeck wrote:

On 8/24/2011 7:56 PM, Boris Popov, DeepCove Labs wrote:

Jon,

 

List behavior is now more in-line with the OS feel, i.e. try Ctrl+Click on the selected item to unselect it on Windows.

I forgot about the lists. 
We patched our system to bring back the old list selection behavior, this is because the UIs we sell depend on it in a critical way (deselection indicates the the user wants an editor to add an item instead of editing an existing one) and using the ctrl-key to achieve this is not easily discoverable (semiotics again).

An other thing I didn't list was the loss of default menu action in context menus. Browsing 'senders of' now requires more intricate gesturing then it used to :-(

These two changes led to something akin to mutiny in my shop, and the new list behavior did not survive for even a day in the dev tools.

Now I can understand that Cincom can get to a decision to align the UI behavior with other systems,
 what I don't understand is how it ended up in the final product since it hobbles the workflow so much. The Cincom developers _must_ have noticed these problems, didn't they vocalize a complaint?



R
-

 

HTH,

 

-Boris

 

From: [hidden email] [[hidden email]] On Behalf Of Jon Paynter
Sent: Wednesday, August 24, 2011 1:30 PM
To: Reinout Heeck
Cc: [hidden email]
Subject: Re: [vwnc] No longer MODERN ????

 

+1 on the noise

On Wed, Aug 24, 2011 at 5:49 AM, Reinout Heeck <[hidden email]> wrote:

On 8/23/2011 9:15 PM, andre wrote:
>
> I'm glad about the route Travis is taking now. Hopefully he will not
> let anyone stop him.

Hmmm, that depends very much on what we are talking about.

It also depends on whether we are really talking about Travis our rather
about how the Cincom process decides on what ends up in my toolset.

Seeing the messages Travis wrote about the ParagraphEditor hierarchy he
gets my full vote of confidence (but I'll have to see the results before
I can judge usefulness).

Seeing what Travis did to the look of the system I am very confident he
has an eye for graphics.

Seeing wat Cincom has done to my toolset however does not induce such a
vote of confidence.
To name a few:
  -standard color mappings are used in non-standard ways (red means
failure for western users, however in the differator tools it means
something else)
  -more and more 'stuff' (particularly icons, method counts) is
rendered in my tools, seemingly 'because we can' and not for some
specific workflow reason).
    This way my brain is being trained to ignore icons...
  -in contrast the places where workflow would be helped by 'more' seem
to get skipped
     (e.g. showing number of shareds in the shareds _tab_ of the RB
would really help,
      instead we do get number of methods in a protocol which happens
to be just cognitive noise because in the workflow it is only
interesting whether a protocol is non-empty, not by how much it is
non-empty).

It would be nice to have somebody from cincom come in and explain why this feature was added.
And in my opinion it would MUCH nicer to have cincom publish an (optional) patch that removes this functionality.  Im with Reinout here -- I dont want the extra "noise" in my browser.
 

  -my tools are replaced by glitzier onces that show less (at least
until I'm done clicking on a gazillion triangles to disclose the
developer information),
   and can do less (context menus not aligned with workflow like in the
differators)
   and dont 'take' our ParagraphEditor extensions.
   and mask our useful extensions (like our in-house icons showing the
semantics of a method tag are now displaced by a generic 'this method
has a tag' icon -- why exactly do I need to know a method is tagged?).
 -'undo' in the paragrapheditor has been a problem for how long?

I havent seen the undo change since vw5i
 

 -menu item placement has been inconsistent for how long? for example:
      -- shareds get a submenu way low in the rb list context, but
other artifacts like methods get treated differently.
      -- rb package list has *two* submenus for opening browsers
('browse' and 'spawn')
      -- 'find methods with strings matching' in the RB but not in the
launcher where most of our method finders are found

So I guess in the dev tools I have seen too much UI development (new
icons! again!) and too little tool development (semiotics anybody...).

I'll add one item to the list here:  the ability to select "nothing" in lists.  This was one of my major beefs after upgrading to vw77 and vw78.
in vw76 and earlier, when I click on something in a list (ex: method category in browser), it selects whatever I clicked on, and the tool updates as expected.  Then wen I click on the Same item again, it selects "nothing".

so why is this a problem?
in the class browser:  i click a class, in vw76 and before, it displays the class categories and all their methods.  I can quickly scan the method list to look for something.  If I want just 1 category, I click that.  If I need to see all methods again, I click the same category, its unselected and im back to the previous list.

In vw77 and beyond, I click a class, and I get all methods as expected, and if im interested in just 1 category, I can click on that.  but this is where things break.  If I want to go back to the full method list.. there is no way to unselect the method category, and im forced to go through some highly annoying gyrations to get this to happen.  (click on a diff class w/o the method category) A single click operation in vw76 turns into 5-20 clicks in vw77 and beyond.

The same applies to inspectors.  I open an inspector on something, and the top entry "self" is selected.
in vw76 and before, if I want to do something with the object, I click whatever is selected, the selected text vanishes and I start typing.
in vw77 and beyond, the "unselect" ability is gone, so I have to get rid of whatever was displayed before I can start typing.  Again a single click operation from vw76 turns into multiple clicks.

Now - im sure its possible to go into the image, find this ability and change it to my liking.  but I would rather be using my tools than trying to fix them.

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

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

James Robertson

http://www.jarober.com

[hidden email]

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

James Robertson

http://www.jarober.com

[hidden email]

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

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              [hidden email]
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

One thing I learned doing BottomFeeder - having an endless array of settings overwhelms users.  Most of the time, it's better to make things consistent and <not> present a large set of config options

On Aug 25, 2011, at 10:21 AM, Dave Stevenson wrote:

I had an initial reaction similar to what Reinout describes when I had to retrain my brain to the new behavior. But I eventually came to like the consistency with other Windoze apps, somewhat offsetting the additional effort to deselect. 

What I wonder, however, is why such behavior is not configurable? Why not add the behavior as an option, rather than replace the out altogether? Add an option in the settings tool, and for good measure allow changing that setting on a widget by widget basis. There will always be some who are merely grumpy about such changes. There will also always be some who rely on the old behavior, rather than just prefer it. Isn't configurability worth the extra effort?

We have UI feels that change certain behavior, and we can pick one feel or another. Why not separate the various behaviors into separate settings that can be selected ad hoc, with a master setting to restore them all to default for one of the various UI feels? 

Maybe refactoring UI feels is not enough bang for the buck right now, but if one determines a change like list selection is worth making, then I submit it's worth making it configurable.

 

Dave Stevenson
[hidden email]

---

From: James Robertson <[hidden email]>
To: VWNC NC <[hidden email]>
Sent: Thu, August 25, 2011 8:38:43 AM
Subject: Re: [vwnc] No longer MODERN ????

I'm not sure how the list behavior hobbles anything, to be honest.  In our shop, we spent a fair bit of time hacking datasets and listboxes (datasets are really awful in 7.6) to get the more platform "normal" behavior.  As it happens, users had been complaining about the old behavior for years.

I guess ymmv...

On Aug 25, 2011, at 4:32 AM, Reinout Heeck wrote:

On 8/24/2011 7:56 PM, Boris Popov, DeepCove Labs wrote:

Jon,

 

List behavior is now more in-line with the OS feel, i.e. try Ctrl+Click on the selected item to unselect it on Windows.

I forgot about the lists. 
We patched our system to bring back the old list selection behavior, this is because the UIs we sell depend on it in a critical way (deselection indicates the the user wants an editor to add an item instead of editing an existing one) and using the ctrl-key to achieve this is not easily discoverable (semiotics again).

An other thing I didn't list was the loss of default menu action in context menus. Browsing 'senders of' now requires more intricate gesturing then it used to :-(

These two changes led to something akin to mutiny in my shop, and the new list behavior did not survive for even a day in the dev tools.

Now I can understand that Cincom can get to a decision to align the UI behavior with other systems,
 what I don't understand is how it ended up in the final product since it hobbles the workflow so much. The Cincom developers _must_ have noticed these problems, didn't they vocalize a complaint?



R
-

 

HTH,

 

-Boris

 

From: [hidden email] [[hidden email]] On Behalf Of Jon Paynter
Sent: Wednesday, August 24, 2011 1:30 PM
To: Reinout Heeck
Cc: [hidden email]
Subject: Re: [vwnc] No longer MODERN ????

 

+1 on the noise

On Wed, Aug 24, 2011 at 5:49 AM, Reinout Heeck <[hidden email]> wrote:

On 8/23/2011 9:15 PM, andre wrote:
>
> I'm glad about the route Travis is taking now. Hopefully he will not
> let anyone stop him.

Hmmm, that depends very much on what we are talking about.

It also depends on whether we are really talking about Travis our rather
about how the Cincom process decides on what ends up in my toolset.

Seeing the messages Travis wrote about the ParagraphEditor hierarchy he
gets my full vote of confidence (but I'll have to see the results before
I can judge usefulness).

Seeing what Travis did to the look of the system I am very confident he
has an eye for graphics.

Seeing wat Cincom has done to my toolset however does not induce such a
vote of confidence.
To name a few:
  -standard color mappings are used in non-standard ways (red means
failure for western users, however in the differator tools it means
something else)
  -more and more 'stuff' (particularly icons, method counts) is
rendered in my tools, seemingly 'because we can' and not for some
specific workflow reason).
    This way my brain is being trained to ignore icons...
  -in contrast the places where workflow would be helped by 'more' seem
to get skipped
     (e.g. showing number of shareds in the shareds _tab_ of the RB
would really help,
      instead we do get number of methods in a protocol which happens
to be just cognitive noise because in the workflow it is only
interesting whether a protocol is non-empty, not by how much it is
non-empty).

It would be nice to have somebody from cincom come in and explain why this feature was added.
And in my opinion it would MUCH nicer to have cincom publish an (optional) patch that removes this functionality.  Im with Reinout here -- I dont want the extra "noise" in my browser.
 

  -my tools are replaced by glitzier onces that show less (at least
until I'm done clicking on a gazillion triangles to disclose the
developer information),
   and can do less (context menus not aligned with workflow like in the
differators)
   and dont 'take' our ParagraphEditor extensions.
   and mask our useful extensions (like our in-house icons showing the
semantics of a method tag are now displaced by a generic 'this method
has a tag' icon -- why exactly do I need to know a method is tagged?).
 -'undo' in the paragrapheditor has been a problem for how long?

I havent seen the undo change since vw5i
 

 -menu item placement has been inconsistent for how long? for example:
      -- shareds get a submenu way low in the rb list context, but
other artifacts like methods get treated differently.
      -- rb package list has *two* submenus for opening browsers
('browse' and 'spawn')
      -- 'find methods with strings matching' in the RB but not in the
launcher where most of our method finders are found

So I guess in the dev tools I have seen too much UI development (new
icons! again!) and too little tool development (semiotics anybody...).

I'll add one item to the list here:  the ability to select "nothing" in lists.  This was one of my major beefs after upgrading to vw77 and vw78.
in vw76 and earlier, when I click on something in a list (ex: method category in browser), it selects whatever I clicked on, and the tool updates as expected.  Then wen I click on the Same item again, it selects "nothing".

so why is this a problem?
in the class browser:  i click a class, in vw76 and before, it displays the class categories and all their methods.  I can quickly scan the method list to look for something.  If I want just 1 category, I click that.  If I need to see all methods again, I click the same category, its unselected and im back to the previous list.

In vw77 and beyond, I click a class, and I get all methods as expected, and if im interested in just 1 category, I can click on that.  but this is where things break.  If I want to go back to the full method list.. there is no way to unselect the method category, and im forced to go through some highly annoying gyrations to get this to happen.  (click on a diff class w/o the method category) A single click operation in vw76 turns into 5-20 clicks in vw77 and beyond.

The same applies to inspectors.  I open an inspector on something, and the top entry "self" is selected.
in vw76 and before, if I want to do something with the object, I click whatever is selected, the selected text vanishes and I start typing.
in vw77 and beyond, the "unselect" ability is gone, so I have to get rid of whatever was displayed before I can start typing.  Again a single click operation from vw76 turns into multiple clicks.

Now - im sure its possible to go into the image, find this ability and change it to my liking.  but I would rather be using my tools than trying to fix them.

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

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

James Robertson

http://www.jarober.com

[hidden email]

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

James Robertson

http://www.jarober.com

[hidden email]

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

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

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

+1 on the noise

On Wed, Aug 24, 2011 at 5:49 AM, Reinout Heeck <[hidden email]> wrote:

On 8/23/2011 9:15 PM, andre wrote:
>
> I'm glad about the route Travis is taking now. Hopefully he will not
> let anyone stop him.

Hmmm, that depends very much on what we are talking about.

It also depends on whether we are really talking about Travis our rather
about how the Cincom process decides on what ends up in my toolset.

Seeing the messages Travis wrote about the ParagraphEditor hierarchy he
gets my full vote of confidence (but I'll have to see the results before
I can judge usefulness).

Seeing what Travis did to the look of the system I am very confident he
has an eye for graphics.

Seeing wat Cincom has done to my toolset however does not induce such a
vote of confidence.
To name a few:
  -standard color mappings are used in non-standard ways (red means
failure for western users, however in the differator tools it means
something else)
  -more and more 'stuff' (particularly icons, method counts) is
rendered in my tools, seemingly 'because we can' and not for some
specific workflow reason).
    This way my brain is being trained to ignore icons...
  -in contrast the places where workflow would be helped by 'more' seem
to get skipped
     (e.g. showing number of shareds in the shareds _tab_ of the RB
would really help,
      instead we do get number of methods in a protocol which happens
to be just cognitive noise because in the workflow it is only
interesting whether a protocol is non-empty, not by how much it is
non-empty).

It would be nice to have somebody from cincom come in and explain why this feature was added.
And in my opinion it would MUCH nicer to have cincom publish an (optional) patch that removes this functionality.  Im with Reinout here -- I dont want the extra "noise" in my browser.
 

  -my tools are replaced by glitzier onces that show less (at least
until I'm done clicking on a gazillion triangles to disclose the
developer information),
   and can do less (context menus not aligned with workflow like in the
differators)
   and dont 'take' our ParagraphEditor extensions.
   and mask our useful extensions (like our in-house icons showing the
semantics of a method tag are now displaced by a generic 'this method
has a tag' icon -- why exactly do I need to know a method is tagged?).
 -'undo' in the paragrapheditor has been a problem for how long?

I havent seen the undo change since vw5i
 

 -menu item placement has been inconsistent for how long? for example:
      -- shareds get a submenu way low in the rb list context, but
other artifacts like methods get treated differently.
      -- rb package list has *two* submenus for opening browsers
('browse' and 'spawn')
      -- 'find methods with strings matching' in the RB but not in the
launcher where most of our method finders are found

So I guess in the dev tools I have seen too much UI development (new
icons! again!) and too little tool development (semiotics anybody...).

I'll add one item to the list here:  the ability to select "nothing" in lists.  This was one of my major beefs after upgrading to vw77 and vw78.
in vw76 and earlier, when I click on something in a list (ex: method category in browser), it selects whatever I clicked on, and the tool updates as expected.  Then wen I click on the Same item again, it selects "nothing".

so why is this a problem?
in the class browser:  i click a class, in vw76 and before, it displays the class categories and all their methods.  I can quickly scan the method list to look for something.  If I want just 1 category, I click that.  If I need to see all methods again, I click the same category, its unselected and im back to the previous list.

In vw77 and beyond, I click a class, and I get all methods as expected, and if im interested in just 1 category, I can click on that.  but this is where things break.  If I want to go back to the full method list.. there is no way to unselect the method category, and im forced to go through some highly annoying gyrations to get this to happen.  (click on a diff class w/o the method category) A single click operation in vw76 turns into 5-20 clicks in vw77 and beyond.

The same applies to inspectors.  I open an inspector on something, and the top entry "self" is selected.
in vw76 and before, if I want to do something with the object, I click whatever is selected, the selected text vanishes and I start typing.
in vw77 and beyond, the "unselect" ability is gone, so I have to get rid of whatever was displayed before I can start typing.  Again a single click operation from vw76 turns into multiple clicks.

Now - im sure its possible to go into the image, find this ability and change it to my liking.  but I would rather be using my tools than trying to fix them.

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

Perhaps I should note that VW bashing is not at all my intent. The  
contrary is true: I want to encourage more investement in the GUI and  
platform integration, 

because I am convinced that VW can be a killer  
environment for any kind of desktop application of medium to high  
complexity. 

And I also believe there is huge business potential behind  
it.
Andre