Choose a side
Of course the answer to almost every dichotomy is to find a solution in the middle which is a compromise. Whether you subscribe to the progress of history as Thesis, Antithesis, Synthesis like Hegel and his cronies or whether you believe society is a wave which only appears to make progess and never moves, the reality is that we need to make choices between opposites.
Continuing off a previous post regarding building user expectations, one area which needs further examining is the use of signs as replacements for text. Or rather replacing the sinage of letters with signs which are more readily digested and understood.
Linguistic researched has already shown that words are better representations of signs than their individual letters. There are two phenomenon which represent this. One test concluded that participants can more quickly identifiy whole words than individual letters, and that you can remove vowels from words in a context and still interprete the meaning with very little loss in terms of speed. This is why yo ucan review an article you have written and miss the same misspellings over and over again. Although you think you are viewling and reading each letter and each word, your brain is filling in gaps in order to speed processing.
Ok enough background. What good is this?
Please shut up
Well I am a Textual Minimalist. I would prefer to have simpler signs to designate meaning rather than text. However, in my company alot of people seem to balk at this and prefer to have alot of text. Like over-analysis/under-construction in the design phase, over textualization can often run into the same issues.
First over textualization wastes time be deciding the correct verbage to use. It has to be clear to the user not only in relation to the application but also to previous examples or text. If the text is being added in design mode, it is without context with regards to the application. But, once added to an application over textualization lives in two contexts, one that is the application into which it is inserted, the other which is the everday language we use to communicate.Since the specialized nature of business applications requires verbage which differs from our everyday usage, using alot of text on the screen often requires some sort of jargon interpreter.
A solution to reducing this complexity is to use sing simple signs and color codings. And as in the previous post regarding building expectations, these signs should be conventions regarding first the application, and secondly the business processes. The more abstract the signs are the more likely the user will be able to assign the sign with the action or functionality of the application without using textual interpreters. The business process sets the ocntext fo the application, and the application sets the context for the signs and texts which it contains. This is why building expectations though clear business rules is important for application development. Trying to create verbage in the application to backfill in business logic will almost always yield high resistance to application implementation.
The Difference
I think it is time for an example. Suppose we have two grids, one utilizing text, the other an image.
While functionally the same (clicking either the image or the button), these two cells do not necessarily convey the same message. Using my company as an example, we never delete data. I am not sure why, that is just 'the way it is'. Rows marked as 'deleted' are seldom used for reporting and once marked as such are even less likely to ever again make an appearance. But the point isn't what we do with the data, it is how the user feels as they interact with the application. We need to remember that although developers interact with data, end users interact with applications. Very few have the conceptual framework of data management. One row in a grid is one row in a grid even though the underlying structures may represent several tables and an aggregation of hundreds of rows.
The phenomenon
What happens when you click the image is more closely associated to that image than when you click on the button (whose text and column read 'Delete'). I will say this as fact. The text on the button says 'Delete' but in fact the data is not getting deleted. Would it be better to say "Make data eternally invisible?" Surely this is not an option. Having only the image present reduces the confusion and complexity since it merely indicates a 'going awayness' of the row. The user realizes that after clicking the button the row is irretrievable. Whether or not the data is actually deleted or just hidden is not of concern to the user for their real world usability. In a rare application that is does matter, signs can be used to signify the difference in other ways. In those cases, it would probably be even more problemmatic to have one button that says 'Delete' and one that says 'Hide', compounded even more if there is no 'Unhide' option.
But I have something really really important to tell you right now about this very important thing here onthe screen
Sometimes over textualization can actually inhibit workflow in addition to adding conceptual complexity. The most insidious form of over textualization is the modal popup when used for validation or informational purposes as opposed to stoppping workflow to indicate an error or the need to take corrective actions. How many times during work can I have a box popup that gives me information that I do not really need. And what is in the box? Text.
One symptom of over textualization is not only the sheer volume text, but rather the forcing of this text on the user. Instead of having popups, modal ones at that, disrupt the workflow of a user, or having gigantic panels taking up real estate with instrucitons consider the following:
Validation errors handled with highlighted violators. Empty textboxes can become color shaded. Invalid values can either have text added next to the offender inline with the entry point or submit point or the form can surface a tool tip.
Tooltips are a very useful tool as long as they don't fall prey to over textualization. Tooltips should not be used in place of training documents. If your application has so many tooltips that the user is afraid to stop their mouse, then your application needs to design and usuability re-working.
Informational issues concerning instructions can be put into a helpfile if need be (i.e. 'How to fill out this form'). Better yet, help icons can be surfaced in the place of a modal popup. If the user feels the need to see the information, they can choose to click on the icon of continue working.
The worst for last
Let me give you an example of how the use of over textualization has been abused at my company.
We have a very simple gridlike application for entering Time worked for the week. For Thanksgiving break, they automatically enter the time for you and nicely shade the box indicating that the values cannot be changed for that cost code for those days. All very nice. However, when I tried to enter time for Thanksgiving day, a modal popup well..popped up telling me basically that there was already some time entered for the thanksgiving day vacation and if I needed to change any of the values other than those for that day I could or I could keep the hours I added to Thanksgiving day. Bascially, the message told me to keep on going, don't mind me. It was the worse kind of over textualization, not only did it disupt my workflow (several times actually since the code that triggered the popup kept on triggering somehow), but it also did not give me any real information. It did not say that what I was doing was incorrect. It did not provide a better way of doing anything. It was basically a squirrel that just ran infront of my car forcing me to put the brakes on.
Nothing is wrong with words as long as they are meaningful. And you can quote me on that. Just don't quote me in your next applications.
No comments:
Post a Comment