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

[Andrew Roeder]

>From: Hylke Bons <h.bons at student.rug.nl>
>To: Andrew Roeder <correnthean at hotmail.com>
>CC: devel at pidgin.im
>Subject: Re: http://developer.pidgin.im/ticket/2367 - 2.1.0 GUI
>Date: Thu, 02 Aug 2007 13:34:19 +0200

>I'd like to react to your points in
>http://developer.pidgin.im/attachment/ticket/2367/pidgin201gui.jpg
>You call the status icon in the infopane redundant, but it is the icon
>in the tab that is redundant.
>The rest of the infopane you call wasted space, while it is the exact
>same code as used in the buddy list, so
>why isn't that a waste of space? Also status messages and special
>emblems are shown here, so it's certainly not wasted.
>The conversation window was made with the future in mind, so it could be
>used better with plugins and possible Voice Video support.
>As for the buttons, I really don't think the texts are a waste of space.
>I don't see one other example in Pidgin's GUI where the icons are used
>  without text and I don't think the icons on there own are clear enough
>to be used "standalone". Maybe it's an idea to place the text beneath
>the icon.
>Now about the buddy icon, making that bigger would waste more  (height)
>space.

The icon in the chat tab I find not redundant based on that it allows you to 
assess -all- statuses of the users you currently have chats open with, 
rather then just the one that has focus.  Often I find that while I'm 
talking to one user, others will go away or idle, and then I know I can end 
their conversation, the icon on the tabs letting me do so without ever 
expanding the buddy list.

The space given could already support a 45x45 icon without sacrificing 
anything, and if I was correct and 50x50 is the smallest icon of the 
protocols, I don't see much difference in a 5 pixel expansion, especially if 
this bar -is- to be eventually utilized for more features and information.

> > Font ⌄ | Smiley | Link | Image
> > Seems right to me, very small space usage(especially if only icons are
>used.) and is the "one click" solution.
>
>I understand why you'd want the "Reset font" in the font menu, and I
>agree with you.
>But then I don't understand why you want to "explode" the insert menu.
>It's about inserting something, and not all protocols support every
>option in there, so with your lay-out
>  buttons get grayed out when not supported, and that would mean, yes,
>more waste of space. :)

I don't see this as a large difference between graying the option out under 
the menu, or graying the button out on the toolbar.  If in fact the "button 
descriptions" were removed from the toolbar, then it would be easy to 
maintain the current goal window size without causing users to lose buttons 
when they resize the window.

>That space could better be used by plugins or "Info" etc. But I think
>the reason it was made less wide is because people complaining
>  that the toolbar was too wide and buttons were "cut off".
>I think the toolbar should have the most common options supported by
>different protocols.

This is true but it needs to be maintained that the GUI of Pidgin needs to 
compete with each protocol's native client in terms of an "easy UI", users 
of those protocols migrating will always gripe if they must take extra steps 
to accomplish an action.

>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.

>luke

First I would like to reimpose, that the "Reduction of bug reports, by 
unimplementation/removing/displacing of features because some users(bad 
users) enjoy playing with options they know nothing about" is very poor way 
to resolve the issue.

It has long been overdue for Pidgin to have a breakdown of its features by 
GUI/Description/usage in a pseudo manual form, if users could easily browse 
through a wiki or hierarchy manual to get "Literal descriptions and 
screenshots of its purpose."  I think this could be easily accomplished by 
allowing the community to have a direct hand in its editing, In my opinion 
this would be necessary since Pidgin's development is rather fast with 
constant changes and improvements.

Having such would allow a better backbone for users who have problems to 
resolve them themselves, if a user is willing to fill out a bug report, my 
supposition would be that they would be willing to find the answer 
themselves if it was more easily available.

>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.

_________________________________________________________________
More photos, more messages, more storage—get 2GB with Windows Live Hotmail. 
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507