Splash Web Effects

When designing a website, or any user interface, we must consider context. What you are producing is a tool, not a product or an application. The better the design of the tool, the more use it will have, and the more it will be used. Designing for multiple levels of skill is something many coders lack in, mainly because they are power-users. What is apparent to them is not apparent to others, and what is contextually relevant to them is, again, obscure to the general populace.

In designing a website or other web-based application, we must consider what else the user is doing- using our application is generally not the sole focus of their task, but a tool to augment it. Whether it be a web-portal for a customer service rep, or a mobile application for tagging music- we have to consider what else is on their mind, and what else they may be interacting with. They may choose to stop using our tool very quickly, and then return to it at a later time- but how likely are they to do that? What are the ramifications of that action?

Mobile devices are short-usage only, and with short timespans the user does not have time to wait for a lot of images to load or an animation/splash screen to play. In Internet-enabled applications, a login prompt may be too much, especially if the data is not especially secure. Having a session expire daily, rather than an application-launch login event may be the way to go. Other tools, such as an intranet, may receive heavy use over a long period of time, followed by long periods of inactivity(like lunch breaks, or leaving for the day.) Where the browser is the application window. Triggering a login following a closed browser may be the best security route, since you are dealing with company data but don’t want to effect productivity.

We must also consider what the user sees when they see our icon, link or button. What are they trying to accomplish by clicking on it? What associates in the user’s mind when they think of using our tool? The human brain is very good at making connections and associations- but remembering ALL the tasks a tool can be used for is simply out of the question. What has to happen, in order to prompt it’s use, is for the user to associate the task with our tool. For instance, if our tool becomes “the button that lets me identify songs”, we have successfully marketed and designed a music-tagging application. However, if the user then wants to “find more songs like this one”, and the answer to the question “what tool should I use” is Pandora, or Last.fm- we have failed in either the placement of the “suggest more songs like these” button, or we simply do not return results relevant enough to the user. We will assume we do however, provide the best service available, being that this is an article on design and not algorithm.

When the user reaches out for related tasks, we want them to look at our tool not as a “multi-purpose” tool, but a “category” tool. If our tool is modular, we need to integrate with other, categorically-relevant tools (consider Shazam’s youtube, twitter, and iTunes integration) in order for the user to associate us as their “category” tool. In being a portal for anything associated with that category, we can ensure use despite alternatives.

Inexperienced users often flock to one-stop-shop applications because they see categories as entire tasks. When they want to “do email”- they click on outlook. This also involves calendars, task lists, contacts, even newsgroups. This is not seen as a multi-purpose program for many tasks, rather all of those tasks are part of email- and email itself is a category we might call “communication” or “business” or “productivity”. Thus creating an “Email” application must take into account things it belongs in the same category as, as well as things it might relate to. The more category-related things it can do (and the more seamless it can make them) the more polished, intuitive and “easy” your tool is.

Do try to maintain however, category apps. Mozilla has Firefox and Thunderbird for a reason- they didn’t want their “Internet” application becoming too big. By keeping the applications themselves light enough to respond quickly, and yet featured enough to encompass a category, we have successfully created a tool that is associable to a particular activity, rather than a specific function.

On a mobile device, this idea is very different. People use an application to perform one or two specific functions, and have a multitude of other applications to choose from. Consolidating here is not recommended as it will slow your application down when time is of the essence. Adding additional functions to an app based around a leisure activity is fine, but any application that has to be used quickly (song tagging, flashlight, 911 dialers) is suicide.

If your service is modular and we are simply concerned with network penetration instead of forward-facing usage, you can consider creating a web service, or API to interact with other websites. Modularization is a characteristic of the web and most people don’t want to receive all of their content from one provider- even if they do want it all in one place. Consider letting others plug into you, rather than attempting to be a full show when you’re a sideliner at best. It’s OK to be a sideliner, this is the web.

We’re all sideliners here. Even Google.

In an intranet however, things are different. Launching of different websites or “systems” as users often refer to them hurts productivity. When a user has to click back and forth or even manually migrate data from one “system” to another, we have failed in the basic mission of computers: make data easier to organize, and less work to manage. If you have data entry staff that don’t interact with handwritten items, there is something seriously wrong with your system.

Humans are not technological stopgaps- they are the reason technology exists. Taking one system, modularizing it and creating an interface that allows for quick access to other parts of the system is no small feat, but it is worth every second of effort. An (overly) simple rule of thumb is that for every hour a programmer spends optimizing a program, or a designer spends optimizing a design, 1000 man hours are saved each year. This goes for big operations as well as small- even small businesses need to save precious hours in a day not processing data- that is the computer’s job.

Smooth navigation is key here- try to make the “drilling down” process easier to manage, by ensuring a map of the site is available on each page. Keeping this map navigable by utilizing dropdowns and expanding trees rather than having the user “back out” of what they were doing and having to “go back in”. We aren’t walking down tunnels, we are on an open plane- point to point navigation needs to be simple.

Human thought processes have a momentum about them- they have to get going before they can stay on one track- such is the case with work. Focusing on a task involves minimizing distractions and freeing your mind of nagging tasks- this is why getting “re-engaged” after interruption(phone call, lunch, or just getting there in the morning) is a huge productivity drain. By minimizing the “set up” process and keeping “re-engagement” to a minimum using efficiently designed user interfaces, auto-completion, user-specific frequent links, bookmark-friendly URLs and a logon page that directs you to the last used page, rather than starting you at the “top”- these practices and others will create a seamless flow into work, allowing users to flow in and out of using your tool, instead of making the tool the task in and of itself.