Category / It’s So, Uh, Gray

Posts from my Southwest Fox 2011 session titled, “It’s so, uh, gray… Tips & Tricks to Improve Your Apps Interface”

by Kevin Ragsdale

What’s In A Name?

Visual FoxPro. The name brings a smile to my face. But for my customers, it usually means something has gone wrong with my app.

Microsoft Visual FoxPro: this name brings a smile to my face, but sometimes for my customers it can bring a frown (and potentially lots of shouting, insults, and an overall bad attitude).

Why? If I’ve done everything right, my customers will never know the app was written with Visual FoxPro. But, if I’ve done something wrong, there’s a good chance they may see something like the image (or, worse yet, a lovely C0000005 message):

THE FoxPro

“Visual FoxPro? What’s that? I’m running Visual Foxy Accounting Professional 2008!”

There are several reasons why I prefer my customers to not know their app was written in Visual FoxPro. Let’s start with the obvious:

  1. FoxPro is old
    FoxPro has been around forever (FoxBase since 1984, FoxPro since 1989, and Microsoft FoxPro since 1992, even Visual FoxPro is over 16 years old – an eternity in the PC age). How many times have you heard, “But FoxPro is so old”? Sure, we can use phrases like “stable” and “mature” as adjectives to describe FoxPro. But, Tom Brokaw is “stable” and “mature” (and 72 years-old). I’ve heard the “FoxPro is old” statement numerous times over the past few years, in part because,
  2. Microsoft dumped FoxPro, and there will be no more new versions
    How many times have you heard this one from clients, potential clients, users and (especially) other programmers? And, they’re right. Visual FoxPro 9.0 Service Pack 2 is as far as it goes, and it was released over 4 years ago. The most recent hot fix was released 3 years ago. Sure, there’s extended support for Visual FoxPro until January 2015, but that is only three two years away. There are no new enhancements coming. With no new enhancements, we’re kind of stuck with what we currently have: a development environment and runtime that was developed primarily for running on Windows XP (a 10 year-old operating system), along with several enhancements in Service Pack 2 to lead us towards better Vista (two versions of Windows-ago) compatibility. Be honest, how quickly did you download the Windows 8 Developer Preview, just to see if your VFP app would run as-is? I did, as soon as it was available for download. But still, even with the Vista-compatibility enhancements, many people look at apps written in Visual FoxPro and think,
  3. “It’s ugly”
     Some people “hate THE FoxPro” because they believe “the FoxPro” makes ugly apps. This is, of course, not true. We have all the power that Visual FoxPro provides to create compelling, modern, and usable interfaces. But, as Uncle Ben told Peter Parker, “With great power comes great responsibility.” Visual FoxPro gives us great power, but it is our responsibility as VFP developers to make sure “THE FoxPro” doesn’t make ugly apps. Some people “hate THE FoxPro” simply because they think the ugly, buggy app they are running is FoxPro. Some people “hate THE FoxPro” because every time their app dies it dies with the aforementioned “Microsoft Visual FoxPro has stopped working” or “Microsoft Visual FoxPro has closed unexpectedly”. There’s one more (very personal) reason I don’t want my users to see “Microsoft Visual FoxPro” in my app:
  4. If they have a problem with my app, they might Google “Microsoft Visual FoxPro” and end up on a FoxPro forum – asking questions of my peers about why my “piece of crap” app doesn’t work. Yeah, I’ve had this happen. More than once. Try Googling your apps’ name and see if any of the results point to the Universal Thread, Foxite, or the VFP forums at MSDN. It’s embarrassing, humbling, and a painful reminder that I’m not quite as smart as I’d like to think I am.

This makes my number one development priority (and #1 Tip): “Lose THE FoxPro“.

Which, coincidentally, is the title of my next post.

 

by Kevin Ragsdale

It’s So Gray: Introduction

THE FoxPro. It’s just so… u-g-l-y…

It was 9:00 on a beautiful fall morning. I was unpacking my laptop, setting up for my first real on-site job at a real client site. I hadn’t turned the office light on so the room was dark, except for the beam of fluorescent light floating in from the hallway.

Suddenly, the fluorescent light dimmed. I looked up and saw the receptionist standing in the office doorway. She asked, “Don’t you just hate The FoxPro?”

“Uh, no,” I responded. “Actually, I love FoxPro. It’s what I make my living with.”

She replied, “But, it’s so – I don’t know – ugly.”

About 20 minutes later, I got my first look at their custom FoxPro app (written by the owner’s daughter). The app was a one-size-fits-all ordering, shipping, inventory, everything-but-the-kitchen-sink application. It was originally written in FoxPro for Windows 2.6, but had recently been “converted” to Visual FoxPro. To run it, the user had to open Visual FoxPro and type do mainmenu in the Command Window.

That was one ugly application, and as far as the office workers who used the app were concerned, the app was Microsoft Visual FoxPro.

It was around this time that I began to notice a common theme in the Fox blogosphere. People were talking about how much their clients hated THE FoxPro, and a few bloggers (namely, the Craig’s – Bailey and Boyd), began talking about how we, as Fox developers, can make our apps a bit less ugly (or, more professional).

Remember Billy Crystal’s character Fernando on Saturday Night Live? His catchphrases were “You look mah-vel-ous!” and “It is better to look good than to feel good.”

In my experience with software, Fernando was right. Sometimes, it really is better to “look” good than to “feel” good. I’ve seen people get excited by an aesthetically-pleasing, yet buggy, application and completely ignore a rock-solid app that looks a bit, well, ugly.

Although we spend a great deal of time as developers trying to meet specifications while minimizing bugs, one thing that I always keep in mind is, “as far as the user is concerned, the UI is the application” (from the Coding Horror blog link below).

The goal of this session is to provide some tips and tricks to ensure your UI looks “mah-vel-ous!”

by Kevin Ragsdale

A Quick Note About “It’s So, Uh, Gray”

A quick note about the articles in the “It’s So Gray” category.

For the past few years, most of my Visual FoxPro development has been geared toward “shrink-wrap” software for the consumer market.

As such, I find myself spending a great deal of time with the overall look and feel of the UI. In fact, a lot of my “main” forms are simply top-level forms which host the Microsoft Web Browser Control – which means virtually the entire UI (except for the occasional secondary FoxPro form) is driven by HTML, CSS and JavaScript.

Some of the tips and tricks you see in this session are geared toward apps that are designed to be compiled as EXE files (namely, the DPI-Aware section and discussions of application icons).

Some tips are simply little tricks I use for classes (properties and methods) that help the overall UI experience.

Other tips (creating custom UI controls) are geared towards stepping back from the usual way of doing things in Visual FoxPro, in order to find new ways of presenting information to the user.

I use the word ugly a lot in this session. I am not suggesting that VFP apps are “ugly” or “wrong”. This session is simply an exercise in improving the overall look and feel of apps created with Visual FoxPro. Beauty is in the eye of the beholder – what is ugly to one person may be beautiful to another – and during the course of preparing this session my opinion of “ugly” shifted from an app perspective to a Windows guidelines perspective.

A lot of the content in this session is based on the Microsoft User Experience Guidelines. It is available online at:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa511258.aspx

A PDF version of the guide is available for download at:

http://www.microsoft.com/en-us/download/details.aspx?id=2695

Finally, all of my FoxPro work is done in Visual FoxPro 9.0 Service Pack 2. If you are not yet using VFP9 SP2, some of the tips may need to be modified in order to work correctly.