I'm gonna hop on a soapbox. I mean, what's the point of having a blog if you don't rant and rave at least some of the time? I wanna yack about UI a bit. Now, I'm not a UI master by any means - but I do think that I've learned some good habits throughout the years. So, here's some of the things I've picked up - and I'm sure most of you probably know this already too. But I find it good for me to keep these ideas in the forefront of my mind when designing UI. It's all too easy to be lazy and crap out some generic unfriendly screens.

Why good UI is so damn important

This is one that I think some software developers seem to forget. The UI is everything to the user. Yes - we know that the biggest challenge seems to be just getting the software to work in the first place, but to a user? That has to be a given. If they don't even have confidence that your software will work in the first place, then you might as well as well print out all your code, delete the files, and burn the printed copies (just for symbolism). At that point it's useless. It kind of sucks that what for us is the most important part, is just flat-out taken for granted by users. And the second something doesn't work? That's when they fall back on whatever they used before - paper, or an old system. Since they pretty much want to do that anyways, so lets not give them any reason to.

So, when the underpinnings of the system take up the focus of a development effort, UI seems to be 'tacked on' last minute, in lots of cases. And that's just unacceptable. Remember - the UI is your user's ONLY connection to this software - it has to BLOW THEM AWAY. Sometimes, "just working" isn't enough. And honestly - if that's your high bar there, then there are serious issues elsewhere.

On top of this - software gets more and more complex every day. With each round of new and improved technology, the demands of the software produced with it grows. With all this extra functionality, presenting it to the user in a coherent, obvious, easy-to-use fashion is a SERIOUS challenge. Some think "Eh, anyone can design a UI" - wrong. Might as well say "any high school student can develop software". I mean, yeah, something can be produced, but it's liable to filled with bugs, short-sightedness, and be unfriendly both to users and future developers on the product.

So - UI is extremely important. Without good UI, noone will use our software, regardless of how robust it is underneath. What are some ideas, tips, and tricks we can encompass to make sure our UI is at least decent?

Visual cues

Reading is so 1999. If a user has to read a novel before they can figure out what to do a screen, they're going to hate your software. Clever uses of images and color that immediately signify what the corresponding action of information is will make your software seem like even a baby could use it! And given that oftentimes, our software is targeted to people who aren't very technically savvy, that's a very good thing.

For color, I find it's useful to use it to indicate a non-normal status. Read that again. That's a tip that was given to me by Dave Garcia - when developing Acuff, for balanced bills I would show green. For unbalanced, red. But, applying this rule, balanced bills show up as the default text color (in this case, black). The reason for this - balanced bills need no action taken. It's the unbalanced bills that are problems, and require an action. So, using color to signify something that is wrong, or out of the ordinary, can visually lead someone's eyes to areas they need to correct items. When things are fine, then just leave it as is.

With images...well...I'm not a graphic designer. Chances are you aren't either. I mean, yeah, I can fumble around in Photoshop (actually, I prefer Paint.Net - it's free. Purdon turned me on to it a while back). But you know who IS a graphics designer? Lots of nerds on the internet. Now - I'm not talking about images for your whole site (although, there are free website skins/templates out there as well), but for images relating to actions. And there are plenty of free icon sets out there for you to use. I find googling for "[action] icon" to be very useful. Like "edit icon" or "save icon". That's easy to do, you'll get lots of results, and looks alot nicer than a buncha text all over your screen. Sometimes you can find a set, then adjust the colors to match your site better.

The end result of all this? Your screens will looks cleaner and more focused. And to the user, this makes it seem simpler. There's an idea of "positive whitespace" - that empty areas of a screen make it seem less confusing. <Martha> It's a good thing </Martha>

Lead the user

When your software is being used, at no point do you want your user to say "Well now what do I do??!??!!". If that happens, you have some work left. Remember - the goal of a user interface is to provide an easy-to-use mechanism to access all that cool functionality built underneath it.

On each screen that you develop, all options available to that page need to presented in a clear and concise manner. This isn't always an easy task - but neither was all the work put in underneath this software, right? So why cheapen it. Take the time to do it properly. At each screen, put yourself in your users' shoes. What question will they ask themselves? Some of the obvious ones are "How can I change this data?", "What if I need to remove this data?", "Is there more detail on this data? If so, how can I get to it?". Those are the standard edit/delete/more-detail scenarios. And they can all be represented by images, yay!

But there may be some more complex scenarios as well. Like "Where else is this data used in the system?", or "I need to enter information that's almost exactly the same as this in another area". Digging out these scenarios that are applicable to your user base, and making the least amount of clicking/typing as possible for a user is where your UI can go from "well, it works" to "this actually helps me get my work done faster". And that's the goal we want.

One last bit - and this has caught on alot in recent years, but it's my blog, and I'm going to type it anyways, so live with it - is home areas. The first screen a user sees when entering your software is extremely important. This usually includes "jumping off" points, that lead a user to more in-depth pieces of the system. Another good idea is tracking what the user does - what reports do they run all the time, what searches are common, what specific object do they always look at. Then, you can present these as well as on the home screen. Home screens are also useful for "quick entry" things - like say time entry, or daily tasks, or quick notes. The home screen is the first thing a user will see - they don't need to go exploring menus to find out how to use your software. Your software needs to present them clearly and directly to the user. Overtime, that user may become more of a power user, and navigate the site purely by the menus - but first time around, it's our job to make what needs to happen obvious.

Present relevant data first

Now, I think this is an interesting one. I applied this to several places in Acuff. This is especially problematic when you're building software that accesses a pre-existing database, with years and years of data (which Acuff has). Sometimes, the list of data and options present in the database can just get incredibly huge. Now - we don't want to restrict the users ability to get to these items. But in cases where it's known that over half the options won't be used in 99.99% of the time, it's up to us to do what we can about it.

"But Rob, there's no way to know!" Shut up. Yes there is. The data is RIGHT THERE in front of us! A simple query to check in the database to see which options are used many many times will reveal it for us. Play around with the cutoff amount until you have a list that presents many options, but isn't unwieldy. Maybe also check by timestamps where applicable. Using this, you can extremely cut down that drop-down list or the amount of rows to page through. A simple checkbox with "Show All", and the user can then get the entire list. The user does less scrolling, their system "seems" less bloated, and they're happier. Everyone wins.

If it's even a slight annoyance to you, it's a huge problem

We're the techincal elite. Noone is more badass when it comes to using computers than us. I mean, not only can we use the stupid things, we can completely alter how they work! Holy crap! But remember - <BenParker>With great power, comes great responsibility.</BenParker>

What this means is - if you're developing your software, and if you find something that even bugs you just a little bit - CHANGE IT. FOR THE LOVE OF GOD CHANGE IT. I know it's extremely tempting to just "let it slide". I mean, after all, it's just one extra button click, right? CHANGE IT.  Let's just break this down to actual numbers. Let's say it takes 30 minutes for you to alter something that only removes what takes about 5 seconds for a user to do. Seems like kind of a bad trade-off, right? Wrong. Your user is going to see that repeatedly. Over, and over, and over, and over...and this will build resentment. Soon, the user will focus on how many times throughout the life cycle of this software they've had to click this extra button for no reason, when the software knew the intention of the action. Then, they're hating your software again. It doesn't matter that it works underneath. They're now annoyed, and your software is complete crap in their mind. Those 30 minutes pay off in spades, when a year later, they still love using your software.

Another good example is pre-population of data. Why have the user reenter all the information, if 90% of it already there in the system? The ability to copy->modify->save will make your users' head explode with happiness. There are of course cases where you want to make sure the user re-enters everything, but in cases where this isn't a problem, do it. It makes them happy. And happy users give us their money.

We're used to these things. We deal with annoying ass software all the time. We just deal with it, and move on. But if we raise the bar for what we produce to circumvent these issues, instead of just accepting it as "the standard", then we enter a whole new level of software. One that doesn't annoy the shit out of everyone.

Alerts - only for when things go bad

This is just a small pet peeve of mine. Alerts are distracting, obnoxious, attention-getters. Now, when there's an issue that needs direct notification or attention, then they're perfect. But restrict use of these to fatal issues. Like if a save fails, or connection is lost. But when things go as planned? Stay the hell away from them. If you feel that the fact that your application managed to successfully carry out it's intended function is so monumental that you need to bring your application to a halt, block the user from doing anything else, and have the user then signify this momentous occasion with manual input, then you probably shouldn't be writing software. Remember - they need to be confident it's going to do what it's supposed to do in the first place. They NEED to take it for granted. They shouldn't be concerned about it.

Now - keeping the user informed with up-to-date status is generally a great idea. But pop-up alerts are NOT the solution for this. Typically, labels on the matching screen, or perhaps a persistent status bar across the whole application is much more desirable. It's bad enough if the user has to do extra clicks when things go wrong. Don't make them have to do it when things go right as well.

Copying - how to make friends and save money!

Guess what? As much of a genius that I am, I'm not the first person who thought "Hmm...UI is pretty important" (probably more like third or fourth). But these first people, and their companies, that realized this, have invested a metric crap ton of dollars and cents into researching this. So, why not benefit from their hard work? This benefits us in two great ways - 1. Saves us time (and thereby money), and 2. Users are familiar to it.

If you're trying to come up with an interface for something, take a second and think about if you've seen a similar scenario in popular software. If that software is popular, usually that means users like it, which means it has a interface that doesn't suck. We don't always have to reinvent the wheel. However, there's also a chance here to bring your software to the next level. Instead of working on your own to make your software "standard", you start off with it being the standard. Then, using your (and your users) past experiences with this popular software, you can easily identify whatever interface annoyances may be present in them, and fix them. Now your software is a step up, AND recognizable. This saves training and acclimation time for your user. Booyah.

Plus, with using this popular existing software as a base, your users will immediately feel familiar with how to navigate around. You'll have your own twists and improvements, of course - but it keeps them from feeling like they're stepping completely into an unknown. This helps them make the transition, and gets them using your software faster. And the faster their using it, the sooner they forget about whatever old process they relied on.

But be careful with this - remember just to keep it "where applicable". A good obvious example, is the Microsoft Office suite. If you have an application that deals with files, some simple things like having the file name in the title bar, and typical options like 'load', 'save', and 'save as', are readily apparent as good fits. Don't skimp on these.

Rob sure does yammer on

Shut up. Now, I know I'm not perfect, and there are parts on my current project where I want to go back and make some adjustments. And I will. There are also lots of places where I've applied these ideas, and more, and I think they've lead to a decent, easy-to-use system. I think we all too often short-cut the UI, and that causes a project to fail. To be done right, it needs a large amount of time investment, and shouldn't be just quickly tossed out there.

I'm sure you guys have even more good ideas, so let's hear them! Or, tell me how full of crap I am, and everything should be out-of-the-box datagrids.