http://developer.pidgin.im/ticket/2367 - 2.1.0 GUI

[Luke Schierer]

On Wed, Aug 01, 2007 at 07:05:06PM -0700, Sean Egan wrote:
> On 8/1/07, Andrew Roeder <correnthean at hotmail.com> wrote:
> > I do not demand a "full-sized" Icon Sean, I have not complained of the icons
> > on the buddy list, because -I don't use them and if they were larger then
> > they would create tremendous clutter for the buddy list- I'm also aware that
> > my icon is displayed at 32x32 on my buddy list, but I really don't mind that
> > since it is my icon, and I have no need at all to see it.  I'm merely trying
> > to convey that the current icon is just too small, and the old icons were at
> > times too large yes.
> 
<snip> 
> Let me share the idea as it existed in my head:
> 
> The tabs' job to let you quickly choose a buddy out of a list of open
> conversations. This is why I preferred it without status icons; I
> don't think they're appropriate there. The buddy icons might be more
> useful even, but I think status icons get in the way of the tabs' job.
> 
> The buddy list's job is to provide as much important, at-a-glance
> information about your buddies' status as possible, without offering
> too much, distracting information. If it achieves that goal, it should
> also be useful anywhere else important, at-a-glance information might
> be useful: e.g. the conversation window. That is why the infopane is
> rendered exactly like the buddy list.

Even with the small view, my buddy list is long enough that I sometimes
cannot see the entire list at once.  Beyond that though, many users
either because of multiple desktops or because of the way they use the
docklet, cannot see both the conversation window and the buddy list.  In
any of the three cases, the tabs provide a quick view of status for the
people you are most likely to try to reach: those you already have
conversations open with.

This rationale for having status on the tabs will hold significantly
less persuasive for those who have many tabs with people not on their
buddy list (and thus for whom the status information is less reliable or
not at all available).

<snip> 
> 
> I realize I'm not, by any stretch of anyone's imagination, a usability
> expert. I also realize that Pidgin's UI both here, and in almost every
> other aspect, is far from perfect.
> 
> I *do* think it's getting much, much better, and that introducing and
> testing different interface approaches is the only way to find out
> what works the best for the most people. While I sound antagonistic
> and defensive, I welcome all the criticism (except for the
> protocol-icon-in-buddy-list people. They got annoying).

I agree whole heartedly here.  In fact, my most common reply to the
protocol icons in the buddy list crowd was "Please wait a release or two
and if you still do not like this, complain *then.*"  I know that
people, myself certainly included, tend to have a knee-jerk reaction
against change, and the longer *we* (I don't care about other IM
clients) have done something, the stronger that reaction is.  Waiting to
complain generally ensures that your (or my) reaction is reasoned and
legitimate, and thus is more likely to influence us. 

> 
> I'm definitely willing to compromise (as I've done with a bunch of the
> infopane before release), but this irrational ideal seems appropriate
> to me, and I think what we have now is a good implementation of it.
> 
> > Really in this aspect, it is Pidgin's fault this space is not used, I don't
> > have the option to use it, therefor it is the designer and program's fault,
> > not mine.  And obviously I don't want pidgin stretching out icons across my
> > toolbar, I specifically want more icons and options easily available.

>From the replies I saw to this, it appears that we are being requested
to detect roughly how big the window is, and display more or less
information in it, and at different sizes, depending on the size of the
window (ie larger buddy icons in larger windows).  If this is not what
is being requested, there is a fundamental problem that the replies I
saw indicate.

We *must* target *some* window size.  Anything smaller than that size
will fail to display everything (notice that at very narrow widths, the
buddy list ends up with horizontal scroll bars and the menus get cut
off),  and anything larger than that size will have empty space
proportional to the amount the window has grown.  This is unavoidable.

Sean's comparison to webpages is particularly sound here, but you also
see the same thing in many desktop programs, where if you increase the
width, you will find that the menu items either have more space between
them (lots of empty "wasted" space between buttons) or more frequently
have a significant amount of space to the right of them (which could be
called "wasted" space by the definition I've seen in this thread).  

> 
> It wasn't clear that you wanted more icons. What toolbar features,
> specifically, do you (and others) think are worthy of a first-class
> spot on the toolbar?
> 
> I'd, for one, argue that "Reset Formatting" doesn't belong there at all, even.
> 
> > I don't really understand this question. I was saying that I do not need
> > descriptions at all for my buttons, the icons are enough, and the
> > descriptions currently lengthen the size of the buttons.

The biggest complaint I have seen is the extra clicks necessary for
inserting a smiley.  This would be particularly noticable for those
protocols that have so many smileys that it is pointless to try to
memorize them all.  

I would agree that "Reset Formatting" exists primarily because of the
bug we have had where when you paste formated text, the formatting
sticks around.  If we believe that bug to be fixed, then by all means
move that button to the font menu.  

> 
> Again, I apologize. It wasn't obvious to me you were asking for more buttons.
> 
> > I've touched on this before in GUI related topics, but why is it never
> > considered that GUI configurability should be much more than "feature
> > on/feature off"
> 
> There are *tons* of reasons that Pidgin developers and users find very
> convincing.

The same logic that I have used in arguing against "skins" applies to
having a significant number of options about the UI design.  Experience
amply proves that users will turn things off and not remember doing so,
turn them off accidentally, or otherwise confuse themselves.  A
practical *recent* example of this is the plugin out there that allows
you to turn off the menus in the buddy list.  We have had a number of
bug reports that stem from this plugin, people have turned of that menu
only to (belatedly) realize that they really do need it, but without
knowing how to turn it back on.  Historical examples include, but are
not limited to, a plugin that would iconify a conversation window when
you send a message.  It was useful to people who wanted to close
conversation windows all the time, but did not want to interupt the
logs, a compromise behaviore of sorts.  Unfortunately, it led to a huge
number of bug reports about gaim (at the time) automatically closing
people's conversation windows.  

Along the same lines, but not as obviously, options have a cost in the
ability to support a program.  Some bugs only happen with specific
combinations of options, the more options, 1)the more such bugs 2)the
harder to track them down.  Other times, it is simply that the plethora
of options has led the user to not notice that we have already
implemented the functionality they are looking for.

Skins make all of this worse by (effectively) turning things on and off
as a function of appearance, and not as a function of discrete actions
(such as clicking a series of menu options or preference checkboxes).
They also have other problems that need not be addressed in this thread.

The long and short of it is that the GUI *cannot* be endlessly
configurable.  At the same point, it is also useful to too few people if
it has *no* options.  Finding the right balance between too many and too
few options is VERY HARD, and is something we have been struggling with
for years.

luke