Rendering Repository
A study in Information Architecture using Box.com
Information architecture (IA) has always had a special place in my heart. Though my understanding of it, heretofore, has been limited to its manifestation as a site map, I find myself pondering its various components — ontology, taxonomy, and to a lesser extent, choreography — on a day-to-day basis, from the most mundane of work tasks (saving design files on the company Box directory after completion of a task) to personal projects (organizing my entire music collection alphabetically by artist, then by album title within each artist’s folder, and finally by song titles within each album folder, and ensuring every relevant field in iTunes’ song details tab is filled out consistently).
Before I even learned about the 3 components of IA, I was already grappling with ontology, taxonomy, and choreography in many of my professional and personal tasks.
Although I am not an information architect by training, I recall a work project wherein I studied and applied all 3 aspects of IA, and it wasn’t in the service of designing a website, web app, or a product.
At a previous job, I was a visual designer/marketing manager at a corporate furniture dealership. One of the ways we presented furniture options to clients was through renderings; project designers (aka furniture engineers) would create sketchups and photorealistic 3D renderings of different furniture options, on a case-by-case basis, depending on project size, budget, time, etc. The problem was that these images take time, effort, and machine power (for rendering), especially when finishes and textures were applied.
The project design department was often under stress to quickly produce these visual aids. And I, as the visual designer, often had to work down to wire, waiting for these images to insert into the proposal package.
After doing countless proposals, I noticed that we often reused 3D renderings and sketchups from previous pursuits. However, this shortcut was dependent on someone remembering which product was included in which package, and whether the product would be applicable for that specific prospective client.
A possible solution.
Seeing an opportunity here, I decided to look into creating a searchable project renderings/images database. The goal was to use a sort of tagging system to organize the files and then to search by tags to filter the search results. The ROI for this tool was to lessen the load on the design department by reusing existing sketchups/renderings, without the need for a photographic memory.
After looking into Flickr and setting up a test account with a few images, we decided that setting up yet another company account and training people on yet another platform were not worth it. So, we looked to Box.com. We had already used Box as our company cloud storage system, and Box itself had tagging capabilities.
We created tags that mirrored the descriptive terms we usually associate to each project image — manufacturer, product line, product type, color, size, etc.
I decided to take this new Box folder for a test run. Problems arose.
I could only filter by the tags I created, not by the tags anyone else created. Screen shots below indicate images tagged workstations. But when I filtered by the tag workstations, no results returned. This defeated the entire purpose of the rendering database, as we needed universally filterable tags.
After conducting a few more tests, I realized that Box tags were not filterable if the files were tagged in a personal folder and then moved to a company-wide folder. Although the tags transferred over during the file move, they were not filterable.
I reached out to Box tech support to confirm this realization. Box confirmed that tags were only filterable on a file owned by the user.
This was a deal breaker in our case. We needed the tags to be filterable for every image, not just user-owned images.
After numerous exchanges with Box tech support, I learned that tagging had been an unstable feature in Box and was being phased out. Box was slowly transitioning to metadata as a way to replace tags.
Metadata Template
I decided to give metadata a whirl. In Box, we assigned metadata for each image, and this metadata would be searchable and filterable.
To customize this functionality to our needs, we needed to create a metadata template, comprised of several attribute fields. This metadata template can then be applied to each file, with specific attributes selected per the file.
Setting up attributes
Working with a team comprised of project designers, account managers, and sales people, we came up with a list of attributes that addressed possible search terms.
The Box metadata template allowed us to select different formats for each attribute — text, number, drop down, etc. We can also add a description for each attribute that would act as a tool tip on hover over the attribute field.
A good sample size
I needed a decent number of images with which to apply the metadata template. With the help of the office manager and a graphic designer in the Marketing department, we went through past proposals and packages to extract renderings and sketchup images.
At the end of a month or so, we had about 300 images in the rendering repository folder, each with a filled out metadata template.
Going for a test drive
With a good sample size of images and metadata information, we were ready to test out the rendering repository.
Users can enter a term in the search field in Box, and narrow the results down to the Rendering Repository folder. Box algorithm searches through titles and metadata templates.
Users can further refine the search by searching by metadata template fields.
Other uses
The use of the metadata template, with its text field attribute functionality, allowed us to append extra info for each image.
For example, we could link a bill of materials file and a specifications file to the image file with URLs in the text fields. This would allow the user to access in-depth info such as the specific parts and pieces that comprised the product shown in the image.
This took the rendering repository beyond a simple searchable database, allowing for faster product specification later in the project process.
After a few more months of gathering images and appending metadata to each template, we rolled out the rendering repository to the rest of the company. I even created a field guide to ensure best practices.
Though I didn’t know it at the time, I was practicing and executing the basic tenets of IA. Ontology (a particular meaning or labeling) — came in the form of choosing the right metadata attributes that would correspond to search terms. Taxonomy (organization or arrangement of parts) — came in the form of the selecting the format for each attribute — text, number, dropdown, and if dropdown, the choices within the dropdown. Finally, choreography — how would people utilize this repository most effectively, understanding how to interact with the metadata template, and understanding what each attribute meant.
Though it wasn’t a perfect solution, we worked within the constraints of Box.com, budget, and time to craft a particular solution for our particular problem.
