Eric Reiss’ Web Dogma – deutsche Übersetzung

Eric Reiss' Web Dogma besteht aus zehn Regeln für Webdesign – mit dem Anspruch unabhängig von Moden und technologischen Weiterentwicklungen zu sein. Ich habe die englische Fassung ins Deutsche übersetzt.

  1. Alles, was lediglich existiert, um die interne Politik des Seiteneigners zu erfüllen, muss eliminiert werden
  2. Alles, was lediglich existiert um das Ego des Designers zu befriedigen, muss eliminiert werden.
  3. Alles, was im Kontext der Seite irrelevant ist, muss eliminiert werden.
  4. Alle Features oder Techniken, welche die freie Navigation des Besuchers einschränken müssen überarbeitet oder eliminiert werden.
  5. Jedes interaktive Element, dessen Bedeutung für den Nutzer nicht klar ist, muss überarbeitet oder eliminiert werden.
  6. Außer dem Browser selbst sollte keine zusätzliche Software nötig sein, um die Seite korrekt darzustellen.
  7. Inhalte müssen erstens lesbar, zweites druckbar und drittens downloadbar sein.
  8. Usability sollte niemals den Regeln von Gestaltungsrichtlinien geopfert werden.
  9. Kein  Besucher sollte gezungen sein, sich zu registrieren oder persönliche Daten preiszugeben, außer es ist dem Seiteneigner andernfalls unmöglich, eine Leistung anzubieten oder eine Transaktion zu tätigen.
  10. Breche diese Regeln, bevor sie irgendetwas grausames tun*

* schamlos aus George Orwells "Regeln für Schriftsteller" gestohlen

Übersetzt von: http://www.fatdux.com/how/our-web-dogma/

Posted in Blog | Tagged | Comments Off

canvas and no brush

Imagine you are a painter and a salesman tells you that you should get rid of your tools in order to have more space in your studio. "Your workspace is not cluttered by all the other things like brushes and colors. What matters is the painting, not the tools!"

This seems silly but it is analogue to what is popular in GUI design nowadays. Freeing the space for what you want to see or create seems reasonable. But the goal of somebody is not to just see something but to see what is interesting and to create great stuff. In offering the functionality to do that a visible GUI is superior in terms of efficiency and learnability to many alternative ways like hidden elements, edit modes or gestures.

But with the rise of the touch driven mobile devices the design decisions that were made for these devices are spreading. And screenspace is very, very scarce there, and it was tried to eliminate as much GUI as possible. But since mobile touchscreen devices and applications have the reputation to be instantly easy to use we apply their designs to other domains. On touchscreens – regardless of their size – we invent complex multitouch gestures and on big displays we get rid of scrollbars

GUI for a good reason: common WIMP Interface (Free Software; ImageSource)

But they ground on a conception of a GUI that merely takes away space for triggering actions that can be accomplished with hiding them via modes or using gestures instead. What should software do is to enable us to reach our goals. We want to read the right stuff and we want to create content efficient and without learning about gestures and hiding places of functions. The conventional select-command GUI paradigm does a pretty good job in doing so, even in contrast to other established techniques. But whether you use the trusty old WIMP paradigm or alternative approaches: don't hide the tools!

UPDATE (7.4.2011):
The unity design team came up with a solution for scrollbars that does save screen real estate and offers visibility. I strongly recommend to have a look at their design!

Posted in Blog | 1 Comment

embodiment and interaction

When you knead clay, you have a direct experience of what you are doing. You feel the clay on your skin, its resistance and its smell. But there is more to it than just senses. Action equals changing something here in its very physical appearance.What you do and think is  embodied and takes place in the physical world.

by Soyer Isabelle (http://nl.wikipedia.org/wiki/Overleg_gebruiker:Soyer_Isabelle) under CC-BY-2.0-BE (http://creativecommons.org/licenses/by/2.0/be/deed.en)

Technology in contrast is often very different. Devices need interfaces, enabling you to communicate with it. There is no unified experience. Input and output can be in different places and different times, feedback is not necessary immediate. Good designs simulate the unified experience of the physical world, but the communication between us and the world of technology needs to be carefully crafted, the media does not support it in a special way. The difficulties start not with digital technology. Appointments and schedules are not graspable either.

I don't argue that we went horribly wrong with technology. We can learn how to deal with the system, new conventions and ways around pitfalls. Technology enables us to satisfy our needs and help us to solve problems. But I argue that we need to adapt to these things as they don't match our natural way of thinking.

But the idea that we are embodied in a physical space and that our interaction with this physical world shaped our brains in nature and nurture is often forgotten or replaced by the idea that we have our bodies to carry our precious brains around to make them access new data.

Having in mind that our cognition is shaped by the experience on acting in the physical world can help tremendously to understand design principles: often these rules guide us to mimic what would be present in the real world and that determines our thinking.

Posted in Blog | Comments Off

Eric Reiss and Søren Muus @Design For Action

I am involved in organizing a lecture/workshop series (so called "Werkmodul") that aims for teaching interaction design at the Bauhaus. This is done in cooperation with Mozilla who contacted some great people and asked if they could mentor the students. I was very happy to hear that Cennydd Bowles, James Kalbach and Eric Reiss are with us for that – but I was even more exited that Eric and Søren Muus, who work together at FatDux, would even come for a real-life mentoring on the 27 of January.

What shall I say? The students and I, as well as Eric and Søren had a really good day I think. The mentoring was great for the students: problems in the details and high level questions like motivations and aims of the students were looked at and we got a bunch of hints and new ideas!

A break in the mentoring was made for Eric's guest lecture about his Web Dogma that was joined by many interested students from other courses as well. (and will be available at Mozilla's webpage soon)

After an incredibly interesting afternoon we ended the mentoring session the head full with possible improvements and Eric, Søren, me and a fellow student went out for having drinks, (crazy) ideas and dinner.

So: thanks to you, guys!

Eric Reiss' talk at the bauhaus

Posted in Blog | Comments Off

making gestures visible

Since the iPhone introduced capacitive touch screens to the consumer market we have touch gestures all around. Gestures are movements that are recognized and trigger a function. Web OS uses this heavily e.g. for closing applications, Apple uses them e.g. for making buttons for deleting mails visible.

It is invisible in current gestural/touch interfaces that gestures can be done and it is invisible what they do as well. Users must know how to use this gestures beforehand. The “natural user interface” that it proclaims to be, sucks. Don Norman wrote about this already a time ago, so actually I don't tell anything new.

There are no ways I know of that introduce visibility to touch-gesture-interfaces. So I made up my mind.

First the user needs to know that a gesture can be done and in which way. For signifying this, I used an element which is already a standard for mouse based interfaces: On scrollbars and at the corners of windows a "rough" structure shows that these elements can be moved. This has been around for some time. So in my designs this visual expression as signifier for elements a gesture can be performed on. Note that this as well indicates the direction of the gesture as the riffle runs opposite to the movement's direction.

what it looks like

Now the user still does not know what the gesture will cause – e.g. does it delete an item or starts reordering elements? – and when –  is a short movement that will cause the action or a longer one? I don't have a solution to show this beforehand. But at least this can be shown directly after the gesture is initiated: Close to the element but not obscured by the finger a button is shown – first transparent, after further execution of the gesture in greater contrast. When the distance threshold is exceeded, the button appears to be pressed. This again draws on the experiences with common interfaces and standards. Try it yourself: demo.

I am not totally satisfied: The gestures can't be more advanced and the result is not clear before the gesture is started. Any ideas?

Posted in Blog | 7 Comments