Smalltalk › Cincom › VisualWorks

Re: vw7.7.1 New Style UI?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

Mark Plas

Re: vw7.7.1 New Style UI?

Hi,

In VW7.7.1 a new style of user interface is being introduced in some tools.

The new comparison tool uses it, but also the prerequisites tool and the bundle structure tool. Maybe there are other tools using it as well but I haven't used vw7.7.1 enough to encounter them.

I'm not convinced this new UI style is better than the old style. I actually prefer the old, vw7.7, way of doing things.

For instance, in the "bundle structure" tab page, I really miss the old vw7.7 window (brought up using 'Edit bundle structure…'):

I think it has a much more clear way of presenting information and of manipulating it. Everything is intuitive. And there's the OK and CANCEL buttons to apply or discard the changes, something that's missing in the vw7.7.1 replacement.

The same goes for the prerequisites tool.

Concerning the new comparison tool, I've only used it a few times on very simple things and I can't help but feeling lost in it. I much prefer the old version's way of organizing information. It has a menu bar for instance, and it has a very easy to grasp 'list-with-sublist-with-textpane' style of user interface. It also has some commands that are missing in the new tool (like "load method"). I find this UI a lot easier to navigate through and find what I'm looking for. Also, it has the same look and feel as the refactoring browser for instance, it uses well known widgets that have already proven themselves over the years. The new tools look & feel completely different. They have absolutely nothing in common with the rest of VW which is not a good thing I believe.

I think the new style UI tries to impress with a more webpage-like feel and fancier graphics, but I find the old tools a lot more intuitive to use. I'm under the impression that this new UI style is still in an experimental stage. I don't think that currently it’s good enough to replace the old style tools.

How do others feel about this?

Mark

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

Georg Heeg

Re: vw7.7.1 New Style UI?

Mark,

Initially I felt like you, but being in vw-dev have been worked with the new tools for a few months and we got quickly addicted as they provide additional benefits. Meanwhile going back feels like a time machine.

Georg

Georg Heeg eK, Dortmund und Köthen, HR Dortmund A 12812

Tel. +49-3496-214328, Fax +49-3496-214712

Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Mark Plas
Gesendet: Donnerstag, 26. August 2010 10:50
An: VWNC
Betreff: Re: [vwnc] vw7.7.1 New Style UI?

Hi,

In VW7.7.1 a new style of user interface is being introduced in some tools.

The new comparison tool uses it, but also the prerequisites tool and the bundle structure tool. Maybe there are other tools using it as well but I haven't used vw7.7.1 enough to encounter them.

I'm not convinced this new UI style is better than the old style. I actually prefer the old, vw7.7, way of doing things.

For instance, in the "bundle structure" tab page, I really miss the old vw7.7 window (brought up using 'Edit bundle structure…'):

The same goes for the prerequisites tool.

How do others feel about this?

Mark

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

Steven Kelly

Re: vw7.7.1 New Style UI?

In reply to this post by Mark Plas

+1 for the new tools being experimental and not ready to totally replace the old ones.

On the positive side: I’m delighted to see new UIs being played with, and Smalltalk should continue to push the boundaries. I’d rather see these things in tools where I have a choice, though, e.g. BottomFeeder and IRC (which have indeed pushed the boundaries and offered their additions to other developers as packages, “how-to” blog entries etc.).

Aside from the problems I’ve already mentioned with the comparison tool, I find that the new UIs are poorly discoverable. There are no menus, and the things we’re meant to click on are often not familiar as clickable elements. They generally lack visible text on the clickable elements, and don’t use familiar icons (e.g. the Prerequisite tab refresh icon isn’t the familiar pair of arrows eating each others’ tails, but a magnifying glass with a C-shaped arrow). The clickable elements are often monochrome and a fairly light grey, a convention which is generally used for a disabled button (e.g. the |<, + and x buttons in the bundle structure tab).

The prerequisite tab opens for me with no contents other than the refresh button and “Scanning (100% done)…” message. I have to resize the window to get it to display its contents.

The tool tips in the new UIs are flaky: often one stays open, so you can’t see the meaning of the other unlabeled “buttons” even by mousing over them (e.g. the pundle version tooltips in the bundle structure tab stay open even when mousing over the |< “rewind to start of track” button).

I agree with Georg that the new UIs are learnable – they share a common philosophy. In some cases they add nice new functionality (nothing to do with the UI approach); in others they remove useful old functionality. I’d much rather see Cincom spend time on the functionality; that’s what gives us productivity benefits, whereas cool new UIs just take more time to learn.

How many customers actually said “you really need to create a new avant-garde UI for the prerequisites tool”? And how many said “you really need to make the menu texts for Store operations consistent across the various tools”? Georg’s argument that the dogfooders liked it is a dangerous one: products are made for their customers, not their developers or internal users. This holds true even for products which are developed in themselves – as we at MetaCase are of course aware.

Cheers,

Steve

From: [hidden email] [mailto:[hidden email]] On Behalf Of Mark Plas
Sent: 26. elokuuta 2010 11:50
To: VWNC
Subject: Re: [vwnc] vw7.7.1 New Style UI?

Hi,

In VW7.7.1 a new style of user interface is being introduced in some tools.

The new comparison tool uses it, but also the prerequisites tool and the bundle structure tool. Maybe there are other tools using it as well but I haven't used vw7.7.1 enough to encounter them.

I'm not convinced this new UI style is better than the old style. I actually prefer the old, vw7.7, way of doing things.

For instance, in the "bundle structure" tab page, I really miss the old vw7.7 window (brought up using 'Edit bundle structure…'):

The same goes for the prerequisites tool.

How do others feel about this?

Mark

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

Tomas Dvorak

Re: vw7.7.1 New Style UI?

In reply to this post by Mark Plas

I find the VW 7.7 prerequisite tool vastly superior to previous versions. It is intuitive, good looking and provides me with almost exactly what I want. I have added an 'Apply computed prerequisites' button, and couldn't be satisfied more.

I haven't used the new 7.7.1 comparison tool yet (still stuck with 7.7), just had a quick look at it. I prefer the expanding trees views to many small opened windows (as well as the strongtalk and newspeak people, who I really look up to), so at least for me this feels like the good direction of UI development. Of course, I haven't really used it yet, so I cannot assess things like choice of the menu items, flow of the work etc..

I also appreciate the UI modernizing effort in general. Some parts of VW are actually beginning to not look and feel ugly and ancient, but sleek and modern. AlphaBlendedIcons, Cairo support, Panel, StoreProgressOverlay, New prerequisites tool, Diggy, Launchpad, ... - Thank you for all of these!

All the best,

Tomas Dvorak

On 26 August 2010 10:49, Mark Plas <[hidden email]> wrote:

Hi,

In VW7.7.1 a new style of user interface is being introduced in some tools.

The new comparison tool uses it, but also the prerequisites tool and the bundle structure tool. Maybe there are other tools using it as well but I haven't used vw7.7.1 enough to encounter them.

I'm not convinced this new UI style is better than the old style. I actually prefer the old, vw7.7, way of doing things.

For instance, in the "bundle structure" tab page, I really miss the old vw7.7 window (brought up using 'Edit bundle structure…'):

I think it has a much more clear way of presenting information and of manipulating it. Everything is intuitive. And there's the OK and CANCEL buttons to apply or discard the changes, something that's missing in the vw7.7.1 replacement.

The same goes for the prerequisites tool.

Concerning the new comparison tool, I've only used it a few times on very simple things and I can't help but feeling lost in it. I much prefer the old version's way of organizing information. It has a menu bar for instance, and it has a very easy to grasp 'list-with-sublist-with-textpane' style of user interface. It also has some commands that are missing in the new tool (like "load method"). I find this UI a lot easier to navigate through and find what I'm looking for. Also, it has the same look and feel as the refactoring browser for instance, it uses well known widgets that have already proven themselves over the years. The new tools look & feel completely different. They have absolutely nothing in common with the rest of VW which is not a good thing I believe.

I think the new style UI tries to impress with a more webpage-like feel and fancier graphics, but I find the old tools a lot more intuitive to use. I'm under the impression that this new UI style is still in an experimental stage. I don't think that currently it’s good enough to replace the old style tools.

How do others feel about this?

Mark

_______________________________________________
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

kobetic

Re: vw7.7.1 New Style UI?

In reply to this post by Mark Plas

"Steven Kelly"<[hidden email]> wrote:

> I agree with Georg that the new UIs are learnable - they share a common

> philosophy. In some cases they add nice new functionality (nothing to do

> with the UI approach); in others they remove useful old functionality.

> I'd much rather see Cincom spend time on the functionality; that's what

> gives us productivity benefits, whereas cool new UIs just take more time

> to learn.

I don't mean to denigrate the various complaints raised, but almost without exception they could be addressed within the new tools without much difficulty. Some are limitations, some are simply bugs. I can certainly see that they can be irritating to the point that they overshadow any benefits from the change. That's why I'd like to emphasise Georg's point: give the new tools some time. They are not just a careless attempt to make the existing ones "prettier". For example, I really like how the comparison tool de-emphasises the packages and gives you a complete overview of "the change" as a whole, which more often than not spans package boundaries. It gives new possibilities, like highlighting that the a pair of a missing and added methods have the same content and are likely a rename, etc. I wish I could drag any method and drop it on any other method there and get a comparison of those two.

If the missing menu items are the primary irritant and disruption to one's workflow, you can add as many as you wish if you follow the pattern in MethodComparisonView. The menus will never fit everyone's taste perfectly, so I'd say the key requirement is that they are no less extensible than the old ones were. The new UI construction approach doesn't have the familiar feel we're used to, but it took me only a minute to find the place where I need to extend it.

Similarly restoring the accept/cancel pattern in the new RB tools is doable, but if the Undo capability worked as expected for this case, would they still be needed ? The bundle structure tool even has the "Reset to the published state" button. Maybe just dropping the same on the prereq tool as well would suffice. At the same time I find it difficult to believe that one would want to go back to the old 'edit structure' tool, where the left pane had an endless list of all packages where you had to manually search for the exact one you wanted. All I can say about the prereq tool is that I don't even remember it, I always loaded the new prereq engine goodie which made it usable AFAICS.

>From my subjective point of view, trying to be fair to both, I can't reasonably agree that the old tools were better overall, we were just used to them (including their quirks). And I can confirm Georg's experience that I get real benefits out of the new tools in my day to day job. So, please, let's not dump the kid with the bath water.

There're my 0.02 CAD,

Martin

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

Steven Kelly

Re: vw7.7.1 New Style UI?

In reply to this post by Mark Plas

This is great, I really appreciate that the different views can be
shared here.

[hidden email] wrote:
> I really like how the comparison tool de-emphasises the
> packages and gives you a complete overview of "the change" as a whole,
> which more often than not spans package boundaries.

Fascinating! There must be a clear difference of process in how we use
bundles, because what you find is a benefit for comparing bundles is one
of my annoyances! We publish packages separately, and when publishing a
bundle we are almost always just collecting existing versions of
packages. We thus don't need the method-level comparison, and
calculating it just takes time. If there are long methods or comments,
opening it can take a very long time.

The version comment for our bundle will be a summary of the version
comments for the packages, over their versions since the last bundle
publish. To calculate the bundle version comment we used to concatenate
each package version comment by going through the package version list.
We submitted a change so selecting multiple packages shows the
concatenated version comments, and that made it into 7.7(?). (We also
added our own button to the old bundle comparison code that automated
this over all packages in the bundle, but obviously that no longer
works.)

Now the version comments also include the package comment, so multiple
selections mean the package comment is interleaved between every version
comment, normally unchanging. (I still don't see why selecting a package
_version_ should show the package comment too.) Obviously, it's a lot
more work to build our version comments manually now using the current
tools, compared to using the old standard tools. I'm sure I can automate
it, but on the question of the usability / usefulness of the new tools
themselves that's not really the point.

I don't think this is peculiar to me, i.e. a matter of taste, but it's
certainly linked to the fact that my process is different from yours.

Thanks for the hints on how to add menus. I'm finding it harder, hours
not minutes, but that may well be peculiar to me :-).

I certainly don't want to see either baby or bathwater thrown out. I've
just been dumped in the dirty bathwater, and would prefer to be standing
outside where I was before, until a) I want a bath, and maybe b) the
water's a bit cleaner ;-).

All the best,
Steve

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

kobetic

Re: vw7.7.1 New Style UI?

In reply to this post by Mark Plas

"Steven Kelly"<[hidden email]> wrote:

> Fascinating! There must be a clear difference of process in how we use

> bundles, because what you find is a benefit for comparing bundles is one

> of my annoyances! We publish packages separately, and when publishing a

> bundle we are almost always just collecting existing versions of

> packages. We thus don't need the method-level comparison,

exactly, why do you want comparison view for that. If you want to see which packages were updated in this bundle publish, the publishing dialog shows that to you, so why do you need the comparison view at this step ?

My most common use case for the comparison tool is code review. I get an AR for review, I want to see the changes. The package boundaries are secondary at that point. That's where I think the tool works quite well.

> and

> calculating it just takes time. If there are long methods or comments,

> opening it can take a very long time.

I'm not sure why the size would matter when opening, all the items are collapsed aren't they ? I'm not saying there's no problem there (although I haven't noticed it yet), but if there is, it seems like something that should be fixable.

> Now the version comments also include the package comment, so multiple

> selections mean the package comment is interleaved between every version

> comment, normally unchanging. (I still don't see why selecting a package

> _version_ should show the package comment too.) Obviously, it's a lot

> more work to build our version comments manually now using the current

> tools, compared to using the old standard tools. I'm sure I can automate

> it, but on the question of the usability / usefulness of the new tools

> themselves that's not really the point.

Yes, I'm not too thrilled that selecting a version combines the two comments. At least now the blessing comment is on top of the package comment. I'd add my vote to prying them apart again.

> I don't think this is peculiar to me, i.e. a matter of taste, but it's

> certainly linked to the fact that my process is different from yours.

Agreed. But now we're talking about different tool, the version browser, right ?

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

Steven Kelly

Re: vw7.7.1 New Style UI?

In reply to this post by Mark Plas

>> We publish packages separately, and when publishing a
>> bundle we are almost always just collecting existing versions of
>> packages. We thus don't need the method-level comparison,
>
> exactly, why do you want comparison view for that. If you want to see
> which packages were updated in this bundle publish, the publishing
> dialog shows that to you, so why do you need the comparison view at
> this step ?

The publish dialog shows only the current package versions, but not what
the version number of each package was in the previous publish of this
bundle. Nor does it have menu items to open package version lists, or
any other way to get the versions.

The publish dialog does NOT show which packages are updated in this
bundle publish - remember, we've already published each package
individually, so they are all unchanged now. The only thing that is
being published is the bundle itself.

> I'm not sure why the size would matter when opening, all the items are
> collapsed aren't they ? I'm not saying there's no problem there
> (although I haven't noticed it yet), but if there is, it seems like
> something that should be fixable.

I imagine it's easily fixable. The initial slowness before opening is
unavoidable if you want the tool to show the comparison. For our use,
it's unnecessary: I'd rather just see the list of packages and their
versions, and when selecting a package see the version comments between
the old published and new version.

I'm afraid I don't remember the exact situation of the surprising
slowness, but you're right that if it involved a long method, as I think
it did, it would only happen after clicking after opening.

> > I don't think this is peculiar to me, i.e. a matter of taste, but
> > it's certainly linked to the fact that my process is different
> > from yours.
>
> Agreed. But now we're talking about different tool, the version
> browser, right ?

Actually I was talking about the whole process of publishing a bundle,
in our process.

Anyway, like with the multi-selection of package versions, I'll try and
make something that works for our progress and see if you think it could
be useful for others.

All the best,
Steve

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

kobetic

Re: vw7.7.1 New Style UI?

In reply to this post by Mark Plas

"Steven Kelly"<[hidden email]> wrote:

> Date: August 26, 2010 4:06:31 PM

> From: "Steven Kelly" <[hidden email]>

> To: <[hidden email]>

> Cc: VWNC<[hidden email]>

> Subject: RE: [vwnc] vw7.7.1 New Style UI?

>

> >> We publish packages separately, and when publishing a

> >> bundle we are almost always just collecting existing versions of

> >> packages. We thus don't need the method-level comparison,

> >

> > exactly, why do you want comparison view for that. If you want to see

> > which packages were updated in this bundle publish, the publishing

> > dialog shows that to you, so why do you need the comparison view at

> > this step ?

>

> The publish dialog shows only the current package versions, but not what

> the version number of each package was in the previous publish of this

> bundle. Nor does it have menu items to open package version lists, or

> any other way to get the versions.

>

> The publish dialog does NOT show which packages are updated in this

> bundle publish - remember, we've already published each package

> individually, so they are all unchanged now. The only thing that is

> being published is the bundle itself.

You're right, I confused myself. But my point is that it sounds like you want a different kind of tool, not the comparison tool. Expecting the comparison tool to not show differences would be a somewhat odd use case, I think.

Cheers,

Martin

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

Steven Kelly

Re: vw7.7.1 New Style UI?

In reply to this post by Mark Plas

RE: [vwnc] vw7.7.1 New Style UI?

>> The publish dialog does NOT show which packages are updated in this
>> bundle publish - remember, we've already published each package
>> individually, so they are all unchanged now. The only thing that is
>> being published is the bundle itself.
>
> You're right, I confused myself. But my point is that it sounds like

> you want a different kind of tool, not the comparison tool. Expecting

> the comparison tool to not show differences would be a somewhat

> odd use case, I think.

Oh, I don't know - after all, the window that opened for bundle "Compare with Parent" in 7.6 didn't show differences. Of course you're right that showing the method comparisons is a reasonable thing to do. But remember I'm not asking to open the comparison tool, I'm asking "Compare with Parent", and I believe that at least for my way of using bundles, expecting that to be able to show blessing comments is not odd.

For me, the blessing comments are a higher level description than the individual changes. We can put the various levels in order:

- Package & blessing comments

- Classes with changes

- Methods with changes

- Text lines with changes

The new comparison tool already sensibly rolls up this tree view, showing just the classes at first. That's a good high-level overview when doing "Compare with Parent" for a package. When we compare a bundle, there's an extra level, and we can go one better by showing the packages with their blessing comments, and within them the classes and so on. Of course I'm happy for those who prefer to merge all packages' changes, as the current tool does, to have that option too. But it's hopefully not an odd request to want to have the option to see things divided up by package. Indeed, that's how every previous version of VW has done it. And bundles and packages are used throughout VW to group code, divide and conquer, and filter views.

If the first level of the tree was packages, we would have a consistent UI metaphor of tree containment - rather than needing to create a whole new kind of UI for the list of packages at the top (initially hidden), as the current tool does. If the second level was the package blessing comment, a single shift-click on the first package would show all packages' blessing comments (making me a happy man, particularly if there was a "dump current view as text to clipboard" button). The next level would be the classes, and then the methods, and then the source code. In the absence of screenshots (hi Travis!), hopefully a little ASCII art will suffice:

Initial view:

+ Package1 3.6 -> 3.8

+ Package2 4.0 -> 5.0

+ Package3 1.1 -> 1.2

After 1 shift-click:

- Package1 3.6 -> 3.8

+ 3.7 Added Foobar class

+ 3.8 Added FoobarModel

- Package2 4.0 -> 5.0

+ 5.0 Rewrote to use Cairo

- Package3 1.1 -> 1.2

+ 1.2 Corrected OS X clipping bug

After 2 shift-clicks:

- Package1 3.6 -> 3.8

- 3.7 Added Foobar class

+ Foobar

- 3.8 Added FoobarModel

+ FoobarModel

- Package2 4.0 -> 5.0

- Rewrote to use Cairo

+ CairoClass1

- Package3 1.1 -> 1.2

- Corrected OS X clipping bug

+ MacDisplayView

Turning off the "Show by package" option would revert to the current 7.7.1 way, where the top level is classes. There might be a need for a "Show by version" option; turning it off would merge Package1 3.7 and 3.8's changes. And of course there could be a "Show blessing comments" option, for those who don't like them.

All the best,

Steve

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

Travis Griggs-4

Re: vw7.7.1 New Style UI?

On Aug 27, 2010, at 4:01 PM, Steven Kelly wrote:

I believe that at least for my way of using bundles, expecting that to be able to show blessing comments is not odd.

For me, the blessing comments are a higher level description than the individual changes.

Being able to see the blessing comments associated with the items you see in the list isn't something I'm opposed to at all. I can see the usefulness of that, especially if you pack a bit of information in them (rather than embedding info in the version string as many do). I'll ponder how to add that to the story said UI is trying to tell.

Travis Griggs

Objologist

"Dying men never wish they'd spent more time at the office"

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

Reinout Heeck-2

accept/cancel (Re: vw7.7.1 New Style UI?)

In reply to this post by kobetic

[hidden email] wrote:
> Similarly restoring the accept/cancel pattern in the new RB tools is
> doable, but if the Undo capability worked as expected for this case,
> would they still be needed ?
Yes, absolutely.

One of my ways of working is to have multiple browsers open with partial
edits, all slowly being prepared towards being 'accept'-able.
This happens often when doing prerequisites administration and sometimes
with other code changes.
Having an 'upcoming version' in the browsers and the 'base version' in
the image is exactly what I want (ephemerally) when doing those kind of
edits, the various code query tools report from the old state (thus
reporting what needs to be done) which I can compare with the new state
I'm preparing.

Please keep in mind that we are manipulating 1000+ packages in our
images, so we do need to do a bit of back-and-forth during editing
before we can accept new prerequisites.

> The bundle structure tool even has the "Reset to the published state"
> button.
Yeah, that was a bit jarring when I first saw it, as in 'hey a new
paradigm' but then implemented in only one place.

I guess this is candidate for some reflection: do you want more
buttons/menu items etc or do you want less....
Off the cuff: what about good old 'browse versions', that one does give
us more without introducing new paradigms, and opens up navigations to
all the other interesting queries like 'compare with...'.

> Maybe just dropping the same on the prereq tool as well would suffice.
> At the same time I find it difficult to believe that one would want to
> go back to the old 'edit structure' tool, where the left pane had an
> endless list of all packages where you had to manually search for the
> exact one you wanted.
Yeah, the incremental search box has never been added to old tool (a
missed experiment ;-)

Another interaction problem:
the new tool introduces a *modal* dialog when trying to add a
prerequisite (the first of the 'plus' icons).
when this dialog is up is *exactly* the time I want to switch to another
window (as in "what was that package named again, let's copy it's name
somewhere from a browser").
In the old tool I could switch windows at this moment, not in the new
one....

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

James Robertson-7

Re: accept/cancel (Re: vw7.7.1 New Style UI?)

That workflow raises a question in my mind. In the WebVelocity code browser, you can view multiple methods at a time in the same pane. It occurs to me that we could reduce the raw number of browsers if the RB had the same type of view.

What do other people think? Mind you, this isn't a feature promise, or even a feature request. I'm just curious.

James Robertson
Cincom Smalltalk Product Evangelist
http://www.cincomsmalltalk.com/blog/blogView
Talk Small and Carry a Big Class Library

On Aug 30, 2010, at 9:40 AM, Reinout Heeck wrote:

> [hidden email] wrote:
>> Similarly restoring the accept/cancel pattern in the new RB tools is
>> doable, but if the Undo capability worked as expected for this case,
>> would they still be needed ?
> Yes, absolutely.
>
> One of my ways of working is to have multiple browsers open with partial
> edits, all slowly being prepared towards being 'accept'-able.
> This happens often when doing prerequisites administration and sometimes
> with other code changes.
> Having an 'upcoming version' in the browsers and the 'base version' in
> the image is exactly what I want (ephemerally) when doing those kind of
> edits, the various code query tools report from the old state (thus
> reporting what needs to be done) which I can compare with the new state
> I'm preparing.
>
> Please keep in mind that we are manipulating 1000+ packages in our
> images, so we do need to do a bit of back-and-forth during editing
> before we can accept new prerequisites.
>
>
>> The bundle structure tool even has the "Reset to the published state"
>> button.
> Yeah, that was a bit jarring when I first saw it, as in 'hey a new
> paradigm' but then implemented in only one place.
>
> I guess this is candidate for some reflection: do you want more
> buttons/menu items etc or do you want less....
> Off the cuff: what about good old 'browse versions', that one does give
> us more without introducing new paradigms, and opens up navigations to
> all the other interesting queries like 'compare with...'.
>
>
>> Maybe just dropping the same on the prereq tool as well would suffice.
>> At the same time I find it difficult to believe that one would want to
>> go back to the old 'edit structure' tool, where the left pane had an
>> endless list of all packages where you had to manually search for the
>> exact one you wanted.
> Yeah, the incremental search box has never been added to old tool (a
> missed experiment ;-)
>
>
>
> Another interaction problem:
> the new tool introduces a *modal* dialog when trying to add a
> prerequisite (the first of the 'plus' icons).
> when this dialog is up is *exactly* the time I want to switch to another
> window (as in "what was that package named again, let's copy it's name
> somewhere from a browser").
> In the old tool I could switch windows at this moment, not in the new
> one....
>
>
> 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

Niall Ross

Re: accept/cancel (Re: vw7.7.1 New Style UI?)

Dear James,

1) I agree that a multi-method code tool would be good. I have done a
little work on it already and would be happy to be given the AR if it
proves to be wanted.

2) Another way of reducing windows would be to let users make two RB
windows into one window with two views and/or into a single view with
the selections of both prior RBs selected. I invite responders to this
thread to comment on that idea as well

The UI that I imagine for combining two RBs into two views in one RB is
drag-drop from one RB hot-spot to another, e.g. drag a menu item in an
open View menu of one RB to the 'View' menu in the toolbar of the other
RB. Comments / other suggestions ?

If the target RB's environment is smaller than the source RB's (e.g.
we're dragging a 4-pane-browser view onto a 2-pane browser), we could
make it that the selection, not the whole view, is added as a new view.

Sometimes it would be possible instead to make this a second selected
item in the current view and that would be what we would want. I'm not
sure how the UI should distiguish that, however. (We could of course,
easily add the ability to spawn a single RB on all selected items in all
views of the spawning RB.)

3) There is some relationship between the above two points. If I have
selected various methods in various browsers and now want to work on
them in a multi-method-displaying code tool, then I want an easy way of
getting them all selected (and simultaneously-visible) in a single RB.

Yours faithfully
Niall Ross

>That workflow raises a question in my mind. In the WebVelocity code browser, you can view multiple methods at a time in the same pane. It occurs to me that we could reduce the raw number of browsers if the RB had the same type of view.
>
>What do other people think? Mind you, this isn't a feature promise, or even a feature request. I'm just curious.
>
>
>James Robertson
>Cincom Smalltalk Product Evangelist
>http://www.cincomsmalltalk.com/blog/blogView
>Talk Small and Carry a Big Class Library
>
>
>
>
>On Aug 30, 2010, at 9:40 AM, Reinout Heeck wrote:
>
>
>
>>[hidden email] wrote:
>>
>>
>>>Similarly restoring the accept/cancel pattern in the new RB tools is
>>>doable, but if the Undo capability worked as expected for this case,
>>>would they still be needed ?
>>>
>>>
>>Yes, absolutely.
>>
>>One of my ways of working is to have multiple browsers open with partial
>>edits, all slowly being prepared towards being 'accept'-able.
>>This happens often when doing prerequisites administration and sometimes
>>with other code changes.
>>Having an 'upcoming version' in the browsers and the 'base version' in
>>the image is exactly what I want (ephemerally) when doing those kind of
>>edits, the various code query tools report from the old state (thus
>>reporting what needs to be done) which I can compare with the new state
>>I'm preparing.
>>
>>Please keep in mind that we are manipulating 1000+ packages in our
>>images, so we do need to do a bit of back-and-forth during editing
>>before we can accept new prerequisites.
>>
>>
>>
>>
>>>The bundle structure tool even has the "Reset to the published state"
>>>button.
>>>
>>>
>>Yeah, that was a bit jarring when I first saw it, as in 'hey a new
>>paradigm' but then implemented in only one place.
>>
>>I guess this is candidate for some reflection: do you want more
>>buttons/menu items etc or do you want less....
>>Off the cuff: what about good old 'browse versions', that one does give
>>us more without introducing new paradigms, and opens up navigations to
>>all the other interesting queries like 'compare with...'.
>>
>>
>>
>>
>>>Maybe just dropping the same on the prereq tool as well would suffice.
>>>At the same time I find it difficult to believe that one would want to
>>>go back to the old 'edit structure' tool, where the left pane had an
>>>endless list of all packages where you had to manually search for the
>>>exact one you wanted.
>>>
>>>
>>Yeah, the incremental search box has never been added to old tool (a
>>missed experiment ;-)
>>
>>
>>
>>Another interaction problem:
>> the new tool introduces a *modal* dialog when trying to add a
>>prerequisite (the first of the 'plus' icons).
>>when this dialog is up is *exactly* the time I want to switch to another
>>window (as in "what was that package named again, let's copy it's name
>>somewhere from a browser").
>>In the old tool I could switch windows at this moment, not in the new
>>one....
>>
>>
>>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

Steven Kelly

Re: accept/cancel (Re: vw7.7.1 New Style UI?)

In reply to this post by Reinout Heeck-2

Good to see some thinking on these issues!

> 1) I agree that a multi-method code tool would be good.

I'm not sure; I think we gain a lot by separating methods. The general
direction elsewhere in the UI is to take things that were a block of
text and split them into several UI fields, e.g. the class definition
dialog.

> 2) Another way of reducing windows would be to let users make two RB
> windows into one window...e.g. drag a menu item in an
> open View menu of one RB to the 'View' menu in the toolbar of the
other

Will you forgive me a "Yuck"? :-). That's non-standard, hard to
discover, and would make menus behave oddly. OK, so we've all seen the
Windows Start menu, but here I think we have other options. A better
solution would seem to be tabs in the RB.

I'd like to see the default for spawning be to open a new tab, as is now
common in web browsers. And for implementers/senders, the default would
be to open the answer over the current tab, with Back and Forward
buttons.

Opening an implementers/senders tab in an existing RB is a little
challenging, as the four top panes would be replaced by one. Judiciously
arranging that single pane into columns for Package, Class, Protocol and
Selector to mimic the four panes might help. With a given method
selected one could choose to change to the normal RB view, either over
this tab (with Back/Forward) or in a new tab.

Obviously this approach is partly mirrored in Trippy, and I'm sure
leveraging that similarity would help make a consistent, easily
learnable, and efficient UI across the dev tools.

Cheers,
Steve

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

Joachim Geidel

Re: accept/cancel (Re: vw7.7.1 New Style UI?)

> I'd like to see the default for spawning be to open a new tab, as is now
> common in web browsers. And for implementers/senders, the default would
> be to open the answer over the current tab, with Back and Forward
> buttons.
>
> Opening an implementers/senders tab in an existing RB is a little
> challenging, as the four top panes would be replaced by one. Judiciously
> arranging that single pane into columns for Package, Class, Protocol and
> Selector to mimic the four panes might help. With a given method
> selected one could choose to change to the normal RB view, either over
> this tab (with Back/Forward) or in a new tab.

When I navigate the class library, there are two actions by which I open
most of the new windows (YMMV, it's just my way of using the tools):

I often find myself following a senders or implementors chain, thereby
opening dozens of windows and often losing track of what I actually wanted
to see: the chain of dependencies between the methods. I like the
implementors/senders browser in Pharo. It's similar to a method browser in
VW, but it lets you "drill down" and navigate back and forward along a chain
of message sends without opening new windows. Adopting this tool in VW might
be less complicated than convincing the RB that it's tabs don't all have to
be of the same kind.

The second source of new windows is opening an RB window for a new class. I
often do that instead of "go to class" because there's no back/forward for
switching between classes, and because I can't open a new tab with the new
class with a single click. I need two actions for seeing a class in a new
tab: add a new tab, then go to class. This does not seem to be much
overhead, but I often find myself taking the shortest possible path. "Open
class in new tab" would be a real improvement.

Which leads to the question why RBTabbedToolsets is still an optional parcel
instead of an integral part of the RB.

Another source of superfluous windows is "browse versions" for methods to
check source code changes. I am using the enhanced version of
RBStoreExtensions which is published as a branch in the public repository.
It shows the source code of old versions right in the main RB window and
lets one open a diff of two versions by simply drawing a line between two
version figures in the graphical version tree (i.e. with a simple mouse
gesture).

Cheers,
Joachim Geidel

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

Boris Popov, DeepCove Labs (SNN)

Re: accept/cancel (Re: vw7.7.1 New Style UI?)

+1 for built-in/beefed-up tabs, all web browsers had now settled on that
concept and a lot of user research had been completed along the way. I'd
rather have that than some attempt at stuffing multiple browsers into
the same view, which wouldn't work too well on smaller laptop screens
anyway.

-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 Joachim Geidel
Sent: 07 September 2010 06:40
To: VW NC
Subject: Re: [vwnc] accept/cancel (Re: vw7.7.1 New Style UI?)

> I'd like to see the default for spawning be to open a new tab, as is
> now common in web browsers. And for implementers/senders, the default
> would be to open the answer over the current tab, with Back and
> Forward buttons.
>
> Opening an implementers/senders tab in an existing RB is a little
> challenging, as the four top panes would be replaced by one.
> Judiciously arranging that single pane into columns for Package,
> Class, Protocol and Selector to mimic the four panes might help. With
> a given method selected one could choose to change to the normal RB
> view, either over this tab (with Back/Forward) or in a new tab.

When I navigate the class library, there are two actions by which I open
most of the new windows (YMMV, it's just my way of using the tools):

I often find myself following a senders or implementors chain, thereby
opening dozens of windows and often losing track of what I actually
wanted to see: the chain of dependencies between the methods. I like the
implementors/senders browser in Pharo. It's similar to a method browser
in VW, but it lets you "drill down" and navigate back and forward along
a chain of message sends without opening new windows. Adopting this tool
in VW might be less complicated than convincing the RB that it's tabs
don't all have to be of the same kind.

The second source of new windows is opening an RB window for a new
class. I often do that instead of "go to class" because there's no
back/forward for switching between classes, and because I can't open a
new tab with the new class with a single click. I need two actions for
seeing a class in a new
tab: add a new tab, then go to class. This does not seem to be much
overhead, but I often find myself taking the shortest possible path.
"Open class in new tab" would be a real improvement.

Which leads to the question why RBTabbedToolsets is still an optional
parcel instead of an integral part of the RB.

Another source of superfluous windows is "browse versions" for methods
to check source code changes. I am using the enhanced version of
RBStoreExtensions which is published as a branch in the public
repository.
It shows the source code of old versions right in the main RB window and
lets one open a diff of two versions by simply drawing a line between
two version figures in the graphical version tree (i.e. with a simple
mouse gesture).

Cheers,
Joachim Geidel

_______________________________________________
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