One skill that I didn’t realize I would develop during my residency was an understanding of the process of developing software with a vendor. This has actually ended up being the bulk of the final phase of my project to develop conservation documentation best practices for the Museum of Modern Art’s digital repository for time-based media. The first two phases of research and design gave me the opportunity to create a metadata implementation for describing the digitization or migration process history of time-based media artworks in MoMA’s collection. The current and final phase of software development is aimed at integrating this metadata into the repository by adapting existing functionality and designing new functionality.
I understood that this type of work would likely be happening in the final phase of my project, but, before this, I really had no idea how software was developed in a practical sense. I had no understanding of the extensive idea sharing and discussion that goes on between vendor and client. My time at MoMA has given me a good understanding of how this process works, so in this post I share my perspective of developing software with a vendor.
The first step an institution would likely take upon determining a need for software development is deciding on a vendor or putting out a Request for Proposal (RfP) to solicit vendors. For this project we were in the position of having just recently finished developing a custom-made digital repository through a vendor with whom we maintained a strong working relationship. Since they had developed our repository system, it was natural to turn to them to further develop that repository to create and store process history metadata.
The next step was to discuss the potential uses of this metadata with project stakeholders – in this case, that meant the two media conservators at MoMA who will be the primary users of the metadata. Even though I had designed a local metadata implementation of a standard that had in turn been designed by a standards team, I understood that what the stakeholders wanted was the most important aspect of this project.
Once I had an understanding of what the stakeholders wanted, the next step was to articulate those ideas clearly to our vendor. This involved creating step-by-step use cases of what exactly we wanted the repository to be able to do with the metadata. This was a pretty grueling process for me, as it required us to think very deliberately about the types of user interactions that we take for granted. For example, a use case might start like:
- User navigates to artwork record.
- User selects artwork component node.
- User clicks button.
- System generates modal.
- User clicks button.
- System generates modal.
In an actual use case document, these steps would be much more specific. But this at least gives you an idea of how clearly a use case must be broken down. For a millennial who barely remembers using dial-up, it can be very frustrating. You want to say, “Well, we don’t need to write that. It’s obvious!” But it’s really not, and the more time you spend clearly spelling things out in this phase, the less time you will spend editing and re-editing these use cases to clarify things to your vendor in the future. You will also avoid the possibility of your vendor creating something that doesn’t match your needs, because your needs will be so very (some would say painfully) clear to the vendor.
Another aspect of these use cases are the wireframe mockups we created to even more clearly demonstrate what we wanted the vendor to develop. I found the free resource Wireframe.cc to be a simple and neat tool that could easily accomplish the job of making a basic wireframe. In this phase, I kept in mind the existing design and structure of the digital repository, but I wasn’t particularly worried about the aesthetics. This part of the process is really about getting your ideas across to the vendor.
Once we had gathered all this documentation, we sent it to our vendor and gave them time to analyze it. This led to next phase of software development, which involved lots and lots of talking. I took part in many conference calls in which the use cases were dissected and reworked. Potential pitfalls, improved design ideas, and misunderstandings about goals were all discussed and cleared up to allow our vendor to give us the most accurate possible quote for the work.
Which, of course, leads to the least fun part of software development: paring down your project to fit within budget constraints. That’s where we are now in the software development process, and even though it’s sad to realize you can’t do everything you wanted all at once, it is very interesting to realize what is essential to your project and what is ultimately additional bonus material. It really clarifies your understanding of the basic goals of a project.
This entire process of software development has been incredibly enlightening for me. Before I started this phase of my project, I really had no idea how software development occurs from the client’s perspective. I still don’t know all of the technical stuff that will allow our vendor to make this happen, but I feel comfortable now creating documentation and having the conversations that will inform our vendor as to how to develop our software. If you’ve never had any experience with this process, hopefully this post gave you a bit of an idea of the types of things to expect.
