Kristen, thanks for these comments. I wanted to pass along my initial response; since you and Joy went through the trouble to look at everything and let me know what you thought, I thought I should let you know how I arrived at some of my initial decisions, and what I'm rethinking in light of your review.

This will be a useful exercise for the reflective piece for my portfolio, too.

florykri@... wrote:

*Strategy Document *

 

You nailed it. Visually, you could bold the first point in each numbered text list. It would just improve easy readability a touch.

Thanks, that's a good idea.

*Function Requirement-- *

            When you numbered your sections--hardware, software, etc., the numbers jump from 1 to 4 to 6…..what happened to 2,3 and 5?

That's very odd. Were you viewing it in Internet Explorer?

The numbering is actually being done by CSS. Here's how it works:

- I define a class of level-3 headings that have the "list-item" display style:

   h3.numbered { display: list-item; }

This means that any h3 element with the "numbered" class acts like a list item.

- I write the document using <h3 class="numbered"> tags to mark up my section headings.

- I surround the whole thing with ordered-list (<ol>) tags:

   <ol>
      <h3 class="numbered">A Section</h3>
      ...
      <h3 class="numbered">Another Section</h3>
      ...
   </ol>

That should cause the browser to turn each of those h3's into a numbered list item:

   1. A Section
   ...
   2. Another Section

It works fine for me in Firefox and IE7, but maybe IE6 has a CSS bug (wouldn't surprise me) that breaks this.

I'm tempted to keep it anyway. It's a nice use of the technology and IE6 is known to be crummy... But I'll look into it.

*Use Cases *

Very comprehensive. No suggestions… OK, Joy just said what about a “new” user or a “visitor”--is that something your system would need to be flexible with?

Ideally, there should be various sorts of help, probably a tutorial, etc, but given the schedule we have in 410, I probably won't have time to create much of it. Something to think about though.

*Architectural Diagram *

For the “results” multilayer page….should that be a multilayer file instead of page? (the dog-eared page?)

If I understand Garrett's description, the "file" boxes are for content that's non-HTML, like PDF files that the user downloads or reads in another application. (OK, many users read PDFs using browser plug-ins and don't know that they're not web pages, but that's supposed to be the idea.) My results pages are HTML, so I *think* that the multilayer page is correct. But I find Garrett's descriptions for his symbols rather vague.

The 1C connect is a little unclear. If sign-in is successful, wouldn’t the arrow point directly to the dotted container?

No, after a successful sign-in you stay on the same page where you were; there are just more items in the navigation menu now. So you don't actually "go" anywhere - you just get more controls you can use.

That probably needs to be clarified in the diagram.

**May need more specific references to the add, comment, edit (perhaps number them) to refer users to the next page. (this was Mike’s suggestion)

That's a good idea.

*Information Views *
 

What about an area to comment/annotate for each bibliographic entry? Is this what the comments in your Arch. Diagram would do?

Yes. I can make that clearer.

*Wireframe *

Good. Nice colors. Easy to understand.

Thanks. I drew those with OpenOffice's Draw application, which is actually quite nice and easy to use. And free.

*Database Design *

            User chart--you should break the full name into first name, last name.

Actually, I deliberately don't separate any names in the system into first and last name. Here's why:

- First and last name are a European convention. Some cultures (eg Indonesian) don't have separate surnames and personal names. Some (Chinese, Japanese, Korean, Thai) put surnames first and personal names second; and when transcribing their names, some people from those cultures reverse the order and some don't. So "first" and "last" name are not well-defined.

- Some names don't refer to people. This applies more often to bibliographic entries - if I had "author" separated into first and last name, I'd have trouble with government publications (where the author is usually a government agency), for example. But it could be true with users of the application, too. Maybe at some point someone wants to create an ID for use by everyone in a group, for example, and they want to put the group name as the "user name".

- Having surname and personal name separated actually isn't all that useful, especially for a small set of users. There's no need to do it for lookup purposes (as with a phone book) - we can search the database. There's no need to correlate these user names with any other database; we don't even have any reason to think people are using their real names.

It's true that one rule of database design is to get the information you think you might need up front, because it's a lot harder to go back and get it later. So if I thought it was likely I'd ever need users' names broken up into surname and personal name, I'd want to design the database that way. But another rule is to have the database reflect how the data's going to be used. I don't anticipate ever using the user names as anything but a single unit; they're just for display purposes. So I don't need to know how users might break their names up, and the database doesn't either.

*Comp *

            Michael, the site itself is really your design concept, yes? It’s very nice and matches back to the wireframe.

Well, the app may deviate a bit from how the site currently looks, but it'll be similar, at least for the first version.

Thanks again! There's a bunch of good stuff here, and it'll definitely help as I'm putting the portfolio together this week.