|laziness, impatience, and hubris|
My Perl-ish Neo-Gavinist Manifestoby InfiniteSilence (Curate)
|on Apr 01, 2017 at 20:04 UTC||Need Help??|
A few people sent me messages via the Message Inbox that I could see under the 'Chatterbox' heading. More than once I admit to not using this messaging feature (even when I saw messages in there for me) because I sort of hate looking at that screen.
Clicking on it shows what I can best describe as one of the most confounding utilities on this or any other website I frequent. And it is the reason for this meditation.
When I normally look upon it I am immediately confronted with what appear to be checkboxes selected for me. This is not helpful. It says, 'Showing messages ' and then appears a 'From' and a 'To' checkbox immediately following. It is not obvious if I am supposed to select something else and under what circumstances I would have to do so (this feels particularly pressing when there are no messages for some reason). When I experiment and click on the 'From' checkbox it does not automatically de-select the 'To' one. After some thinking about it I realize that it would show both messages from and to me. It would have been far easier to have something that allowed me to see 'All Messages' even if offering such an option would be redundant.
The next line has yet another checkbox next to 'not' in parenthesis with yet more options: Inbox, Archive, Deleted, all with parenthesis but some with what appear to be counts. There is yet another line that reads, 'constrain by content' which is apparently some way of saying, 'filter by,' followed by the ability to additionally filter by a user box which is not even a drop down list of user identities (minimally it could contain the users who have sent me something). This text is all in the English language which means it is to be read from left to right. When my eyes dart to the beginning of a line I should never have to guess what is going to be on that line. Think about it -- when reading a book every line you read tells you, using context clues, what you are about to read next. Webpages are no different.
For years I would develop forms just like this one. I would say that if the user did not understand my interface it was because they were too stupid to understand it. I was wrong.
Gavin in Gavin-ish
The term 'Gavin-ish' does not exist. I made it up. It is a term derived from the name Gavin, for Andy Gavin, co-creator of and developer of the successful Crash Bandicoot and Jax and Daxter video games for the old Sony Playstation 2. I do not think Andy is a Perl hacker at all. One of his posts called scripting languages 'toy' languages. Andy was a Lisp enthusiast who, in his own words, forced his game developers to use his Lisp engine to develop games. His website has an entire series on this. You might be wondering why in the world I would promote such a person here on this forum. Because I think some of the things he said about producing games are relevant for developing software as a whole. It certainly changed my outlook quite a bit. Here is the excerpt from his writing that I found most compelling:
"...This is because games are all about gameplay, and good gameplay only comes from constant experimentation with and extensive reworking of the code that controls the game's objects."
Take away the word 'game' and replace it with 'UI experience.'
So in my quest to be a better coder I've started subscribing to this Neo-Gavin-ist philosphy (Neo because Andy is a Lisp and perhaps now a Ruby coder and not a Perl one). I now believe that UI design is about clarity and exhibiting both thoughtfulness and an assurance that a user's actions will result in proper/predictable outcomes.
Consideration for things like spacing and grouping are not optional and must be used judiciously; size, color, emphasis, and even font choices are all relevant. Useless things should be removed (for instance, empty parenthesis...?) to enhance clarity. Rework of this type and kind Andy used to make some truly revolutionary games despite seemingly fantastic obstacles (memory constraints, unhelpful equipment vendor, etc.) and the same should be the goal for any UI.
Granted, most of us are not making games. True, this type of rework takes time unless you have tools that do a lot of the heavy lifting for you. But doing nothing is just that and has a predictable and undesirable result. We can do better.
Join my movement. Agree that UIs must subscribe to the philosophy of constant experimentation and rework for improvement irrespective of whether the underlying language is Perl or some other. Then develop better UIs, toolkits in Perl to make it easier to crank them out, and share your comments on this here.
Celebrate Intellectual Diversity