Janko At Warp Speed

Starting my own business

Tue, 13 Dec 2011 08:00:00 +0100

Some time ago I decided to take up new challenges and next week I am going freelance and starting my small business. I am leaving my company with which I will keep good relationship and where I met some truly great people. However, I feel it is time for me to continue chasing my dreams.

I have been working for years for different companies and besides my day job I handled multiple freelance projects. It worked for quite some time but it wasn't sustainable in the long term. At one point, the amount of work exceeded my free time and energy and after I nearly burned out I realized it's time to make a change. Luckily, I met some wonderful people and have truly fantastic projects, some of which you could've seen on my dribbble stream. I'm eager to continue working on the current projects and to start a couple of new exciting ones. Most of the future projects will be team work - some of my colleagues designers will work closely with me in various aspects of design process.

My moleskin is full of article ideas which I haven't had time to tackle but I plan to fix this in the near future. After all, I neglected this blog completely for the last 10 months! I will write about UI/interaction design principles and practical things I learned, thoughts on design research & usability testing and observations about being an in-house UX person.

One of the goals is to redesign my portfolio

This site will also need some work and the focus will be on my portfolio. Currently it says nothing about design processes and decisions I've taken on projects so I find it more or less useless. Also it lacks most of the recent work. Each project in portfolio will consist of a short case study and sreenshots that will reveal more details.

It will probably be hard, but more important is that it will be fun, and I am determined to do something really good. We'll see how it goes.

Innovation is all about iteration and refinement

Wed, 23 Feb 2011 09:00:00 +0100

There's a popular belief that innovation can only come straight from the mind of a genius. After the article User-Led Innovation Can't Create Breakthroughs; Just Ask Apple and Ikea has been published some people have taken it as proof that processes like User Centric Design (UCD) stand in way of innovation. I've spoken to my colleagues designers, developers and managers and it seems as if many (but not all, luckily) agree with this belief.

I believe this is wrong.

First and foremost, I think many people don't understand what innovation is. Innovation is not just something that is new, more creative and radically different. Rather, it is something that is better, something that has proven its worth for the people. If you invent something new, that is just an invention. If your invention is accepted and used by people, that's an innovation. Lightbulb, for instance, is an innovation. We know that because it changed lives of generations for the better.

Innovation doesn't come straight from a mind of a genius. Something new, creative and different might be a consequence of one brilliant moment of enlightenment. That's an invention. But to create an invention that is useful and that makes sense, one would need to evaluate and refine many different concepts. Some of them completely crazy. Most of them completely wrong. But we know which ones to dismiss and which one to refine only through iterations of trials and errors. Lightbulb, that I mentioned before became a useful invention only after 10,000 iterations.

Then there's a huge and important misconception about the UCD process. The misconception is that UCD, by focusing on users, forces designers to answer their wishes, stifles creativity and limits their ability to create something substantially different. UCD does focus on users, but it focuses on recognition of their needs, limitations, tasks, and goals. It's about understanding people which will help designers make the right decisions. It isn't about what people want - it is well known that people can't tell you what they want. Rather, it's about what designers want to make in order to meet users' needs or create something new and unimaginable for users.

Can you really make something better for the people if you don't understand them? Not listen to them as the article says, but understand them. Can you increase value for them if you are unaware of their goals? Can you predict the future if you don't know the past or presence? Highly unlikely. An innovation might be a sparkle in a mind of a genius, but I would argue that innovation is a consequence of a very hard, iterative process.

Prevent feature-creep by focusing on users' goals

Thu, 23 Dec 2010 09:00:00 +0100

There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

— Charles Antony Richard Hoare

Feature-creep or featuritis is a tendency to constantly add features which inevitably leads to complex products that are confusing and hard to use. To make matters worse, by adding features we move the product away from solving primary issues - the reason for making the product in the first place. Some products are even conceived with featuritis.

Adding features is the easiest to do in the world of software. There is no need for physical changes plus they are quick and easy to accomplish. Thus, most software products suffer from this disease.

What causes feature creep?

Most software suffering from feature creep are technologically rich solutions which arise from user and business people requests, as well as from marketing research. Engineers add features because they want to create a technologically better product. Because they are the ones controling the development process, we get a technologically advanced software which fullfils the business requirements, but is very difficult to use. On the other hand, business people want a product filled with features believing that would make it more competitive and wanted on the market. However, it must meet client requirements as well. Everything is about quantity with them: requirements, time and resources.

By asking the wrong questions like "Wouldn't it be cool to add this feature?", development teams add functionalities which are unnecessary for basic software purpose, the one that supports users' primary activities. As we know, intermediate users use only a part of software functionality, so a large part of the added features is not going to be used at all. Even when the team agrees to focus on core functionalities only, no one is quite sure what these are. There are only assumptions and guesses which easily lead to feature creep.

Users and their goals

Features are important - they present a picture of software capabilities and value. However, there is something more important which is usually left out - people. People who use the software. Without users in mind, without knowing why they do something, you only ask what are we building and how. The why is left out. Nobody is wandering if there is a need to build something. The users have goals and needs different from those whose create or sell software.

When user goals are not recognized, the only thing that we can focus on is individual activities and tasks. Tasks and activities, however, are only steps a user takes in order to achieve their goals. A task is uploading a CV, an activity would be applying for a job, but the goal is to get a good job. Since goals are what motivates people their tasks and activities will serve in achieving their goals; and as tasks and activities map onto features, it is clear they too are serving this purpose. If we don't know what the goals are, there is no limit to adding new functionality. This is where the true nature of featuritis lies.

Missing design process

A successful product requires not only good technology platform and satisfaction of business needs but also an adequate design process, which is usually missing. Instead of non-designers asking questions about cool features and making decisions based on that professional designers should, as an integral part of the team, seek answers to who the users are, how do they act, which activities they wish to perform and how the software should behave in order to meet their requirements.

Answers to these questions are available through various research methods, which should come before the development process begins. Research results should be modeled into Personas - presenting the central point for design process. Personas will always remind us of who we are designing (and developing) the software for and keep features under control.

Furthermore, various ideas will be researched and validated, iteratively, through people testing thus allowing us to create software accommodated to users rather than forcing them to accommodate to a software product filled with fancy features. So, an iterative, user-centric design keeps the users in focus throughout the design process and enables us to meet users' needs and goals. Thus keeping non-important features out of scope.

Good and bad (and very ugly) example

Take Dropbox for example - Dropbox does one thing and it's doing it well - it synchronizes your offline data with their online copy. No fancy features here. Dropbox is focused on what the users need. By answering the question "Why is Dropbox popular and not something similar, like Windows Live Sync, which is free?", Michael Wolfe explains in a short and effective way what's standing behind Dropbox success.

To much regret, it is far easier and cheaper to build a feature-rich software than to satisfy the needs and goals of users. We know this due to a large number of bad examples. I once came across an article (can't remember which or where, if anyone knows, please share) explaining how the problem of featuritis was solved by adding a feature which let's you choose a mode: beginner or expert. Another feature to cure featuritis! Unfortunately, this is how many software products look like today - difficult to maintain metastasized mutants, which scare the users.

Looks like something you saw recently?

Opera mobile window chooser, recreated with jQuery

Thu, 18 Nov 2010 09:00:00 +0100

It's always fun to play with jQuery especially when you are trying to recreate something that you enjoy using. One such thing is window chooser in Opera Mobile browser where opened windows are positioned below each other and only a portion of each window is visible. The one on the top is current window that is fully visible. Clicking on those windows is followed by some nice effect.

View demo

Our "windows" are nothing more than simple unordered list. Each LI element can have any content, as you can see in the demo. Initially the first LI element will be "the chosen window".

<ul id="container">
    <li class="current"></li>
    <li></li>
    <li></li>
    <li></li>
</ul>

On the very beginning we define how much each window will be hidden and how much it will slide to the left and right. Next, we assign ID to each window that will be needed later in the process and position them below each other.

var itemWidth = $("#container li").width();
// hide 50% of each window
var itemPosition = itemWidth * 50 / 100;
// slide each window 60% if its width    
var itemMove = itemWidth * 60 / 100;        

// move windows below each other and assign ID to each
$("#container li").each(function(i) {
    $(this).attr("id", i).css("z-index", 100 - i).css("left", itemPosition * i);
});

Now the main part. When user clicks on a window, several things should happen. First we determine the position of a clicked window and the previsouly chosen one. If clicked window is on the left side of the chosen window, all windows before the clicked one will slide to the left. Analogously, if clicked one is on the right side of the chosen window, all windows after the clicked one will slide to the right.

$("#container li").click(function(e) {
    // Get id's of the current window and the one that user clicked on
    var currentID = parseInt($(".current").attr("id"));
    var clickedID = parseInt($(this).attr("id"));

    if (currentID != clickedID) {
        if (clickedID > currentID) {
            // slide windows to the left
        }
        else {
            // slide windows to the right
        }
    }
});

Here's how we slide windows to the right. We take the ID of the clicked window (and add 1 to prevent clicked window to slide) and loop through the collection of windows to the end. We then first slide each windows to the right, move them behind clicked window (with z-index) and slide them back to the left.

var i = 1;
var total = $("#container li").length;
for (j = clickedID + 1; j <= total; j = j + 1) {
    $("#" + j).animate({ "left": "+=" + itemMove * i + "px" }, 500);
    $("#" + j).animate({ "left": "-=" + itemMove * i + "px" }, 300);
    $("#" + j).css("z-index", currentZ - i);
    i = i + 1;
}

Believe it or not, left sliding is more complex than right sliding. The reason for this is in the fact that windows will be sent to the back immediately upon clicking, so we need to postpone changing z-index for sliding windows to the moment when they are on the leftmost position. Then we can slide them back. We do this in the loop that will iterate from the first window one the left of the clicked one, all to the fist window in the collection.

var i = 1;
var total = clickedID - currentID + 1;
for (j = clickedID - 1; j >= 0; j = j - 1) {
    $("#" + j).animate({ "left": "-=" + itemMove * (i) + "px" }, 500);
    $("#" + j).animate({ "left": "+=" + itemMove * (i) + "px" }, 300);
    i = i + 1;
}
var i = 1;
setTimeout(function() {
    for (j = clickedID - 1; j >= 0; j = j - 1) {
        $("#" + j).css("z-index", total - i);
        i = i + 1;
    }
}, 500);

Now, before we slide windows, we need to remove class .current from the old "chosen one" and assign it to the clicked window. We'll also postpone this to the moment when windows reach their leftmost/rightmost positions.

var currentZ = 99;
var current = $(this);
setTimeout(function() { $(".current").removeClass("current"); current.css("z-index", currentZ).addClass("current"); }, 500);

At the end, we have one issue here. If windows contain links user might think they can click on the link even ehen they are semi-hidden. In order to fix this issue we prevent default click action by adding e.preventDefault() just below the if statement.

if (currentID != clickedID) {
    e.preventDefault();
    ...

We can also style links as normal text so that there's no doubt if there's anything clickable in semi-hidden windows. This way users can access the content in chosen window only.

View demo

I am somehow sure that this can be optimized so if you know the way, shoot it! If I find some free time (which is unlikely) I will create a plugin. Above all it was fun to play with jQuery after such a long time.

Empathy and web design

Wed, 25 Aug 2010 09:00:00 +0100

Although different people assume different things when it comes to design, the fact is that good design is often thought to be decorative and aesthetic. This applies to design in general so web design is no different. We admire beautiful design solutions that are mostly nothing more than eye-candy. Seems as if primary goals of many web designers are creating beauty and satisfying clients' needs where the client is often mistakenly considered to be an actual user.

Too often the essence of web design comes down to "Genius design" where everything depends on the designer's experience, appraisal and sensibility. It is not uncommon that web designers are people who have large egos. On one hand, ego is useful because it implies self-confidence, pride and expertise, but on the other it is very damaging because it also implies arrogance and selfishness which is contrary to the nature of design. One of the statements by a web designer/developer I have heard recently, explains this in an explicit way:

There is a warning... if people don't bother to read it, it's not my problem. I made it red, should be spotted better now."

If it is not our problem then it becomes a problem of our users and that is bad design. Design should solve problems rather than create them.

Also, the fact is that low barriers to entry allow large number of people to easily become web designers or developers which creates the impression that everyone can do it with minimum effort. One can relatively quickly gain solid Photoshop or HTML skills (and even master them), but that is not enough for a good design.

What's missing?

A good design requires knowledge of various design techniques, design principles, business requirements, technical constraints and the most important, understanding users, their problems, motifs and eventually goals. Understanding people (in this case users) to the extent that we can understand and share their emotions is empathy. That is an essential characteristic needed for a successful design, yet many web designers miss it. I would go even further and say that humility and overcoming your own ego are necessities. At least, it is necessary to create a balance between ego and empathy.

In order to understand users we need to understand their needs and goals that are often hidden - the user is not aware of them. It's designer's imperative to discover those goals. The best way to understand the users (and probably most popular among designers) is observation. By observing how people use products in their natural environments, a designer is able to get into other peoples' shoes and see what otherwise would be incomprehensible.

Observation, careful listening and talking with people give us insights into a completely different perspective. Through analysis of data obtained by observation we are able to explore various solutions, develop prototypes and evaluate them through testing. This is the basis for User-centric design. And it all begins with empathy.

Fortunately, there are attempts to emphasize the importance of users and show that users are not idiots but we need even more than that. Always keep in mind that we are advocates for the users instead of being advocates for the clients. Empathy comes after walking a mile in someone’s shoes. Get in those shoes.

Rethinking form validation

Wed, 21 Jul 2010 09:00:00 +0100

We all know how important form validation is. Users must provide required information, users must provide information in specific format, user must... Right. But imagine the scenario in which user saves a form even if validation fails. That is, when inappropriate formats are provided or required fields are left blank. Sounds ridiculous? To kill validation? Well, no - we just might rethink the validation process.

My team had a debate about this topic when we first read Alan Cooper's suggestions on data saving. We decided to try it in one of the projects. Developers hated it. Designers endorsed it. Users loved it. Let's see why.

How should this work?

Here's the scenario: user, who works in one of the bank branches, fills in the same forms every day. She deals with different forms, from simple to complex, such as leasing requests. If a customer doesn't provide all the information necessary to approve the leasing request, which happens often, she won't be able to submit the form and store it in central database. Sounds correct? Let's try again.

User, who works in one of the bank branches, fills in the same forms every day. She deals with different forms, from simple to complex, such as leasing requests. If a customer doesn't provide all the information necessary to approve the leasing request, which happens often, she can enter whatever information she has at the moment and store it in the central database. If some of the required fields are missing she is notified with inline validation that she needs to provide it later in order to process the request. If she enters some information in the wrong format she is also notified by inline validation that it should be corrected in order to process the request. But she saves the request. Incomplete, but she can save it.

User becomes more confident because she feels that she can't make a mistake. No errors, no popups, no interruptions. She can easily save an incomplete leasing request and complete it later. When she opens the request again inline validation will show which "required" information is missing and what data is in the wrong format. Of course, the leasing request can't be processed without information that is absolutely needed for calculations, so it can be processed once the form is completed.

Is required really required?

I deliberately placed the term required in quotation marks here, because required information isn't required in the way we perceive it. Information is required for successful leasing request approval but not for storing the same request in the database. Same applies to data format. So, think again why some information is required - to defend database integrity or to support users' goals.

Don't take this literally

This can't be applied to every single form. Of course, this makes sense mostly in so called enterprise web applications. For instance, it wouldn't make much sense to submit a comment on my blog without providing the comment and name. So I'm not suggesting that you should make the worst example of web form validation ever. You get the point.

One thing is certain - this would be a headache for developers. Not only because they love to defend the database in any possible way, but also because such approach would require much more work on their side. But more important is that there would be fewer headaches for users.

Issues with modal overlays on the web

Thu, 17 Jun 2010 14:00:00 +0100

Seems as if modal overlays are quite popular on the Web lately. A large number of easy to use plugins such as Lightbox, contributed to the expansion of overlays on the Web. Two years ago lightbox was named a dialog design technique of the year. Since then, overlays became a common way to show forms, feedback and other content.

But despite the fact that overlays are popular and easy to implement they should be used carefully. It is not necessarily true that modal windows improve user experience.

Issues

While modal overlay is visible, the page behind it (parent) is disabled and dimmed. This prevents users to interact with the parent and to refer to any information except that shown in overlay. If users need information in the background, this becomes a problem. Even worse, most overlays are not movable and cover the central part of the viewport. In such situations users are forced to switch back and forth between parent and overlay.

The least you can do in such cases is to make sure that information in the background is readable and the overlay is movable. The latter means that you should take affordance into consideration. Many lightbox plugins don't have a titlebar - an area that suggests that element is moveable. It should also contain a close button, positioned consistently across the site or application, preferably in the top right corner.

The other thing I noticed during usability testing sessions confirms what was said many times before - it might break back button functionality. Some users, mostly the ones that are not tech-savvy, just don't understand that they are on the same page. This is typically the case when overlay covers a large portion of the viewport.

So, if you want to use an overlay, what should you be paying attention to? Besides issues I mentioned in previous paragraphs, I'd include some of the recommendations stated in (a bit older) article A Farewell to Pop-Ups:

The user expects new content, and expects that content to be a diversion from the current task rather than intrinsic to it.
There is some advantage to the user in seeing the new content on screen at the same time as the existing content.
The pop up size is between one quarter and one third of existing window size. (If the size is less than one quarter, then the content should be moved onto the main page. If the size is more than one third, then you break the rule of context).

I would add that modal overlays shouldn't be used to show feedback messages in any case - there are some misconceptions that overlays are actually an ideal tool for this. Among some other mistakes, this is a common mistake in web form design. As addition to this, you should avoid using overlays to simulate confirmation dialog boxes.

Are there any alternatives?

Aza Raskin suggests two alternative solutions: a tray and a slide (sidebar or sliding bar). Both solutions are quite good alternatives for overlays. One of my favorite variations of a sidebar - docking sidebar is very efficient because it allows immediate interaction without breaking the flow or covering the area users are working with. Developers and designers should be familiar with such sidebars, as they are heavily used in development environments.

But, does all of this mean that you shouldn't use overlays at all? Well, least you can do is use them sparingly. What do you think?

Autosave my work, please

Wed, 02 Jun 2010 00:10:00 +0100

I was in the middle of writing a long text in one online web application (made in Silverlight) when my FireFox crashed (Firefox is doing a great job in restoring your work, but in case of silverlight or desktop apps, you just can't count on your browser). I lost the most of what I wrote just because the Silverlight application didn't have one simple function - autosave. This functionality periodically saves user's work and thus prevents data loss, or at least minimizes it - in case of software crash, only changes that are made after the last save will be lost. Although it seems as if it is quite simple function, there are some issues that need to be considered.

Frequency

Software crash doesn't have to be the only reason for data loss. Sometimes the internet connection breaks or user simply presses the wrong button - she closes Firefox window instead of one tab. This means that autosave should happen often enough to minimize the effect of unpredictable events. Alan Cooper suggests that, if possible, autosave should be performed after each keystroke or, in other case, when user stops interacting with the interface. When choosing autosave frequency one should always consider application performance and responsiveness, though.

Enable autosave by default

If an application implements autosave, it should be enabled by default. If autosave isn't enabled, chances are that beginners and perpetual intermediaries will never discover it. I believe I fall into intermediaries when it comes to Inkscape and I didn't even know it has autosave. But it has autosave functionality which is disabled by default. And since it crashes quite often, it happens that I lose hours of work. Although I am trigger-happy when it comes to saving, I tend to be carried away with design work and simply forget to save.

Unobtrusiveness

Besides this, autosave should be unobtrusive, which means that it should be performed in background without interrupting user's work. Here's an example of how things can go wrong for users when autosave isn't unobtrusive. I was typing an extremely important email in my webmail client when suddenly a green message box appeared - the same message box which appears after email is successfully sent. I instantly started to look for cancel/discard action and pressed it once I found it. Only seconds after I realized that was an autosave message. But the draft was deleted and I was quite frustrated.

Among many others, Google Docs is another example of obtrusiveness - after each autosave the cursor moves to the top of the text. I am sure this is a bug that will be solved but currently it is obviously more than annoying. Besides this bug, Google docs is a good example of how autosave should be done.

When document isn't saved there is information about the last save and enabled Save button next to it. After autosave the message changes and Save button become disabled. Also, autosave is being performed after each keystroke which eliminates the need for "Do you want to save changes?” popups.

A problem

However, autosave raises one important question - with each save, all previous versions of the same document become unavailable (undo can sometimes be helpful but not enough). Autosave overwrites the same document over and over again. For instance, user might want to edit some template and just print it without saving it at any moment, but autosave might overwrite the template. Some applications use versioning to fix this issue (by adding timestamp to a file name for example). Some, on the other hand, keeps the history of actions where each action refers to one of the previous document versions. But those solutions tends to be complicated and seems as if there's no definite solution to this problem.

In any case, if you are not sure about autosave functionality, don't think anymore and implement it - and keep the common save functionality and unavoidable keyboard support.

Why and how to create Microsoft Office Minibar with jQuery and CSS3

Sun, 23 May 2010 21:00:00 +0100

Although many will argue that Microsoft products are an example of a good design, Minibar was one of design refreshments that came out with the Office 2007. It is a variation of a toolbar that exposes context-related functionality. In case of MS Word, context is a text selection. Since Minibar always pops up near the mouse pointer it enables users to quickly perform actions related to a selection.

Check out demo

So how it works? When user makes a selection in input field Minibar pops up, semi-transparent, above the selection. When user hovers the Minibar it fades out. It disappears when user clicks anywhere in the input field or performs an action by clicking on a Minibar button.

Quite simple Minibar will be shown in this tutorial - it has only bold, underline, italic, and link buttons.

<textarea id="description" rows="8" cols="50"></textarea>
<div id="menu">
    <a href="#" id="bold">b</a>
    <a href="#" id="italic">i</a>
    <a href="#" id="underline">u</a>
    <a href="#" id="link">Link</a>
</div>

We need to make Minibar semi-transparent initially, and solid-color on hover.

#menu {padding:5px; background-color:#f5f5f5;
       background-color:rgba(245, 245, 245, 0.6);
       display:none; position:absolute; top:0px; left:0px; overflow:hidden;
       border:solid 1px #929292; border-radius:3px; -moz-border-radius:3px;
       -webit-border-radius:3px; box-shadow: 5px 5px 5px #888;
       -moz-box-shadow: 1px 1px 3px #555; -webkit-box-shadow: 5px 5px 5px #888;}
#menu:hover {background-color:rgba(245, 245, 245, 1);}

Fade it in and out

To be able to control Minibar position we will need to track the mouse position and use x an y coordinate to set top and left properties of its container. To show Minibar upon selection we will use .select() event, where its container will be faded in at the specific location. We also need to handle .mousedown() event in order to fade the Minibar out when user click somewhere else.

$(document).ready(function() {
    var mouseX = 0;
    var mouseY = 0;

    $("#description").mousemove(function(e) {
        // track mouse position
        mouseX = e.pageX;
        mouseY = e.pageY;
    });
    
    // Fade out the menu on any click
    $("#description").mousedown(function() {
        $("#menu").fadeOut("1000");
    });

    $("#description").select(function() {
        // get the mouse position an show the menu
        $("#menu").css("top", mouseY - 30)
            .css("left", mouseX + 10).fadeIn("1000");
    });
});

Handling clicks

Now when we know how to handle fading in and out, we can add some functionality. If we want to make a selection bold, we can wrap it with <strong> and </strong> tags (of course, it can be done with span element and some CSS but for the purpose of this tutorial I will wrap selection with tags).

function wrapText(startText, endText){
    // Get the text before the selection
    var before = $("#description").val().substring(0, $("#description").caret().start);
    
    // Get the text after the selection
    var after = $("#description").val().substring($("#description").caret().end, $("#description").val().length);
    
    // merge text before the selection, a selection wrapped with inserted text and a text after the selection
    $("#description").val(before + startText + $("#description").caret().text + endText + after);
}

This function, which relies on jCaret plugin wraps the selection with tags and merge it with text before and after the selection. Quite simple, when you have useful plugin such as jCaret. We only need to handle click events for each Minibar button.

$("#bold").click(function() {
    wrapText("<strong>", "</strong>");
    $("#menu").fadeOut("1000");
});

$("#italic").click(function() {
    wrapText("<em>", "</em>");
    $("#menu").fadeOut("1000");
});

$("#underline").click(function() {
    wrapText("<u>", "</u>");
    $("#menu").fadeOut("1000");
});

$("#link").click(function() {
    var url = prompt("Enter URL", "http://");
    if (url != null)
        wrapText("<a href='" + url + "'>", "</a>");
    $("#menu").fadeOut("1000");
});

Handling click events for bold, italic and underline actions is more than simple. We just call wrapText() function, pass it appropriate start and end tags and fade Minibar out. Handling click for link button is a bit different - we first need to prompt users to enter URL and then pass the URL inside opening tag.

Check out demo

Conclusion

As a regular Word user I am so used to this small toolbar and I am missing it on the web. I would really like to see it as a feature in WYSIWYG editors such as TinyMCE. It can also be a part of comment/contact forms. In order to play around with it more I will add it to my comment form as a part of the current blog realign.

Although it works in all major browsers, the code is everything but perfect - it can be optimized and more features can be seen here. Feel free to play with it and if you find any bug, please drop me a line.

Poka-Yoke in UI design

Mon, 10 May 2010 21:00:00 +0100

As I mentioned before forgiveness is very important principle in UI design. But error prevention is even more important - whenever possible try to prevent an error instead of recovering from it. Preventing an error to happen is known as Poka-Yoke principle. The first time I heard of it was in the book Designing for Interaction by Dan Saffer, but it is just another term for "fail-safe".

The purpose of Poka-Yoke is, according to Wikipedia "to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur. The concept was formalized, and the term adopted, by Shigeo Shingo as part of the Toyota Production System. It was originally described as baka-yoke, but as this means "fool-proofing" (or "idiot-proofing") the name was changed to the milder poka-yoke."

If you search for Poka-Yoke you will find some nice examples such as 3.5" floppy disks, where the shape of disks prevents people from inserting them improperly. But Poka-Yoke can be used in user interface design as well. Applying it to UI design means to prevent an error using constraints and correction, and to warn/inform users about the reasons for prevention.

Prevent actions and disable elements

Naturally, forms are ideal for applying Poka-Yoke. Its most obvious usage is preventing an action to begin until all of the conditions necessary to perform that action are met. For instance, don't allow form submission until all required fields are filled in. Disable submit button if input field is empty. Disable Delete all link if less than two items in the list are selected. Examples are numerous.

I'd recommend you to read (a bit old but good) discussion on ixda.org Hiding and Disabling Menu Items.

Restrict user's input

You can restrict user's input in many ways - allow only numeric characters, disallow special characters, limit user's input to a specific range or limit the size of user's input. This is usually done by rejecting user's input if invalid characters are detected. You should always make clear to the user why rejection happened (e.g. "You can enter only numbers"). Plugins like alphanumeric can be a good choice here.

Mask user's input

Similar to previous technique, masking forces users to enter information in a specific format. It is a good practice to reveal mask in input field upfront and make it clear to the user which format is allowed. The problem with masking is that help text is not always clear enough - would users know what "~9.99 ~9,999.99" means? In case when masking pattern is not easily understandable, it is better to show users an example of usage.

Correct user's input

In some cases, the application will be able to correct the user's input automatically without interrupting her/him. For instance, the application can automatically add "http://" to an URL if user omitted it. Another example is when user enters a value that is larger than maximum allowed. In this case the application can replace the user's input with maximum allowed value while letting the user accept it or change to another value.

Other helpful techniques

Use defaults

In some cases defaults can help further in error prevention. If user wants to book a flight and have to choose a number of passengers, you can set 1 as default (instead of leaving this field empty which will trigger validation later). Another good example I can think of is my android-based mobile phone. Each time user starts a new SMS message, upper-case button is turned on. When user types the first letter it turns off.

Use appropriate controls

Another good way to provide fail safe is to use specialized controls. Instead of using input fields for dates, use date picker controls and disable associated input fields.

Conclusion

Those were just some of the examples of how to apply Poka-Yoke in user interface design. The important thing to remember is that whenever an error is detected, make sure you provide a clear explanation of why the process is stopped.

On design process

Tue, 04 May 2010 09:00:00 +0100

After publishing the article Redesign process of JankoAtWarpSpeed, I was criticized by some people that I used Scrum "improperly". This related to uneven iterations, non adequate documentation and the fact that I was alone in the project. All of these claims are accurate. But I didn't use Scrum. It was rather an iterative design combined with some Scrum techniques and artifacts. Honestly, I don't believe that there is a proper way to use a process and that one process (or, more formal - a methodology) can be used in all situations.

So what I did was that I chose techniques that were appropriate for that project. Iterations allowed me to have testable prototypes and feedbacks, despite the fact that they didn't last for 2-4 weeks as it is defined by Scrum. Lightweight documentation (such as user stories) helped me save time and stay focused. Product backlog was a nice tool to keep the project under control since I was able to work only when I had some free time.

Formal methodology or process in this case would probably contribute to a never ending project. Although this was a personal project, this can be applied to any project you normally do for your customers. Each one is different and carries its own constraints and uncertainty. Sometimes the problem is tight deadline. Sometimes it's resources. And sometimes it could be the scope. Therefore designers should be able to adapt their processes to circumstances on each particular project.

The problem is present in large teams also. Teams often have their own processes or apply some of known methodologies, and they stick to them regardless of circumstances (of course, some practice only ad-hoc approach which is nonsense on its own). It is not rare that teams adopt a process after successful completion of a project. This becomes their one-size-fits-all processes. It is also not rare to see that methodology turns into a pure bureaucracy. Seems as if some companies adore ginormous, heavyweight methodologies.

If we say that a process is a set of steps and rules that we take to accomplish our goals, it becomes clear that these steps can't be used always and in every situation. Following steps of some process really doesn't guarantee success. It only guarantees that you will follow the steps. And, very likely, not repeating previous success using the same steps.

In his speech from 2008, Journey to the center of design Jared Spool compares process with methodology and eventually a dogma. But he also emphasizes the importance of tricks and techniques, or toolbox of each team member. The success of efficient teams (and individuals) is in knowing the wide range of techniques that can be used in different situations.

For the end I would quote Joshua Porter (taken from the article The Process Police)

No process guarantees success. If there were a process that guaranteed happy users everyone would be using it. But design doesn’t work like that: it’s iterative, responsive, ever-changing. You have to react as much as plan. You have to change your process on the fly to react to the marketplace. That’s why we need to optimize for what’s most important, a happy user, and do whatever it takes to make it happen, process be damned.

My dear Scrum fanatics, Scrum is not always the answer.

Create Windows 7 start menu using CSS3 only

Tue, 06 Apr 2010 23:00:00 +0100

I am fascinated with how much you can do with so little using CSS3. Many user interface elements that require images in order to have appropriate visual appearance now can be styled only with CSS3. In order to prove that I assigned myself a task to create Windows 7 start menu only with CSS3 (and some icons).

If we decompose the menu we'll get one div, two unordered lists with a couple of links each and a few icons. Let's see how each one of those is styled.

Check out the demo

Container

The container named startmenu holds two unordered lists that act as menus. It has linear gradient with three color stops: light blue at the top, dark blue in the middle, and another shade of light blue at the bottom. Transparency is achieved using rgba() which has four parameters. The first three represent red, green and blue color values and the last one is opacity. Two borders are created with border and box-shadow properties.

#startmenu { border:solid 1px #102a3e; overflow:visible; display:inline-block; margin:60px 0 0 20px;
             -moz-border-radius:5px;-webkit-border-radius:5px; position:relative;
             box-shadow: inset 0 0 1px #fff; -moz-box-shadow: inset 0 0 1px #fff; -webkit-box-shadow: inset 0 0 1px #fff;
             background-color:#619bb9;
             background: -moz-linear-gradient(top, rgba(50, 123, 165, 0.75), rgba(46, 75, 90, 0.75) 50%, rgba(92, 176, 220, 0.75));
             background: -webkit-gradient(linear, center top, center bottom, from(#327aa4),color-stop(45%, #2e4b5a), to(#5cb0dc)); }

Programs menu

This unordered list has white background and two borders created with border and box-shadow properties. Its links, which contain icons and program names, uses gradients and box shadows in hover state.

#programs, #links {float:left; display:block; padding:0; list-style:none;}
#programs { background:#fff; border:solid 1px #365167; margin:7px 0 7px 7px;
            box-shadow: 0 0 1px #fff; -moz-box-shadow: 0 0 1px #fff; -webkit-box-shadow: 0 0 1px #fff;
            -moz-border-radius:3px;-webkit-border-radius:3px;}
#programs a { border:solid 1px transparent; display:block; padding:3px; margin:3px; 
              color:#4b4b4b; text-decoration:none; min-width:220px;}
#programs a:hover {border:solid 1px #7da2ce; 
             -moz-border-radius:3px; -webkit-border-radius:3px;
             box-shadow: inset 0 0 1px #fff; -moz-box-shadow: inset 0 0 1px #fff; -webkit-box-shadow: inset 0 0 1px #fff;
             background-color:#cfe3fd;
             background: -moz-linear-gradient(top, #dcebfd, #c2dcfd);
             background: -webkit-gradient(linear, center top, center bottom, from(#dcebfd), to(#c2dcfd));}
#programs a img {border:0; vertical-align:middle; margin:0 5px 0 0;}

Links menu

As in the previous case, links menu is quite simple. But the interesting part comes in hover state. Each link has horizontal gradient with three stops: dark blue on the left and right side, and a bit lighter blue in the middle. Now, unlike programs menu links, here, every links has inner <span> element which contains text. This span element has one more gradient - vertical linear gradient. It is transparent in the upper half and the lower part goes from very dark blue to almost transparent light blue. The combination of two transparent gradients gives exactly the same look as buttons in Windows 7 link menu.

#links {margin:7px; margin-top:-30px;}
#links li.icon {text-align:center;}
#links a {border:solid 1px transparent; display:block; margin:5px 0; position:relative;
              color:#fff; text-decoration:none; min-width:120px;}
#links a:hover {border:solid 1px #000;
             -moz-border-radius:3px; -webkit-border-radius:3px;
             box-shadow: 0 0 1px #fff; -moz-box-shadow: inset 0 0 1px #fff; -webkit-box-shadow: inset 0 0 1px #fff;
             background-color:#658da0;
             background: -moz-linear-gradient(center left, rgba(81,115,132,0.55), rgba(121,163,184,0.55) 50%, rgba(81,115,132,0.55));
             background: -webkit-gradient(linear, 0% 100%, 100% 100%, from(#517384), color-stop(50%, #79a3b8), to(#517384)); 
             }
#links a span { padding:5px; display:block; }
#links a:hover span  { background: -moz-linear-gradient(center top, transparent, transparent 49%, rgba(2,37,58,0.5) 50%, rgba(63,111,135,0.5));
            background: -webkit-gradient(linear, center top, center bottom, from(transparent), color-stop(49%, transparent), 
            color-stop(50%, rgba(2,37,58,0.5)), to(rgba(63,111,135,0.5))); }

Here is the preview, but I suggest you to check out the demo. You can play with backgrounds and see how transparency works.

The code works fine in Firefox 3.6+, Safari and Chrome. It degrades gracefully in Opera and IE. I guess I could optimize it a bit so if you have any suggestions please let me know.

Creating a software product - are you doing it wrong?

Sun, 04 Apr 2010 23:00:00 +0100

The goal of software, be it web, mobile or desktop applications, is to help achieve business goals. However, without achieving people's goals, and with that the ones of software users, it is very unlikely that the business will achieve its own goals. This is why software projects should start with design, not programming. User centric design, that is, where accent is on understanding users and especially their activities. Not to diminish the value of other aspects, the quality of user experience is the most important.

You would think this is obvious? Absolutely not. The fact is that a large number of software projects neglect design completely and this inevitably brings about bad user experience. After posting Designing User Interfaces For Business Web Applications on Smashing Magazine and a large number of comments and e-mails that followed, I realised that problems I faced are still there and little is done to understand them and solve them. And, what are these problems?

The first problem is competency and responsibility. Most companies don't have a person in charge of making design decisions. That's what Bill Buxton calls Chief Design Officer (CDO) in his book Sketching User Experiences. Instead of having a person who'll make decisions and understand why they were made and what the consequences are, design is often everybody's and nobody's responsibility.

The next problem follows on to the first, and this is the work process. Although it is very ungrateful to generalise things, we could say that the process of developing a typical software project is oriented almost entirely at its functionality. By this I mean implementing business requirements. The problem is that business requirements describe only what and how the system should do (business rules), leaving out the fact that software will be used by people.

The process looks something like this:

Project starts by gathering requirements and writing a specification
Based on this, resources are planned and estimates given
Further decomposition happens to get from abstract to necessary implementation documentation
Backend and frontend are implemented
Designer is found to create a "theme" for the application (when I hear something like this my left eye starts to twitch)
Software is delivered (with a huge delay)
Users start using the software, after which starts a series of usability issues, complaints and a lot of work for support staff
After a while, it turns out that only 20% of delivered software is being used and sometimes it's not even used at all.

Although I've caricatured a little, you get the point. Many of us have taken part in this type of projects. Where are the users? Where is the interaction with people? Software is used by users and not analysts, project managers, or developers. Most project stakeholders create the software to suit their own needs i.e. for themselves. Most developers, for instance, just don't have the knowledge necessary to design a UI for humans. Just because it makes technical sense, it doesn't mean that it will help user experience. The technology is there to help people and not to make them its slaves.

To avoid these catastrophic scenarios, it's necessary to change the whole idea of software development, root and branch. So, instead of creating a "clean, professional and good looking theme" for a completed software it is necessary to design the behaviour of user inteface before the software is created. This includes various aspects of design, from determining the scope to interaction and interface design. Thus, decisions on user interface should affect the behaviour of the system and not vice versa. Technical contraints and business rules permitting, UI behaviour should not be stipulated by system backend implementation.

As Jessy James Garett says in his book The elements of user experience:

Everything user experiences should be the result of a conscious decision on your part. Realistically, you might have to make a compromise here and there because of the time or expense involved in creating a better solution. But a user centric design process ensures that those compromises don't happen by accident. ... It can be easy to fall into the trap of thinking that we are designing our site for one idealized user - someone exactly like us. But we aren't designing for ourselves; we're designing for other people, and if those other people are going to like and use what we create, we need to understand who they are and what they need.

This is certainly easier said than done, because as I have already said in the SM article - a good software product takes harmonization between needs and goals of both the business and the users. To achieve this you need to harmonize management, design and development. Otherwise, we come to a situation where everybody is frustrated, from developers and managers to clients and users.

Since this subject is somewhat neglected, I'd like to hear your experiences and opinions.

The real value of undo

Tue, 16 Mar 2010 23:00:00 +0100

The true value of undo lies not only in the ability to correct mistakes but also in encouraging exploration and learning which affects confidence in work. It is especially important that Web interfaces be forgiving and allow the users to get confidence since they mostly don't have it.

Although this topic was discussed earlier, a recent debate with colleagues lead me to once again, briefly, point out the importance of undo feature. Back in 2007, A List Apart published Never Use a Warning When you Mean Undo, and we are still not there yet. It is a shame that in 2010 this feature is almost ignored on the Web. The problem is that designers overlook the possibility to undo things on Web. Except for a few examples, all you can have are confirmation dialogs. Forgiving, but not enough.

Users make easy decisions and perform fast actions when they know they are correctable. They are confident in using such systems. For instance, they easily add a product to shopping cart but they are not even closely confident when placing the order.

In his book The Laws of Simplicity, John Maeda writes about undoable purchases:

Knowing that a purchase is correctable later makes the shopping process simpler because you know that any decision made is not final. Indeed, today's customers don't expect to be held accountable for their purchase. Eager to build consumer trust in their brands, companies are willing to assume the extra risk inherent in a returnable purchase. The losses incurred by the cost of returned goods are outweighed by the gains in customer trust. That is the power of undo.

So let's not forget that undo (and forgiveness in general) is much more than possibility to correct an error. It's much more than Ctrl-Z.

Win a free license for FlairBuilder, wireframing and prototyping tool

Fri, 05 Mar 2010 21:18:00 +0100

The importance of wireframing and prototyping in designing process is more than significant. These tools enable you to explore different ideas and test them before proceeding with next stages in the process. FlairBuilder, a tool for wireframing and prototyping can ease the job of creating interactive, testable prototypes. You have the chance to win a free license of FlairBuilder, thanks to its creator, Cristian Pascu.

Important note: the giveaway is closed.

A quick introduction to the tool

It is a prototyping tool that helps you create interactive and testable wireframes and prototypes with ease. With more than 50 available elements you will have more than needed to easily create wireframes. But the real power of FlairBuilder is in interactivity. You can define custom events for some of the elements and quickly create interactive, testable prototype.

Creating a project structure is very easy which will enable you to stay organized even with very complex prototypes. You can easily change between sketch and line art mode at any point of time which give you the ability to emphasize the fidelity of wireframes. Once you are finished, you can just switch to preview mode and test your prototypes. No compilation, no browsers.

I recommend you the check out coming soon page and see some nice features that will make this tool even more powerful in the future.

There is more to say about FlairBuilder but I will suggest you to download the trial version and explore its features.

The contest and how to participate

I am giving away two licenses for FlairBuilder to readers who leave the comment at the end of this post and share their experiences with wireframing and prototyping. If you don't have any experience, that is just fine - it is the right time to learn about it. You can also tweet about this contest.

Two winners will be selected randomly with help from random.org and announced on Monday, March 8th 2010 12:00PM (GMT +1).

Good luck!

Update: The winners are

Congratulations to the winners, and I hope we will hear their impressions soon :) Thanks everyone for participating and leaving valuale comments. It was really great to see different stories regarding wireframing and prototyping process.

Ultimate guide to table UI patterns

Fri, 26 Feb 2010 12:00:00 +0100

Many agree that tables are a phenomenon in user interface design: they are very important parts of user interfaces but often overlooked. Tables show structured data and their purpose is to make that data readable, scannable and easily comparable. The thing is that in many cases tabular data is obscured. This is why tables have bad reputation and many find them boring.

The truth is that the are everything but boring. For people who need tables in everyday work they are hated element that makes them scream. And it shouldn't be this way. Here are some of the patterns that can help in creating less evil tables.

Alternating rows styling

Ok, this one is pretty obvious. But is it? Take a look at the web applications (and websites) today and you will see that many don't apply it. So it is not obvious and that's why it's first in the list here.

By styling alternating rows differently you increase the ability of users to distinguish between overcrowded data in multiple rows and columns. You can use background color or background image. If background color is used it should be just slightly lighter/darker than a page background. For background images you should choose subtle gradients that match your color scheme. You can also combine background colors/images with table borders. Table header and footer should be easily recognizable and to achieve that you can use darker (or lighter) colors than table row colors.

BlinkCampaign uses subtle green color for alternate rows while keeping the header a bit darker.

Full row selection

If there is a single action that can be performed on a specific row, you can make the entire row clickable. This expands clickable area and declutters an interface. This can be used if, for instance, the only action you can perform on each row is view details. Each row should have hover state styled differently. There are several ways to achieve this effect, among which I would recommend you RowSelect jQuery plugin.

CrazyEgg uses full row selection to expand the details of the current selection (we'll talk about this pattern a bit later). Row which is being hovered is slightly lighter. I really like how they designed this area (as well as the rest of the application).

Table sections

When you need to group related rows you can consider using table sections (or table grouping). A section is a part of the table that groups related data. All groups shares same set of columns. For example, in a table that shows list of countries, regions are natural way to group rows. Each section should be styled differently and can be collapsible/expandable. Under each section you can show summarized data, if needed.

PulseApp uses table sections to show income and expenses details, but also to group data in subsections that will show even more details. Each section and subsection is expandable.

Sorting

Sorting is used for cases when users have difficulties in finding a row they want in a very large set of data but they don't know any keyword that can be searched by. Users also sort tables by columns when they want to compare adjacent information.

The common practice for enabling sorting on tables is to make header labels clickable. A column by which the table is sorted should be marked. This is usually done by placing an arrow next to column name, indicating in which order the column is sorted (ascending or descending). Clicking on a column that is already sorted should just reverse the order.

There has to be a clear difference between sortable columns and the others that aren't. It is a good practice to sort table by default by one of the key columns.

Quite usable plugin is TableSorter which is very simple to use. It sorts many known data types and you can define your own as well. It also supports multi-column sorting, but I a not big fan of it anyway.

OneHub application clearly marks the sorted column and sorting order. What I like about this design is that it uses realism even in such small details.

Filtering

Filtering is very useful when you deal with large amount of data. Use dropdowns, radio buttons or checkboxes to make filter selection. In the example below, builditwith.me uses dropdowns to filter the list of people by profession, interest and availability.

However, you can perform filtering only by predefined set of values. For instance, you can filter a list of jobs by it's type: full-time/freelance or by type: design/development. This means you can't filter by First/Last name because there is infinite number of variations. In this case you can use live filter which uses keywords to filter data. For live filter you use input field where users can type any keyword and list is filtered by keywords found in any column.

Builditwith.me has several filter options above the list and live filtering below it.

Pagination

When dealing with large amount of data it is a good practice to split them in pages. Pagination is commonly used pattern but in many cases it is ineffective. This works for search engines but that doesn't mean it will work in all cases.

Product Planner implements pagination in a common way - with page numbers and prev and next links. But can you tell what is on page 2? Page 3? Sure you can't. But standard pagination can be improved. Take EveryBlock example shown below. Since it is a large addressbook, they used numbers and letters to define pages. Although in their case all pages are shown this would work well with hiding pages as well. You can use the similar approach for other criteria by which tables are sorted. If table is sorted by date, you can show date ranges instead of page numbers (Page 1 can be shown as Feb 10 - Feb 12, and so on).

If pagination links become too wide, you can use common page numbers (as seen in previous example) and show additional information while hovering over links.

Continiuos scrolling

As a contrast to pagination, continuous scrolling reveals new sets of data while you scroll down the list. There is no option to go to a specific set of data as it is the case with paging. Instead, new set of data is being added to a list. During the load time a progress indicator should be shown. In the example below, a progress indicator on dzone.com is showing how many items are loaded.

There are certain usability and accessibility issues with this pattern so you should test if this work with your users. You can read more about this pattern on UI Patterns.

There is a variation of this pattern (or actually another pattern) that doesn't have such issues. Instead of revealing new set of data while scrolling, users can get the next set of data by clicking on more button, positioned at the end of the list. A good example of this can be seen on Twitter.

Fixed table header

This is a nice simple trick you can use to keep table header always visible. You can use it on fairly large and complex data sets to help users distinguish between many columns. I don't have any live example so if you know one, please share! FixedHeaderTable plugin can be a good example.

Headerless table

If data in a table if self-explanatory there is no need for table header. A table that shows emails can be a good example - email subject, sender and date sent are self-explanatory and distinctive data which doesn't require table header. However, there are cases when you won't be able to remove table header. If there are ambiguous data, such as two dates, you would need a header description for these columns.

Rivalmap dashboard is a good example of headerless table. The information in the table is obvious and formatted in such way that no table header is needed.

Expandable rows

I already wrote about this pattern and created a small jQuery plugin that you can easily implement. The key point of this pattern is to enable adding additional information or functionality to tables. BuySellAds, for example, uses this pattern to show advertising details about each publisher, while keeping the most important information always visible in master rows.

Row actions

Tables are often much more than a plain placeholder for endless data. They also can be interactive elements that can perform specific actions. Actions are usually performed on a single row (they can be also performed on multiple rows, see next pattern). Actions can be shown inline, they can be revealed on hover or shown as a menu.

Inline actions

The simplest way to show actions is to place them in line with row data, at the beginning or the end of the row. In the example below, Mixx shows voting action at the end of each row which makes voting quite easy.

Hover actions

This is variation of the previous pattern that can be used in cases when you have multiple actions. By hiding them and revealing them on hover you declutter interface and make more space for data. Project Estimator by Astuteo shows edit and delete action on hovering each row.

Menu actions

If there are a lot of actions you can perform on each row, you can show them as a many that can be revealed on hover or click. DropBox utilizes this pattern very effectively. Since there are a lot of actions you can perform on each file, they show them as a context menu.

Actions on multiple rows

A good approach in many cases is to enable users to perform actions on multiple rows. Users can select rows by clicking on a checkbox, usually placed at the beginning of each row, and perform group action by pressing one of the available group action links or buttons. I will use DropBox in example also. Users can select multiple files and perform one of the group actions available from menu.

It is also a good practice to enable select all/deselect all functionality which instantly select or deselect all visible rows.

Final thoughts

The article covered the basics of the most common table patterns and some live examples. If I missed something please let me know! I also recommend you reading two more articles about tables: Big Table issue that tries to find an solution for tables that are so big they no longer fit in the viewport, and 15 Tips for Designing Terrific Tables that shows many different contexts in which tables can be used.

Thanks to Theresa Neil, one of the authors of Designing Web Interfaces, you can read about three more patterns that she documented: Inline Editing, Super Wide Tables and In-column Filtering.

Process of redesigning Janko At Warp Speed, explained

Tue, 16 Feb 2010 08:00:00 +0100

Since I put a lot of efforts and time into the redesign of JankoAtWarpSped (it wasn't fast as warp speed, it was rather a snail speed) I would like to share my experience, thoughts and working process. The redesign process took several months (I can't even remember when exactly I started) because I am always overloaded with work and often have only a couple of hours weekly to work on blog.

The old site

I think the old site is a good point to start the story. The issues with the old site triggered the thoughts about redesign. I performed several different tests and collected a large amount of feedback and it became obvious that it has some serious usability issues. Dark background and poor readability, for example. There were issues with navigation. Many widgets cluttered the interface. A commenting experience wasn't so great neither, and in some cases it was quite confusing. Personally, I was far from satisfied with aesthetics. Those and some other issues was a clear sign for me that I should go with total redesign.

So the main goal were:

Declutter interface
Improve reading experince
Improve commenting experience to help have more people involved in conversation
Improve aesthetics
Provide enough space for new content
Create design that can be aligned later without a need for total redesign
Drop support for IE6

The importance of Agile

I am big fan of Agile principles. As the matter of fact I am working according to Agile for a couple of years, lately only with Scrum. Since I was a team of one, I decided to adapt Scrum to the needs of this project. I certainly couldn't have daily scrum meetings, but I took the advantage of iterations, user stories and product and sprint backlogs.

The image above was my product backlog and, along with several sketches, a complete requirements specification. I realized I will only lose time with traditional specifications and usage scenarios so I started with first sprint as soon as I identified main goals. At the end of each sprint (iteration) I had something that I could use for testing. Either sketches, wireframes or prototypes. However, I tested only with html/css prototypes.

Throughout many iterations I explored different ideas and concepts. Many proved to be bad ideas. And I am happy with that because the ideas I incorporated in the final design were the ones that proved to be the best.

The new design

My first thoughts about new design was about keeping it light and minimalistic. I started with classic sidebar at first, but I decided to remove it completely and go with the current solution. My main focus in the beginning was on the article view and not on the home page. Although home page is the first most visited page on my blog, about 90% of visitors land on article pages either from search engines or referring sites.

I wanted to combine hand-drawn elements (because I draw a lot and I wanted the design to reflect this) and minimalistic style.

One of the early sketches of article view and home page shows many element that proved to be bad ideas

Header and main navigation

I was playing a lot with header and main navigation. I tried with categories and rss box in header, with different background images (and without images), with many different layouts and the one I chose is the one with the minimum elements on it. Categories are no longer the part of the navigation. Readers access other articles through articles link, breadcrumb or categories in footer.

Links in navigation have a hand drawn hover background which I also use to mark the current page (other than posts). I also modified the logo a bit, so you can always see the actual logo if hover over it.

Breadcrumb separator is just one of hand-drawn elements.

Content

One of the main tasks was, as I mentioned earlier, to improve the reading experience. A light background with a lot of whitespace was a good choice. I organized 125x125 ads in one vertical column. Some may find this distracting, but it is a compromise between the needs and wishes. The intention of the left column is not just to hold meta data about the post but also to enable showing images and other content that is wider than the post width (the previous sketch shows an example of this).

Post footer shows information about the author, tags, categories and share options. There is no stupid related post widget anymore. I will create a list of related posts manually if needed.

Comments

Since commenting experience was one of my main goals I spent a lot of time thinking about the look of comment section and interactions with comment form. After many tries, I end up with the design shown below. The left column is used to show comment meta data ant the rest of the space for comment text and gravatar. This widens each comment and saves vertical space. Since I hate comments replies indentation, I was thinking a lot about how to indent replies but keep all comments aligned. I came up with the idea to indent only meta data and add small arrow before name. It turned out it was a nice solution. Since many readers scan through comment in searching for replies only, I added pale background to author's comments.

Trackbacks are placed below the comment form and are initially hidden, but can be easily revealed if needed.

The previous comment form design was confusing. It wasn't clear that comments are moderated and what is happening with the comment once submitted, there were no reply to comments and there was one unnecessary field. A new solution clearly shows what is happening with the system. Once you click on submit button, the form is submitted through Ajax. A huge hourglass is visible during the request after which the page is moved to the position of your newly added comment (this is animated with jQuery). There is a clear message above newly added comment that comments are moderated.

The image below is a sketch that shows what happens when you submit a comment, reply to comment or cancel a reply.

Home page

The home page is even more minimalistic. The last article is styled differently with meta data in the left column, image and continue reading link. All other articles contain only title and meta data below the title. A link at the end of the list redirects to a page where you can browse all articles. Although I tried several layouts, different features and traditional older and newer pagination (which I dislike, btw) it turned out that this design works just fine. Until some next realignment.

Articles page

The purpose of Articles page is to help readers find the content of interest by filtering articles by category or tag. By default, it shows latest 10 articles. If reader come from home page this will be a redundancy since they already saw a list of latest 10 articles, so I might think of some better solution for this (even though readers mostly come to articles page from pages other than home page).

Footer

The role of the footer is supportive. Readers can browse categories, subscribe, join me on social network sites, check out some of my work or read different books that I will recommend from time to time. A different styling should easily grab the attention while scrolling.

Technical details

The blog runs on the latest version of BlogEngne.NET, which I modified a lot to meet my needs. I use a touch of jQuery on several places. Color scheme is minimal, with shades of gray and blue. Visited links are a bit lighter than regular links. Lucida sans is one of the my favorite fonts on the web so there was no doubt about typography.

I decided to use grid system and I regret after a while. Not because the grid is bad (it certainly isn't bad) but rathar because it complicated things during the front-end development. I could achieve the same result with less time spent. The HTML and CSS inherited from the latest prototype so the code isn't perfect, but I really don't care much about that. I use one large image with CSS sprites for many details. For comment form and search box I use CSS3 borders that enables the level of details I wanted to have on forms, without affecting load time.

Inspiration

There is always a large number of things that influence and inspire. This is what inspired me the most during the redesign.

1. The Universe itself, but especially The Universe series on History channel and similar shows on National Geographic.

2. Drawings of Michelangelo Buonarotti and Leonardo Da Vinci.

3. Faith No More for fantastic music. Too bad I missed their concert in Budapest last year.

4. Sushi and robots website

5. David DeSandro's site

Final thoughts

I hope that I succeeded in explaining the reasons behind the redesign and each design decision. Thanks everyone for the feedback so far. I am looking forward to hear your comments and thoughts.

JankoAtWarpSpeed redesigned and a giveaway begins

Wed, 10 Feb 2010 10:39:00 +0100

After almost two years of its existence JankoAtWarpSpeed has been redesigned, this time dramatically. There were several reasons for total redesign among which are usability issues discovered in testing, feedback from readers and aligning the design with the goals for the future.

Update: The giveaway is closed on February 15th 2010, 12:00PM (+1 GMT), winners are announced at the end of the post.

Since I was occupied with many things at the same time, the redesign took much longer then it should, so I am very satisfied (and very happy) it is finally live! I am currently writing an article that will explain reasons and the process of redesign in more details. I will share my analysis results, thoughts, sketches and activities.

Feel free to explore the site. As always, I am looking forward to hearing your feedback!

Giveaway

To celebrate the new design I am giving away some cool stuff here.

1. One Happy Webbies T-shirt

Thanks to Lori from nGenWorks you might win a fantastic T-shirt with one of the most famous interwebbers,such as Jakob Nielsen, Jeffrey Zeldman, Molly Holzschlag and many more (see the image above). The winner will be able to choose the t-shirt and desired size. While you are here you might also want to download some of their awesome wallpapers.

Happywebbies are very professional, t-shirts are of a high quality so if you don't win one, I recommend you visiting their site and buy one for yourself.

2.One "Rocket Surgery Made Easy" Book

I guess that many of you read legendary Don't Make Me Think from Steve Krug. His new book, Rocket Surgery Made Easy goes deeper into the usability testing - how to find and, what is even more important, fix usability problems. The goal of this book is to introduce usability testing to non-usability professionals and guide them on how to organize and perform, what is know as discount usability testing.

If you are not an usability expert, this might be very useful book for you.

3. One Moleskine Sketchbook Pocket

I think that many know what Moleskine is but for those who don't, it is a brand of notebooks, sketchbooks, addressbooks, planners, etc. made by company named Moleskine. They are the choice of many designers and artists who use them to capture ideas, concepts and thoughts. It is a tool that you must have. I am giving away one pocket size sketchbook.

Update: Thanks to Topher from HTML Rockstars you might also win these two great books:

4. Sexy Web Design

Sexy Web Design is a book published by SitePoint. "Sexy Web Design is an easy-to-follow guide that reveals the secrets of how to build your own breathtaking web interfaces from scratch. You’ll be guided through the entire process of creating a gorgeous, usable web site by applying the timeless principles of user-centered design."

5. Simply JavaScript

Simply JavaScript is a book also published by SitePoint. "Packed with examples, Simply JavaScript is all you need to start programming in JavaScript the right way. Learn how easy it is to use JavaScript to solve real-world problems, build smarter forms, track user events (such as mouse clicks and key strokes), and design eye-catching animations. Then move on to more powerful techniques using the DOM and Ajax."

These two also can come as an aplogize, because my blog was down fo a couple of hours.

How to participate

Just leave a comment at the end of this post or tweet about this giveaway. If you leave a comment, feel free to leave your thoughts about the new design. The winners will be announced on Monday, February 15th 12:00PM GMT +1 as the update on this post. To make it more uncertain, the selection of winners AND prizes will be random. Good luck!

Update: Winners announcement

The giveaway is finished, and here is the list of winners.

Happy Webbies t-shirt: Markus Bürgler
Rocket Surgery Made Easy: Ashok (no lastname)
Moleskine Sketchbook Pocket: Chris Maynard
Sexy Web Design: David (no lastname)
Simply JavaScript: @desizntech (via twitter)

Winners will be contacted via emails in order to provide their shipping addresses. Congrats to all the winners and thanks everyone for the feedback!

Dynamic tabs using jQuery - why and how to create it

Tue, 26 Jan 2010 21:00:00 +0100

This tutorial will show you how to use jQuery to create tabs that can be added and removed dynamically. Although the example looks bulletproof, there are some questions I will raise about how to use tabs and in which context should they be used in order to make them meaningful and usable.

View demo

When we talk about tabs on web we usually think about tabs used for navigation. However, in this case I'd like to use them in a different context. I want to use them for showing different entities on the same page. By entities I mean anything from plain text to web forms. Actually, I will try to simulate tabs as seen in browsers. Well, at least to some extent. Take Google docs for example, instead of opening each document in a new window (or browser tab), you could open them in page tabs.

Questions

What kind of information makes sense to be shown in page tabs? This is probably the most important question to ask. I would say that you should use page tabs in cases when there is a set of actions that you can perform on all tabs at the same time. For example, you can search and replace text in all tabs with a single action and then save it again with one action. Next, read only information such as text and reports can also be used in this context. But what about web forms? What if I want to create an application that will allow management of different data at the same time? In one tab, I could edit inventory data, while in other I can view related data. Sounds interesting, but seems as if implementation would be too complex. What are your thoughts on this one?

Implementation

Ok, before I raise more questions, let's see how to create tabs. In this tutorial, we will assume that we have a list of documents that can be opened in separate tabs. Tabs with their content can be removed by clicking on "x" sign located at the right side of each tab. The constraint is that one document can be opened only once.

This is the HTML structure needed for the example. We'll use rel attribute for creating ids of elements and title attribute to create content. Please note that instead of using title attribute, you can load content in other ways, using Ajax for example.

<div id="doclist">
    <h2>Documents</h2>
    <ul id="documents">
        <li><a href="#" rel="Document1" title="This is the content of Document1">Document1</a></li>
        <li><a href="#" rel="Document2" title="This is the content of Document2">Document2</a></li>
        <li><a href="#" rel="Document3" title="This is the content of Document3">Document3</a></li>
        <li><a href="#" rel="Document4" title="This is the content of Document4">Document4</a></li>
        <li><a href="#" rel="Document5" title="This is the content of Document5">Document5</a></li>
    </ul></div><div id="wrapper">
    <ul id="tabs">
        <!-- Tabs go here -->
    </ul>
    <div id="content">
        <!-- Tab content goes here -->
    </div>
</div>

So, the usage should go like this: When I click on Document1 link, a new tab will be shown with the title "Document1" and content "This is the content of Document1". It will contain a red cross on the right side of the tab title which will remove the tab and its content.

$("#documents a").click(function() {
    addTab($(this));
});

This code will add a click event on each document link, and will pass the link itself to addTab function.

function addTab(link) {
    // hide other tabs
    $("#tabs li").removeClass("current");
    $("#content p").hide();
    
    // add new tab and related content
    $("#tabs").append("<li class='current'><a class='tab' id='" +
        $(link).attr("rel") + "' href='#'>" + $(link).html() +
        "</a><a href='#' class='remove'>x</a></li>");
    $("#content").append("<p id='" + $(link).attr("rel") + "_content'>" +
        $(link).attr("title") + "</p>");
    // set the newly added tab as curren
    $("#" + $(link).attr("rel") + "_content").show();
}

The addTab function will first hide all tabs (if there are any) and remove class current from all tabs. This class sets a different color for the current tab. Then, it will create a new tab (li element) that will contain a link for tab title and another one for removing the tab. The content is added in a similar way. At the end, the code will set the new tab as current.

So far so good, but this will be pretty much static - we have to add functionality to tabs. When tab header is clicked related content should be shown. Also, when red cross is clicked tab with its content should be removed. For these two scenarios, we will use live method that will bind events to existing elements, but also to all elements that will be added later to HTML dom.

$('#tabs a.tab').live('click', function() {
    // Get the tab name
    var contentname = $(this).attr("id") + "_content";
    // hide all other tabs
    $("#content p").hide();
    $("#tabs li").removeClass("current");
    // show current tab
    $("#" + contentname).show();
    $(this).parent().addClass("current");
});
$('#tabs a.remove').live('click', function() {
    // Get the tab name
    var tabid = $(this).parent().find(".tab").attr("id");
    // remove tab and related content
    var contentname = tabid + "_content";
    $("#" + contentname).remove();
    $(this).parent().remove();
});

The first function will add the content while the second will remove tab content. Now, there are a few more things to do. First, we need to implement a constraint which says that one document can only be opened once. To do so, we will extend addTab function with this code:

// If tab already exist in the list, return
if ($("#" + $(link).attr("rel")).length != 0)
    return;

The last thing we need to handle is the case when a tab is removed. With the current code, no tab will be the current one, and no content will be displayed. What should be done next? In this case I will assume that it will be the best to set the first tab as the current one, although we could also set next or previous one from the one removed.

We need to extend the function that removes the tab with this code (put it at the end of the function):

// if there is no current tab and if there are still tabs left, show the first one
if ($("#tabs li.current").length == 0 && $("#tabs li").length > 0) {
    // find the first tab
    var firsttab = $("#tabs li:first-child");
    firsttab.addClass("current");
    // get its link name and show related content
    var firsttabid = $(firsttab).find("a.tab").attr("id");
    $("#" + firsttabid + "_content").show();
}

Conclusion

Although the technical implementation is fine, the main thing you should think about is context. Used in wrong context this can add unnecessary complexity and usability problems. There are also several other things that need to be considered. What if we have large number of tabs? How should this be handled? The way Firefox handles it or some other way? Then, should one tab always be visible (same as Firefox, again)? Then, what about adding new tabs? Should they be added to the end or next to currently shown tab?

What are your thoughts about this? Have you used this concept before and where do you see its usage?

Homo Universalis

Sun, 10 Jan 2010 08:00:00 +0100

Let me get straight to the point: it would be great if all of us, somehow connected to design, aimed at being Homo Universalis, or as it's commonly referred to today a "Jack of all trades". To go a little further, many of us already are. As much as we regard ourselves specialists in some field, I think that various interests and every day activities show that we are not specialists at all. But, let's go back a little.

A story from the 15th century

To explain and corroborate my claim, I'd like to go back some 500 years to renaissance Italy. In the time of humanism and renaissance in Italy, a thought emerged that "a man can do all things if he will". The chief idea was that men have the potential for immense education and improvement in various areas. Ideally, this would encompass all known areas of arts and science. This is where we get the terms Polymath, Renaissance man or Homo Universalis. Today, a more accepted term is Generalist or Jack of all trades, even though these terms are often used in the wrong context, sometimes even negative one. You can read about Renaissance Man and Renaissance humanism on Wikipedia.

Typical representatives of that movement are Leonardo da Vinci and Michaelangelo Buonarotti. The first association to da Vinci is the picture of Mona Lisa, but it is definitely not his most significant work. He wasn't only a painter but a sculptor, architect, musician, scientist, mathematician, engineer, inventor, anatomist, geologist, botanist and writer. And he was good at most of these. If this sounds incredible, then you will be amazed by the fact that his inventions were hundreds of years ahead of his time. He drew blueprints for airplanes, helicopters, submarines, tanks, even concentrated solar power! It would take 500 years for his ideas to see the light of day.

Another "giant" of that time was Michaelangelo Buonarotti. According to Wikipedia, he was a painter, sculptor, architect, poet, and engineer. Those, a little more versed in Michaelangelo's life, will know that this is a sin he would never forgive - to call him a painter before sculptor. Michaelangelo, apparently, hated painting, publicly criticized and deprecated it. The irony is that he is mostly known for his painting and one of the greatest painting feats in the history of mankind - the painted walls and ceiling of the Sistine Chapel. He was, however, an excellent sculptor. His works are the pinnacle of sculpting world wide. Also, he was a very successful architect, just look at the dome of St. Peter's Basilica.

Although these two are the most famous, they are certainly not an exception, which is the point of my story. Almost every artist of that time had the same idea and aimed at achieving universal knowledge. Some had more success than others, but the want and craving existed which affected the art of the period and left tremendous heritage to posterity.

Back to 2010

So, what does this have to do with today? Everything. Rennaissance Humanism is based on rebirth of Latin and ancient Greek values, which are the foundation of modern civilization. People like da Vinci and Michaelangelo have left us not only the greatest works and ideas but also a model where "universal knowledge" is undoubtedly possible.

However, universal knowledge must be put in today's context. Although, during the Renaissance the Polymath had knowledge in arts and sciences, today it is a very large set of areas which is impossible to master. Industrial, technological and later information revolution have expanded the man's complete knowledge to unthinkable limits. Therefore, a Polymath of today would be a man (or a woman) possessing the knowledge of related fields. Da Vinci of today would, apart from web design, have the skills in UI design, interaction design, UX design, usability, front-end development and so on.

Diversification of knowledge helps, not obstructs

It certainly doesn't mean that a Polymath should be an expert in all fields, just as it wasn't the case with renaissance Italy artists. He could be a top UI designer, web designer and front-end developer and also have solid knowledge in other areas. This is how I look at this:

I believe that many can draw a similar diagram of their knowledge. How ever subjective, it will contain several specialties which you work with and possess a certain amount of knowledge in them. Secondary skills, summed up, can be greater than one primary area. I know what you are about to say, that someone's knowledge in total is not a simple sum of skills from other areas. And you're right. Someone's total knowledge is actually a synergy of their co-effects, meaning that by leaving out secondary skills you lose the big picture of someone's actual knowledge. Therefore, if you have other skills, don't discard them in fear of being characterized as "Jack of all trades, master of none".

Master of one or none?

The point is not to be a master of none. But, neither is it to be the master of one. The point is to expand your skills to become richer, more experienced and better because you have the ability to see the bigger picture. So, you can be a master in some areas and very good in others. Is there a law of nature that says that you can be a master of only one? Where's the limit? What's stopping you? Living in the fast lane? Lack of time? Social guidelines? Money? Commercializing all values? Think again as to what are the real obstacles and what are the excuses?

In the end, isn't it human nature to research and expand one's skills? Wasn't exactly that that allowed us to become who we are now - sensible, rational beings? Many species which have specialized in one area of life or nutrition have become extinct and, even today, are an easy prey of the evolution. We are where we are, the ultimate surviving machines.

You don't agree?

I know that many will not agree with what I'm saying and that for some specialization is the right choice. There were attempts to stand in defense of the jack of all trades. Still, my impression is that the predominant opinion is that specialization is the only right choice. And it's ok if you think so. However, I know that most of us can do it. If you have taken the Design something every day challenge, it's a good start. You could also learn something every day. Buy a book. If you are, for example a designer, learn usability. If you are a graphic designer, learn web design.

Why don't we renew these values lost somewhere along the road of universal human progress? What's stopping us?