I have been reading through a rather lengthy Microsoft document regarding UX (User eXperience) design and standards.

There are many great suggestions that I have started to adopt. But something occurred to me last night while working on my solution and I wanted to solicit some ideas and possibly have a short discussion on the topic of features and the Windows Forms Application UX.

Last night I was driving home from the office after spending quite a few hours on a handful of wizard forms and a concept that would allow users, on first run of the application, to setup a brand new data source. They are effectively presented with two options, create and use a new SQL Database, or create and use a new MS Access Database. Each selection carries on to a different form in the wizard asking the appropriate questions for the data source type and then finally executes a final form that creates, and inserts some default data into whatever data source type they selected.

I designed the forms using the UX guide that Microsoft published, which suggests that wizards only be used for tasks that are infrequently performed. Setting up the initial data source seemed like something that needed to be done on first run and never again. A wizard seemed logical.

The concern is though...is it necessary to offer it on first run or even at all?

My initial goal was to create a system that allowed flexibility, giving the user the ability to use whatever data source they were most familiar with. For some users an MS Access file is much more familiar than a daunting SQL Server that could carry a lot of overhead. But I figured both should be offered because larger users with multiple clients might prefer a SQL system because of the performance.

The UX guide however also suggests:

What does “power” really mean in terms of software? An application might be considered powerful if it is jam-packed full of features, having a tremendous breadth of functionality in an attempt to be all things to all users. Such a design is not likely to be successful because an untargeted feature set is unlikely to satisfy the needs of anyone. This is not the type of power that we are after.

[...]Simplicity is the most effective way to achieve ease of use, and ease of use equals use. Complex, hard-to-use features just don’t get used. By contrast, simple, elegant designs that perform their function well are a joy to use. They invoke a positive, emotional response.

For example, consider the wireless networking support in Microsoft Windows XP. Microsoft could have added a wizard to walk users through the configuration process. This approach would have resulted in ease of use but not simplicity, because an unessential feature (the wizard) would have been added. Instead, Microsoft designed wireless networking to configure itself automatically. Users ultimately don’t care about the configuration details, so long as it “just works” reliably and securely. This combination of power and simplicity in wireless networking technology has led to its popularity and rapid adoption.

Obviously in a multi-user environment, which is where my application could potentially run, an Administrator account needs to be created for the user, so some first experience interaction would be required before the application could be used.

I just wonder if, instead of presenting the options to use the various data source types I should do something more automated. I mean, if a SQL server doesn't reside on the PC that the software is being installed on, why would I offer it as a choice? Maybe to give them the option of installing it? That should be done at setup, not on first use right?

Also, if the application is able to detect a SQL server on the PC, and I decide to make that the default choice for storing data, I might run into issues that might make users unhappy and might end up with me getting in trouble. The last thing I want is my application to start creating databases and tables on a server without some sort of user interaction.

I just wonder...for the average user...what's the best choice here?

I do know that a feature Microsoft Outlook includes (the business contact manager) uses the MS SQL 2005 server. When you install the contact manager, it installs the server and then uses the server. It doesn't even really tell you it's going to do it. It just...does it.

Any thoughts? Experiences? Suggestions?

This is a very valid question, But this is more complicated then it seems. First ask your self this: "Who will be using my application?". If a large company that will have many clients connecting to the database you are creating, and top speed and reliability is the most important feature, Then maybe you should only support the use of a SQL database. But if only a one or a few clients will be using the database then Access would suffice and just fine and you could just use that.

But if you really want to offer the user a choice, which can be a very sensible thing to do, why not just have on first run a quick wizard with the option of either "automatically configure data sources" or "Advanced Data source Configuration". Where one would just use access, where as the Advanced option would allow the users to choose between the two and run your wizards.

Many programs use SQL server express and use it. But I have written asp.net pages that use simple access databases larger than 3bg in size with no problems, so if you aren't needing a super fast database for hundreds of users MSAccess isn't a bad choice.

Diamonddrake,

Good point.

The scalability of the application ranges greatly. Some users could be single users with no need (or even access to for that matter) for an application that could interact with a SQL server instance hosted on a network. But at the same time, a totally different user might need to allow access to a few dozen or even hundreds of users at the same time.

Though I don't think that many users would need such a large range. Similar software in the marketplace doesn't claim to have any restrictions on speed, network abilities, or the number of users (no surprise there). But in reality, a file based (Access) data source poses quite a few limitations, but also provides quite a few advantages. The same also applies to the SQL server solution though.

My main concern is not so much whether to offer the flexibility of choosing a data source type (file or server based), but instead how the end user's first interaction with the software is perceived.

First impressions mean a lot, especially in software. I can't tell you how many times I have downloaded "freeware" or purchased software that claims to be "user friendly" or "easy" and turns out to be nothing of the sort.

I understand that presenting setup wizards and first run guides are pretty standard in many applications. I would just prefer to limit the amount of time a user has to set up a software solution, before actually using it.

The UX Guide states:

In the ideal first experience, users install your program (or even just start it if it doesn’t require installation) and use it productively immediately—without answering a bunch of questions or learning a bunch of things.

This ideal is obtainable for most programs, so you should strive for this ideal experience whenever you can. However, this goal is often not obtainable for programs that require significant system integration, have many optional features, or have privacy implications. For example, if your program has features that might reveal personal information to untrusted parties, the tenets of trustworthy computing require that you obtain user consent before enabling these features.

I think your idea of "standard" or "advanced" settings is a good idea. I just wonder how many screens to setup an application is too many?

It's hard to say how much is too much, that depends on the software. Just like with anything. With power comes complication. It's your place as a programmer to make the program as simple to use as possible while still performing all the necessary functions to it's purpose.

Diamonddrake,

Yeah, I've put my original wizard aside and have started working on a more simple one. The first one wasn't that complicated, but even so, it was less intuitive than my new concept. The new concept will take your suggestion of having default settings and advanced settings and will actually select some default choices based on the environment the software is running in (is the correct Ole extension installed? is there a SQL server running on the machine that can be automatically detected? is there a SQL server running on the local network that can be automatically detected?). Having some of these questions answered by simply querying the registry, the active services and the network can make the wizard look a lot less "heavy" and might prevent users from selecting options that would otherwise cause errors (such as selecting to use an Ole connection, but not having the extension installed to do so).

Now maybe instead of 4 screen changes, I'll only have 2 or 3. The code behind the wizard is much more complex now and was taking a while to perform tasks (now I need to split those into separate threads to possibly make it faster), but eh...I think it might be worth it.

No point in bothering a user with things that aren't necessary.

Anyone interested in taking a look at screen shots of the two wizards and providing some feedback? I'd love to have some constructive criticism.

It sounds good in theory. But for testing the intuitiveness of the wizards if you are that concerned, I suggest that you throw them into a test app and let some friends not from a programming or power user background run through the wizards and see if they have trouble with any of the options. Make sure its friends who daily user computers, but not so much that they really understand how program's work. this will target your typical user, see how they feel.

A good idea would also to have a failsafe option marked something like:
MSAccess (recommended for most users)

Also, as for threading the system that checks for the prerequisites, that's not a bad idea, but don't get crazy with it, just a background worker should do fine, and i would probably do a progress bar on a wizard with a label that said something like "Checking for prerequisites" or "Checking for database compatibility". Then automatically go the next wizard screen when that finishes instead of waiting for a "next" click.

But these are just suggestions based on my opinion, which I humbly offer. Feel free to attache some images. I'll have a whack at them.

Diamonddrake,

Sorry I've been busy working on this thing...I never realized threads could be so complicated!

I'll have to post those screen shots either this afternoon or Monday...it's been so busy lately.

lol, don't worry about it. I'm here to offer my opinion when you need it.

Threading can be complicated, but its not that bad. Use a background worker control when you can.

This article has been dead for over six months. Start a new discussion instead.