We’ve devoted a lot of time in the past few weeks to working out how the project layer – the highest level within diPH – should be structured. The goal of this layer is to package all of a project’s associated content (visualizations, data, and user-generated content) into a unified bundle as a single JSON feed that can be exported to other diPH installations, CMSs, or blogs. All diPH content must be associated with at least one project, though content can be re-used across projects, whether in a single diPH instance or not.

A high-level view of the project layer, and all of its associated content.

While all of the data will have the same backend structure, it will be rendered differently on the front end depending on the visualization chosen. A geo-spatial project, for instance, will use a map as its primary method for displaying its data. The map, then, would be the main (but not the only) point of entry into the project’s content. As we work on our oral history pilot project, we have been exploring other visualization types, including using individuals and concepts as additional points of entry. We envision a display of “people cards,” where site visitors can browse via each oral history interviewee. Likewise, concept cards (possibly ranked based on number of mentions) will be another point of entry. Allowing multiple visualizations enables us to support both structured search and exploratory browse for our users. Additionally, we are experimenting with how we can continue to preserve the other visualizations regardless of the active visualization. For instance, when a user wants to browse by concept cards, we’d like him/her to also see the interactive map, at least as a thumbnail. This will help users draw connections across the visualization entry points, hopefully producing a more cohesive project. (More on our progress on the Long Women’s Movement pilot to come in a future update.)

Though a project may have multiple visualizations for its data, only the primary visualization will determine the type of data point (a marker, date, tree element, network node, etc.). Once a primary visualization is selected, secondary and tertiary visualization types may be applied, and can be edited at any time by the admin user.

All of the content in a project is contained in WordPress posts. That is, individual markers, events and so forth are stored and rendered as blog-like post pages. This allows us to maximize WordPress’s blog power. But we are adding some important enhancements that enable us to harness the potential of WP’s underlying MySQL database. When setting up a project, an admin may create an unlimited number of “custom fields” (think of these as attributes in a database), which will be associated with every data point (or WP post). This allows the project’s information to be structured, which allows for rich search. Additionally, faceted search will be possible because admins will be able to create structure within and among their custom fields by creating filter controls (more on this in a future post). That is, custom fields can be arranged into hierarchies and groupings to support controlled vocabularies and other taxonomical organization.

Admins can select a custom field to serve as the primary category for a project. The category determines the appearance of the data point. For instance, in the Hayti demonstration project, buildings with a commercial use display as red, residential properties are yellow, and community spaces (such as churches or schools) are blue. This allows site visitors to quickly see and process the different data points. Because the category has the same structure as any other custom field, admins can change their categories as they create the project, and they can also create structure (child categories) to enrich the visualization. In a geo-spatial project, the categories determine the marker icon (color, shape, size), but the same applies to other visualization types.

Of course, an admin may choose to leave the data unstructured, and can add the content in narrative form to the data point’s post content area (that is, he/she can simply load text as if publishing a blog post). This makes it easier to create a project, though search capabilities might be more limited. While full-text search is always possible in WordPress, the kind of faceted search we’ll allow won’t be possible without custom fields. We recommend that projects contain at least one custom field, which can be used as the category to drive the visualization. A project with few, if any, custom fields will emphasize browsing over specific search tasks.

Finally, projects will contain user-generated content, including tags and comments. WordPress currently supports tags, which we used in the Hayti project (each tag is a specific building use, such as barber shop or funeral home). Tags are non-hierarchical metadata (i.e. additional descriptive data). For now, we will reserve tags for user-generated content. Site visitors would be able to tag (and save) data in a project in ways that are meaningful to them (a folksonomic approach). WP also supports comments, and since every data point is a post, it is very easy for users to comment on data. We are not focusing our current efforts on user-generated content, but once the beta version is completed we will begin working on this aspect in the next phase of development.