Years ago attended some training in information design from Jared Spool of the firm User Interface Engineering. One thing that Jared said that really stuck with me was this: in the software design community we use the phrase "look and feel" a lot, and usually we spit it out as a single word, lookandfeel. But it's useful to parse the phrase. A software UI like an operating system or application has certain attributes that we can call "look" attributes, and other attributes that we can call "feel" attributes."
• The "first impression" visual appeal (for example, "Oh I recognize that this table in Project reminds me of Excel").
• The ability to transfer knowledge from experience with a different UI (like the fill handle for using the AutoFill feature in both Excel and Project).
• From a software design perspective, relatively easy to change or customize (or "skin," as we sometimes say).
While feel is:
• Deep and architectural; baked into the bones of the product.
• Extremely difficult if not impossible to change beyond a certain point in the product development lifecycle.
This distinction leads to all kinds of interesting ideas in software design, but my focus here is twofold. First, I've previously pointed out the drawbacks to entering fixed dates on tasks. In the Project UI this tends to cause problems for people--the Excel-like ease in setting fixed dates on tasks rather than creating task dependencies, and the deep-rooted consequences of doing so.
More broadly speaking though, the rigid data type requirements of most fields in Project make it a difficult tool for some types of planning--a subject I have previously touched on as well and will elaborate on here.
Table for two?
If you're an avid Excel user, some parts of Project feel pretty familiar. The table portion of a Gantt chart view, for example, has some capabilities like AutoFill that might remind you of Excel. But the similarities are shallow (more look than feel) and sometimes misleading.
Here for example is a free-form brainstorm (emphasis on the "free") of an initial task list for an upcoming project.
TIP Click the screenshot image to see a larger view.
While Excel is a free-form grid, the table in Project is highly structured and restricts what kinds of data you can enter in most cells. The table in Project is, indeed, a table in the database sense of the term (more feel than look). Each row in a Project table represents a task (or in other views, a resource or an assignment), and each column represents a unique data type, called a field. If you come to project with, say, a background with structured database applications like Access, then the table in Project not only looks familiar, but should feel familiar as well.
Here's my same free-form brainstorm of an initial task list for an upcoming project. It's not so free now though; the Duration, Start and Finish values in Project allow only specific data types.
If you're a George Carlin fan, let me put it this way: Excel is more like baseball, while Project is more like football.
Am I just splitting hairs with geeky definitions here, you may ask? Not really--this is important stuff. A lot of project users quickly discover that the Project table is not well suited for the kind of free-form data entry they would expect in Excel. You can't for example enter a task duration of "a few weeks" or a start date of "sometime in August." At least you can't in Project 2007 or earlier.
Hands-on with Project Step by Step
To read more about this blog entry's subjects in the two most recent editions of Tim Johnson's and my Project Step by Step books, see the following cross-references.
- Project 2007 Step by Step: "Creating a Task List," pg. 36.
- Project 2003 Step by Step: "Creating a Task List," pg. 32.
- Project 2007 Step by Step: "Linking Tasks," pg. 48; "Adjusting Task Relationships," pg. 137.
- Project 2003 Step by Step: "Linking Tasks," pg. 43; "Adjusting Task Relationships," pg. 123.