Ah. That's something I can learn from. If you think I lost important
information on the way, let me know.

[packages shouldn't disappear when I update the Squeak version, and
generally, being hidden is not a good response to being
not-version-approved, because it doesn't suggest the obvious options
(like take the risk anyway, or not)]
The initial logic behind filter was - it should basically show you
packages that can be installed easily and are very likely to do no harm.
More experienced users will remove protections/filters as they wish.
Therefore, don't show a package that's already up to date, don't show a
package that can't be autoinstalled, and don't show a package that's not
certified for the current version. It's consistent, if the user knows
that logic.

The problem is, that logic is NOT self evident to all users (could you
imagine that? ;-) at all times (when changing versions).

[Show version compatibility in bold, installation status in italics]
Does make the information more available, at the cost of stylistic
clutter. 

I am a little loath to change the default filters, because it would stop
presenting a completely safe and simple state for newbies. Or maybe I'm
wrong about this. Below is an alternative suggestion.

It seems to me that part of the problem is that the state (filter
combination) is hidden most of the time (only accessible by explicitly
bringing up the menu). If it were constantly visible, as soon as you
can't find a package you expect, you'll see the explanation, and prod
the system to give you what you want. Say, a text box at the top saying
"Showing only package that are compatible with 3.6 AND are automatically
installable AND for which you don't have the latest version installed".

For the people that have stubbed their toes on this, would this solve
the problem? Should the default filter state change anyway, and let the
new comer see everything until he says different?

Daniel

Andreas Raab <andreas.raab at gmx.de> wrote:
> More user friendly:
> Rule: Be consistent. In our case it means, don't confuse people who know a
> package is there by not showing it to them as they update to a new version.
> SM hasn't changed when you updated. Same for installing a package - if the
> metaphor is that "we see SM" then don't remove the installed packages. SM
> hasn't changed by installing it.
> Rule: Don't try to be "overly smart" if you can assume a halfways
> experienced audience. In our case, we can assume that if we tell people that
> package vX has not tested with Squeak vY they will understand that there
> *may* be problems (in many cases there will be none). Therefore, rather than
> just filtering make it easy to see "what you approve of" and what you don't.
> 
> For example: By default, show all packages (or at least show a _consistent_
> set of packages). Display those which were designed for your local Squeak
> version as bold (to emphasise "those are the ones we approve of"). If you
> try to install any of the others put up a warning saying "This packages has
> not been designed for your version  of Squeak (X.y). Installing it may cause
> trouble and you should only try to if you have saved your image (in case
> anything goes horribly wrong). Do you want to continue installing package
> XYZ?". In addition, if SMLoader is one of the primary UIs we use for dealing
> packages it should show us that the package is *installed* rather than
> *absent*. Consider displaying installed packages italic or adding a check
> mark in front of it or something like it.
> 
> Note: None of the above prevents you from using filters - for those people
> who've learned how to use them. But I think that for most people the way the
> package loader works right now is quite confusing. For me, the most
> confusing part is if I look for a package I *know* is on SM and can't find
> it. Reason?! Because I have installed it already! Very, very confusing.
> 
> Cheers,
>   - Andreas