[RESOLVED] Tracking and managing projects and design

This is kind of a two-part question and it doesn't seem to relate directly to any other forum so I dropped it here.

I originally was going to develop a few of programs by doing one then moving on to the next. Now I am finding that in the background, there is so much that can be reused, I am thinking I should start thinking about all three programs at the same time so I get all the issues together.

I've also now been handed a new project that will last several months that is completely unrelated to my own stuff. BTW, I still don't really considere myself a "programmer" yet, but I am trying. Using VB2008.

1) Project Management - What do you use to manage the full extent of projects? I am finding that my regular stuff gets in the way of programming and I want to make sure I leave myself enough time to do everything. I tend to bump my own stuff because it won't bring in money until I am finished and I bump for consuslting that does bring in money. Right now I am using Outlook and scheduling time to do the programming as well as tasks to track some specifics but I am not sure this is the BEST way. Is MS Project a better way or overkill? Is there another program (eg. cheaper, more complete, easier to use)?

2) Design - What options are there for tracking design elements? Currently, I am using a Word doc to itemize forms, actions, etc. but when it comes to form design, I am resorting to paper. This works but I find it a little clunky, especially when I want to just mock up a few things and show an end-user and ask "which do you prefer". Is there a better way?

TIA rasinc

Normally you'd want to approach design in terms of an application, which may consist of several programs. Some common functions will be so obvious that you'd start right away by designing reusable components for them. Other things will be discovered as the application design progresses, and you'll want to factor them out as components as you go. Some of this can happen at a high level, before you write any code at all. The rest is going to be grunt work as you code: commonality will be recognized and you'll have to recode things for reuse.

For solo development I can't imagine needing MS Project but you could. More likely all you need is a spreadsheet where columns contain time spent on activities (coding, testing, documentation, maybe even broken down finer and probably with other things in there) and rows for each day or week. You might have totals by interval (week, month) and show those as %s of your estimated grand totals to be spent on each.

You just want to know whether you're spending enough or too much time and where, right? Based on the running totals and %s you should be able to project completion by eyeball.

People usually use some form of structured drawing tool for prototyping things like Forms or Reports. Visio is an obvious candidate, and I think there are Visio templates for common Windows Form elements and report items. Some people will even use PowerPoint for this kind of thing, but that has its limitations.

You can even rough out Forms in the IDE. You don't need to add any code, just drop controls and set a few things like caption properties and such. In olden times we had stuff like Dan Bricklin's Demo. You might read through Review: 16 User Interface Prototyping Tools.

Thanks for the info and links. Interesting reads. I hadn't actually thought of Visio. I think I have an old copy, 2000 I think but only ever used it for tracking networks, never thought of forms design. Wasn't into programming that much when I was setting up networks.

Maybe I'll try a spreadsheet instead of word processing for documenting for now, but if anyone else has any comments on this, I'd like to hear them. I figured Project was a little overkill and yes, I am a solo programmer right now.

I have prototyped forms directly in VB but have had people not really "see" things like list boxes when no data really exists, so I thought if there was something that showed real data, I wouldn't have to put in time putting in fake stuff just to show data when really only need just images. Maybe as I go along, I'll just create my own images for prototyping what I am missing. I think I still have Snagit around somewhere.

Thanks again.

Ok I see where you're at now. It isn't just static UI layout, you also need an interactive model showing how the UI will operate. I suspected as much but that's going to be more work than just painting forms, you're right.

One thing to be careful of is that users often don't know best. You can end up with a UI that seems clear to them but is hell to program reliably, or worse yet one they think is great when they're new to the idea but in practice it'll be much slower and clunkier for them to use than one adhering to standard UI guidelines. "The customer is always right" of course, but they're paying you to help them avoid mistakes too. Just like when they hire a plumber or a doctor.

I have a philosophy that I created when I made pizza. The customer is always right, unless they are wrong. The big touble I find when I write reports for people is that their original view is not always what we end up with. I make people write up a mockup of a report with their real-ish data so they can visualize it before it comes to me. I get far fewer modification requests that way.

Having them mock it up a program form is not as easy. I can't always do it myself the first time (my design of a form, from yesterday is different now that I slept on it). So I thought I would ask how others handle it. And it seems that there is really no one best way to handle either the forms layout concept, nor the project planning aspect. Each project is different and things change based on that, so I think I am going to have to get with the program and get the programming done and not worry so much about how to do it.

Quote:

---

than one adhering to standard UI guidelines

---

Now if only I knew what those were :) but that is a topic for another thread some other time. Thanks for the info.

Some baseline material is available here Windows User Experience Interaction Guidelines. There are several books on this subject too.

Thanks. Looks like I've been using some of it but there are some interesting parts too I've never considered.