strona główna

Blog

Designing interaction at natrasie.pl

In August 2008 I joined four friends of mine, Tomek, Bartek, Michał and Sebastian, in a quest to create a cool new web application. For every one us it was a side project, done after our daily jobs. However, we were determined to make it successful and for it to bring us fame, fortune and glory. One year later... well, the glory is here. The rest should now follow easily.

Our intended audience are the travelers. We focused on the tourists and day-trippers, though diehard globetrotters should enjoy the website as well. We decided to make the trip experience the central point to the application. The website is supposed to capture that experience and let our users share it with others. The other important goal is to give travel ideas to people who are considering making a journey.

Taking all that into account, we decided to choose the name and the tagline: natrasie.pl – Wrażenia z podróży. In Polish it means something like On the road – Trip impressions.

I had a few roles in the project. I was responsible for interaction design, coordinating the work of the graphic designer and writing the front-end code. It was the first time I worked in a startup-like setup so I've learned a few lessons, especially in the area of interaction design.

When I joined the team, the guys already had some idea of what the application should offer. In order to clarify the functionality and ensure a common vision, I created paper prototypes covering each screen of the application. The prototypes were hand drawn and very low-fi. My complete lack of drawing skills certainly helped to avoid unnecessary details. However, even such rough prototypes were a great help. Most of the interaction design decisions were made during the discussions based on these prototypes. Although it's not possible to find and resolve every problem during this early phase, we achieved a common agreement on the functionality. Thus we had much less to discuss in the later phases of the project.

At the same time I've found Helena Pryłowska (aka Helen), a graphic designer who eventually created a brilliant visual identity and graphic design for our website. Apart from a formal design brief, I provided her with a second set of prototypes. This time the prototypes were much more detailed and polished. I used Omni Graffle as the drawing tool. I quickly fell in love with it. It is amazingly easy to use, has a big set of freely available stencils and allows you to create very different kinds of drawings. I used Graffle to create a site overview (using Jesse James Garrett's visual vocabulary) and mockups of each page.

Prototypes created with Omni Graffle, unlike the paper ones, contained all the elements that made their way to the final design. Before passing the mockups to the designer, we had the final internal discussion about each page. While most crucial decisions were made during the paper prototyping phase, detailed mockups helped to clarify a lot of details related to content and application behavior.

The mockups also made the work of the graphic designer easier, as she could focus on the visuals instead of guessing what should be on the page. It limited the number of iterations we had on graphic design. For most screens the first version from Helen was accepted, and only two or three times there was a need for significant amendments.

It's clear that the process we followed was quite “heavy”: it involved a lot of prototyping before we dived into the code. Because I had limited time to work on the project (approximately 10 hours each week) and each mockup was discussed with both the team and the graphic designer, it took us 4 months to go from the vague vision to the finished screens ready for the implementation.

However, it paid. First, the mockups helped to ensure effective collaboration with the designer. Secondly, when we eventually started to code, it went very smoothly and without a need to change the design significantly. All important decisions were already discussed and made, so we could spend the next few months translating this into the code. I also believe it helped to achieve a good level of quality from the very beginning, removing a need to rewrite huge parts of the application the very next day after it went live.

Of course no real project comes without blunders. The single most important lesson I learned? Design is all about the communication. Interaction design is no exception. This apparently obvious fact cannot be overstated.

The interaction designer is responsible for achieving a common understanding of the application within the team of developers and graphic designers. The prototypes themselves help a lot, but the way of presenting them to the rest of the team also matters. Initially I made a mistake of not explaining the prototypes sufficiently. During the process I eventually worked out a more effective way of presenting them.

A day before face-to-face discussion on mockups I sent them to the rest of team. In the e-mail I explained:

• the goals of the page
• design challenges it entails
• the rationale behind my design decisions.

It takes time to write such an explanation but it really helped us to have effective discussions the next day. Skipping this part can bring a lot of misunderstandings.

Tip: always write down the results of a discussion. We wrote minutes from every meeting. Later on we often referred to these minutes and avoided unnecessary arguments about established decisions.

Unless your team mates don't care about the project, they will probably disagree with you once in a while. How to handle this? First, ensure you have common goals for your product and want to reach the same users. A useful technique to achieve this is to use personas. The designer not only needs to create personas, but to make sure that everybody in the team understands them and believes they represent real target users. The lack of buy-in for the personas in the beginning leads to the pointless discussions starting with “Being a user myself, I believe that…”

The other solution to the last problem is the user testing. Unfortunately, it's also a first victim of the tight timelines. I strongly believe in the value of prototype testing, so the lack of it in natrasie.pl is almost like a personal failure. Because the prototyping phase took so long anyway, I decided to skip it.

It was a direct consequence of our team structure: there were four Java developers and one interaction designer, also responsible for the front-end code. It was no surprise that I quickly became a bottleneck. While the other guys were eager to finally put their hands on the code, I was still struggling with the mockups. The lesson? The interaction designer should start working as soon as possible. Otherwise the developers can become (understandably) frustrated by the lack of work in the early phase.

Fortunately they had managed to cope with me and we finally deployed our first public beta on 12th May 2008. It quickly became apparent that it's just the beginning of the real work: bug fixing, introducing new features and marketing. Though I had finished my work on the project at the end of June to work on other ventures, Bartek, Michał, Sebastian and Tomek bravely continue their journey to make the best web app ever. Good luck, guys, and thanks for all the fish :).

@media 2008

Another spring, another @media conference. This year's London installment was accompanied by the moody website with a promising list of speakers. The content was pleasing enough to deserve over ten kilobytes of pure text. Fellow reader, be warned.

“Designing Our Way Through Data” by Jeffrey Veen

Two years ago Jeffrey was presenting at @media 2006 as a newly hired Google employee. Now he had just quit Google. Apparently, being an ex-Googler is as hip as being a Googler two years ago.

In his talk, Veen demonstrated some of the challenges faced by designers of modern, data-intense applications. He used a few examples to demonstrate clever solutions to some old problems. The examples included:

• Harry Beck's Tube map. By hiding geographical relationships, the map puts focus on what's more important for the travelers: how to get from one station to another.
• Charles Minard's graph of Napoleon's march to Moscow. This brilliant illustration shows at least five dimensions of information.
• John Snow's map of cholera epidemic in Soho. Visualizing the dry data had helped to find and eliminate the source of the disease. It was probably the first time when real, scientific data was the main justification for a political decision. One could argue if it isn't still a rare case.

Being a fan Edward Tufte myself, I was glad to see that Veen recommended Tufte's books and used them as a source. He also showed how easy it is to make mistake of oversimplification. Modern presentation tools like Keynote or PowerPoint make it easy to “posterize” the data and obscure it with fancy ornamentation. Veen shared his own experiences with Measure Map design to illustrate these mistakes.

“Mental Models: Sparking Creativity Through Empathy” by Indi Young

Indi Young is one of the founders of Adaptive Path, the same company Jeffrey Veen had been working for before Google. Recently she had left AP to focus on her book about mental models. What is the mental model? This is another tool in your user experience tool belt, next to personas or wireframes. Below is a sample model, taken from J. Veen's presentation.

It's a two folded graph. The top part shows boxes representing user needs. This data could be gathered in many ways: from interviews, call center recordings, usability testing etc. It's important that it comes from users and shows their language instead of technical jargon. Boxes above the fold create mental groups (or towers – pretty obvious analogy when you look at the graph). Groups create mental spaces. Below the fold are the means to support user needs.

What are the advantages of using mental models? They make clear which user needs are sufficiently supported and which are not. Mental models could be useful when new features are planned, as they help to resolve the eternal argument: “what do users want?”

The presentation ended with the small pitch for Young's book.

“Designing User Interfaces: Details Make the Difference” by Dan Rubin

Dan Rubin turned out to be a great, witty showman. His presentation was very much a “design for engineers” course – probably that was the reason I enjoyed it so much :). He gave practical tips on how to use hardly visible details to improve the design. It's hard to pinpoint these details on the finished website, but they certainly add up to the feel of the site.

He mentioned several techniques for different design areas.

Proportion

• Create patterns for margins and paddings. Rubin showed the new cnn.com design where the “rule of 6” is applied and each margin is either 6, 12 or 18 pixels wide. He also used an obvious counter example. However, even the latter site could be improved by applying similar rules and Rubin demonstrated it with a quick compo.

Typography

• Use relative text sizes. You could follow the rule of 5 where text size for any element is a multiple of 5: 5, 10, 15.
• Adjust range kerning (or letter-spacing in CSS syntax) of headings. Usually it makes sense to use 1px negative margin for large fonts.
• Avoid widows. Currently it means inserting additional  . I'd love to have a CSS solution for this.

Texture

• Reality is rarely smooth. Applying light texture to the design could give it a more natural feel.
• A quick way to create a simple texture effect is blending one layer with the second, filled with noise. Similar technique was used on My Mile Marker to give the header a more “asphalt” look.

Tactile effects

• Interesting lighting effect can be created by stretching a 1-pixel edge from a photo and blending the resulting layer with another color layer.
• “Invisible” bevels are another way to create tangible look. Rubin gave an example of Mint and its use of bevels.
• Borders and lines can look more natural when combined with blending, as can be seen on Livtopia. To make color changes easier you can put black and white lines on separate layers and blend them with the rest, instead of applying color directly to the lines.

All examples can be found in Dan's slides.

“Professional Front-End Engineering” by Nate Koechley

Nate is a senior front-end developer at Yahoo! I'm a big fan of his presentations, filled with juicy technical details. This one was no different.

In the beginning he showed how the importance of the front-end engineering has changed during the last years. His own company is a good example. In 2001 Yahoo! had hired the first fron-end engineer. Now it has 700 of them. With more complicated websites and applications online businesses rely on the front-end as much as on the back-end part. Additionally, as Douglas Crockford put it, browsers are the “most hostile programming environment”. Anybody struggling with IE6 will surely confirm this.

Koechley listed what he believes are the principles of the professional front-end engineering. Each principle was accompanied by techniques.

1. Availability. It doesn't mean that every browser should display pages exactly the same way. Yahoo! uses graded browsers support instead.
2. Openness, achieved by progressive enhancement.
3. Richness – providing much, but not too much.
4. Stability – prepare for the future.

Nate shared a lot of practical tips for different areas of front-end engineering.

HTML

• Learn it through. There's a lot of rarely used but useful elements and attributes. Do you know every one? You should.
• Aim for performance when constructing HTML source.

CSS

• Focus on the left side: use precise selectors.
• Always think about maintainability.

JavaScript

• Quality. Use JSlint, profiling, and minimize touch points with vendor code. The last thing not only makes code maintenance easier, but also let browsers evolve faster. Koechley also mentioned unit testing. Apparently, all the major libraries (YUI, dojo, jQuery and Prototype) now have testing modules. For me it's the sign that JS is really getting mature. However, it's doesn't imply that everybody actually writes unit tests. <guilt>I don't</guilt>.
• Security. This is still the underestimated topic. The general rule is to never trust content from the client side. Koechly recommended watching the progress of AdSafe and Caja projects.

Accessiblity

• Watch ARIA.
• Use decoupled events, so any device can listen to your events.

Internationalization

• Serve all CSS and JS in UTF-8.

Performance

This is Koechly's hobbyhorse, so it was no surprise that he had a lot to say. However, his advice was taken from Yahoo's performance best practices, so I just recommend reading them. It's worth it.

Final words were a bit high-flown, but definitely right: always show stubborn empathy for your users.

“Communicating best practices”

This was a panel led by Paul Boag, including Rachel Andrew, Patrick Lauke, Murray Rowan (former head of European Web Development at Yahoo!).

Introducing web standards and usability-driven design to the management or the clients is a real challenge. I already faced it, so I was eager to hear some tips.

One advice from the panelist is obvious but requires empathy. When talking to your managers focus on business value and avoid tech-talk. Talk money, effort and user needs. Show the consequences of good and bad practices.

One of the panelists claimed that standard-based redesigns will last, as opposed to a mixture of content and presentation. In my opinion this particular point still needs a reality check ;).

Sometimes it's possible to just follow the right path without asking for permission. I find it to be true in companies when developers are trusted by managers (I'm lucky to be speaking from my own experience). Murray Rowan made a good point saying that you shouldn't hire people who add up to the problem, eg. are not used to web standards or usability-driven process.

There were a lot of tips on how to position yourself as an expert and thus have more impact:

• Do the homework and know your stuff.
• Don't be too picky – focus on battles worth fighting.
• If the managers push for timelines, fight for a promise of later quality iteration and enforce it.
• When you work for a customer forcing you to do something you believe is wrong, you can ask for removing your name from the website. It can make the client think.

Hot Topics

Both days of the conference ended with Hot Topics panels. The first one was more focused on design, the second – on front-end engineering. Here are some highlights from both panels.

Work between designers and developers.

Jeff Veen noticed from his Google experience that it's impossible to have the same amount of control over front-end people as over programmers. It's even harder with the designers. Forcing them to follow practices common for developers (like daily stand-up meetings or checking .psd files to source code repository) can make them mad.

Andy Clarke (a designer) mentioned how ridiculous it was for him to participate in the morning stand-up meetings. How a designer can refer his daily work? “I was thinking about tabs”?

It doesn't mean that it's impossible to work with designers in a team. The panelist talked very positively about Campfire as a tool of collaboration. As opposed to source control tools or bug tracking system.

What clients want?

Andy Clarke said it's a strong warning sign when a potential client wants a “Web 2.0 website”. Well, it's cool to be able to pick clients.

Front-end

It's still hard to define the front-end part of web development. However, it was welcomed with a loud applause that front-end nowadays is at least as hard as the back-end (Simon Willison). CSS knowledge seems to be the best common denominator for the professionals in this area.

Switching from corporate job to freelance

Simon Willison and Jonathan Snook, booth freelancers at the moment, shared a few tips. A good idea is to share an office space to avoid anti-social effects of working from home. They agreed that writing a blog is one of the best ways to get clients. The sooner you start it, the better. A 5-year-old blog should be a solid preparation before going to freelance.

Checked.

RuPy 2008

The last few weeks have been very busy for me. I attended two conferences, I'm preparing for a third one, and I've just launched a new web app together with my friends. All of these have been important enough to deserve a place on this weblog. So please turn a blind eye to the delay of my postings and let me start with a one-month-late report from the first of the forementioned events: RuPy 2008 – Ruby and Python conference in Poznań.

It was the second edition of the conference I wrote about last year. This time it was bigger, the list of sponsors was longer, and the speakers' page included more famous names. Fortunately, the conference preserved its “geek camp” atmosphere. The organizers, who were the students last year and are now graduates, had much more experience this time. The talks went according to the schedule, which was probably the biggest change from the previous installment ;).

The two talks I enjoyed the most were:

• Correlations and conclusions by Zed Shaw. Mr Shaw delivered a witty presentation on measuring performance of web apps. He compared web.py with Ruby on Rails in serving a “Hello world” application. To nobody's surprise Python's library won by an order of magnitude, confirming Zed's proposition that “Rails sucks”. While one could argue whether it makes sense to compare the efficiency of a fork and knife in a spaghetti eating contest, the show was entertaining.
• TDD in Rails by Andrzej Krzywda. Andrzej is a Rails developer with a Java background. He shared his practical experience with a test driven development in different languages. While he advertised TDD as almost the only sane way to develop a software, I'm still a bit skeptical. I work mostly on the UI part of Ajax-heavy applications, and it's hard for me to imagine even partial test coverage of complicated interactions. And what about automated testing of CSS layouts? I'm currently playing with Selenium, but my first impression is that it won't be a silver bullet for front-end testing.

I also had my own talk. I covered a few of the Amazon Web Services: S3, EC2, SQS, SimpleDB and Mechanical Turk. I demonstrated their possible use cases and pitfalls, plus Ruby API's. As I expected, people were mostly interested in Mechanical Turk, but unfortunately this service is available only for US developers.

As a side note, I had the worst possible time slot: Sunday morning, after the conference party. The party was good enough to stop most people from getting up in the morning.

My slides are shown below. RuPy folks have promised to put videos from the talks online on YouTube.

What's coolest about the conference is the people. My personal highlight was Netguru, a small code house in Poznań. I met three nice guys from the company: Adam, Wiktor and Kuba. It turned out they have developed the main competitor for the web app I've been working on recently. It didn't stop us, however, from sharing a beer at Saturday's party :).

Now I'm looking forward for RuPy 2009!

Book review: Envisioning Information

It tells a lot about an author when you learn that being dissatisfied with the quality of what a publisher could offer, he started his own publishing house. That author is Edward Tufte, professor emeritus at Yale University. Recently I had the real pleasure of reading one of his books: Envisioning Information.

My reading began with disappointment. The book was recommended to me when I attended a workshop on interaction design by Bruce “Tog” Tognazzini. So I was hoping for a guide on how to effectively present information on screen. But Tufte doesn't even aim for that goal.

He virtually dismisses the computer screen as a medium for presenting information. The book was published in 1990, so his comparison of computer applications from that time to a “grim parody of a video game” is very correct. Sadly, even modern displays can't compete with the resolution of Tufte's favorite medium: paper.

The attitude omnipresent in the book seems to be opposite to the trends typical in web design. The mantra of web usability is to let the user access key information quickly and effortlessly. While the goal itself is very worthy, it typically results in what Tufte calls “posterization”: limiting the amount of information presented in order to make it more “friendly”. Posterization is often accompanied by superfluous ornamentation that obscures its meaning.

Fortunately the author doesn't stop at criticizing today's trends. The book is a wonderful catalog of carefully crafted designs. They range from traditional Japanese calligraphy textbooks to train schedules. Each piece is accompanied by a description that puts the work into a broader context. Often it's a journey showing how visualization of a certain aspect of our world has changed through the years. A good example from the book is the evolution of sunspots depictions, from 17-century drawings by Galileo to today's computer-generated images from NASA. Tufte proves that the dry topic of statistical data can be told as an engaging story. He holds to his own saying: “If your numbers are boring, then you've got the wrong numbers”.

However, Envisioning Information is more than just a catalog of obscure images. The book describes few principles of information design that can be applied to any medium, even as barbarian as web browser window. Tufte shows how to use color, outline, text and other means to effectively visualize dense, multidimensional data.

Some of these principles could be applied directly in many areas of design. One is less tangible than others, but seems to be present throughout every page of Tufte's book: respect for the audience.

I noticed something contrary among designers and web developers who assume that people “don't read on the web”, have a short attention span, or are just plain stupid. That notion is so prevalent that it affects many designs found on the web. It also forces designers to remove important parts of the message and “posterize” it by favoring ornamentation over information.

Of course it doesn't mean that all the efforts to simplify designs should now be dismissed. Yet, there's a lot to learn from old media for the web design crowd and Tufte's book is a great guide through the history of solving design problems. The book gives a thought-provoking perspective on the subject of information design. And even if it won't change your way of thinking, it's definitely worth reading for the sheer richness of its content.

On passion, money and open source

Recently I had a discussion sparked by my article on open source licenses, published here in 2005. In a blog post accompanying the article I was wondering if it is possible to build a sustainable business model upon open source software (OSS). A lot has changed during the last two years and the topic of making money from open source doesn't seem to be so hot anymore.

As everybody out there seems to be concerned with startups and web-the-ever-inflating-number-point-oooh, I will gladly come back to more eternal topics like money and passion.

When I browsed the presentations from OSCON 2007, probably the biggest conference devoted to OSS, there was essentially no mention of generating revenue from the open software itself. The speakers were concerned with practical applications of the software. Even less technologically focused presentations covered topics like making the most from the community potential or handling difficult people in a team.

To the awe of some, there was even a talk titled “Open Source at Microsoft”. The same Microsoft which has a long tradition of condemning open source, and whose CEO once proclaimed Linux as a cancer. The speaker, Bill Hilf, summarized the efforts within Microsoft to get closer to the open source community. He announced that MS has started the process of obtaining Open Source Initiative certification for some of its licenses and opened the website with the meaningful address: microsoft.com/opensource.

So what has changed during recent years? Did somebody discover a wonderfully effective way of earning money from open source software, a way that is appealing even to Microsoft? I don't think so.

The lucky ones

There are few ways a company can make money from OSS. One is to create a new market around a piece of open source software. A good example is Zend, “the PHP company”. PHP itself is an active, open source project. But Zend has managed to build an apparently profitable business model on top of it. They sell all things PHP: from baseball caps, through training, to commercial development tools and optimizers.

This method is great for established projects with a large user base (or a smaller number of wealthy enterprise users). That way a company can get paid for software development and support, even though its core product is free. Obviously, it can work only if the software is popular enough to have its own market. However, starting a business with this model raises a number of concerns. It won't work if users can easily find some other free alternative and conveniently switch to it. It won't work until your product is mature enough for people to start investing their time and money in it. And if the user base is too small, guess what? It won’t work. Such a project can eventually turn out to be a source of revenue, but rather by luck than design.

Another way is to open the underlying code and charge for the services built with that code. This model is successfully employed by 37signals. The company used its own open-sourced Ruby on Rails framework to build web applications such as Basecamp or Highrise. While the framework itself is free, 37signals charges for the use of their applications and keeps their code built upon Rails. The good thing about this model is that you don't rely financially on the success of your open source code. It's the application build upon that generates money. If there are other people willing to use and improve the open parts of its code—that's great. But your bills don't have to wait until you hit the critical mass of popularity with your open source code. While you need to cross the threshold of popularity before your commercial product becomes profitable, that threshold is certainly lower than the mass necessary to make a living from something which is essentially free.

There are more ways of making money from an open source product. For example Mozilla uses Firefox's market penetration as a basis for a deal with Google: default searches in Firefox use Google, as described in a deal that turned out to be worth millions of dollars.

More than meets the eye

There is more than quick money to be made when it comes to open source. When a company decides to open some of its code, it can reap other benefits as well.

Firstly, it could be an effective way to outsource some parts of the development efforts. Obviously this is not always the best route, as “effective” doesn't mean “free”. The costs of maintenance and losing control over the code could outweigh the benefits; however, in some cases it can let developers focus on essential parts of the application and share components, such as an installer, with the open source community.

Some companies have their own core projects, but sponsor development of open source tools or libraries already available. The company then gets better, faster developed tools, and the rest of the world can benefit from it as well. “Rest of the world” includes competitors for that matter, but nothing is perfect in this world.

Finally, going open source is a way to build a community and gain mind share among developers. I think this is the case with Microsoft. Almost every programming geek I know thinks of Microsoft as an Evil Empire ruled by Satan himself (or two, when Steve Ballmer is included). Microsoft used to get away with this, but in the long-term perspective it's dangerous to ignore geeks. These include the people who are often the greatest programmers, and who will eventually have a huge impact on decision making—even in the largest companies. Having an active, motivated community around the product always pays in the long run.

Some people noted that Microsoft is losing Alpha Geeks; others claim that the company is now irrelevant for the programming crowd. Microsoft seems to notice this, so I think the rumors of its death have been greatly exaggerated. We shall see how it will adapt to the current prevalence of OSS, but I'm sure the people there are too smart to simply give up.

For I don't care too much for money

With this in mind, I don't attribute the lack of discussion on open source revenues to the advent of new business models. Open source is here to stay because it benefits programmers from the outset, regardless of whether a company is going to make money from it or not.

Working on an open source project is a great way for a programmer to develop skills and gain experience. There is also a chance to work on something that is far more interesting than ‘monkey-coding’ at a daily job. It can also be a very effective way to gain visibility and, eventually, a better job. Serious involvement in an open source project can open many doors, not only to Googleplex.

I can hardly think of any successful open source project that was started with the idea: “let's write some code, make it open and earn money from it”. The beginning was rather a matter of solving some problem, learning new technology or simply doing something for fun. When that passion is accompanied by persistence and—very often—pure luck, it is then possible to start thinking about profits.

Open source is not a business plan. You can end up being rich, but you probably won't if you start a project with this goal in mind.

Krzysztof Szafranek 2003-2005, some rights reserved