Respecting User’s Windows Settings

I know, you’ve probably heard this a million times before in books, articles, and other conference sessions. I’ve said it, preached it, and tried to practice it, but I often find myself short on respecting Windows settings (remember the high contrast theme?).

This tip is exactly what I was talking about in the “quick note about this session.”

I’ve always taken great pride in my UI design (right or wrong, and many times I’ve been wrong), and I had planned for this session to show you something pretty. But as I worked on the session (and re-worked it again, several times) I found that some things I built that looked pretty to me could be very ugly to others.

During the working and re-working, I found myself going back to the Microsoft UX Guide many times.

The Microsoft UX Guide for Vista and Windows 7 contains the following statements about user settings (on page 621-622):

  • Accessibility and the system font, sizes, and colors
    The guidelines for making text accessible to users with disabilities or impairments can be boiled down to one simple rule: Respect the user’s settings by always using the system font, sizes, and colors.
  • If you do only one thing…
    Respect the user’s settings by always using the system font, sizes, and colors.

During the course of preparing this session, the guideline above went from being an afterthought to a driving principle.

Define Your Lowest Common Denominator

I think of the lowest common denominator as the minimum supported operated system for my apps.

I spent many years supporting apps on Windows 95/98, Windows ME and Windows 2000, but recently I have set my lowest common denominator to be Windows XP (even more specifically for some apps, Windows XP Service Pack 3).

Why? Tons of code wrapped in IF – ENDIF statements, checking for the major version number of the OS: If Windows 98, do this, else if Windows 2000, do this, else if Windows XP, do that, else if Windows Vista, do something else.

Frankly, it just seems a waste of time to continue adding to that code. I’d much rather take out the parts I don’t need anymore. Plus, I gain the benefit of ease in my design decisions.

Windows XP is an eleven year-old operating system. Supporting anything earlier than XP just doesn’t make much sense to me (though depending on your own situation, your mileage may vary).

About two years ago, I had a new customer complaining that an app I wrote just wasn’t working right on his Windows 2000 computer. After a few emails (during which he continually shared with me that he is a professional software developer and he is running Windows 2000 Professional), I asked him which Service Pack he was running (I had successfully tested the app on Windows 2000 Service Pack 4, and assumed anyone still using Windows 2000 would be running SP4).

He wrote back saying he was on Service Pack 2, because in his opinion it is rock solid and he has his development environment set up just right for SP2 and he doesn’t want to mess that up.

He refused to even consider updating to Service Pack 4.

So, I refunded his purchase and said, “When you’re ready to join us in the 21st century, we’ll be here. Just email me when you get a new computer with a newer version of Windows, and I’ll give you a free copy of the software.”

As far as I know, he still hasn’t joined us in the 21st century.

In an earlier post, I mentioned that a lot of my apps these days use the IE web browser control. Lately, I’ve found myself changing the lowest common denominator for IE as well. At this point, I require at least IE8.

Do you have a lowest common denominator for your apps?

 

So, What Is An Ugly App Anyway?

Here’s one:

I call 'em like I see 'em. This is an ugly, u-g-l-y app.

I call ’em like I see ’em. This is an ugly, u-g-l-y app.

The form above is an absolute mess. The colors are bad, needlessly distracting your attention from the task at-hand. The controls are misaligned, and the tab order is not ordered at all (you’ll have to trust me on this one – I moved some controls around after saving the form, and forgot to reset the tab order – have you ever done that?).

What’s with the navigational overload at the bottom of the form? Sure, tooltips help the user know what the buttons do, but come on!

A standard Windows icon in the upper-left corner tells me that no icon was assigned to the form, and (though you can’t tell from the screenshot) the maximize button and close button are both disabled.

How do you close the form? With the close button in the navigation area, of course!

Any guesses as to which button is the close button?

Even worse, I copied the style for the form shown above from an actual online tutorial for building Visual FoxPro applications!

Here’s another ugly form from another ugly app. This one is from one of my apps. I figure if I’m going to point out other ugly apps, I should be fair and point out my own as well:

My Ugly App

I thought it looked great. Would you believe for some users it’s ugly?

Not nearly as bad as the form in the earlier image, is it?

  • It’s got an icon.
  • It can’t be resized, minimized or maximized, but that’s OK – after all, at least the minimize and maximize buttons have been removed, right?
  • The tab order is set properly, so no problem there.
  • The “Read more about Quick Add” uses the Windows color for a link, and when you click the link it opens the help file to the correct entry.
  • Once some search terms and a search name have been entered, the Search button becomes enabled. This prevents me from prompting the user with a MESSAGEBOX(), alerting her to the need to enter a phrase, etc.

Overall, I thought the form had a nice “Windows 7-feel” to it. Professional, polished, functional. Sweet!

But, within three days I heard from a customer, complaining about how ugly it was (you may need to click on the image to see it full-size):

"It's blurry," said the customer to the frustrated developer.

The form running with DPI of 150% (144 dpi), using Windows’ DPI Virtualization

See the title bar? The user has told Windows to set the dpi to 150% (or 144 dpi), possibly because she has a super-large monitor and just wants the text to appear larger. Or, maybe she has sight problems and needs the text to be larger.

Windows did its job and made the title bar and close button larger, but the rest of the form is a little blurry. This is because Windows 7 used DPI Virtualization to draw the form. DPI Virtualization makes the form bigger, but can cause the objects on the form to “blur” if your app is not DPI-Aware. I’ll discuss DPI-awareness later in this series.

Still, there’s something really ugly about this form. Have you noticed it yet? Let’s take a look at the next screenshot:

High Contrast Theme

Ouch! Same form, but using Windows High Contrast (Black) theme

Windows XP, Vista, 7 and 8 all include the high contrast themes, for accessibility reasons.

If you do not design for all possible Windows themes, you may will eventually get a support call from someone who uses a high contrast theme. I mentioned in an earlier post that beauty is in the eye of the beholder – when we add accessibility into the equation we move beyond beauty right into functionality.

It is much easier to design for high contrast themes and higher DPI settings upfront than it is to redesign later.

What’s ugly to me may be beautiful to someone else. Or, what’s beautiful to me may be ugly (or unusable) to another.

“Beauty, like supreme dominion, is but supported by opinion.” – Benjamin Franklin, Poor Richard’s Almanack (1741)

 

When Do You Say Your App Is “Not Supported”?

Do you develop your apps for the least common denominator, or do you provide a set of absolute minimum requirements that must be met in order for your users to install your app?

I have an app that is installed in roughly 750 locations. Of those, nearly two-thirds of the users are still running Windows 98. Naturally, whenever I work on enhancements (and bug fixes) for this app, I have to develop to the least common denominator (in this case, Windows 98). As you can imagine, with the hardware for most of these users I also have to be careful about memory, hard drive space, and dial-up connectivity versus cable/dsl.

Some developers I’ve worked with insist that the absolute minimum OS for their software is Windows 2000, preferably Windows XP, and even more preferably, Windows XPProfessional. I dunno. If I took that approach, I’d lose over 500 customers for this one app alone.

On the other hand, dropping support for the app on Windows 98 would save me a ton of time on testing… One less OS to worry about. And I have to admit, sometimes it would be nice to say, “You’re running Windows 98? Sorry. Not supported on Windows 98.”

When I look at Microsoft’s Product Lifecycle dates, I see that “Paid incident support is now available through 30-Jun-2006” for Windows 98, and I wonder if I should follow the same type of path with the apps I’m developing today.

Do you use Microsoft’s Product Lifecycle in determining your minimum requirements, or are your minimum requirements simply based on what’s needed by the individual app?