The Old Joel on Software Forum: Part 4 (of 5) - GUI design with different views

GUI design with different views

I've been writing software for a long time, but mostly on the server side. The GUI's I've written have been primarily web based and dialog based, but nothing too polished.

I've decided the client-server app I'm writing would look a lot nicer if I got away from using a lot of dialogs (except for setting properties). By that I mean that when the user starts the program, the main window appears and all subsequent views remain in the main window - no popup dialogs to do CRUD and other activities.

I writing this in C#, and I wanted to get advice on my approach. Should I:
a) Try to write the controls completely in code and display the appropriate set based on the current task?
b) Create different panel controls for each view and show / hide the panels based on the current task.
c) Screw it and go back to dialog based navigation.
d) Some other approach?

Thanks in advance.

P.S. A tab control would not be appropriate for this app for various reasons.

the beGUIled one
Friday, January 30, 2004

Have you considered a "tabbed" interface?

hmm?
Friday, January 30, 2004

I did something similar in a large Java client-side application.

First, we had dialogs everywhere. For opening files, saving, blah blah blah. They had to modal or else people would click all over and get the main window on top of the dialog, lose the dialog, etc. When they are modal, notifications couldn't pop up. They couldn't click the help menu on the main window. They couldn't change their preferences, etc.

So it's all in the main window now, and I just flip between pages using a CardLayout. TThe user can still access the menus and do whatever they want. I just switch to the screen that's appropriate for the current task.

At first I thought that people were used to using dialogs that are modal, like when you open a file in Word. For whatever reason this didn't sit well with my users. I guess they just like being able to jump to any part of the application at any time, without having to close the current task.

Don
Friday, January 30, 2004

The best example I can think of is tax software. It lets you navigate from page to page without using tabs or dialog boxes. The "next" button navigates you to a new page displayed in the same client area, with each page having a different set of controls.

Again, tabs wouldn't be a feasible option. It would take dozens of tabs to represent all the possible views. Also, I want to control navigation in a logical manner, which tabs would defeat.

the beGUIled one
Friday, January 30, 2004

I just can't picture what you're trying to do, maybe a real big Wizard? Tax software always has a tree or menu structure so you jump to any form whenever you want.

Tom H
Friday, January 30, 2004

Treeview.

Norrick
Friday, January 30, 2004

Is this kind of like what you're looking for:
http://hianoto.net/projects/articles/en-membuat_wizard_dalam_delphi.php

It's a component called KWizard. It uses "RouteMaps" and it's <mumbles> for Delphi </mumbles>.

:)

Perpetual Newbie II
Friday, January 30, 2004

Sorry,
the bottom two images have the routemaps.

Perpetual Newbie II
Friday, January 30, 2004

I'd say "b" with UserControls for each "page" and a navigation manager class to tie everything together. You might also want some sort of app specific taskbar or active task list. Maybe a navigation breadcrumb trail too.

Or wait for Longhorn which will have this all built in.

Or use Longhorn as a guide so it'll be easier to port when it becomes feasible.

http://longhorn.msdn.microsoft.com/lhsdk/appcore/overviews/appmodel_pagefunctions2.aspx

Chris Altmann
Friday, January 30, 2004

Chris, the navigation topology link was just what I needed. Plus, now I can say the phrase "navigation topology" and sound smarter than I really am. Thanks.

BTW, the tax software example probably wasn't a good one. I used the example in terms of the views, not the navigation topology (see, sound smart, don't I?).

I don't want users to be able to jump to any other form. For example, the app will have a start page and paths A - J. Path A will have steps 1-5, path B steps 1-7, path C steps 1-3, etc. Each step of each path is a separate page with different user controls and the completion of each path will bring the user back to the start page.

Also, I really don't want wizard-style dialog boxes.

the beGUIled one
Saturday, January 31, 2004

I'd watch out for two things when designing the navigation:

1) Most users want to feel that they're in control; it sounds like you want to dictate the exact sequence of steps. That's okay if it's really necessary; but the user has to understand (and accept) why you are taking control away from them.

2) People will make mistakes, change their minds, want to review what they've entered, etc. If you force them through a long series of pages whenever they want to change the last entry field on the last page, your app will be a pain to use.

Tom H
Saturday, January 31, 2004