Always focusing in end users’ needs, Martin is our VP in user experience. Besides staying on the cutting edge as regards new technologies, he is particularly interested in applications related to medicine and humanitarian aid, subject on which he is writing his master thesis in Computer Science at UBA.
Let’s face it: as a developer, I’m lazy. I just want to write just enough code. What is more, I want to reuse it whenever possible. I want it to be abstract.
If I’m asked to implement a view which needs a sortable grid, one of those whose rows you can sort by any column by clicking on it, I’ll either make use of any sortable grid widget available in the project’s UI framework of choice or build sorting functionality into a regular one. No matter the choice, I would end up with a grid widget that sorts strings lexicographically, dates chronologically and numbers… well, you get the idea.
Sounds reasonable, doesn’t it? Yes, it does… in general. In general means that statistically it IS the desired behavior, provided that we know nothing else about the context of use. If we don’t focus on the task we’re trying to help the user accomplish, if we don’t wear her shoes, we risk ending up happy with our reusable grid at the cost of making it less usable.
Let’s take a look at an example of a team which clearly cares for its users:
The grid in iTunes music library, sorted by song name
So, let’s see. Name is a string field, then we should sort it lexicographically… wait a minute! If it’s in lexicographical order why is it that “5 – In Your Eyes!!s” is placed between “05 – Heartbreaker” and “05 – Intermedio (JadeI)”? Because it makes sense in this context.
Odds are I don’t care whether the track number starts with zero or it doesn’t. By discarding the general approach to sorting strings, the iTunes’ team made its users’ experience a little bit more pleasant. And, at the end of the day, all those little details add up to make an overall satisfactory experience.
Now, if you ask me, at least when I sort my list by song name, I usually don’t even care about the track number and whichever other characters prefixing a song’s title. I would even ignore all those characters and start sorting by the first alphabetical character. But I can’t assure most iTunes users would agree with me. Maybe it’s a good example of a decision you would like to make based on the results of usability tests.
To sum up, if you’re a lazy developer like me, don’t let your appetite for abstraction and reuse leak into the user experience. Less is more, except sometimes when more is more!
Don’t make me think is a great book about usability and interaction design written by Steve Krug. One of the best things about it is that Steve has used the very same principles he preaches at in his book in the design of its reading experience. The book goes straight to the point, focuses on a handful of very clearly stated ideas and can be read in just a couple of hours!
I don’t mean this post to be a review of Don’t make me think, it’s just that it was the first thought which came to my mind when I received the following “update email” from a very well known group mailing system:
Who’s the new member? Do I know her? Wouldn’t it make sense to be able to see some of her profile info right there, without needing to go to the group’s home page? Why do I have to make an additional step to get that info? Don’t make me work more than what’s strictly necessary!
By the way, “geochatUsers-Geochat Users Community” is a link, but you just get to know that once you hover over it and your mouse cursor turns into a pointer. I remember having got this wrong in my own developments countless times: links which don’t look alike links. Don’t make the user think! If there’s something that she can click or act over, it has to be apparent. That’s what designers call affordance: it’s what an object’s appearance, smell, texture, sound, etc, tells us about what we can do with it.
Last but not least, when I clicked the link I had to manually log in before being able to enter the group’s home page. The group mailing system already knew it was me (or it could have easily known it), because I clicked the link from my email box. That takes us to another principle: user input is sacred, don’t lose it nor ask more of it than necessary.
Have a nice week!
I’m currently in the process of upgrading an application from Rails 2 to Rails 3. Fortunately, it’s not the first time someone does so, and there’s plenty of resources throughout the web that will help you to work it out. In particular, I chose to follow the steps demonstrated by Ryan Bates in an outstanding series of three railscasts, titled Upgrading to Rails 3 (Part 1, Part 2, and Part 3).
Everything was going smoothly, until while trying to get my functional tests to pass I got the following error:
test_should_decode_a_message_with_a_plain_code(DecodeControllerTest):
RuntimeError: @routes is nil: make sure you set it in your test's setup method.
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/actionpack-3.0.5/lib/action_controller/test_case.rb:388:in `block in process'
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/actionpack-3.0.5/lib/action_controller/test_case.rb:386:in `each'
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/actionpack-3.0.5/lib/action_controller/test_case.rb:386:in `process'
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/actionpack-3.0.5/lib/action_controller/test_case.rb:47:in `process'
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/actionpack-3.0.5/lib/action_controller/test_case.rb:355:in `post'
test/functional/decode_controller_test.rb:67:in `block in '
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/activesupport-3.0.5/lib/active_support/testing/setup_and_teardown.rb:67:in `block in run'
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/activesupport-3.0.5/lib/active_support/callbacks.rb:428:in `_run_setup_callbacks'
/Users/mverzilli/.rvm/gems/ruby-1.9.2-p180/gems/activesupport-3.0.5/lib/active_support/testing/setup_and_teardown.rb:65:in `run'
As usual, I resorted to allmighty Google looking for “@routes is nil”, since “someone must have already stumbled upon this before”…and no luck. So I started comparing some of the files in my upgraded app with their correspondent files in another (working) app which had developed using Rails 3 from scratch. I found out there was a slight difference between both “test_helper.rb” files:
require 'rails/test_help'
That line was present in the Rails-3-from-scratch app but not in the one I’m upgrading. Then, I just added that line and the “@routes is nil” error was gone. I should have payed more attention, because when running rake rails:upgrade:check, I was getting the following warning:
Deprecated test_help path
You now must require 'rails/test_help' not just 'test_help'.
More information: http://weblog.rubyonrails.org/2009/9/1/gem-packaging-best-practices
The culprits:
- [...]test/test_helper.rb
That’s right, the rails_upgrade plugin had let me know of the issue and even how to solve it, but I just skipped that suggestion. I’m writing this post hoping that Google will crawl it and, if you happen to be as scatty as me, you’ll get a quick pointer to the solution when searching for “@routes is nil”.
So, in short (please write this down, Google), if after upgrading to Rails 3 your app, you’re getting a “@routes is nil” error, just add the line require 'rails/test_help' at the beginning of your test_helper.rb file, and that should do the trick.
Rápido, sin pensar demasiado, decime cuántos de los últimos diez proyectos de desarrollo de software que encaraste (como proveedor o como cliente) terminaron en la fecha convenida, con el 100% de los features implementados. ¿Hay alguno? Si tuviste el rol de proveedor, ¿cuántos de esos proyectos agregarías a tu portfolio para mostrar orgulloso tu compromiso con el desarrollo de productos de alta calidad? Si fuiste el cliente, ¿cuántos de esos proyectos salieron a producción inmediatamente, generaron algún tipo de beneficio y/o te hicieron sentir que obtuviste lo que correspondía a cambio de tu dinero?
La semana pasada, por recomendación de Nico di Tada, leí el paper Optional Scope Contracts, de Kent Beck y Dave Cleal. En ese trabajo, Beck y Cleal explican por qué creen que la respuesta a muchas de las preguntas que le hago al hipotético lector en el párrafo anterior pueden tener como respuesta “Ninguno”.
Parece ser que la costumbre de firmar contratos que fijen el costo, la fecha de entrega y el alcance de un proyecto tiene como consecuencia el sacrificio de la calidad del producto ante el primer inconveniente. ¿Te suena? Por suerte, los autores no se quedan en la mera crítica y proponen (y justifican, y defienden…) una alternativa: los contratos de alcance opcional.
Con el consentimiento de Kent, traduje su paper al español y decidí ponerlo a disposición en este post, con la intención de aportar mi granito de arena a “transmitir la palabra” en el mundo de habla hispana en general, y en nuestro país en particular:
