Re: The Trunk: SMLoader-cmm.85.mcz -- SqueakMap Installable packages / installed packages display

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: SMLoader-cmm.85.mcz -- SqueakMap Installable packages / installed packages display

Hannes Hirzel
On 9/15/15, Chris Muller <[hidden email]> wrote:

> After review and some thought, it has become clear to me that Dave's
> change is incorrect.  Please take a look at the SqueakMap filters and
> consider them from the context of the use-cases -- what users need to
> do with SqueakMap, and NOT from the context of a database that needs
> to produce generalized "query results" <---- because it doesn't.
>
> "Published" are the ones which have software to install, while
> "Auto-installable" shows only packages that are installable from the
> "Install" menu selection within the image.  These two filters are
> useful together in a restricting fashion, not an inflating one, so
> that newbies can see what's ready to go.
>
> It was then that I also realized that Hannes' combination was not a
> use-case either.  The use-cases we have are:  1) user wants to install
> software or, 2) user wants to see what they have already installed.
> Seeing a cumulative list of both installed and uninstalled satisfies
> neither use-case.

I disagree.

>From a user interface perspective the problem lies in the fact that it
allows me to _select_

1) show installable software
2) show installed software

at the _same_ time.

Then
I expect to see the set of installable software unified with the set
of installed software.

What is implemented corresponds to check boxes. What is implemented is
radio buttons behaviour. But the radio buttons do not work as it is
possible to have more than one buttion active at the same time.
Cumulative selections should not be allowed. At the moment they are.

The behaviour of the GUI is not what is expected. Some people actually
do call this a bug.

> Nevertheless you may once again "Clear all filters" (which was broken
> by Dave's commit) if you want to see everything.
>
> I still say SqueakMap catalog can and needs improvement,

+1

 but we need
> to really consider our changes because its clear that Göran put a lot
> of thought into the usage of SqueakMap and its role in the community;

Yes, he did but but this surely not the right spot to illustrate this point.

The GUI seems to be abandoned as of now. I think it is worthwhile to
fix obvious issues.

> so I think we can afford to be a bit more skeptical before thinking
> something like that was a bug in the first place and for nine years
> running..

There could be other reasons for no change in 9 years
a)  Not many people use it and see it as a legacy app which does not
need to be fixed.
b) Idiosyncrasies are accepted as other parts of the GUI have similar problems.

The fact that there was no change in 9 years is not an argument for
the quality as such as you easily can imagine.

>
> On Tue, Sep 15, 2015 at 2:58 PM,  <[hidden email]> wrote:
>> Chris Muller uploaded a new version of SMLoader to project The Trunk:
>> http://source.squeak.org/trunk/SMLoader-cmm.85.mcz
>>
>> ==================== Summary ====================
>>
>> Name: SMLoader-cmm.85
>> Author: cmm
>> Time: 15 September 2015, 2:58:07.033 pm
>> UUID: 21a75b8d-4a1b-49c8-8f82-fbbd74fae96b
>> Ancestors: SMLoader-dtl.84
>>
>> Revert dtl.84, because it broke the Catalog filters.
>>
>> =============== Diff against SMLoader-dtl.84 ===============
>>
>> Item was changed:
>>   ----- Method: SMLoaderPlus>>packageListCalculated (in category 'lists')
>> -----
>>   packageListCalculated
>>         "Return a list of the SMPackages that should be visible
>>         by applying all the filters. Also filter based on the currently
>>         selected category - if any."
>>         ^ self packages select: [:p |
>> +               filters allSatisfy: [:currFilter |
>> -               filters anySatisfy: [:currFilter |
>>                         currFilter isSymbol
>>                                 ifTrue: [(self perform: currFilter) value:
>> p]
>>                                 ifFalse: [self package: p
>> filteredByCategory: (map object: currFilter)]]]!
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: SMLoader-cmm.85.mcz -- SqueakMap Installable packages / installed packages display

Chris Muller-4
On Tue, Sep 15, 2015 at 4:24 PM, H. Hirzel <[hidden email]> wrote:

> On 9/15/15, Chris Muller <[hidden email]> wrote:
>> After review and some thought, it has become clear to me that Dave's
>> change is incorrect.  Please take a look at the SqueakMap filters and
>> consider them from the context of the use-cases -- what users need to
>> do with SqueakMap, and NOT from the context of a database that needs
>> to produce generalized "query results" <---- because it doesn't.
>>
>> "Published" are the ones which have software to install, while
>> "Auto-installable" shows only packages that are installable from the
>> "Install" menu selection within the image.  These two filters are
>> useful together in a restricting fashion, not an inflating one, so
>> that newbies can see what's ready to go.
>>
>> It was then that I also realized that Hannes' combination was not a
>> use-case either.  The use-cases we have are:  1) user wants to install
>> software or, 2) user wants to see what they have already installed.
>> Seeing a cumulative list of both installed and uninstalled satisfies
>> neither use-case.
>
> I disagree.
>
> From a user interface perspective the problem lies in the fact that it
> allows me to _select_
>
> 1) show installable software
> 2) show installed software
>
> at the _same_ time.

Sure, but those are *filters* you've selected.  Filters are things
that only remove, they don't add...

> Then
> I expect to see the set of installable software unified with the set
> of installed software.

Please read the balloon help on those filters you selected, they
decribe their behavior and are performing it correctly.

There is actually a plausible use-case for that combination of filters
you selected:  to show the user the software that is either not
installed or is installed but can be upgraded because there's a newer
version available.  That's actually sounds useful..

> What is implemented corresponds to check boxes. What is implemented is
> radio buttons behaviour.

No it isn't, because you can have multiple filters in place at once,
which we see satsify meaningful use-cases.

> But the radio buttons do not work as it is
> possible to have more than one buttion active at the same time.
> Cumulative selections should not be allowed. At the moment they are.

I had actually started an implementation to "group" the filters into
groups of radios that would cause others in the same group to be
unchecked.  That forced me to consider all the use-cases and that's
when I realized the purpose of the existing filters.

> The behaviour of the GUI is not what is expected. Some people actually
> do call this a bug.

Reading the balloon help provided by those filters actually helps to
understand why its not a bug.  Please check that out.  And, why do you
want to see Installed and Uninstalled all in one list and why not just
"Clear all fiters" to do that?

Best,
  Chris

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: SMLoader-cmm.85.mcz -- SqueakMap Installable packages / installed packages display

Chris Muller-3
Although changing that allSatsify to anySatisfy is not the right
solution, I think you are on to something about the UI.  It shouldn't
be confusing, but it is, isn't it?  I remember now that those filters
have confused me before, too, exactly the same way.

Maybe we should revamp the filters and possiblly even make them radio
buttons to really suggest the correct pattern of usage..?

Instead of "Safely available", etc., maybe we should just make it
simple and have something like, Installed, Compatible, and Latest..?

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: SMLoader-cmm.85.mcz -- SqueakMap Installable packages / installed packages display

Karl Ramberg
+ 1
The filters are for advanced users.

Karl

On Wed, Sep 16, 2015 at 3:56 AM, Chris Muller <[hidden email]> wrote:
Although changing that allSatsify to anySatisfy is not the right
solution, I think you are on to something about the UI.  It shouldn't
be confusing, but it is, isn't it?  I remember now that those filters
have confused me before, too, exactly the same way.

Maybe we should revamp the filters and possiblly even make them radio
buttons to really suggest the correct pattern of usage..?

Instead of "Safely available", etc., maybe we should just make it
simple and have something like, Installed, Compatible, and Latest..?