Package manager: filter vs. selection

Hi Blair,

I can't find the relevant post right now, but, I wanted to return to (at
least what I can remember of) the discussion re the package manager and
selecting all packages in and below a given directory.  IIRC, you said to
think of the folder as a filter.  That sounds great, but, is it really
necessary to select every package and therefore every class in a major chunk
of the system every time the user wants to change the filter?  If not having
a selection is a problem, would it be possible to simply select the first
package matching the filter?  The user could always select all if that's
what they want.  The way it is now, the package manager seems to be working
against me a bit, and doing a lot of work in the process.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> Hi Blair,
>
> I can't find the relevant post right now, but, I wanted to return to (at
> least what I can remember of) the discussion re the package manager and
> selecting all packages in and below a given directory.  IIRC, you said to
> think of the folder as a filter.  That sounds great, but, is it really
> necessary to select every package and therefore every class in a major
chunk
> of the system every time the user wants to change the filter?  If not
having
> a selection is a problem, would it be possible to simply select the first
> package matching the filter?  The user could always select all if that's
> what they want.  The way it is now, the package manager seems to be
working
> against me a bit, and doing a lot of work in the process.

A few people have moaned about this, but no one has said _specifically_ what
the problem is with selecting everything? Even on my old 333 Celeron laptop
there is no performance problem (and if you are using older and slower
machines than that for _development_, then its probably time to think of an
upgrade because time is money), so I'm afraid the argument that it is "doing
a lot of work" falls on rather deaf ears here. Why is the package browser
working against you? Why is it any more work to select an individual package
when initially all in a folder hierarchy are selected, than it is to select
one when there is no selection (or any other selection for that matter)?

This was a deliberate design decision and reflects a new hierarchical way of
thinking about the organisation of the system of which this is only the
first stage. We've been working with it for some months now, and it is
"right" (in our opinion), so we are dead set against changing it, therefore
any arguments to the contrary will have to be convincing.

Regards

Blair

Bill,

I have to second what Blair says here. As of D5, we're trying to encourage
developers to split their apps into finer grained packaged components (since
it aid efficient deployment) and to place these into a directory hierarchy
as recommended in my initial post to the beta newsgroup. One this is done
then the fact that the PB auto-selects all the packages below a directory is
(I find) rather convenient. All of the directory nodes then become like
"macro-packages" and the PB allow you to view the contents of these with
just a single click.

Also since the PackageSelector component is used in the same role in the
System Browser then it makes sense for it to operate in a consistent manner
in both situations. I can't imagine why it would be preferable not to
autoselect the packages in the SB.

Ian mentioned at some point that the new PB seemed to lead to more mouse
clicking. While this may be true, it also seems to me that having the
auto-select feature reduces the number of clicks required to get to a given
situation by at least one. The points about adding a package find facility
and a "synch" operation to locate a directory by double clicking on a
package have been taken on board however.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

"Blair McGlashan" <[hidden email]> wrote in message
news:[hidden email]...
> "Bill Schwab" <[hidden email]> wrote in message
> news:[hidden email]...
> > Hi Blair,
> >
> > I can't find the relevant post right now, but, I wanted to return to (at
> > least what I can remember of) the discussion re the package manager and
> > selecting all packages in and below a given directory.  IIRC, you said
to
> > think of the folder as a filter.  That sounds great, but, is it really
> > necessary to select every package and therefore every class in a major
> chunk
> > of the system every time the user wants to change the filter?  If not
> having
> > a selection is a problem, would it be possible to simply select the
first
> > package matching the filter?  The user could always select all if that's
> > what they want.  The way it is now, the package manager seems to be
> working
> > against me a bit, and doing a lot of work in the process.
>
> A few people have moaned about this, but no one has said _specifically_
what
> the problem is with selecting everything? Even on my old 333 Celeron
laptop
> there is no performance problem (and if you are using older and slower
> machines than that for _development_, then its probably time to think of
an
> upgrade because time is money), so I'm afraid the argument that it is
"doing
> a lot of work" falls on rather deaf ears here. Why is the package browser
> working against you? Why is it any more work to select an individual
package
> when initially all in a folder hierarchy are selected, than it is to
select
> one when there is no selection (or any other selection for that matter)?
>
> This was a deliberate design decision and reflects a new hierarchical way
of
> thinking about the organisation of the system of which this is only the
> first stage. We've been working with it for some months now, and it is
> "right" (in our opinion), so we are dead set against changing it,
therefore
> any arguments to the contrary will have to be convincing.
>
> Regards
>
> Blair
>
>
>

Isn't it just a question of familiarity? Andy and Blair have been using the
new Package procedures for some time and have got used to it. It still feels
strange to the rest of us, well me anyway, as it's not what we would
normally see - imagine selecting a folder in WindowsExplorer and it
displaying and selecting all the files in the complete sub-folder tree as
well.

I have to say that, whilst not completely comfortable, I am getting used to
the new layout. The alterations made in B2 certainly helped along with a
change in the way I trying to use it - I now don't initially worry about the
folder list but go straight to the package in the full list, double clicking
it to open the correct folder if needed.  Another thing I noticed was that I
don't need to use the PB as much as I did before and, rather than having one
open on the desktop all the time, I can close it after loading the packages
I wanted.

FWIW, I am also quite enjoying the new SystemBrowser. I did some "proper"
coding yesterday, rather than the maintenance stuff I have mainly been doing
recently. Having all the classes in a package in one list and the ease of
switching packages to view another set of classes seemed to make things so
much quicker. There are some rough edges still, the question of loose
methods is the one that seemed to grate a bit, but definitely a good
addition.

My ?0.02

Regards
    Ian

Blair,

> A few people have moaned about this, but no one has said _specifically_
what
> the problem is with selecting everything? Even on my old 333 Celeron
laptop
> there is no performance problem (and if you are using older and slower
> machines than that for _development_, then its probably time to think of
an
> upgrade because time is money),

There are different kinds of development.  Slow machines have a very valid
role in performance tuning, and in debugging by exposing problems that will
arise in the field under stress.  Fast machines are great for refactoring,
deployment, improving documentation, running/fixing unit tests, etc..


> so I'm afraid the argument that it is "doing
> a lot of work" falls on rather deaf ears here. Why is the package browser
> working against you? Why is it any more work to select an individual
package
> when initially all in a folder hierarchy are selected, than it is to
select
> one when there is no selection (or any other selection for that matter)?

It's more subtle than that, and it's not performance related.  Ian seems to
be further along in making sense of it.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Andy,

> Ian mentioned at some point that the new PB seemed to lead to more mouse
> clicking. While this may be true, it also seems to me that having the
> auto-select feature reduces the number of clicks required to get to a
given
> situation by at least one.

IMHO, the problem is too much of a good thing.  However, Ian also observed
that he's using the PB less than before.  He and I both had permanently
allocated screen space to a PB.  That space might now go to a SB or in my
case, maybe to one of my more experimental gizmos.  BTW, that's not
necessarily bad; the PB might have simply been pressed into service where a
SB was the preferred solution.

Having said that, I want to go on record as being a big believer in a CHB.
A good SB is always welcome as an addition, but, not as a replacement for a
CHB (not that there's ever been any mention of getting rid of it).

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Ian,

> Isn't it just a question of familiarity?

That's probably a large part of it.


> Andy and Blair have been using the
> new Package procedures for some time and have got used to it. It still
feels
> strange to the rest of us, well me anyway, as it's not what we would
> normally see - imagine selecting a folder in WindowsExplorer and it
> displaying and selecting all the files in the complete sub-folder tree as
> well.

I find it strange too.


> I have to say that, whilst not completely comfortable, I am getting used
to
> the new layout. The alterations made in B2 certainly helped along with a
> change in the way I trying to use it - I now don't initially worry about
the
> folder list but go straight to the package in the full list, double
clicking
> it to open the correct folder if needed.

If I'm following you, then the select all kicks in, selecting all peer
packages and possibly taking the one of interest out of view.  That
situation will no doubt improve once I have a chance to "hierarchize" my
packages.


> Another thing I noticed was that I
> don't need to use the PB as much as I did before and, rather than having
one
> open on the desktop all the time,

And that might be the answer.  I've relied heavily on the PB for a long
time, (I think) mostly as a filter for opening CHBs.  I've lost track of it,
but, I really liked your change of the CHB's hierarchy filter to a package
filter.  One thing I still miss about Smalltalk/V is the ability to open a
CHB on an arbitrary collection of classes, and the PB has filled that void.
The system browser will probably take over the role of getting a CHB on the
right part of the class hierarchy, which is how I prefer to work (in a CHB
vs. a SB).


> I can close it after loading the packages
> I wanted.

I do most of that with Migrate and your chunk browser (for the safe and
dangerous selectors).

That reminds me of an enhancement idea for the chunk browser: it would be
nice to have an easy way to see the current code that would be lost if a
method were filed-in.  It currently does a nice job of indicating that
something is at risk, but, I haven't found a slick way to see _what_ is at
risk.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

> > ... imagine selecting a folder in WindowsExplorer and it
> > displaying and selecting all the files in the complete sub-folder tree
as
> > well.
>
> I find it strange too.

Ditto for me.  I still don't understand the rationale for what seems
counter-intuitive, but I suppose for now I consider it an annoyance that I
can live with (and with trust in OA, maybe even come to love).

> ... I really liked your change of the CHB's hierarchy filter to a package
> filter.

I might be missing something, but I don't see this in the CHB.

> ... One thing I still miss about Smalltalk/V is the ability to open a
> CHB on an arbitrary collection of classes, and the PB has filled that
void.
> The system browser will probably take over the role of getting a CHB on
the
> right part of the class hierarchy, which is how I prefer to work (in a CHB
> vs. a SB).

FWIW, I too liked having a CHB open on selected classes, which is one reason
I built that kind of browser for myself.  I posted something on it many
moons ago, with a picture of it at
http://www.mindspring.com/~lsumberg/Dolphin/LasClassBrowserShell1.jpg.  I
didn't get any response so didn't pursue it in the newsgroup, but I've been
using it, off and on, for some time (along with the regular CHB).  A
treeview example is at
http://www.mindspring.com/~lsumberg/Dolphin/LasClassBrowserShell2.jpg.

> That reminds me of an enhancement idea for the chunk browser: it would be
> nice to have an easy way to see the current code that would be lost if a
> method were filed-in.

I agree with this enhancement idea, but my thought is for the PB to have a
"Preview Install" option that would essentially show methods in an incoming
package that will overwrite those in the image.

-- Louis

P.S. Sorry I haven't been testing the beta stuff much, especially the new
things.  I've been using it, however, for my current development.

Blair, Andy,

> A few people have moaned about this, but no one has said _specifically_
what
> the problem is with selecting everything?

I have a pop at explaining what I find so unsettling about this way of doing
things.

First off, I like the new hierarchy approach.  I like the idea of being able
to see and, scope operations to, a sub-set of packages.  I am looking
forward to you taking the idea forward in the future (like the scoped
searching operations).

What I take issue with is the very specific point that selecting a folder
causes all the packages in that folder to be selected.

Since Blair's comment about "try to think of it as a filter" a few days ago,
and after thinking about what you could mean for a few hours (on and off), I
finally realised what it was that you were trying to do.  Again, I have no
problems with what you are aiming at, I think it's a very good idea and will
be very useful.

The problem is that the *mechanism* you have chosen for *implementing* that
aim subverts one of the most deeply engrained aspects of the Windows UI.

In normal Windows the selection is something that *I* set, at *my*
discretion in order that I may inspect or otherwise interact with one or
more objects.  The new UI does not respect that idea.

Note that this is not about saving/wasting keystrokes -- in fact, even if
the automatic selection saved keystrokes in *every* interaction then it
would still be disturbing and hence wrong.

I suggest that a better way of working would be for the selection in the
folder pane and package lists to be decoupled.  When I select a folder, the
contents of all that folder's packages would be displayed (ignoring the
selection in the package list).  When I select one or more packages from the
package list then those packages' contents would be displayed.  I'm not sure
whether selecting nothing in the package list (if that's even possible)
should mean "display all this folder" or "display nothing" -- I could make
arguments in either direction, but it is the kind of thing where you have to
try both alternatives to find out which feels natural.

The above (or some better scheme) achieves the same functionality as I
believe you were aiming for, but does so without breaking the mental model
of "selection" which is so fundamental to Windows.

> This was a deliberate design decision and reflects a new hierarchical way
of
> thinking about the organisation of the system of which this is only the
> first stage. We've been working with it for some months now, and it is
> "right" (in our opinion), so we are dead set against changing it,
therefore
> any arguments to the contrary will have to be convincing.

I don't know whether I have succeeded in convincing you yet.  I'll witter on
for a bit more.

Speaking for myself, my first thought when I saw the new behaviour was that
"something was wrong", but I couldn't articulate just what.  It has taken
some days for me to be able to say what the underlying problem is.  If I'd
been asked what was wrong before about yesterday, then I'd have been forced
into vague mutterings about "too many keystrokes", "not what I'm used to",
etc, but really I'd just have been groping for a way to express a jarring
disquiet, a less-than-half conscious outrage.  I'm guessing, but I *suspect*
that this is what has been underlying Bill and Ian's (and others? I can't
remember) problems with the scheme -- what do you say, people ?

You said that you'd been working with it for some months now, and liked it,
and implied that our problems are caused by not having got used to it yet.
With respect, I think that is backwards: if a bunch of intelligent users
dislike a new pattern of interaction, and find it hard to intuit the
underlying logic, then that suggests that something is wrong, and that you
have been using the new interaction for so long that you no longer perceive
its problems.

Anyway, that's my best shot at explaining why I don't like the
auto-selection.  I'll close a regrettably pompous post by repeating that I
*like* what you are doing with the hierarchical stuff; I *want* the greater
power and control it will give me as a user; but I think that you have made
a small but rather important mistake in designing the user-interface to the
great new features.

    -- chris

Chris

You wrote in message news:[hidden email]...
> Blair, Andy,
>
> > A few people have moaned about this, but no one has said _specifically_
> what
> > the problem is with selecting everything?
>
> I have a pop at explaining what I find so unsettling about this way of
doing
> things.
>... [snip]...
> What I take issue with is the very specific point that selecting a folder
> causes all the packages in that folder to be selected.
>
>... [snip]...
>
> The problem is that the *mechanism* you have chosen for *implementing*
that
> aim subverts one of the most deeply engrained aspects of the Windows UI.
>
> In normal Windows the selection is something that *I* set, at *my*
> discretion in order that I may inspect or otherwise interact with one or
> more objects.  ....

That isn't always true, particularly for multiple selection lists. These are
commonly used to show pre-selected items. In certain circumstances it can be
very inconvenient when multiple selections are not preset.

>...The new UI does not respect that idea.
>
> Note that this is not about saving/wasting keystrokes -- in fact, even if
> the automatic selection saved keystrokes in *every* interaction then it
> would still be disturbing and hence wrong.

We regard that sort of thing as very important. I could not imagine shipping
a Smalltalk system for years and years that required one to first select
every expression one wanted to evaluate with the mouse. Unecessary
interactions are a waste of time, and mentally and physically damaging to
the user :-). Of course that is not to say that Dolphin is by any means
perfect in this respect, but we treat it as a high priority.

>
> I suggest that a better way of working would be for the selection in the
> folder pane and package lists to be decoupled.  When I select a folder,
the
> contents of all that folder's packages would be displayed (ignoring the
> selection in the package list).  When I select one or more packages from
the
> package list then those packages' contents would be displayed.  I'm not
sure
> whether selecting nothing in the package list (if that's even possible)
> should mean "display all this folder" or "display nothing" -- I could make
> arguments in either direction, but it is the kind of thing where you have
to
> try both alternatives to find out which feels natural.

I ceratinly don't agree with the idea of display everything when nothing is
selected, since I think that would be inconsistent. As you yourself have
pointed out before, much of the Dolphin UI is about direct manipulation of
objects. In the package browser many commands operate on packages, and now
they operate on multiple packages. In a few cases the operation on multiple
packages leaves something to be desired, but the principle remains.
Selecting everything fits both with the idea of the package selector acting
as a filter, and as a means of grouping packages for manipulation. One can
easily refine the filter/package group to a single package with a single
click.

> The above (or some better scheme) achieves the same functionality as I
> believe you were aiming for, but does so without breaking the mental model
> of "selection" which is so fundamental to Windows.

Fundamental? I don't buy that at all, especially for multi-select lists.

>
> > This was a deliberate design decision and reflects a new hierarchical
way
> of
> > thinking about the organisation of the system of which this is only the
> > first stage. We've been working with it for some months now, and it is
> > "right" (in our opinion), so we are dead set against changing it,
> therefore
> > any arguments to the contrary will have to be convincing.
>
> I don't know whether I have succeeded in convincing you yet.  I'll witter
on
> for a bit more.
>
> Speaking for myself, my first thought when I saw the new behaviour was
that
> "something was wrong", but I couldn't articulate just what.  It has taken
> some days for me to be able to say what the underlying problem is.  If I'd
> been asked what was wrong before about yesterday, then I'd have been
forced
> into vague mutterings about "too many keystrokes", "not what I'm used to",
> etc, but really I'd just have been groping for a way to express a jarring
> disquiet, a less-than-half conscious outrage.  I'm guessing, but I
*suspect*
> that this is what has been underlying Bill and Ian's (and others? I can't
> remember) problems with the scheme -- what do you say, people ?

It sounds to me as if you are saying that the cosmetic appearance is
unfamiliar and upsetting. I wouldn't want to diminish that point, but apart
from reinforcing the notion of filtering within the hierarchy, the use of
the PB becomes much more fluid with the auto-selection when one is working
on hierarchically grouped arrangements of packages, since quite often one
wishes to apply commands against all the packages in a hierarchy.
Pre-selecting avoids the 'Select All' step.

> You said that you'd been working with it for some months now, and liked
it,
> and implied that our problems are caused by not having got used to it yet.
> With respect, I think that is backwards: if a bunch of intelligent users
> dislike a new pattern of interaction, and find it hard to intuit the
> underlying logic, then that suggests that something is wrong, and that you
> have been using the new interaction for so long that you no longer
perceive
> its problems.

That argument applies equally in reverse. It is new, and unfamiliar, and it
is natural to be predisposed to prefer what one already knows.

> Anyway, that's my best shot at explaining why I don't like the
> auto-selection.  I'll close a regrettably pompous post by repeating that I
> *like* what you are doing with the hierarchical stuff; I *want* the
greater
> power and control it will give me as a user; but I think that you have
made
> a small but rather important mistake in designing the user-interface to
the
> great new features.

Thanks for trying. The best I can promise is an option to turn it off
(especially since that is needed anyway in order to use the PackageSelector
component in situations where it is not acting as a multiple-selection
filter, but to select a single package).

Regards

Blair