2011 Cultural Heritage Informatics Fieldschool

To begin, I’d like to illustrate msu.seum by the numbers…

• 6 CHI fieldschool students
  • 2 programmers
  • 2 UX designers
  • 2 content curators
• 10 days
• 60 hours… officially – some have kept working off the clock!
• over 1000 commits to our file repository
• 42 folders and subfolders
• 300+ files, all manually generated and coded

msu.seum is the first development project I’ve seen through from concept to finish and I leave it and the field school with new experiences and lessons which I can apply to my future work as a web developer. For instance, I learned some invaluable self-teaching strategies and was humbly reminded that patience and perseverance are required for this kind of work. And, above all, I learned that lolz, treats, and good jams make slaving over a hot laptop for 8 hours a day much less painful.

As I reflect on the past 2 weeks of my time developing msu.seum, I find myself thinking about how the app and future development could be improved in subsequent phases. As new mobile developers, we faced conceptual, experiential, and organizational hurdles – many of these we overcame, but some issues proved insurmountable in the short time that we had to complete the project.

Our most damning challenge had to do with content management. That is to say, we did not utilize any sort of content management system (CMS) or database to store and organize the data that comprises msu.seum. This was not a deliberate decision – in fact, it’s a question that never came up. Because we started development in the last two weeks of the five week-long fieldschool, we were forced to make really important foundational decisions (such as deciding how to manage and organize data) on the fly or not at all. This resulted in a development process mired by confusing information architectures, ad hoc workflows, and an incredible amount of hand coding. The numbers above illustrate, if nothing else, the sheer volume of work and raw data that has gone into msu.seum as a result of not utilizing a content management system.

A content management system, in general, simplifies the publication of content to websites and mobile devices. It allows content creators to create, submit, and manage content without requiring technical knowledge of programming languages such as HTML or Javascript. A database is the repository at the core of a CMS that holds all of the content for a particular site or application. With the content organized and able to be summoned from the database, developers can then use a server side language such as PHP to program the site to call content forward in response to the user’s queries.

To put it another way, a database enables the separation of presentation, style, and content in websites and mobile applications. Without a database to manage the enormous volume of data associated with msu.seum, we were unable to achieve a separation of style and content in the application. All of the content for the application lives in numerous HTML files. This made for a confusing, time-consuming development process. For me and my UI teammate, Minh-Tam, this meant that we were stuck in a never-ending circle of overwhelming, repetitive workflows to implement even the smallest change to the interface of the application because we needed to update every individual HTML file of content in the application.

Furthermore, msu.seum, though finished and functional, will not be easy to update in the future because content is situated within the programming. In fact, subsequent phases will result in the application being remade from the ground up unless a database is implemented. Because the content and programming are contained all together in the same HTML files, a programming update will necessitate a content update, even if the content remains the same. Likewise, a content update or a user interface update will need to include a programming update whether or not it is needed. The work associated with maintaining an application with no database at its core is tedious, time-consuming, and wholly unsustainable.

The absence of a database has more dire implications than just a boatload of work for developers. The most glaring weakness from a usability standpoint is that msu.seum is unsearchable. This means that users can only find information in the app by physically looking for it and following our predetermined paths of interaction. When a primary characteristic of the web today is its incredible queryability, it is a HUGE oversight for this application to not include a search function.

Katy rightly pointed out that the people will not come if the content is not interesting; I would like to add on that the people will not stay if the content is not fresh. Fresh content has more to do with the configurations of data, than the actual newness of information. That is, it doesn’t necessarily mean brand new data; it can mean new configurations of data… refreshed, remixed, mashed-up data. Databases granulize information and render it sortable, mixable, and mashable. Were msu.seum to include a database, it would be possible to make new things out of existing data and provide users with fresh content even when there are no new archaeological and historical discoveries to add to the application. The possibilities are truly endless.

It is not my intent to undermine or diminish our accomplishment in building two functioning native mobile applications in ten days. Rather, I am interested in increasing the value of msu.seum. I would love to see it reach a wide audience of Spartan students, alumni, faculty, and surrounding community members for a long time to come, but in order for that to happen the highest priority in the next phase of development needs to be to create a sustainable data ecology. Whether the next phase of msu.seum development involves implementing a full-featured content management system or harnessing the power of a raw database and programming the app with PHP, the end result will be an application that is easier to update, highly searchable, more sustainable, and ultimately more user- and developer-friendly.