RE: prev/curr/test

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

> -----Original Message-----
> From: Brian Keener [mailto:bkeener@thesoftwaresource.com] 
> Sent: Tuesday, March 26, 2002 12:02 PM

> Sorry guys,
> 
> I still like the idea of keeping Prev,Curr and Test but as a 
> means of limiting 
> the maximum version I want to see - IE if I didn't select 
> Test I won't see any 
> test but I will see prev and Current. 

That's an approach that could be taken. I think it will confuse people
more: "Jason said a new postgresql was available, but I can't see it".
That's just my 2c of course.
 
> Then I suggest we do away with the Source Box and nix the 
> idea of a bin box and 
...
> (retrieves installed src), retrieve 1.4.4 bin&src ...
 
Ouch. I'm going to put my iron-fisted maintainer hat on here:
There is no way that GUI code structed like that is going
into setup.exe for the following reasons:
1) That increases the number of clicks to install a given version by 2
to 3 times.
2) It is no more nor less clear than what we have.
3) We started off with that sort of approach... and it does not work
well.

Modal design - which that is an extreme example of - is easy to pick up
and use, but almost impossible to use fast or effectively.

Look back in the mailing lists, the majority of the pre-categories
questions where about "why is it so *hard* to get setup to do what I
want to". Not "How do I get setup to do what I want".

While your suggestion solves the current "how do I" questions, it does
so by reverting to the "why is it so hard" behaviour.

I think we are a little hard to use, and that needs to change, but not
by swinging all the way back.

And please note: 
you actually have *two* proposals (1- curr and test limit to become
upper limits on whats visible and 2- have a click-forever approach)
here. It would probably help your case to address them separately.

Rob