[Pidgin] #4986: automatic chat input field resizing should be optional, regression from 2.3

[Pidgin]

#4986: automatic chat input field resizing should be optional, regression from 2.3
---------------------------+------------------------------------------------
  Reporter:  swbrown       |       Owner:                   
      Type:  enhancement   |      Status:  reopened         
  Priority:  minor         |   Milestone:                   
 Component:  pidgin (gtk)  |     Version:  2.4.0            
Resolution:                |    Keywords:  chat input resize
   Pending:  0             |  
---------------------------+------------------------------------------------
Comment (by DSK):

 [and another user having registered for the sole purpose of complaining
 about this 'feature'][[BR]]
 Why is it that you want to _force_ such a change of one of the most
 substantial elements in an IM on your users? The current behaviour is a
 misfeature because of several reasons:

 > A program should follow the `Law of Least Astonishment'. What is this
 law? It is simply that the program should always respond to the user in
 the way that astonishes him least.
 >[[BR]]
 > A program, no matter how complex, should act as a single unit. The
 program should be directed by the logic within rather than by outward
 appearances.
 >[[BR]]
 > If the program fails in these requirements, it will be in a state of
 disorder and confusion.

 [http://www.faqs.org/docs/artu/ch11s01.html Another article on the
 principle of least surprise]

 It absolutely goes against the principle of the least surprise. I will
 expect, that an area in which I can enter text, to be static. I will
 expect that, because it is just like that in every other program there is
 out there, and has always been. And even before that, when we still had to
 write on paper, the area in which I could write was static in size.
 Principally users will see all input fields the same - be it in an editor,
 e-mail client, mobile phone, or an input field in an IM. And I _never_
 ever would want my editor to just resize itself in the progress of
 writing.

 > It's a consequence of the fact that human beings can only pay attention
 to one thing at one time (see The Humane Interface [Raskin]). Surprises in
 the interface focus that single locus of attention on the interface,
 rather than on the task where it belongs.
 The primary task while working on any arbitrary input area is writing.
 There might be the additional task of reading what has been previously
 written. Now with an automatically resizing input field, there comes the
 additional task of refocusing because the input area suddenly grows and
 thus the chatlog area shrinks - maybe making stuff I was currently reading
 disappear. And now it has completely destroyed my flow of work. I have to
 scroll up again, which in itself already needs the task of moving away my
 hand from the keyboard to the mouse, and back - and alas! You've got the
 user completely annoyed. Probable solution there would be to make the
 chatlog area stay the same size and make the window itself grow. [Just the
 idea of that just makes me shrivel, apart from maybe not even being
 possible programmatically.] Now the program gets absolutely intrusive,
 maybe blocking the view of what was behind the chat window, doing
 something completely unexpected, in expecting to be the only program
 that's running - no good. In no way.
 Furthermore, you're being absolutely obstrusive in expecting to know what
 the users want. Or, even worse, expecting the users to not know what they
 want - making them feel stupid, or incapable of making decissions of their
 own.[[BR]]
 If you feel like providing a user with a special, and extraordinary
 feature - give them an option field to turn it on [_opt in_]. _Too_ many
 options might be a bad idea because they might overwhelm the user, when
 not being presented in a way that will make him feel like having a lot of
 control without having to do much. And users - being mostly human as of
 yet, love control. Everything else will make him/her feel constricted. And
 Pidgin is far from having too many options. Users like to be able to tell
 a program how to behave.

 Here another article that might be interesting for you:[[BR]]
 [http://www.osnews.com/story/6282/The_Command_Line_-_The_Best_Newbie_Interface_/]
 [[BR]]
 Derived from that article, you will see that users like to work with
 something that is less intelligent than them. Not behaving less
 intelligent, as in not being able to tell exactly what the user wants.



 You're putting a Sisyphean task on yourself there, chasing to improve your
 implementation in trying to reduce the ways in which the autoresizing
 input field can behave in a way that would be unpleasent for the user,
 probably introducing other ways in which that will be the case; trying to
 make an extraordinary feature suit for everybody. DWIM is not feasible
 yet. Yet. Do a decent implementation of a DWIM interface, and I - and
 surely all other people, will go happily along. But trying to do that -
 no, sorry; trying to force that on users, as in giving them no other
 choice than to use that anti-feature - when there has been a most
 reasonable and satisfactory solution for that all along - let the user
 decide on the size of the input field, and let it be static - is not
 something to go with.

 > And if a feature just does not seem sensible, do not be afraid to throw
 it away.

 DSK

-- 
Ticket URL: <http://developer.pidgin.im/ticket/4986#comment:233>
Pidgin <http://pidgin.im>
Pidgin