On Wed, Jun 01, 2005 at 03:56:50PM -0500, Marcos Pinto wrote:
> > This is going to be blunt. that was a STUPID thing to do. How many
> > times must we tell people that cvs is NOT ready for general use?
> i have no problem with bluntness. :-) i was *not* thinking of doing a
> release of gaim 2.0.0 before it's finished. this was nothing more
> than a test case for me to gage things (which was why it was only
> installed for a few users) and i thought that you might also like some
> feedback. trying to do you a favor here, luke. because of my
I understand and appreciate the attempt, its just horridly premature,
and I'm shocked that you didn't realize that before proceeding. I'm
also more than a little upset, because there is a huge tendency in
normal users to see something labeled beta, or even more so something
labeled "cvs" since they won't understand what cvs is, and form
impressions that will continue even after massive changes have taken
place to bring it to a release-ready point. We saw this with the
wingaim alpha releases, so many of the responces clearly were looking
for a finished product, and some of those users will not seriously
consider gaim again because we made it available to them before we
were ready to try to provide that.
> findings i now plan to write a guide about the changes to gaim to hand
> out to the employees when the upgrade occurs. that way, when they
> have a problem or find something different, they'll have a place to
> very easily look up a solution. in fact, i'd be more than willing to
> give you the guide once gaim 2.0.0 freezes if you want to put it on
> your site or something.
when we get FAR FAR closer to a freeze, this sort of testing, and the
guide that would come out of it, *would* be useful. And it *would* be
something that I would look at putting in the documentation section
of the website with a link to it in the release announcement.
> > That's interesting, but not entirely unpredicted. When we removed
> > the button bar, I suggested we move the "send" up to the right of the
> > input widget, just as the buddy icons are currently to the left of
> > them. I wonder why this is though, since it is so much more
> > efficient to use a key stroke to send.
> i'm pretty sure none of the users even use the "send" button. it's
> just something that confused them when they saw that it wasnt there.
> i like your idea of having "send" to the right of the input widget.
I'd wonder. It'd be worth looking over people's sholders. I know my
mother, who surpisingly does use IM (though primarily to see if my
brother, way at college, is available for a phone call or not), is
consistently confused by the send button exactly as Sean describes.
For that reason, sean's position is something that I have significant
sympathy for, though I am not sure how to make this change more
obvious and intuitive for people who are used to seeing a send button.
> > I'm not surprised. this is unfinished, it should not be loosing away
> > messages like this when we release. BUT YOU KNEW IT WASN'T FINISHED
> > BECUASE WE'VE BEEN SAYING IT IS NOT READY FOR GENERAL USE SINCE WE
> > FIRST BRANCHED. so you KNEW that users were going to hit this, and
> > that it wouldnt' be intuitive, BEFORE you did this to your users.
> yes, i did know and i wasnt surprised in the least. i was not
> planning on rolling out gaim 2.0.0 before release even if the small
> group ran into zero problems. again, and i'm not sure how else to say
> this, it was simply a test case and i thought you might like to hear
> some feedback.
> > some things you didn't note: preferences, as a ui, are horridly
> > broken, esp. if you enable plugins. There are some issues upgrading
> > new accounts, under unknown circumstances, the first time an account
> > signs on with 2.0.0cvs, sometimes the buddies will appear to be
> > groups. under unknown situations, preferences aren't saving. under
> > partly understood situations, draging or closing tabs will cause a
> > crash. other issues are listed at gaim.sf.net/gary/bugs.xml
> this wasnt brought up because most of my users arent the type to look
> at a program's preferences. like i said, these are the typical joes.
This highlights the importance of things Just Working, and setting
good defaults. While my first thought is that this thought also
undermines the idea of prefs slashing, on second thought, I think it
makes the idea of few preferences more important. If the user *is*
forced to go into preferences for some reason, too many preferences
will confuse them, and further, as I've seen in the past (ie the hide
on send plugin), they'll forget what they changed and think they are
still using the defaults.
> > Further, I've seen your name on this mailing list before, so you
> > probly saw the LONG threads on the usability of the ui, and what it
> > should look like. So you saw Tim's proposed, and generally liked,
> > modifications to the ui at sean/status.php, which also have not been
> > implemented yet.
> i'm not talking about what *i* liked and disliked here. i'm a fan of
> what's been done. i'm talking about how normal users react to what's
> been done, which is why at the end of my last email i stated that i
> didnt know which type of userbase you were aiming for, but hoped you
> could find my information useful. if you dont find it useful, then
> that's fine with me. no loss on my end
eventually your users would provide a valid test case. But not yet.
There is simply too much to be done to get an accurate impression
from anyone who doesn't already *know* what parts of the UI are
unfinished and transient.