A Look at diPH’s Architecture

Text:
Increase font size
Decrease font size

Now that we’ve completed a fully-elaborated demonstration project in our diPH prototype, and have begun to work on the actual diPH plugin, we’re thinking in earnest about how all of the beta features will fit together, on both the back and front ends.

Map and Marker Icon Libraries

A high-level view of the diPH plugin architecture, designed by Joe Hope using the Idea Sketch app.

Two of the critical features we plan to offer are map and marker customizability (for projects with a geo-spatial component). Our work on Main Street, Carolina taught us the need for an extensible set of maps and marker icons. While we will provide a map library of current maps that can be used in diPH, we do not want to limit our tool to one set of maps. To be extensible, we need to be able to pull in map layers from a range of servers using a range of georeferencing and rendering protocols, including Tile Map Services (TMS) and Web Map Services (WMS). Our hope is that, through the use of APIs in the map library, all a user need do to add a new map is copy and paste the URL of that map’s source location. That is, rather than serve all the maps through diPH, the tool will point to other maps in other locations – but the site visitor will not notice the difference. New maps should retain their functionality in diPH.

Additionally, it’s important that the ways of marking up the map will be highly customizable – from the standard pin drops that you see in Google Maps, to recognizable icons for institutions such as banks, hospitals, schools, and so forth. Administrative users will also be able to create and add their own icons, thus making our marker icon library extensible. And, we’re also exploring how we could generate and display polygons and line data on maps.

Marker Capabilities

Much of our work has been devoted to thinking through the user experience for creating, editing, and deleting markers (or, for non-geospatial projects, data points). Broadly speaking, each data point functions as a “post” in WordPress. So whether it’s a marker on the map, an element in a genealogical family tree, a point on a timeline, or a node in a network visualization, each data point will share the same functionality (for simplicity, I’ll refer to data points as markers). Like any WordPress post, markers can have titles and textual information (e.g. interpretative analysis or narrative) and can support a range of multi-media content. They can be assigned categories (hierarchical) and tags (non-hierarchical descriptive labeling).

But that’s just the beginning. Users will be able to create and define custom fields for markers. These would be the equivalent of attributes in a database (i.e. columns in a table). Admin users will be able to modify, add, and delete their fields at any point in the creation of their project. And they can decide how their site visitors will interact with those fields. That is, some fields might contain additional filterability and searchability. When logged in, administrative users will be able to edit the content of their markers from the administrative dashboard as well as from the front end. We envision a seamless set of interactions for administrative users that reduces the number of unnecessary clicks in a streamlined interface.

Look for a much more detailed blog post on marker capabilities in the coming months.

Audio/Transcript Tool

One added piece we’ve started developing is the Audio/Transcript tool, inspired by our Long Women’s Movement Oral History pilot project. This will allow us to stream audio and text simultaneously. We’re beginning to think about how to extend this functionality to other media types, such as video or images. More on that in a future post.

Project Layer

And then there’s the project layer. All of the data for a project (for instance, each of the properties in the Hayti project, along with each parcel’s corresponding details and documentation) will be tied together in the project layer. Think of it as the top-level category or root node in a hierarchy. Anything that you add will be bundled together under that project category (all markers, images, media files and any descriptive or interpretive content you’ve created). This will allow users to export projects out of diPH via project feeds. Project feeds can be pulled into other websites, loaded into other diPH instances, or transformed for use in another platform. This approach also allows us to create multiple unique projects within a single diPH interface. Creating, for example, three separate and unrelated projects can either be done by hosting three unique diPH websites, or including them all in a single website. The project category layer allows you to silo your projects, as we have done in our diPH prototype – the data for our Charlotte 1911 project is completely separate from Hayti. The two projects require different categories, different tags, and different content types, but because they are distinct projects in diPH, there’s no conflict between their different structures.

Administrative Layer

Encompassing all of these layers together is our Admin layer, which we’re designing to fit seamlessly with the WordPress Dashboard. We want to make it as easy as possible for administrative users to create and edit their content, while taking advantage of all of the affordances WordPress has to offer.

This is just a taste of what’s to come. Stay tuned for more detailed looks at these different pieces of our plugin.