Author: agup

4 reasons user interface workflows are important

This blog post is for teams that are looking to build new applications, or are rebuilding existing systems from the ground-up. User interface workflows are the steps someone needs to take in order to complete a single task. These are no different from any other system you may have for doing things in your daily life. We all have systems. Sometimes we implement our own systems without even thinking about it because we they can make our lives intuitively easier.

Some common examples of systems that you might use are making coffee every morning and then drinking it on the way to work. Or, taking the same route to and from work every day. Eating dinner at the same place every Friday night. Maybe you have a system for creating passwords. The list goes on. We often also refer to these as rituals. It’s rare, or perhaps even unheard of, for us to devise a ritual for ourselves that causes frustration or anger. Eventually a ritual, or system, can become a habit and then you don’t even think about doing it anymore…it just happens.

User interfaces deserve the same love and care as any self-imposed ritual or system you’ve ever devised. We’ve all experienced bad user interfaces: things are hard to find, or finishing a task isn’t intuitive, or the application breaks. A good user interface follows a natural progression and it simply just flows along with a minimal number of instances where you simply “get stuck.”

The 4 Reasons

Note, I’ve vastly simplified these reasons and I could certainly write a lot more on each topic. So rather than blathering on and making this an academic-grade paper, I think these speak for themselves and can hopefully spark constructive conversation within your team or organization.

Time and money. Intuitive workflows are enjoyable to use and almost second nature. If a workflow is non-intuitive, it can cost your organization time and money as users struggle to complete tasks. Long term technical support costs can be a direct reflection of how easy or hard your application is to use.

Attracting/retaining customer. If you own an online retail site, where seconds matter to web visitors with the sub-second attention spans, having a well-designed site can actually help attract and retain customers. New customers appreciate when a system is easy-to-use. Systems that take to long to learn can cause customers to leave and never come back.

Training costs. Training costs can be lower for well-designed systems, especially if the concepts are easier to grasp. More complex systems, of course, have a longer learning curve and involve more in-depth training and training follow-up.

Modification resistance. There is typically some resistance to change and change is inevitable for most applications as time goes on.  Re-training costs are almost always taking into account when systems are modified in any way. If a system has been well perceived to begin with then small changes may not be a big deal. However, if a system has a perception of being very complex then there will be an expectation that any new additions will also be very complex. It may be fair to say within an organization that any resistance to change increases along with perceived complexity of the application.

What are some examples of simple workflows?

I believe travel web sites have nailed down their workflows pretty well and we can learn a lot of from them. Competition is fierce in the travel industry and they live and die on generating high sales volume. Sites such as Hotwire, Travelocity and others have to get you the information you need as fast and as easy as possible or visitors simply go elsewhere. Because of this pressure, they have to deliver exactly what you are looking whether it’s a simple round trip plane ticket, or if you need lodging, rental cars, an entire travel package or more.

How hard is it to build a simple user interface?

In many software circles there are often discussions proposing it’s far easier to quickly start coding an interface and to simply get the project going than it is to take the time and design a really good interface beforehand.  If you’ve ever worked with a user interface designer you’ll have had this concept strongly debunked and new concepts drilled into your brain. Understand and agree on the design first with all interested stake holders…well before anyone types a single line of code.

It can seem counter-intuitive at first to hear about spending time at the whiteboard drawing story boards and diagrams rather than simply sitting at your desk slamming down lines of code and pushing out prototype after prototype. I can guarantee one thing: It is far faster, easier and significantly less expensive to change an initial user interface storyboard in something like Basalmiq than it is to re-write user interface code over and over again as different groups try to agree on the best workflow.

Calculate size of indexedDB database

IndexedDB has no built-in mechanism for calculating the size of a database. Below is a code snippet that shows how to calculate the ‘approximate’ size if you are storing strings. In my case we are storing Base64 images.

Depending on what data type you are storing here are some suggestions on how to calculate the size:

  • String. The example shown below simply uses the String.length property. You can typically get a one-to-one ratio where each character is equal to one byte. For example, if length equals 20, you can roughly assume that the size of the string is 20 bytes. However, if you have many uncommon characters in your strings those can equal 2 bytes each. For more information see this page on the Mozilla Developer Network.
  • Array. The size of an array depends on the array type and what you are storing in it. If it’s just a plain old Array of strings, such as [“a”,”test”,”something”],  you can parse the array for strings and then measure the size of each item within it as I just mentioned. If it’s a typed array you’ll have to take into account if it’s 8-bit, 16-bit, 32-bit or 64-bit. If you have numbers in your array, I believe all JavaScript numbers are 8 bytes each.
  • Blob. Access the Blob.size property.
/**
 * Provides the size of database in bytes
 * @param callback callback(size, null) or callback(null, error)
 */
var size = function(callback){
    if(this._db != null){
        var size = 0;

        var transaction = this._db.transaction(["your_db"])
            .objectStore("your_db")
            .openCursor();

        transaction.onsuccess = function(event){
            var cursor = event.target.result;
            if(cursor){
                var storedObject = cursor.value;
                var json = JSON.stringify(storedObject);
                size += json.length;
                cursor.continue();
            }
            else{
                callback(size,null);
            }
        }.bind(this);
        transaction.onerror = function(err){
            callback(null,err);
        }
    }
    else{
        callback(null,null);
    }
}

Usage

Here’s how you would use this in your application:

getSize(function(size,err){
     if(size > 0){
         console.log("Database size = " + size + " bytes");
     }
     if(err != null){
         console.log("There was a problem getting database size: " + err);
     }
}

Reference

W3C Specification for IndexedDB Database API
MDN – Blog

The 3 most important questions for building a successful website

I’ve lost count of the number of times I’ve been told by web development teams that a public facing web site must be okay because there haven’t been any (or many) complaints. True story. Okay…sure, that is one way to measure success. But now that I’ve called this out, most of you will likely agree this shouldn’t be the first metric you look at.

Websites need to be looked at through the lens of our users. I think people take things personally when they visit a website. Web surfers form expectations based on all the other sites they visit as they go about their day, it’s not just about your website. If you want them to come back often, they need to like using your website. It’s similar to anything else in life. If it’s frustrating to do something then you’re not likely to keep doing it over again for very long.

An excellent website that fosters long term loyalty will easily answer three questions:

  1. How easy is it to find what I want?
  2. How long did I have to wait for the pages to load?
  3. Did the website work on my particular device?

You may, in fact, have the most awesome, beautiful GPU intensive website ever built. However, if people can’t find what they want or if they have to wait too long to get it, or it just didn’t work on their device of choice then you’ve lost them. For example, if you are monitoring your website stats and notice a shift from iOS-based devices to Android, then you’d better make sure your website works on Chrome.

Certainly there are many, many other questions to be asked when building an excellent website and, of course, I’m oversimplifying things quite a bit. But the nice thing about these three questions is you can always swing the conversation back to them. Use can use these as a tuning fork to help build a solid foundation for success.

I think we can all take lessons from 3rd party travel websites. These websites operate on thin margins and they have to do only one thing to be successful: sell as many travel packages as possible. There is one thing that is absolutely consistent across the successful travel sites: the primary call to action is always in the upper left hand corner and it asks the three most important questions right up front. What’s your starting point? Where are you going? How do you want to get there? Bam.