Wednesday, August 22, 2012

Considering the Past or Testing and User Experience II

A couple of things happened that came to my mind recently.  One was a webinar I decided to check out and see what the presenters had to say on "User Experience, Design and Testing."  No kidding - that was the title.

It started well enough with basic ideas like being aware of consistent look and feel between screens and functions and make sure the screens can be read and ... yeah, you get the idea.

The presenter then began addressing why these ideas were important.  "You need to make sure the users can actually use the system and it is easy for them to do so and that the screens look good while they are using it."  OK, my ears perked up a bit.  That struck me as being a little curious - "Where was she going with this?"

"Back when people first began using computers for work in the early 1980's designers and developers did not worry about usability.  All the screens had light text on dark screens and nothing was in color and you had to tab to get from field to field and they were really hard to work on for an long period of time.  Its like the designers did not care about ideas like that and simply did not consider it."

Oh dear. I was one of those people who "did not worry about usability."  I must be evil, or at best, heartless and cruel to make people use technology they had and not stuff that hadn't been rolled out on a scale where companies (and individuals) could afford it.  I was mean and vicious because I used light text on a dark screen when everyone knows that is the hardest thing there is to try and read.

Unless that is what you have to work with. Unless, there are no other options.

The objections raised by other attendees were brushed aside with "If you really wanted to make it easier you could have."

She then talked about how you needed to click the tab button instead of using a mouse.

I disconnected at that point.

Those who cannot remember the past are condemned to repeat it.
 George Santayana
(Jorge Agustín Nicolás Ruiz de Santayana y Borrás)

Sometimes I wish things were as simple as people tell us they are - or should be - or can be.  I am not a utopian visionary.  I don't have an idealized view of the world.

I am old enough where some of my younger colleagues, like the recently graduated former intern in the office ask if I'm retiring.  I am young enough to think "What an odd idea!  Why would I retire?"  I am also sensitive enough to feel a little offended at the thought I might be "nearing retirement."

I'm reminded of when my grandson was far younger than he is now.  He asked me what I talked about with King Arthur when we had lunch. 

Yet I remember those "dark days" the presenter was describing.  I also remember working with "seasoned professionals" for whom the idea of a shared CRT was a luxury that seemed astounding to them.  It certainly was better than using the coding forms and punching cards up based on the forms.  And that was better than hard-wiring the circuitry and flipping switches appropriately to get the computer to do what needed to be done.

I also realized that the people doing the work were doing the absolute best they could do with what they had to work with.

Could it have been better? Possibly.  I have not seen any system that could not be improved on.

It is important, however, to recognize that things can be better.  It is also important to recognize that sometimes, things are the way they are because they are familiar to the users.  Change is unpleasant as it is.  It makes us all uncomfortable.  Is there something to be gained by making things better, by some measure, in the revision or replacement process?

When looking at a revised design, a refactoring of the system or a complete rewrite, most people will throw away what is in place for what they believe should be in place.  Now, my younger self would say "Of course!  That makes sense!  They want NEW! Bright! SHINY! OOOOOOoooooh! Glitter!" 

That really makes sense to my younger self.

My current self is a little more nuanced.  "What is it they don't like? What do they like? What do they want to do they can't do? Are there things in the system that are getting in the way of what they need to do? Are they looking at business process changes that need changes in the system?"

I'll also throw in "What do they consider the system to be?"

The questions are relevant.  They help us, as testers, make an estimation of what the user has in mind, and importantly, what their expectations are. 

Only the dead have seen the end of war.
 George Santayana
(Jorge Agustín Nicolás Ruiz de Santayana y Borrás)
(Somehow, I'm going to work that second Santayana quote in.  I promise.)

We can dive in and throw our lot in with the latest and greatest... and then in a few years someone else is going to do the same to our "perfect" work.  It is the way of software, no?

The next closest thing to the experience of determining what is good "usable design" or design that is good for the "user experience" is GUI Automation test development.  A solid set of automated tests are developed and six to nine months later - it has fallen apart.  It has not been maintained and the changes made to the system render the automated test suite unusable.

At some point everything we make becomes obsolete.  

The shiny, new "Absolute Best" stuff becomes... old, outdated, archaic and old-fashioned. It is kind of like hearing your favorite song played on the radio and the DJ makes a comment about "an oldie but a goodie" or (worse) "a blast from the past." 

The people who most freely criticize an application, its usability, its interface, its design and its function, are rarely the ones who worked so hard to design it, implement it and get it "right."  Go gently when commenting on an older system and its shortcomings. 

When you create your "perfect" system, it will not be long before someone else is saying the same thing of your system as you did of its predecessor. 

Remember Shelley's poem Ozymandias and its warning:

I met a traveller from an antique land
Who said: "Two vast and trunkless legs of stone
Stand in the desert. Near them on the sand,
Half sunk, a shattered visage lies, whose frown
And wrinkled lip and sneer of cold command
Tell that its sculptor well those passions read
Which yet survive, stamped on these lifeless things,
The hand that mocked them and the heart that fed.
And on the pedestal these words appear:
`My name is Ozymandias, King of Kings:
Look on my works, ye mighty, and despair!'
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare,
The lone and level sands stretch far away".


  1. I can identify with this. The presenter was interpreting 1982 through her understanding of the world in 2012, which is pointless or dumb, depending on how harsh you want to be. She didn't understand the limitations of the technology available as you say. I'd prefer to turn that round. I must have started about the same time as you. Terminals were lined up along the sides of the room, and I was expected to do most of my work at my desk on paper. I came in right at the end of that era and within the first few months we switched to terminals on desks, mounted on turntables so two or three people could share a terminal, which would swing round. I got one of my own, because of the work I was doing. That made me feel important!

    I never thought in terms of the limitations imposed on us, because things were changing fairly quickly and we were getting new software and hardware all the time. So although what we could do seems very limited 30 years on I was constantly thinking about new opportunities rather than frustrating limitations.

    So that's where the presenter had really gone wrong. She didn't understand the 80s, the technology, the job we were doing or even the people we were. However, she did have a valid point, which she totally blew. I don't think we did take usability seriously (except for response times in my case). There were perfectly valid reasons for that. It wasn't just the technology. The problem was a mixture of the imposition of project management orthodoxy on software engineering, structured methods, and procurement practices. We were also developing for a captive audience whose needs were filtered through an organisation that saw them as components rather than people. That was our job then, and when the world changed with the internet and web technologies we did need to rethink what we were doing and how we engaged with users. That was difficult for many people and organisations. It still is.

    As for the "ooh, shiny new equals good" mindset and its corollary "old equals bad and irrelevant", I had a few battles to fight at the time of Y2K when there were serious proposals to dump business critical functionality built into 1960s batch suites rather than make them Y2K compliant. Senior managers who should have known better assumed that applications more than 30 years old couldn't be doing anything difficult, interesting or useful, and that replacement would be a trivial job. They had no idea of the implications of their proposals; utterly clueless.

    I find the mindset particularly frustrating when I'm dealing with inexperienced management who can't seem to grasp that their predecessors were intelligent, savvy and responsible, who did a pretty good job in the context of their time. Worst of all, the youngsters sometimes assume that they can do things that failed before. Sometimes it's simple ignorance. Often it's based on the assumption that the oldies failed because they weren't up to the job, not because it was a bad idea.

    James Christie

    1. Thanks for the comments. And yes, from previous conversations, we did get into the game within a few years of each other.