Interface Design For Developers – Glossy Buttons

In this series each topic will be split into two parts – First, creating the graphics using Photoshop and normally with a screencast. The second part will be a blog post on how to use the newly created graphics in a project — normally websites.

This screencast shows how to create a glossy, reusable button with Photoshop and then make changes to the colors, text and icons it displays. We also discuss adding a reflection to buttons by using a Smart Object. Additionally, we look at how to add text and change the color of the button.

Creating Glossy Buttons

[Watch the screencast]

Resources

Below are resources for the content created in this screencast. You can use the .PSD file to get the finished Photoshop file. You can use the .PNG file to create buttons with a different art program.

[Tutorial PSD file]
[Buttons.png]
[Buttons-No-Shadow.png]

Check back for the next blog post where we discuss how to use the buttons in a website.

Is there a topic you’d like to see covered in this series? Make sure to leave a comment with your ideas!

Interface Design For Developers – Introduction

Simple is better when it comes to design. Adding a bunch special effects doesn’t automatically make an interface element better. Good design is normally very subtle and involves very few special effects (if any at all)

See what I mean?

However, a hint of gloss or a slight reflection for an interface element can make a plain website much more attractive (no, not System.Reflection, stay with me here…).

Design Tutorials For Developers

If you’ve ever seen my personal websites then you can tell I’m interested both code and graphics. I’m more or less one of those jack of a couple trades, master of none sort of guys.

So, this series of posts we’re going to discuss both how to create attractive interface elements and how to use them in our code – a little bit of both worlds in the same post!

I’ll be using Photoshop for these tutorials but I’ll try and use concepts that apply to other art programs as well. If you don’t have Photoshop then you can download a trial version.

The Tutorials

Below are previews for the tutorials I’ll be releasing the next couple weeks. I’ll also come back and add to this list as more come out.

Shiny 'Web 2.0' style buttons with HTML and CSS

Create a simple 'Post-It' note and then write dynamic text to the image

Extend the 'Post-it' note by creating a photo frame and change the subject dynamically

These should be a good start to but if you have ideas that you’d like to see then leave a comment or send an e-mail my direction.

Avoiding Confirmation Boxes

One thing I try to avoid in interface design is unnecessary user interaction – Basically, asking the user for feedback when it isn’t needed. The area that probably bothers me the most are “confirmation boxes” – Especially those that block the entire application until you’ve clicked ‘OK’?

I’m not really sure why you see them so often in applications since I’m pretty sure that users and developers alike probably get tired of seeing them. Not only that, studies have shown that they are mostly ineffective, normally only earning a cursory glance before being dismissed.

So what can you do instead?

Don’t Confirm Success, Notify On Failure

Probably the easiest and quickest improvement to an application is to stop confirming when your application worked. How many times have you seen this pointless little window pop up?

Uh, yeah…

For the most part, a user should be able to assume that their “request completed successfully.” — Otherwise, why the heck did they buy your software to begin with?

Instead, pop up a modal dialog box if something goes wrong and their request didn’t work. This is a much better time to interfere with user work flow.

Allow Permanent Dismissal

New users of an application don’t mind confirmation boxes as much since they are still poking around and trying to figure out what everything does. But after the 10th or 15th time the ‘your request has been completed!’ message is starting to wear on them.

Sure, it was helpful at first but now that they know the expected behavior, the additional confirmation is an annoying extra click.

Ah, now that is better. I’m confident using this part of the program – stop bugging me!

Even Better – Don’t Confirm, Make It Easy To Undo

Remember the computer before the undo button? It was painful and frustrating, but then one day like magic we could fix our silly fat-finger mistakes – Genius!

What about the Internet before the undo button? Oh… wait. The ‘undo’ button is actually still pretty uncommon in web applications. Of course, web applications aren’t the only area that this applies – but it is still possible to make it happen. GMail is a great example of how this applies to any application – including the web.

The message explains what happened and gives immediate actions for the two most probably user responses – “What the heck did I just do?” and “Oh snap, I didn’t mean to delete that!”.

Use Visual Indicators As Confirmation

Visual indicators work well as additional confirmations. If you make it clear enough what a user is about to do then normally you can avoid a confirmation box.

Red highlights, short and clear sentences, explanation of the final result – All of these items act as an additional confirmation for the user to understand the result of their action. To take it a step further, the text on the button OK would be even clearer if it said Delete (see how easy this is!)

It doesn’t take much to reduce, and in many case eliminate, the dialog boxes we pop up in our applications. You’ll be happier, your users will be happier — Heck, I’ll even be happier even if I never use your application.

What are ways you can use to limit the number of dialog boxes you use in your applications?

ERROR: Cacographic Solecism Directive Encountered **

** Unreadable Error Message Found

I’m pretty picky about user interface with a lot of the projects I work on ranging from the user experience to the design and layout. Ever since I read Steve Krug’s, Don’t Make Me Think, I find myself spending a lot of time reading over the same content again and again trying to simplify them to their shortest possible length.

One section that has always been a focal point for me has been error messages or really any dialog that requires user interaction. However, I’m not just talking about the cryptic, developer designed error messages like ‘IOError Detected!’ or ‘Generic GDI+ Error’ (I especially hate that error).

No, the error messages I’m talking about are messages that don’t really help the user — or error messages that help the user, but too late into the message.

Here is an example from Netflix. It isn’t a bad message but I think that it could be improved.

The Anatomy Of An Error Message

Not all situations are the same but I try to write all of my error messages in the following order.

1. What happened in a short sentence.
2. Give the user options and solutions
3. Explain in slightly more detail what happened but only if the problem may happen again or it helps them understand how to avoid the problem.

What Happened? Few Words Should Say It All — Or Don’t Bother!

I try to stay brief with everything… well, except blog posts, of course. If you’ve visited my latest project CustomWebmail.com then you’ll notice I try to keep everything to a sentence or two. I’ve had a lot of feedback that people like how short and to the point everything is.

Your error message should be the same – short and to the point. Don’t waste a lot of time explaining why it broke or telling them what happened in the background that caused the failure.

In some cases you don’t even need to present the problem as an error message especially if the resolution is simple. The Netflix message is a good example of this. The message feels a lot like an error – but should it? Or should it be presented that this message is the natural result of leaving the page idle?

User Options – Empower The User Quickly

Giving the user the control to fix the problem right away should immediately follow the title of the error – not an explanation of the problem. Include only as many options are really relevant.

I’d even go as far to say that even Yes and No buttons should have a description as well. Explain what the yes and no buttons will do — even if it seems obvious. A button that reads “Yes; Save my document to the server” is much clearer than simply a button that says “Yes” or “OK”.

The Netflix error says to reload the page — manually. Why? Chances are they already have a mouse nearby — why not simply say Click Here To Continue Your Movie! and handle reloading their page when they press the button?

They do offer a suggestion but they don’t offer to do it for you, which I think would improve this box a little more.

Explain The Problem: But Only If It Matters

I’m sure this part would be a point of contention to many people. Often we feel like we need to tell the user what is wrong but also why there was a problem. Clearly, each situation is different, but more often than not I think that the ‘why’ is irrelevant. Here are a few times I think explaining why is important.

• The user might make the same mistake again (ex. invalid e-mail addresses)
• The problem might make a user think your service is broken and you need to explain that it is either normal procedure or a problem from somewhere else.
• To answer why a response is required (ex. input form that wants information a user might not be comfortable in providing)

More or less, if the reason why doesn’t affect the user then you don’t need to share it. If your function SaveUserData() crashes and returns an ‘Unable to save to /Data/Profiles/Users.txt’ error then don’t tell your user. Simply saying ‘We’re sorry – We had a problem saving your information’ is more than enough information to explain why they need to do the same step twice.

My Version

Remember, I like to nitpick this kind of thing. I realize that error messages in my own programs could be improved as well. That said, here is a sample that I think would work better for visitors.

With this message, we are to the point faster and offer a solution to the problem immediately. I also dimmed the error message some and highlighted the actions that could be taken so the user would be drawn to it quickly. I’m sure this message could be improved upon even more but this seems like a good start.

How much time do you spend making your messages as short and as simple as possible?

** The author spends a lot of time reviewing content — but not his own blog — so if you see any typos then please be forgiving 🙂