Three reflections on an email design assignment

Adapting and Appropriating eMail, ProcessRight WorkFlow


First,

I have always loved email since 1978 when I began using it over the University of Alaska’s UNIX main frame in Anchorage to email people in Fairbanks. Significantly at that time we were discussing music, Bob Marley and The Wailers (how I discovered them), another thing of strong social importance Microsoft managers failed to recognize as valuable.

Why Bill Gates and the factory did not see what a huge innovation email was, and how extensible, I never understood. Why, despite my input and the input of others at Microsoft, development for email failed to gain much footing. Until the last few years a very small amount of money was invested in developing email. This was due in part to the structure of the development managers directly reporting to Bill Gates -- within that hierarchical structure, at each level there is a decreasing amount of authority, however at the next level down one can not really question the voice of authority above. This is an old fashioned management style based on military structures developed for waging war.

From interviews I did last fall including one of a former Microsoft lead email development engineer, I found that all that required was one manager at one level to wipe out Bill Gate’s vision – if Gates said spend $10-$20 million, the next manager changed that to 3 million, or less, there was nothing the visionary email engineers below could do about it. Eventually they quit and formed other companies.

Everyone understood the value and power of email of communications – but no one, save the customer voting with their buying power, could get management to budge. Finally when Microsoft's eMail product became the leading selling product after Windows itself did Microsoft management take notice. They were forced to do so by the downward trend in stock value and sales. Now we clearly see all end users really need are two things – browser and email -- and some products can be both and more at the same time using the same basic interface.

I believe this is why we have this as an assignment – had Gates encouraged other non-traditional, cooperative, even tribal structures to form leadership in various ways the product we describe would already exist, not just be embedded as a possibility in applications such as Outlook which require a developer to pull into reality.

In this way, over so many years, I learned that new ideas can be killed due to stubborn traditional systems which may not be recognized for what they are. New ideas may long await fresh new management.

Second,

Having the third party review engage the cohort from our idea stage down to their formal presentation was a stroke of genius in envisioning and shaping up our resulting product.

I found much that I took for granted was still embedded in my thinking as an “of course” and not explicit. In communicating with people you have to make your ideas explicit.

So such usability issues as landing pages to track the results of a process are one of these “of course” structures, which will be included in my future product designs.

Performing recent usability studies I found the exact same problems with beginners learning software exist now as they did in 1989 – the year Windows 3.0 was released. In 1984 I recall having very little trouble learning the MacOS interface.

Third,
The VIEW

There is a small political commentary nod in our selection of the title for the company “ProcessRight” Actually it relates to the political LEFT because the public voided the Right. I recently searched on ‘processright’, and quickly realized it owes its name in part it to the format of method calls in C++ and C sharp, such as used in the Invaders game at Duke University:

http://www.duke.edu/~jbs3/cps108/ooga/oogadocs/invaders/Invaders.html

“ProcessRight
public void processRight() - Provides the rules for what to do when a left event is pressed
Overrides:
processRight in class Game”

We used Google Talk IM to communicate in the last hours of our project. One of my cohorts, an employee of our favorite 800lb gorrilla across Lake Washington, may not want a GMAIL account to communicate using Google Talk IM.

It is true that Patton said, “There's a great deal of talk about loyalty from the bottom to the top. Loyalty from the top down is even more necessary and much less prevalent. One of the most frequently noted characteristics of great men who have remained great is loyalty to their subordinates." This should apply to Microsoft employees too.

But you got to get into the game so I invited my cohort to get an GMail account to learn what the other guy is doing - here is why - to paraphrase Patton (if even from the film) metaphorically --

'Google are Microsoft's enemy. Wade into them. Spill their blood. Shoot them in the belly. Lift their software and interface ideas.'

“For over a thousand years, Roman conquerors returning from the wars enjoyed the honor of a triumph - a tumultuous parade. In the procession came trumpeters and musicians and strange animals from the conquered territories, together with carts laden with treasure and captured armaments. The conqueror rode in a triumphal chariot, the dazed prisoners walking in chains before him. Sometimes his children, robed in white, stood with him in the chariot, or rode the trace horses. A slave stood behind the conqueror, holding a golden crown, and whispering in his ear a warning: that all glory is fleeting.” -Patton

Last,

Very much enjoyed working with my team – it was a blast!

“We're jammin'
I wanna jam it wid you
We're jammin',
And I hope you like jammin', too
Ain't no rules, ain't no vow, we can do it anyhow
I'n'I will see you through;
Everyday we pay the price with a little sacrifice,
Jammin' till the jam is through. Ooh, yea.

We're jammin'
To think that jammin' was a thing of the past
We're jammin',
And I hope this jam is gonna last
No bullet can stop us now, we neither beg nor we won't bow
Neither can be bought nor sold
We all defend the right; Jah - Jah children must unite
Your life is worth much more than gold. Ooh, yea.[1]”

[1] Song lyrics from Robert “Bob” Nesta Marley, “Jammin’” Release Date: 1977 Genre: Reggae Label: Tuff Gong Downloaded Monday December 9, 2006 from http://www.hotlyrics.net/lyrics/B/Bob_Marley__amp__The_Wailers/Jammin_.html Lyrics originally published on the album.

Docusign.net heuristic evaluation

https://www.docusign.net is the subject of this heuristic evaluation.

This application uses the technical convention of an authenticated user on a website printing a document to a local service which has been previously installed on the local box to obtain a legal signature from a remote party or to send or respond to such a request. This “printed” document then appears in a registry in the Web interface on which the user will perform actions which the Web services provides. The document with its various suggestions for use, such as SIGN HERE, grants the ability to have legal digital signatures.

From the point of view of a user the convention is sending a letter, with the contents, envelope, and stamp of approval, proof of receipt and similar mail conventions.

While I found it stunningly easy to use, there arose what I refer to as “Omissions of the 3rd Kind” which means they are not intuitive and require more in depth experience with the system to understand, or some simple reason prevents the enduser from understanding the interface such as fear of use.

The first one was encountered after successfully following the steps to install the application locally, and printing the document I wanted to send it to someone to have it digitally signed. As I went through the crabwise steps appearing and clicking “Next”



Addressing the header in the Envelope.

After passing through all the steps, it became apparent that the application was going to allow me to send a document to be signed but not to open and digitally sign a document myself, and then forward it. I stepped through the entire process, taking screenshots of the process. I located the help files and played them and found that the interface did support signing and sending. But first the document needed to be prepared with the locations for signing embedded in the file.

So I stepped through the application again. I felt that instead of “New” in the interface it might have a option to Request Signature, and one for Send Signature as a scenario based design could offer. But as I used it the second time it seemed more intuitive.

I took it at face value, I trusted it. Signers IS Signers – it is anyone including me. So I addressed the “Envelope” to myself.



Adding myself as the addressee for sending and signing

Then I simply followed each step as it was encountered. Forwarded the document to myself through the application and voila, it was done.

The only real limitation I could immediately discover considering the purposes I wanted to use it, is if the new window is open, any documents you have not “printed” will not appear in the open window. This application detests the back button which is not a familiar scenario for some kinds of web uses.

Eureka! This application works from the heuristic point of view and it works well, with three simple caveats
1. View the basic instruction presentation
2. Trust the application to lead you, don’t overthink it
3. Read the interface.

For most users I believe they could get this to work the first time.

Wicked Problems in User Interface Design

The wicked problem examples from urban planning that Rittle & Webber (1973) present ring true for information systems design because when addressing and serving more and more people’s diverse needs naturally wicked problems arise, hopefully to be solved, in large part with monkey-like mischievous solutions.

Working with Apple Computers, Mountford (1990) expressed those wicked problems in computer information systems outlining on the first page:
“The world is rich with data, rapidly becoming more and more varied in media type…
The challenge is how to best present and represent such data within the interface, to transform it into useful information.”

Making this suggestion for resolving these problems:
Future interfaces need to incorporate new information types and to accommodate new types of users with additional customized real-world interface metaphors that make information easy to find and use.”

Suggesting merging the efforts of two groups not generally thought of working together, scientists and artists. Comparisons from design traditions, animation, theater, architecture, industrial design, and information display (using Tufte’s famed cartography example of Napoleon’s March to Moscow: The War of 1812”). Suggesting looking at real world tasks and environments to find new ideas which in the technology and music fields we call “mashups” today, Mountford writes:
“Some people believe that new ideas are almost always the result of collisions –juxtapositions or recombinations of ideas” (Koestler, 1964)

These are outlined based on Adam’s (1986) brainstorming steps, as new uses for the object, adapt the object to be like something else, modify, magnify, minimize, substitute, rearrange, reverse or transpose, combine the data into an ensemble. This advice seems virtually the same as Jasper Johns’ esthetic theorem, now considered basic advice to artists --
"Take an object. Do something to it. Do something else to it."

Role playing is suggested as a creative exercise to delve more deeply into the change the idea or object metaphor, and outlining four personality and functional roles, the Explorer, the Artist, the Judge, the Warrior, that could be worn like a costume on Halloween, but accurately providing a warning that if interacting all at once, perhaps the role of the judge should wait to sort the ideas presented instead of eliminating them.

In a way Johns is a good example of the polar differences between scientists and artists, with information science providing solutions to needs looking for something one doesn’t know or have and Johns ‘something’ becoming something else based on “things the mind already knows. ”

Mountford ends advising interface designers to live in the present and future, anticipating the challenges for designers in new ways to use computers having suggested prototyping models, and these several techniques that are in wide use today.

Life too far in the future isn’t always economically feasible, but combining with role playing should help software projects remain practical and satisfying for those of us who enjoy building successful information tools and toys, or just imagineering we are. I feel the analysis is especially accurate as far as customizable user interface design goes.

Jasper Johns sketchbook, page 42 from 1963–1964 http://www.thenation.com/doc/20001218/danto/2

Quote obtained Oct 31, 2006 from http://www.metmuseum.org/toah/hd/john/hd_john.htm

Rittle & Webber / Mountford on Wicked Problems

Rittle & Webber (1973) present the concept that due to the complex nature of human beings scientific answers fail because of the nature of the problems (in the context of Urban planning), such as hard to measure or soft things - societal concerns - which as stated:
“do not have a solution in terms of definitive and objective answer. ”

Mountford (1990) collects ideas from a variety of sources, and advises In effect doing the same thing for information system design - advising finding ways for artistic and scientific people to collaborate, approaching things from a variety of levels of human experience, stating:

“some of our new interface ideas will come from people who study thought, language, entertainment and communication, as well as from people who study hardware, algorithms, data structures. ”

However some wicked problems can only be resolved in granting end users rights and freedoms when it comes to information. Some problems are not served by direct end user participation because it won't help anything and it would not make sense for the many.

Take a WAP (wireless) phone application which has a GPS function (locator that knows where the end user is all the time), and a Search function, so if an end user wants to find a coffee shop within a short distance, they run a Search and the 5 closest coffee shops are returned.

What users may be interested in doing is setting their own preferences to Starbucks Only coffee houses, or only hotwired coffee houses which have computers available for rent. They may be interested in knowing how other people who went there rated the coffee, etc. They may also be planning to meet someone there for reasons other than coffee (but that is for an adult audience).

Google weighs query responses using a variety of ways, but one of them, perhaps the strongest, is by how many times someone clicks on it. This is just like voting - there is a good argument that personalization is the greatest contribution that the American post war baby boomers, with their large purchasing power have made and continue to make today. Companies, and other ensconced or older established organizations still experience enormous trouble facing these kinds of 1 to many, 1 to 1 individualization or personalization changes.

During today’s and yesterday’s job interviews I advised allowing end users to set their preferences on a Web site when they are at a full sized computer to help them find whatever they want on the smaller screen, even if some “father knows best” defaults must be present.

While there are things that the end user may wish to configure, the typical end user is not interested in exactly how the algorithm returned the Search sort to the database, and has no interest in writing it, or contributing to writing it, or even ever hearing the word "algorithm" -- users just want the results and fast.

One of the questions I was asked in a recent interview was a standard sort question for an algorithm, my response was true to that of a designer (or an end user) – “Find a database engineer, sorry that’s not how I think about or consider these problems.”

This remains a problem that inexperienced or less well educated technical or scientific approaches believe that individuals should know everything – most end user/customers can not function in this manner and should not be expected to think about how the machine runs to obtain the results they want, even if they have some kind of mental model.

Imagine if Google functioned only as well as the user’s understanding of search engines permitted – they wouldn’t find anything – they have to rely on Google’s code poets to figure out how to take Search from the functional status of a hammer and make it into a starship. Same goes for Live Search, in my humble option, but that’s a completely different subject.

The wicked quality of being human means that solving ill-defined and sticky problems should not be and can not be the domain of just one facet of thinking about a problem or a system, but as my recent interview demonstrates simplistic thinking about designers roles and customers needs still dominates the software industry.

One solution is everytime a designer uses the term BRAINSTORM and wants to use this technique they should define it so that all present understand that some wild and crazy ideas are likely to form, and just as likely they will go away later, leaving just the good stuff, it's all part of the process. If critics make their presence known immediately, the uber creative will find someplace friendlier to be.

Holtzblatt, K., & Beyer, H. (1993). Making customer-centered design work for teams.Communications of the ACM, 36(10), 92-103. Retrieved 1 Dec 2004 from http://doi.acm.org/10.1145/163430.164050.

Leonard, D., & Rayport, J. F. (1997). Spark innovation through emphatic design. Harvard Business Review, 75(6), 102-113.

Friedman, B. (2004). Value Sensitive Design. Encyclopedia of human-computer interaction. (pp. 769-774). Great Barrington, MA: Berkshire Publishing Group.