The Life of a Project - Issue Tracking: Day 4

• Download the demo project - 292 Kb

Read this first, please

This is the fourth in a series of articles that hopefully will be educational to novices and helpful to more advanced developers alike. I hope to learn a lot from doing this. I am taking the approach of maintaining a journal of the day-to-day process of software development, starting from a concept and going to a product. I hope you enjoy this series of articles.

• Day 1.
• Day 2.
• Day 3.

Where are we?

We have been handed a project to create an issue tracking system (no longer just an application) targeted at software developers, standalone programmers to be exact. We have gathered a list of requirements and we have a vision to drive our project. Yesterday we created a simple preliminary specification for the application as a whole (not the individual components). We also created our UWEs and that brings us to what we need to do today.

At this stage in the design process, we have done our research, racked our brains and formulated what we believe to be a solid working model for how we are going to fulfill this project. We have even put ourselves in the users shoes (so to speak) and challenged our model. We still don't have a design document, but we're not quite ready for that just yet. Our application model seems to be perfect for our target audience, but you can never be too sure. We must not rely on our intuition, it is time to get back with our users and find out what they think about our model.

Today, we are going to create prototype UIs to illustrate the UWEs. We will use these prototypes when meeting with our users to get buy-in, validate our ideas and flush our any potential problems.

What exactly is a prototype?

Most of the time when we think of prototypes, we think of real applications that present a UI that simulates the appearance of our proposed final application. Often we will use VB, or for web apps, FrontPage, to quickly produce a simulated UI, planning to throw it away when we are done. We usually try to spend just enough time on these to make it look "good enough". We don't invest any time into error handling or making sure things are spelled right. Then we happily take our simulated applications to our users and present our ideas.

Users however, typically don't have a clue about how software is developed. When they hear the word "prototype", they probably think about something like a prototype car from Detroit or something like that. In-fact, I can't think of an instance when I use the word "prototype" outside technical fields. Obviously, users just don't have the same meaning assigned to the word that developers do. Developers often fall into the trap of failing to recognize this gap and jump feet first into their own graves. The next stop on this train occurs the day you show the prototype to your manager, boss or other decision maker, and their response is "Wow! I knew you were fast, but not that fast. I guess this will be ready by Friday then. "All that effort put into designing a perfect application is thrown away by a mistake.

What this means of course, is that we have identified a risk to project success. Just like the technical risks we identified on day 2, these risks have the potential to derail and destroy our project. We must take steps to understand these risks and be prepared to prevent the causes of this risk or at least limit our exposure to it.

Risk reduction and research - Take 2

What is the best way to approach the problem that presenting prototypes to users can cause? Well, as with anything, there's more than one way to skin a ... um ..., I mean more than one way to accomplish something. Here are some of the strategies we can choose from:

1. Push prototyping until after we have a finished design
2. Push prototyping until after the project is semi-useful
3. Just take our prototypes to the users and cross our fingers
4. Only present screenshots of our prototypes to the users
5. Create a controlled demo of our prototypes using Flash or DemoShield or something
6. Forgo prototypes all together

Which strategy is best? Well, it just depends on the project, the makeup of the users, the target audience, schedules, etc. Part of our job here is to choose an appropriate strategy. Lets examine each possible strategy a little.

Push prototyping until after we have a finished design

I can't think of a situation where this is a good idea. I just can't. Not only would this increase our risk (we could have wasted much of that design work if the users puke on our ideas), but I can't think of a reason why the prototype would be better then than now. Well, we might learn something new about this project, have an idea, or come across a new problem, but that is another risk we must weigh. Even considering the potential risk of us uncovering a new idea or problem, we must counter that with the cost of user mandated changes.

Push prototyping until after the project is semi-useful

Just what exactly does "semi-useful" mean? I think this is one of those terms of convenience that only has meaning to developers but means nothing to users. As far as users are concerned, semi-useful is the same as useless.

Maybe that's a little harsh, but I suspect that most of the time, it is not. There is a concept called "tracer bullets" which I found in a book called "The Pragmatic Programmer". The general concept here is that, if we must present users with some form of interactive experience, we must be practical and realize that there is a high risk of having our project schedule smashed. Instead of a mock up, we go ahead and "frame-in" our applications, not leaving out error handling and other real-code stuff. I really don't care much for this concept, but if the situation demands it, it's better than no prototypes at all.

Just take our prototypes to the users and cross our fingers

This is the most common approach used to present prototypes to users and the one which many of us have seen fail over and over again. I don't think this method is necessarily a bad way to go about presenting our prototype, but it needs structure, control and a little luck. More importantly, when using this method, the developer needs to use his intuition to measure up the audience and weigh the risk. Is my audience likely to jump on this as a close-to-final product? Are they going to understand that I'm nowhere near finished? Will they be able to fill in the missing gaps (such as no implemented menu points, etc.)?

The answer to these questions is largely dependent on how close to the technical side of development our audience is. It is also dependent on whether or not the developer has evangelized his audience on the nature of software development and whether or not it was well received. Be careful when taking this approach and realize that we developers see things that aren't there (like print outputs, help pages, etc.). Users typically don't possess this ability and are likely to look for these types of features because they are natural outcrops of how they use software, and what they expect.

If you are going to take this approach, carefully consider how you are going to deal with missing features (and be realistic, don't overlook anything). Are you going to mock up every possible screen and output? Sanity says that this is almost always a terrible idea because if that's your approach, you might as well wait till the project is finished, because making all that stuff work is going to take a while.

Only present screenshots of our prototypes to the users

This is an often overlooked method that deserves much more attention. With this approach, you have the benefit of writing a prototype without the risk of overlooking features, or exposing the user to crashes or other unexpected behavior. You have total control over what you present and you can storyboard the screenshots for effect.

This method is not always ideal, though. Be careful with this approach because you will most likely leave the screenshots with the audience. With an application, you will typically control where and when the program can be executed. You don't want to put so much on the page that users will be asking questions for days, nor do you want to show too little. Bare this in mind when taking those screenshots. Also, be highly selective in what you show.

P.S. Another advantage to this method is that if we need to (for whatever reason) we can use Photoshop to cut and paste together GUI elements without having to make any special GUI components we don't already have.

Create a controlled demo of our prototypes using Flash or DemoShield or something

I have never used this method, but have seen it used. On one hand, it is nice to be able to see the application in action on screen. The programmer still controls what the user sees and how the screens are presented, which is a good thing. On the other hand, one of the problems I have with computer based prototypes is that users often have a hard time separating a computerized demo from the real thing. The advantage of paper is that it is totally disconnected from the computer and users seem to be better able to see this separation.

One other concern with this method is that I suspect it will take longer to put this type of prototype together. I don't like spending much time on prototypes. Just enough to make it look good and look useable, but not more.

Forgo prototypes all together

At the other extreme of these options is the option of not presenting any prototypes at all. I don't usually like this method, but the risks of presenting a prototype may just be enough to warrant its use. Some examples of where this method might be appropriate are:

1. The project involves merely copying another product (i.e. company doesn't want to pay for X, so you have to write X)
2. Past experience with audience has all been bad
3. Totally new project to users, but not to you. You really (and I mean really) understand the user's workflow and feel the risk of showing them a prototype is greater than not showing one.

Even if you decide that presenting a prototype(s) to the users is not a good idea, it might still be a good idea to put together some internal prototypes to test your ideas.

Time to pick a prototype strategy. Lets see, our target audience is software developers, so that should help offset the risk of interactive prototypes. Also, this is a user mandated project which means they have a great deal of influence over this project (the spec even demands it). We feel good about our model at this point. This may just be one of the rare situations where an interactive prototype is acceptable. I normally lean heavily to the screenshot method, though, so be careful in your selection. After some more thought, though, I can't think of a reason why an interactive prototype would benefit us. We want to get our ideas in front of the users, not our applications. Therefore, we are going to take the paper screen-shot approach.

What exactly is a prototype? - Take 2

To put it simply, a prototype is some medium presented to users with the intent of communicating our vision and model of the application through UWEs. The prototype may include forms, dialogs, reports, web pages, help files, or any other article that the user will see or interact with. An important thing to remember when creating these articles is that they need to be presented in such a way that makes sense to our users. For instance, don't take screen shots at 1600 x 1280 resolution, if our target user typically uses 1024 x 768. Keep an eye out for "out-of-place" stuff in your prototypes so that you don't give the user or ourselves a false impression.

STOP THE PRESSES!

We have forgotten a critical part of this project. How can we move on without solving this problem? ... We've got to give our project a name. We need something cool, possibly a codename (like Longhorn or Yukon), maybe a user-friendly name, maybe an acronym. We've just got to have a name.

No really, we do. The GUI elements we are going to present need a title like every other application, so lets come up with a name for this project. (Besides, who wants to work on the "Issue Tracking project" when they can work on "The Prometheus project". After some thought, I've decided that I like the idea of having a codename for this project, something cool. What are some cool code names for this project? Here are a few of my ideas.

I really like cameleon (damn! misspelled it already), but I know I'll get it wrong over and over again. I really can't think of a another good project code name right now. Please suggest some good names for this project. (I'd love to hear from readers if they have any cool project code names to offer.)

Getting organized

We're well on the way to having a name for this project, so lets dive into the prototyping. Here is a list of the GUI elements we need to mock up for our users.

1. The "record a bug" data entry form
2. The "idea data" entry form
3. The "fix a bug" data entry form
4. The "Show me a list" form
5. The Windows Explorer namespace extension
6. The task bar tray-icon with popup menus

We could include a sample report, since that is part of UWE #5, but I am uncomfortable with this because we don't really know what fields the user wants, or if our model is going to work at all. We are most interested in validating our model, not getting too deep into details. We want to get a good feel from our users, not a list of questions a mile long.

Exactly what is this going to look like?

Well, I have given this a great deal of thought, and it's an important question to answer. All of the applications listed above (except the namespace extension and tray-icon) are pretty small little applications intended to make getting information in and out of the system efficiently. We want to make the user feel at-home with these applications, since they will be the most commonly used visual aspects of the system. Therefore, we need to take special care when laying out how they will work. Their appearance must feel natural to our users and must not overwhelm the users.

Many times, I like to look at what the competition is doing and use their best ideas in my design. In this situation what I would be looking for is what not to do, so I am going to forgo that process on this project. Instead, I want to look at other data entry tools our developers are already using. One name keeps coming up, MS Outlook. Our users are currently using it regularly, they will be using it as part of the data entry mechanism (sending e-mails to our special accounts), so modeling our UI after this, at least seems natural.

I know someone out there is thinking that not all developers use MS Outlook, and they would be right. For that reason, lets take a look at Eudora, Pegasus Mail, and The Bat!. (Note: I could not find any decent screenshots of Pegasus mail, and I did not want to install it on my PC, so I am basing my observations on the limited screen shots I could find.) Composing a new e-mail in each of these consists of popping up a new window (appears to always be sizeable) with a menu, toolbar, controls area (fields such as To, CC, Subject) and finally a large area for text. When sizing, the notes area expands horizontally and vertically and the fields size horizontally. This is pretty much the same as the way MS Outlook works, so I think we are safe taking this approach. I really think that users will find this to be a natural feeling interface. Another benefit is that we can use SDI based apps which makes it easy for the user to quickly hide, maximize, minimize and resize the windows. One potential downside to this approach is that there will be one taskbar entry for each instance of these windows. I don't think this will be too great of an issue, though, since ideally they will not have many of these open at any time.

We could look into using a web interface, but I have yet to see a truly rich web interface. If you know of any, please let me know.

Our prototypes - Take 1

I have prototyped the first 3 UWE's and I want to give them a good solid review before proceeding.

Here is the source code to our prototype demo application. It takes command line parameters to determine which form to display.

• To see the "bug" forms, don't use any command line options. IE. "Sample1.exe"
• To see the "idea" forms, pass -idea exactly like this (in lower case) on the command line. IE. "Sample1.exe -idea"
• To see the "fix a bug" forms, pass -bug all lower case on the command line. IE. "Sample1.exe -bug"

Click here to download the demo project

Here are the screenshots of these initial prototypes:

Recording a bug:

A

B

C

Recording an idea:

A

Fixing a bug:

A

Critiquing the screens

I feel pretty good about these screen layouts, but I don't want to do anymore until I have reviewed them and thought through any potential usability problems, glaring omissions, spelling mistakes, etc. Here are some of the issues I see with these screenshots.

The toolbar

I used icons from known sources, so they look good. I used MS Outlook as a guideline (i.e.. words on right instead of under, similar spacing, similar icons). One thing that is missing is the little etched line between sections that MS Outlook has. I know this is nit-picky, but I would prefer the little lines to be there.

The time fields

Each of the main panels has a date and time entry field on them. The date field has a corresponding drop-down button with a popup calendar, but the time does not. Entering time is typically a structured type of thing (i.e.. masked edit, dropdown or something). Just the edit box does not convey much information to the user on how to enter the time.

Source code hints (Record a bug, Screenshot B)

I added this list here because many times when someone notifies me of a bug, I have an immediate idea of where to go and fix it. I would like to be able to record that and look it up when I get ready to fix the bug. After some thought, I am not sure why I need a list control here. I think I'll just make that an edit box.

The My fields panel

I know how I work and there are times when I need to record structured data without hassling with redesigning forms and all that crap. I just want to create a new field and drop in the value. Maybe later I'll redesign the form to accommodate the new field. I went with a simple list control with 2 open ended fields (name and value). Seems simple enough, but what about recording dates and times, long text, images, etc.? I think this simple method is just too simple.

I have a control I created for a project a few years ago that presented the user with a very simple auto-generated form, based on fields previously created. This control presented a real edit box, date picker, file picker, etc. instead of just simple edit boxes. There is a web-like link labeled "Customize" in the upper-right hand corner, that allows for quickly adding new fields. I think I will use this control here.

Fixing a bug panel

We want to make it incredibly simple for developers to use this tool and recording that a bug was fixed is a critical link in the chain. The "Bugs fixed" list shows the user, a list of active bugs for the group/groups selected above, from which he/she can select as being fixed. The "Projects / Files involved" list shows the user, a list of recently detected file changes and allows the user to check off which ones were involved in the fix. A change snapshot for those selected files will be automatically incorporated into the bug fix record. A potential problem with these lists is that they are too small. I designed these forms for 800 x 600 and I wanted to make sure there was plenty of room left for comments, sizing the forms will increase the size of these lists, so that helps. I could shrink the comments area, but this would only buy me a small amount of space. I could add tabs to the property sheet for these individual lists and this would make for plenty of room. I don't like this though, because I can definitely see those panels never being used. These features are far more likely to be used when they are on the same page as the other critical information.

After some thought, I have what I think is an innovative idea. What if I added a gripper to the bottom right of each list (like is typically found in a status bar for non-maximized windows)? This gripper would be drawn on-top of the list contents, but should be out of the way enough to be non-intrusive. The way I see this working is that a user could click on the gripper and resize the list to whatever size they want. When they are finished with the list, they click outside of the list and it snaps back to the original size.

Nit-picky stuff

Did I spell everything right? I know what you're thinking...who cares!? Well, I think it is important to remember that first impressions are critical to many aspects of life and these prototypes will be the first impression our users get, of the application we are building. Simple problems like spelling mistakes can be a nick in that impression.

On the "Fix a bug" panel, the label "Projects / files involved in fix" is really more information than is needed. Lets just change that to "Projects / Files involved"

The list controls on these panels need to have their columns sized appropriately.

We need to fill in the various fields for our presentation. Leaving the fields blank does not communicate as much information as having them filled can. We want to fill the fields with relevant values that make sense to our users, not "dfjhadfjasdfjhsdafhj".

Should prototypes be developed this way?

The code for these prototypes is a worthless piece of crap that I wouldn't put my name on without a gun pointed at my head. (In case you're wondering, I used Visual Studio .NET, MFC, some of my own classes and some fellow CPians' classes.) Is this the way prototypes should be written? Good question. Should prototypes be thrown together in bouts of uncontrolled typing without proper coding guidelines, or any concern for reuse?

The answer depends entirely on how you plan to present the prototypes and how confident you are that the prototype will not become the end product. Ideally, prototypes will always be thrown away and dropped into the deepest pits of hell, never to be seen again. As we discussed earlier, this is often not what happens. If you take the paper approach, it's probably fine to just throw the code together without finesse. If you take the DemoShield approach, you're going to have to refine things a little further (like filling out menus) and picking better icons, etc. If you're going to show the users a live application, walk with care. You're just going to have to judge your audience and determine the proper mix of code quality/schedule/risk that fits the bill.

I do not like spending a tremendous amount of time on creating prototypes because of their volatility and the fact that they are to be thrown away.

What's next?

We need to take our self-criticism and adjust our prototypes accordingly. We also need to go ahead and put together the other 3 prototype components. I am going to do this behind-the scenes, though. Tomorrow, we are going to move on to our architectural design. In the mean-time, please suggest better names for this project and critique my prototypes and ideas.

Homework

We are about to have an important meeting with our users. We need to prepare for it by putting together an agenda and gathering any necessary materials we will need. We want to come off as good as possible so that we instill confidence in our abilities to get the job done, and done well. There is quite a bit of information on the net on meeting with users, and I have posted an article titled "The Standalone Programmer: Communicating with users" that you can read also.