05.17.07

Traffic in India - Embracing Constraints

Posted in Trading Grid, Usability and Design at 10:45 am by justindz

I just returned this weekend from a business trip to India.  Aside from being a very productive trip, it was also personally relevant.  My mother lived in India until she was 18.  As a consequence, I grew up with some Hindustani cuisine, religious and secular decorations and quite a few stories.  The last two opportunities for me to visit with her coincided with my graduation and my marriage.  This was to be my first trip.
Friends and family alike have asked what I found to be most amazing.  The answer is simple: I did not see any traffic accidents while I was there.  That is amazing because driving in major Indian cities makes DC commuter rush hour look like a relaxing weekend spa.  More people with more vehicles in the same space, 24 x 7, with no lanes, signs or lights.  Traffic is regulated by frequent use of the horn and by constant bravado.

This reminded me of an old post on the 37Signals blog.   The post discusses the “less is more” philosophy of roundabout traffic circles and applies that concept to web software.  Admittedly, it’s a bit of a stretch.  37Signals is sometimes controversial–they are the creators of Ruby on Rails and a number of popular web-based productivity tools to which I am thoroughly addicted.  Most of the controversy comes from their frequent criticism of software development, web design, enterprise software, the public web company craze and other things which people feel passionate about.

Although this was an old post, I remembered it while thinking about the traffic in India.  I started to think about what lesson there might be, if there would be any, for the Trading Grid and for software in general that could be derived from the traffic in India.  This was the most interesting thought:  speed limits are not necessary, since the traffic is too constantly high volume to present an opportunity to speed.

I thought this was a very good example of embracing your constraints.  Embracing your constraints means not fighting against a limitation you have, but accepting it and building it in to your design as a principle or design factor.  Speed limit signs would rarely be applicable.  In fact, they might only be distracting.  In that kind of traffic, people need to watch their bumpers and not read signs.  On the off chance that there is an open road, there’s an incentive to move a bit more quickly and keep it open as long as possible–the chance of a multi-vehicle accident is lower as well since the road is open.

Embracing your constraints or acknowledging the environment in which your tools are used is an important factor in good, human-friendly design.  When I write requirements or work on design with the engineers, I always try to present the customer’s working environment as a driver in the design.  The average EC coordinator, for example, probably does not have two hours per day to sit down working on complex reports and workflow.  They generally need snap, overview health or checkup information.  If there are exceptions, they need to narrow in.  Sometimes, they need to isolate a particular event when supporting their partners.

The dashboard, drill-down, deep-dive approach to analytics workflow is an example of embracing your constraints and scaling your tool according to how much attention the user can really pay during a normal work day.  I think Google Analytics does this very well, and that is even more true with their new UI.  I could also bore you with other examples, like our web forms security time-out handling designed to recognize end users in the shipping dock or the warehouse moving away from the station constantly, while still in progress on forms.  But what I’d like to hear is what constraints you face (or your customers, if you’re not an end user) during the day that your tools need to embrace.

Do you get no more than 5 minutes of face time with your apps in one go?  Do you work in a noisy environment where audio alerts are always drowned out?  What constraints do you need the Trading Grid, or any other tool, to better embrace?

P.S. - Sorry Mark .  I will leave all the driving topics to you in the future ;-)

05.07.07

The First Post

Posted in Uncategorized at 2:23 am by justindz

Greetings. I am the Global Product Manager for Trading Grid Online, the GXS web portal to the Trading Grid. For a while, I have been communicating inside GXS with a marginally work-related blog and have made this leap to the external world. I have been blogging in different contexts and businesses for 8 years now. I thought I should say a bit about myself, briefly and then try to convince you to keep reading :-)

I am one of those funny people in Marketing who have a degree in Software Engineering and experience building web applications. My primary functions at work are gathering customer requirements, designing the Trading Grid strategy and producing plans for the engineers to carry out. At home, my wife and I raise two boys. On the first Sunday of every month, I read poetry and short stories at a little tea house in my not-so-little-anymore home town in West Virginia. Those are the highlights. I also like to debate philosophy, love learning phrases in different languages and eating new foods.

Regarding this blog, I thought I would give you a little list of the things I am likely to blog about as well as give you an example of my writing style (or lack thereof) that illustrates one of the likely topics.

  • Trading Grid anecdotes - from time to time I will probably talk about projects or thoughts related to the design of the Trading Grid, although John Radko already does this better than I will.
  • Reviews of good-looking web products and services - I like to stay in tune with the usability community and with new and interesting web applications to keep professionally current and to drive more improvements into the Grid.
  • Thoughts on interface design and usability - I have a tendency to think about design in both likely and unlikely contexts and love to hear what other people think about building good human interaction.

To illustrate that last bullet, here’s a thought from my last flight. I am currently in Bangalore reviewing a portal upgrade project to move customers on to our new portal. I took a Lufthansa flight from Dulles International through Frankfurt. This is a rather long trip and so I had several opportunities to use the reclining seat. I found the controls for operating the chair to be clunky. They were analog, imprecise and didn’t give very good indications of what would happen when you pressed them. Frequently, I would hold down a button too long and end up in akward positions because I assumed that I could lay down flatter than the chair would let me. Maybe you’ve had similar experiences.

So I started thinking about how it could be better. That is, after all, why I’m here. So, what are the problems that could be solved?

  • The buttons were mechanical and had been used long enough that they weren’t as accurate as they had been designed to be.
  • Although different parts of the chair had their own controls, the whole chair would move even if I only wanted to move one part.
  • There were no presets, only adjustments. I suppose if you always fly the same airline (which I don’t) you could get used to it. I was flying blind.

Step 1 - replace the buttons with a touch screen pixel display. Controls should stay precise longer and it’s possible, if the controls need to change, to change the code rather than rip and replace the whole physical unit. This is more cost-effective over the long term and stays easier for the passenger to control.

Step 2 - display on screen the parts of the chair as draggable within their range of motion. This way, it’s possible to see what the full range of motion is without having the chair push you around in uncomfortable ways and spilling your Masala Chai (which Lufthansa offers exclusively on flights to and from India, by the way). Move the parts to a comfortable looking position and then press a button to have the chair gradually adjust into shape. That way, you are not contorting yourself around like a Cirque du Soleil cast-member trying to figure out how the chair moves.

Step 3 - provide some presets for positions like “eating, reading, sleeping, snoozing while sitting.” Choose one from a menu on the screen, preview it on the display, and turn it on. You could then, supposing you wanted your head a tiny bit higher, just tweak from there. Although, it would be a bad idea to display “brace for impact” in general. You would only want that one to show in case of an emergency ;-)

What do you think?  Don’t hesitate to leave comments.  I love to read them and I am good about responding.