Second Design 06

The User Experience

Our data design centers around these features:

  • How/where does this item fit into the Strong genealogy? Internally we discern this with the Dwight classification number.
  • From this item, we can click to the Langbehn Database, which allows us to explore the early Strong genealogy and family relationships.
  • From a given point in the Langbehn Database (or anywhere else, for that matter) we can bring up links to all related resources we have online with the SFAA.
  • We can create a master names list as the alternate way of exploring the above.

I don’t think we need to design in any advanced searching capability. That can come later as experience warrants. The Langbehn Database does have advanced search capability.


Multi-Part Data Design

The first part of the data design is the natural representation of the artifacts which I’ve described. We can base that design on samples of each existing artifact.

The second part of the data design supports the user experience. In other words we need to define the end-user Web site:

  • What information should be on each type of Web page?
  • How should things be interlinked?

We don’t need to design implementation details such as pagination, site layout, or navigation. The implementation is dictated to be in MySQL and CakePHP.

CakePHP allows for extremely rapid development if the data design supports the Web presentation. That is, if we design the properly-normalized tables around how we want to present the information.

These tables are read-only. We only update with data imports.

Of course how we present our information may be quite different from how we naturally represent our artifacts in a database. That’s why I suggest a multi-part data design. We have one design to support the artifacts and data import, and we have the other design supporting the User Experience.

We would then have some process which imports/replaces data from the “artifact” area to the “presentation” area. I see that as an implementation detail which need not be addressed in the data design.

There is potentially a third part of the data design. Some of these artifact data imports may be tricky, and handled over time. I expect to probably create ad-hoc tables supporting those imports. From those tables I could then transfer/import the data from the ad-hoc import area to the first part of this data design, which “properly” represents that artifact.

This third part need not be part of the data design. In my mind, it’s an implementation detail to be determined later.