Identify db by color?

[LaRetta]

It has come to my attention by a User (me) that the color of layouts is important. I thought having the same color (consistency, you know) through all of my db's was better than having lots of different layout colors. Problem: When working between several dbs, even though the heading clearly shows which db I'm on, I will occasionally 'forget' which db I'm in (silly but true) because they're all the same color. I know I could leave the choices to the Users (using global containers for backgrounds), but I'm not sure I want to do that. So I thought, have one db (Service) one color, the Client db another, etc.

My question is this: How do ya'all use colors throughout multiple dbs? Or is it a simple indicator that my headings and layouts aren't 'clear' enough for my Users?

[LaRetta]

Hey, ya'all, did this post slip past you? I REALLY could use some input. I'm in a the middle of re-vamp! Pleeease?

[SteveB]

Okay, for what my 2 cents is worth: I've gotten away from battleship grey, but I use a few colors consistently across files and I feel that changing the background color every time a user switches files will give them a headache or eye strain. Plus, it's kind of hard to come up with more than a few decent (non-objectionable) colors. What happens when you get to 10, 20 files? You'll quickly need to reuse colors.

[LaRetta]

Thanks Steve! I currently have all layouts in all dbs a kindof bluish grey. And I've worked so hard for consistency -- they all have everything in the same places -- navigation buttons etc. -- they just all look alike! I was thinking that, maybe the three MAIN dbs that users jump back and forth between might be different colors -- I really don't care about many of the others -- some are just lookup and ancillary dbs. Maybe I need to focus on the headings so they stand out more. Maybe a combination of a few colors AND more easily identifiable headers.

At my last agency I made the mistake of asking the Users which of five colors they wanted!! A major war ensured between them (no, I'm not kidding). Staff took sides and almost went on strike! I won't make THAT mistake again! Can anyone else share how they handle this issue?

[kennedy]

I think it depends upon the semantic meaning for the users. For example, I have 9 tabs at the top. In some cases, while still under the same tab, you actually go between 3 files... the distinction between those files has to do with relational design, NOT semantic meaning for the user. Switching colors there would be bewildering and not useful.

On the other hand, on my website I do switch colors of the border region when you switch major tabs. Why? Because in the case of the website, the minor tabs are identical and some of the structure and content is identical... the color helps remind you of context. It is useful there, IMO.

Returning to the FMP database I am working on right now, it does not switch colors between major tabs. Too many of the workflows pass seamlessly between the major tabs... the tab context is not important to understanding the content. The tabs are mainly quick ways to get to certain info. Changes in color in some steps of a workflow but not others would just create questions and uncertainty in the minds of the users.

In contrast, the commercial database I am replacing DID change color on every layout. And they were bright, contrasting, and somewhat clashing colors. I suppose it was intended to key you in on where you are... but it just served to annoy and alarm me every time a screen came up. But then, that's far from that UI's worst features... it consistently places buttons up top, but also consistently re-arranges where certain buttons are. For example, the "Main Menu" button is one of the top 6 80% of the time, but its never in the same position up there... and sometimes its not there at all. And even that's not the worst of that UI.

Sooooo, without knowing more, I'd say "keep it consistent". But if there is some confusion among your users on context, then consider using no more than a handful of colors and only as accent colors (not whole background colors)... where you use them in an absolutely consistent manner with a well-thought-out purpose. "If the header is in green, then X is always true."

That's my inflation-adjusted 2 pence...

Brian

[LaRetta]

Brian, that was well said. And SO TRUE! Thank you. Well, I think the use of an 'accent' color alone may assist users in focusing on where they are a bit more. Or, I could have it PLAY A SOUND like "Welcome to Human Resources" every time it changed from the Clients db to Human Resources, for instance!! NOT! If all Users consistently came in through the front door it would be easier, but sometimes they jump (windows can be a pain at times) around, reviewing and doing other work. Well, I love your ideas and will certainly review the entire visual package I'm attempting to pull together. HTH

[falkaholic]

My 2 cents: I've tried different colours. Didn't work. If you have an extra-special layout/DB (say the who-to-kill-next DB) you can make it a different colour to differentiate but otherwise keep it cosistant, you'll thank yourself later. You don't have to follow every users' request.

[LaRetta]

Thanks Eric! Well then, that settles it! Pooh on the Users in this case! I WILL make my layout headings a pt larger, though.

And, because I'm the one doing this project, I GET TO CHOOSE the color ... Oh God, that makes me feel so powerful! Maybe I'll let the word out that I'm open to bribes!

[Vaughan]

I teach this stuff...

I get my class participants to open a program (a well designed one like Ms Word or FMP) and report what the overall colour scheme is.

Try it yourself.

Programs like Word and FMP have $Millions spent on interface testing and usability studies, so they know what works.

Having said that, you can give people what testing proves to be superior, or you can give them what they think is better.

An example of this is keyboard shortcuts vs mouse and menus. From http://www.asktog.com/basics/03Performance.html...

"In one study... (Tognazzini, Tog on Interface, 1992.), users were asked to do the same task using the keyboard and the mouse. The keyboard was powerfully engaging, in the manner of many video games, requiring the user to make many small decisions. The mouse version of the task was far less engaging, requiring no decisions and only low-level cognitive engagement. Each and every user was able to perform the task using the mouse significantly faster, an average of 50% faster. Interestingly, each and every user reported that they did the task much faster using the keyboard, exactly contrary to the objective evidence of the stopwatch."

For those interested, Tog spent 14 years at Apple Computer, where he founded the Apple Human Interface Group and acted as Apple's Human Interface Evangelist. The test mentioned above was a block of text where the letter "e" was replaced with the vertical bar "|" character -- the most difficult to select with the mouse because it's just one pixel wide. The task was to replace the "|" with "e" using (1) keyboard shortcuts; and (2) the mouse and menus.

[LaRetta]

'Maximizing Human Performance" is powerful stuff. Thanks, Vaughan. I always feel my questions are probably stupid ... but I WANT to know. Then after I've asked, I'm always so glad I did, because I learn so MUCH! I'm in the middle of a heavy data migration and must stay focused on this ... but, when I allow myself some 'play time,' you can bet the first thing I'm going to do is look at other successful programs. I appreciate the information

[BobWeaver]

Vaughan, I agree, the people who developed Apple's User Interface Guidelines did an excellent job. Volume 1, chapter 2 of Inside Macintosh "The Macintosh User Interface Guidelines" should be required reading for any software developer.

Just about the most horrid user interface I have ever endured was an industrial controller application that constantly required the user to alternate between mouse and keyboard. Click this, type that, click this, type that, click this, type that, etc. Dialog boxes were constantly popping up asking to confirm the obvious, but the natural choice was never the default button. The only text field in the dialog boxes would not have the focus, so you couldn't just start typing without first clicking in the field (even though there was no other place for the text to go). After 10 minutes I was ready to fling the computer through the window.

You can't completely avoid alternating between mouse and keyboard, but if you can minimize it, group the mouse actions together and the keyboard entries together, and/or operate the program with one hand on the keyboard, and the other on the mouse, it's a bit more tolerable.

[LaRetta]

Hi Bob,

Is there a way a Windoz person could see what you are referring to here? Is this online or only in hardcopy?

"Apple's User Interface Guidelines did an excellent job. Volume 1, chapter 2 of Inside Macintosh "The Macintosh User Interface Guidelines"

[BobWeaver]

Here is the pdf version:

http://developer.apple.com/techpubs/mac/pdf/HIGuidelines.pdf

[jasonwood]

I find that using a lot of different colours can really make your layouts look like they're wearing a clown suit (ie: unprofessional), BUT I have succumed to using different colours especially to help distinguish between Quotes and Invoices, which can otherwise be very similar layouts, but ONLY as accent colours. They are enough to visually inform you of where you are but they don't jump out at you. Thanks for posting the HIG, I've been meaning to browse through that!

--

Jason Wood

HeyWoody.com

[BruceJ]

I agree that switching between the mouse clciks and keyboard is anoying. Sometimes I'm afraid that users will come back and sue me for tennis elbow!

I just wish that buttons coudl be tabbed into on layouts and activated with by hitting enter.... just imagine... but that's all you can do for now!

As far as colors goes, I agree that same color is important. I only change the color when the layout is one that a typical user isn't supposed to be abel to access. I use bright red for the backgrounds of my developer layouts, default files, ect. That way if a database "breaks" and a user ends up in some funky file, they call me and say something about a red background and I know something has gone terribley wrong.

I also use a special background color in "starter" files, so if the hosted database dosen't open automatically, it's clear to them (and me) something is wrong.

First thing I ask when a user calls me, is "what color is the background?".

[keshalyi]

Also,keep in mind, there are other methods of differentiation, a lesson I learned when I had to roll out a real bugger of a project on a monochrome work-flow. Fonts, icons, window size and shape is a good one too. And its not ALWAYS an option, but if they have a big googly screen, the best of all worlds is to have all their windows open at once in SOME cases, I've found (OSHA makes some of us buy 22" monitors... that ******* Sony lobby...) But outside of that, for my users that get ABSOLUTELY lost, and just panic when they forget what screen they're in, I find pictures are the worst. I now have a little picture of a photo frame in my pictures DB, one of a dollar sign in my clients, one of a newspaper in my issues, etc...