Artículo

 

 

 

 

La escritura alfabética representó un avance significativo y radical para la comprensión y difusión del lenguaje escritoInteraction Language

By Daniel Mordecki
February 3rd, 2016

Este artículo en español: El Lenguaje de Interacción

If we first build an Interaction Language, which articulates the relationship between each elemental interface component and its representation on the screen, and only then build the dialogues that make up the system from this elemental components, we will get the same positive effects of an alphabetic language: the dialogues understanding will be uniform and consistent, and the extension of the system to new dialogues and interactions is feasible with a very low learning cost

 

Some time ago I heard Carlos Maggi [1] talk about the power of the alphabet, and I was stunned by his observation brevity, simplicity and power: with just 27 letters, the alphabet is the tool that enables writing on paper every story, every contract, every declaration of love, that the millions of Spanish speakers produce every day, since hundreds of years ago. Only 27!

With just 27 letters, the alphabet is the tool that enables writing on paper every story, every contract, every declaration of love, that the millions of Spanish speakers produce every day, since hundreds of years ago. Only 27!

The sublime elegance of a small set of icons that represent the only and indivisible raw material of everything that was written and will be written in Spanish, sharply contrasts with the difficulties and limitations involving ideographic languages, being perhaps the Chinese [2] the most notorious example of the latter.

While in an alphabetic language we will be able to read and write unknown words, in an ideographic language that is not possible. This is a key difference. It's enough to think that when we learn a new verb, knowing the infinitive is all we need for the alphabetic writing, while in the case of ideographic writing we must learn each conjugation symbol or waive conjugating.

The reverse is also true: we can read an unfamiliar word long before knowing its meaning, or what is most striking, deduce the meaning from its writing. For example, when Les Luthiers [3] sings its "Candonga of the bus driver, hybrid of candombe and milonga" only knowing that candombe and milonga are two very popular musical styles you can immediately understand the joke, even without being a Spanish speaker. Also the phonetic and writing of the new word does not imply any difficulty. How words invented as metaphors, jokes and wordplays are written when the writing system needs a new symbol for each word? And more: how this new symbol is read by someone that doesn't yet know the ideogram - term relationship?

The same happens with interfaces: some of them could be described as ideographic, with a specific solution for each problem, while others are solidly supported on an interaction language.

Two steps interface building

The parallel is as significant as illustrative. If we first build an interaction language, which expresses a relationship between each elementary component of the interface with its screen representation, and then build the system dialogues from this elementary components, we will get the same positive effects than in an alphabetic language: on one side consistent and uniform understanding of the dialogues, on the other the system extension to new dialogues and interactions is feasible with a very low learning cost.

If keeping a style is a great achievement, to build an interaction language is quite different, something positioned at a qualitative higher step.

While the idea seems incontestable and benefits largely justify its adoption, it is not evident in all cases, especially at the beginning of a project: the two steps interface building can become more laborious, not because it requires more time, but by the need of bringing together the organization ideas about a software based product design and implementation. In addition to this, as most of the Usability benefits, the shocking result arrives usually at medium term, and not always immediately, which causes little support from other organization areas beset with schedules and the need for urgent achievements.

The idea of an interaction language is not linear, neither is trivial its acceptance. When design teams face the challenge of a new interface, the usual approach is to start with the design of the central areas, the most relevant to the system interaction. Then a set of "style" guidelines are derived from these early designs, which in turn are spread to other system features and screens.

But if keeping a style is a great achievement, to build an interaction language is quite different, something positioned at a qualitative higher step. That is crystal clear in the images taken from a Samsung Galaxy S4. The first was taken from the call log, the second from the address book and the third from the favorite contacts.

contactoS4uno

contactoS4dos

contactoS4tres

All representations have the same purpose, to show contact relevant data and allow communication. The graphic style is the same: fonts remain unchanged, spacing, colors and all other elements allow stylistic continuity. But the interaction language that underlies each gadget is radically different. While the first supports right swipe for a phone call and left swipe for SMS, the second works tapping both for calls and texting. The third lost the SMS functionality. It's worth noting that the latter is so bad that it not even meets the required functionality: with this design it's not possible to have as a favorite the fixed and mobile number for the same contact.

One thing is that an interface element puts a particular emphasis on some of its attributes when it's displayed, just as verbs are conjugated and nouns get adjectives. Another story is that it becomes a different element with different properties and interactions, as in the example. The interaction cost involved in recognizing the three formats and remembering how to interact with each one is significantly higher than the interaction cost provided by a consistent interface. That is precisely the value of an interaction language.

The structure of an interaction language

The idea of building a language based interface has been around for some years. Probably the first complete proposal is that of Alan Cooper, in his 1995 book "About Face", where he talks about a "canonical vocabulary".

cannonicalVocabularyCooper
[4]

In Cooper's proposal all the fundamental ideas are already ripe

In Cooper's proposal all the fundamental ideas are already ripe: a set of primitives that work as an alphabet equivalent of simple and indivisible elements, the interface components built from these basic elements which correspond to the words, and finally the interface itself, that emerges from the combination of these components.

Closer in time, in 2013, the designer Brad Frost proposed a new approach under the name Atomic Design [5] . It is fair to say that the article owes a quote to prior references to the idea, which appear there as born from nothing.


 
dienoAtomico

Frost's approach is a significant contribution, since it includes a clear and visible way to capture the idea of an interaction language in a project of any size. The atoms play the role of letters, molecules replace words, and organisms, templates and pages are the constructs product of these language basics.


atomos
moleculas

Atoms

Molecules

organismos

Organisms


Cooper's idea, inserted in a book aimed at developing large applications and operating systems, seems to be too abstract for small-sized projects. Atomic design as proposed by Frost, however, is truly simple, tailored to the Web and mobile challenges of the second decade of the XXI century.

The weakness of the Atomic Design proposal is that it only cares about screen represented elements, prioritizing displaying over doing.

The weakness of the Atomic Design proposal is that it only cares about screen represented elements, items that can be composed from information atoms, but says nothing about actions taken on these items, prioritizing displaying over doing.

Nouns and verbs

An interface, like a language, includes pieces of information of any kind that correspond to nouns, actions that can be performed on them, which correspond to verbs, and a series of rules working as a syntax, that allows combining all this pieces into more sophisticated compositions and more complex actions, that at the end it's what finally meets the ultimate objective of the interface.
The distinction between nouns and verbs in the interaction language that underlies the interface is neither a technical preciousness, nor something you can ignore.

Extending the atomic design language at each stage of the interface construction, needs that allowed actions are specified for each atom, molecule and organism, that is, which verbs are applicable for each noun and how they conjugate.

For example, a button can be clicked and disabled. In addition to that, a button always has a fields group on which it runs its action. Meanwhile, a text field allows writing, editing, copying, cutting and pasting. It can also be disabled, which pauses all other actions but retains the value. All around the interface, buttons and a text fields should retain these properties and always execute them consistently.

HTML magic

The massive irruption of the Web, back in 1994-1995, had a magical effect on interface design. For the first time in about 40 years of computing history, all designers and developers of software-based products agreed on a unique way to build interfaces, supported by a solid and elegant interaction language, implicit in HTML.

The interaction language underlying HTML is simple and consistent. It has the atoms that constitute the fundamentals, the actions that can be performed on each of them and the ways they relate to build molecules and organisms. By simply complying with the standard, the interface become consistent with itself and with the rest of the Internet ecosystem.

Over time, HTML knew how to show the structural integrity of its foundations and the flexibility of its proposal, expanding its limits up to the sophisticated couple of HTML5 and CSS3.

Over time, HTML knew how to show the structural integrity of its foundations and the flexibility of its proposal, expanding its limits up to the sophisticated couple of HTML5 and CSS3.  HTML always provided the ability to build functional and consistent interfaces, just sticking to standard.

The advent of the App world was a new turn of the screw, which returned us to the pre-HTML era, with the revival of designers and companies that confuse innovation with differentiation. They consider setting their design apart from the rest as an absolute value, at no charge. Being different has become a value in itself, although most of the time involves promoting a creativity as useless as full of interaction poverty.

Creating an interaction language

The interaction language creation process is nonlinear. It doesn't begin with the discussion about atoms, then molecules and then the rest of the interface. By contrast, it is an iterative process where three forces compete:

The design idea is to begin from an initial drawing of a few crucial areas, crumble them into atoms and molecules and then build a few other crucial areas from them, quickly iterating until the design gets stable.

Deffects, omissions and inconsistencies are quickly found in this go back and forth.  As they are corrected, problems found in each cycle of refinement become less and less important, until we get a stable and consistent language interaction proposal, capable of building the rest of the interface without suffering changes.

Building the interface

Giving life to the interface starting from an interaction language involves creating all the molecules, organisms and dialogues which make users able to use the system.

It is important that all the item functionality is available either directly or indirectly each time the component is rendered at the interface

It is important to ensure that each interface component is unique and always has the same behavior, regardless whether in a dialogue you can have some more prominent properties and other disabled, while in the following dialog is exactly the opposite. It should be obvious to the user it is the same element behaving according to the needs of the context and the function executed.

It is also important that all the item functionality is available either directly or indirectly each time the component is rendered at the interface. The only exception to this rule is when some functionality must be excluded because a valid reason, such as safety.

This implies, for example, that if a data value is editable, it must be possible to access edition whenever it is rendered. That doesn't mean that you can only show it in edit mode. It means that when it's shown there must be a way to access edition that doesn't involve starting from scratch.
PowerPoint slide is a relevant example to understand the use of interaction language when building an interface.


powerpoint1
powerpoint2



The three forms always represent the slide as the same object, and always a slide collection is a unique presentation. Actions on a slide, no matter in which form they are taken, have a single and indivisible effect, beyond the fact that each representation has certain features enabled and others inhibited. This is quite evident in PowerPoint, since changes are expressed in real time on all visible representations.

As a general rule, objects that make up the system are represented in different ways on the screen based on two fundamental dimensions: the size they occupy on the screen and the ability to edit / modify them. One consequence of a properly conceived interaction language, perhaps the most important one, is that all these representations express the same object in an obvious way to the user, regardless of size and whether they are in reading or editing mode.

From the size point of view, whether the object is expressed as an icon, a row in a table, a summary dialogue or a full screen form, it remains the same object and allows access to the same functions

From the size point of view, whether the object is expressed as an icon, a row in a table, a summary dialogue or a full screen form, it remains the same object and allows access to the same functions: not all necessarily just a click away, but inside what could reasonably be considered direct manipulation. In other words: no matter how an invoice is  being represented on the screen, if I'm watching it I necessarily have to be able to delete it without going through the main menu and navigate to Customers -> Accounting -> Billing -> Delete Invoice.

The edition / modification side of the rule is more complex, because the ability to edit not only depends on the real state available on the screen, but on the editing probability and the consequences of change. While a customer discount is likely to vary in each transaction, his phone has a low probability of changing and his name usually never changes.

That's why the decision of how easy it will be for the user to modify a datum at the interface doesn't depend only on the easiness of offering edition, but on other additional components. This doesn't free us from the rule that objects should be editable where they are displayed, either because they are rendered in editable fields or because they have mechanisms that make them editable.

cono
Regardless of the size and context, its's always the same element that is represented

Teaching how to write

Experience shows that while the organizations in which we operate as interaction design professionals claim for quality interfaces, they often refuse to take the appropriate techniques and methodologies necessary to build them, in a sort of masochistic schizophrenia.

The interaction language is a powerful tool: it's simple to show, easy to explain and can be disseminated throughout the organization with a reasonable effort.

If we're in the UX business, if we have chosen to devote our lives to building interactions, we know that this is the challenge, having the necessary patience to generate organizational spaces and managerial support for interface improvements.

The interaction language is a powerful tool because while employing it generates a strong impact, it generally receives rapid acceptance: it's simple to show, easy to explain and can be disseminated throughout the organization with a reasonable effort.

Our task is then to conceptualize the interaction language and teach the organization to write with it.
 

________________________________________

[1] Carlos Maggi, was an Uruguayan writer, journalist, historian and playwright. He died on May 15th, 2015, at age 92, while I was writing this article. Here it is our little tribute.
http://en.wikipedia.org/wiki/Carlos_Maggi

[2] The linguists use a finer classification of languages in which Chinese it not pure ideographic, but the simplified classification is enough for our analysis.

[3] Les Luthiers is a musical group that combines humor with homemade instrument music. Since 1967 entertain us with a unique cultural proposal.
https://en.wikipedia.org/wiki/Les_Luthiers

[4] Taken from About Face: The Essentials of User Interface Design - page 48

[5] Atomic Design - Brad Frost - http://bradfrost.com/blog/post/atomic-web-design/

mordecki.com

 

 

 

Valoraciones

Calificacion promedio 7

Una valoración

Su opinión:

Excelente

Muy bueno

Bueno

Aceptable

Regular

Malo

Muy malo

¡Suscríbase!

Reciba una notificación cuando se incorpora un artículo
Más información

Usabilidad, y estrategia en Internet

white_spacer

Comentar

Nombre:

Email:

Comentario:white_spacer

Escriba la letra A

white_spacer

Comentarios

white_spacer

Usabilidad Estrategia Presentaciones Otros Temas Casos Otros Autores

white_spacer

     Contactar      Comentarios sobre el sitio      Valoraciones      Privacidad      Curriculum


Late Latino

calific1

  0

calific2

  0

calific3

  0

calific4

  0

calific5

  0

calific7

  0

calific8

  1

 

Articles in English