Getting Things Done and Tangible Interfaces

If you walk into any bookshop it is very likely that you are going to find lots of books related to personal productivity and personal time management.

Reading a productivity book is not going to make you 120% more productive immediately and it depends on your personal management style, the type of work, your colleagues, the environment and many other things. There are no silver bullets.

These types of books offer generally complete methods of how to be work better and suggest that if you follow them you could be more productive. However, for most of us, this would require fundamental changes in the way we work. Rather than a full solution, such books can offer small tips that we can adapt to our context without having to go through major changes.

GTD or “Getting Things Done” is just one of them in which, in a nutshell, tells you to dump everything that you have in your head into little index cards and folders (following a very structured and logical workflow) so that you can focus on the task at hand and forget the rest.

Although you could implement the method digitally by using different calendaring applications such as MS Outlook, one of the interesting part is that the method tries to create “tangible instances” (index cards, notes, physical and fixed storage places, etc) of the things that are in your head bugging you. By “dumping” them physically, the mind is set free to concentrate on what is now important.

As these items are tangible now and organised in a fixed structure, logically and in a way that the items are highly visible, in principle, it requires less mental load to recall them and less "space" to store them in the shortterm memory system. Also, the mere act of writing everything down and classifying it helps the recall as it can create some form of context and in turn helping a bit the episodic memory system of our brains. As an example, forget your electronic diary and have a "tangible interface" to your ToDos/ToRemember/ToDelegate etc such as the Hipster Pda.


Source: 43folders.com

There are other things that can help the recall, such as the affordances* of paper based method versus the affordances of its digital counter-partners. In this context, tangible is better than digital and the paperless office is still a myth.

• Affordances in the sense of Technological Affordances by Bill Gaver

Introduction to MDA

Introduction to MDA

Source: ibm.com

MDA stands for Model Driven Architecture. MDA refers roughly to a way of modelling enterprise-scale interactive systems where the models can be executed. MDA separates the business logic from the platform specifics allowing vendor and tool independence.

In a nutshell (and in an ideal world), instead of programming as writing lines of code in your favourite tool and compile it to generate an executable, architects model the system according to the business processes and generate a PIM (a Platform Independent Model). Then using tools they can generate a PSM (Platform Specific Model) that is targeted to a specific system and architecture (such as J2EE or .NET).

IBM DeveloperWorks has published with their last article (of a series of 3) an introduction to the OMG standard MDA.

Part I
http://www-106.ibm.com/developerworks/rational/library/3100.html

Part II
http://www-128.ibm.com/developerworks/rational/library/apr05/brown/index.html

Part III
http://www-128.ibm.com/developerworks/rational/library/may05/brown/index.html

As Simple as a Bowl of Milk and Cereals

In this article, John D. Michell, using a bowl of milk and cereal as a metaphor for software development project estimations, points that the best way of making a good bowl of milk and cereal is to add little by little small amounts of milk and cereal.

Although the goal is clear (the perfect bowl of milk+ cereal) and even we could follow a recipe, the best way to achieve a good result is to adjust the ingredients. A plan is better than no plan.

The same thing happens with software projects estimations: it is pretty difficult to have a full picture at the beginning of the project of how long it is going to take and what challenges we are going to face (we can only estimate), and we need to make little changes as we move forward to adapt to the current reality.

….Pour some cereal, pour some milk, mix it all up, and taste it. If there's too much milk, add a small amount of cereal. If there's too much cereal, pour a wee bit more milk….

The consecutive iterations that take place while doing User Centred Design are the same thing. Even with the “perfect” user requirements specifications (the recipe) and the user research, all the ethnography made and so on, we will still need to adapt the solution as we implement and adjust it.

Less Is More, Again

Last month, Microsoft research run a workshop in Cambridge (UK) with the title “Less is More: Simple Computing in the Age of Complexity”. The title says it all.

If there is an example of a device that tries to do exactly the opposite, “More is More”, it has to be mobile phone with an ever increasing range of functionality, applications and services all cramped in a small form-factor.

The convergence of functionality, applications and services in mobile phones represents a problem for designers that have to balance the creation of interesting user experiences, useful applications and services and the hardware and physical limitations of the terminal.

The BBC is running an article where they interview Scott Jenson, one of the workshop participants. In the BBC article he discusses some of the issues that mobile operators face in the near future. You can also browse his website and read some of his articles related to the tensions between “More is More” (for the operators) and “Less is More” (for the users).

HCI and Emotions

Following my previous post, there will be a workshop at the British HCI conference dedicated to emotions titled:

"The Role of Emotion in Human-Computer Interaction"

http://www.emotion-in-hci.net


British HCI 2005 Conference
http://www.bcs-hci.org.uk/hci2005/

K.I.S.S. and Emotions

In the Japanese tradition of Kansei Engineering, emotions can be translated into product parameters. As the field of User Experience matures, more and more people are trying to define its limits, what it is and what is not. One example is to perceive UX as an overall quality of the product or service. On a higher level, it can even be possible to affirm that good user experiences are filled with not just interactions, but emotions and therefore UX has more to do with the "irrational" emotions than anything else.

More quantitative than qualitative, function (in the case of a physical product) and content (in the case of an online service) are also key parts of the UX. In this opinion article in the Scientific American, E. Tufte gives some clues about some principles of providing information that can be applied to UX: “Simple Design and Intense Content”. By keeping it simple and still useful/usable, there is plenty room for other aspects and not just pure functionality or usability. K.I.S.S can be a big contribution to emotional designs.

Perhaps good design is emotional. Focusing on K.I.S.S. can be an strategy that helps the design to be free of distractions and interruptions, facilitating flow and even perhaps facilitating emotions.