Text assets, which make up the vast majority of our content, are a little trickier to manage than images. Text is everything from one letter to every letter we’ve ever written. Because the content management system defined assets as objects (or files), we needed to figure out how much text would go into each file.
First we identified all the products the publishing system would create. That’s one level of division for the text assets. But how practical is it to have to check out an entire book if you just want to edit a piece of it? We needed to identify smaller parts. The products could be divided into things like units and chapters. Smaller yet were things like quizzes and worksheets. And then there were the component parts that made up all those quizzes and worksheets. Where to draw the line?
We decided to create a new kind of content level, which we called Activities. The capital A was meant to differentiate these content assets from certain worksheets that were called “activities.” From an editorial perspective, an “activity” was a particular kind of thing with a particular structure and purpose. An “Activity” broadened that definition to be the “smallest teachable part.” In other words, what’s the smallest indivisible content chunk that a teacher would likely assign to a student, or that we would provide for the teacher as a professional development or classroom management tool.
An Activity could be one page, or part of a page, or several pages long. The concept of “page” was not important here. The information conveyed by the Activity had to be a single unit of content that could stand on its own. This is a tricky concept to explain to people who are used to thinking of everything as pages in a book.
There was one other content chunk that we normally dealt with on an individual basis: test items. Test items can be reused in a variety of products. If you have 1000 test items on a particular concept, you can mix and match them to create different products for different audiences. We knew this. We also knew that our content management system had to manage everything as a separate object, with separate metadata, and separate listings within the user interface. In other words, if we managed items individually, we’d have screen after screen of test items that you’d have to scroll through, or search, to find the one you’re looking for. This sounded obnoxious and difficult to deal with, from both a programming and user perspective.
Stupid thing 2: Sacrificing business requirements for development expediency.
It would have been very difficult to manage test items as separate assets. But test items are an extremely important part of our products. Maybe they’re the most important things that our publishing system would store, manage, and output. Our developer (who didn’t want to deal with it) advised against it from a time and money standpoint. Our team was more than happy to agree, because it would have been a pain for us to come up with the metadata and management strategy as well as the user experience. By that point the project was already getting behind schedule, so dropping this big challenging thing was very easy to do.
What we should have done: Suck it up.
Yes, even with the ensuing complications, we should have built the system to manage items as separate objects. Maybe it would have made the content management experience more difficult and slower than it already was. But it would also have made the system much more flexible and useful in its original mission of creating products from stored assets. The trade-off may very well have been worth it.
Now I’m not saying that you have to put in everything all at once. We had to sacrifice all kinds of things to schedule and budget. Most of them were small features that would have helped a small group of users, or were for a small group of products. And we had workarounds for all of them. Or we added them later. Leaving out a huge, core, central piece, one of the main reasons to do the whole project in the first place, was not a smart move.
Filed under: XML |