For an archival project, you will need a prototype or wireframe both for the internal structure of your content and for any interface or output where your content will be used. Since archival projects are about creating an organized, sustainable structure for digital content, the key issues to consider with your wireframe is how content will be organized and how information will be accessed given your audience’s needs. Although you might end up using one program or platform for all of this, you need to consider each component individually: the way the data is stored and structured in its repository, file system, or back-end database; and the construction of the user interface that presents that information in a useful way.
When you create your wireframes for this project, you can follow the general instructions for creating a wireframe or storyboard, but you will probably create multiple wireframes to address both the final user interface and the data structure. While you will probably build your archive beginning with the structured repository or file system, it is useful to draw a wireframe from the end user’s perspective, then work backward to create wireframes for the repository itself and prototypes of your processes.
User interface wireframe
The “user interface” may be a website, or it may be a particular viewing structure or process you use to sort or filter your files. It might also be the output(s) you need for a different program or project, like .csv files for relationship mapping or spatial projects or a file structure to import to an exhibit site like Omeka.
Start by identifying your audience(s) (even if it’s just you or your research collaborators). What things are most important to this audience? How much background do they have with the tool and with the content?
This audience profile will help you consider what the user needs to do with your content. The kinds of questions you would ask at this point might include:
How will the user search, filter, or sort content? Will they use open search fields or select from lists? Will there be any visualizations or other non-text tools for finding content?
Does the user user need to be able to export or alter the content in any way? If so, how do they do this and how will they get it?
Do you need any instructional information, guidelines, or background information? Will you be making database-driven exhibits or other story-like presentations of your content?
Once you have this structure in mind, start drawing a sketch of the interface. Check out the examples in the guidelines for creating wireframes to find out more about examples or tools you can use to guide you.
Data structure wireframe
Your data structure wireframe should address how material is stored in your repository. This might be something like a diagram of the columns you will use in a spreadsheet, or a list of tables and how they connect to each other.
You want this wireframe to show you four things:
What content is stored? Make sure this is specific: not “names,” but “last names of patrons”; not “images,” but “building facades at a resolution of 300 dpi.”
Where is that content stored? This might be in a column/field in a database or spreadsheet, but it also might be a folder structure for media files.
What is the content’s format? For files that are stored on their own, like media files, this might be the file type (.tif, .obj, etc.), but this is also where you introduce naming conventions or entry instructions, like “each image file is titled with year_shortname_number” or “all dates are entered as day - month - year.”
How is the content connected? If you have files in folders, is there a spreadsheet that links to them? If you’re building a database, what are the links or joining tables between them?
By doing this after you’ve made your interface wireframe, you can make sure that you take that final interface into account when you decide how to structure your data. You don’t want dates and places stored in a big text field if people might need to search for a particular year, and if you enter in names with the first name and last name in the same field, you’ll have a hard time sorting things alphabetically.
While the wireframes help you think about how to break up your content and organize it for users, a prototype lets you test actual processes for getting your content into and out of these formats using your proposed tools or systems. Prototypes often occur in conjunction with developing your workflow, though prototypes for end user tools like websites can come a lot later in the process.
A prototype for an archival project could include any sample version of a process or stage of your project that allows you to experiment with the project’s functionality. This is especially useful if you plan to do complex calculations, allow a lot of user interactivity, or use the data directly in another project.
Examples might include things like testing whether the format and fields you use for your spreadsheet load properly into a GIS mapping program, mocking up search or filtering functionality in a user web page, or running a sample of scanned text through an OCR program to make sure you end up with a computer-readable final format. It also might be as simple as trying to enter some content into a spreadsheet and seeing where you have questions about the format or limitations of data. What do you do with imprecise dates? Do you store locations as longitude/latitude pairs or as city names? What do you do with “anonymous” content or missing fields?
The goal of the prototype is to help you identify the problems with your wireframes and workflows.
Continue reading: Timelines & Workflows for an Archival Project