Building a (good) website should be hard, because building a good website is hard.
With all of the technology, user-friendly platforms, and GUI tools available today, we often forget this. Building a good website takes an awful lot of work. It’s time consuming, and at the end of the day regardless of what CMS we might choose or which WYSIWYG editor we’ve plugged in, a good website is built upon strong information architecture and communication strategies.
Ideally the long term management of a good website can be easy – in a technical sense, anyway – but this can only be the case if the real work was done up front during the strategy, design, and development phases. Even we developers occasionally slip into the falsely comfortable notion that the flexibility of a system like WordPress or Drupal can be a substitute for the necessary pen-to-paper planning that must take place before development begins. ‘We can always just add a new field if needed,’ I have found myself thinking. But that attitude is dangerous because it produces an environment in which site maintenance and site development coexist as regular ongoing, activity.
A website for which development is regularly needed to handle content management is not a good site. The graphical design could be beautiful. The code might be written to efficient perfection. All of the data could be wonderfully accessible and the functionality gracefully degradable, but there is a large hole which time-consuming development is attempting to fill. That hole is the disconnect between the goals and the informational design of the site, and no amount of after-the-fact code shoveling will fill it in.
Avoiding the Hole
A project that I feel is particularly successful in this regard is the NU Global Opportunites website which details Northwestern’s international activities and partnerships. Built upon Drupal, this project incorporated a range of interesting custom functionality such as the mapping of search results and the dynamic production of charts, but that’s not why I see it as successful. The design is clean and straight forward, allowing visitors to easily engage in the exploration of a fairly layered stack of data, but this is not the reason for what I see as success either.
NU Global Opportunities is a successful project to me because we worked with the Buffett Center for International and Comparative Studies to produce a site that can be managed successfully by their content specialist. Meghan Beltmann and Krzysztof Kozubski of the Buffett Center spent months researching their content and their target audiences’ needs before sitting down with NUAMPS. When we finally did step into development, everyone had a very clear idea of the materials we would be working with and the goals for the site, and because of this we were able to be very targeted in our development approach – building out front-end functionality and back-end tools which address specific, known needs of the site. If we had to implement controlled vocabularies for the field ‘program timeframe’ after one or two rounds of development, we probably would have been forced to compromise on other (more interesting) areas of development. But we all knew up front exactly how program timeframes should be handled and what we intended to do with that data.
Because the initial work led to a more concrete concept of the site, we quickly worked through core functionality and then moved on to the type of development that pushes a CMS from ‘functional’ to ‘usable’.
Controlled Vocabulary Selection
We built custom content management widgets after observing Meghan’s workflow. We implemented additional layers of content such as charts and a faculty/administrators directory once we began seeing new patterns and relationships.
Dynamic Graphs
These enhancements were the result of knowing the content, audiences, and goals. The hard work was done early, so we were able to avoid the hole, and because of that we never had to rethink (or more importantly rework) the technology or design strategies. NU Global Health was a hard site to build, but that is paying off now in that a small office is able to efficiently maintain a very complex system.
But Sometimes There Will Be a Hole
Great. Our partner on that project had it all together. But can that always be the case? No, of course not. Projects often begin vaguely but with an immediate need for some form of web presence. In such cases, the development and design process will be both for production and research purposes – building something immediate and investigating the full range of project needs through iteration.
In this scenario, it’s important for all involved to be aware of the cost of the approach. The hard work is shifted from the initial planning phase to… well… the rest of the life of the project. This is sometimes unavoidable or even preferred.
When we began our work with the Oncofertility Consortium, we did not have any real guidelines for the project. This was primarily due to the fact that the consortium was just starting up, and no one could predict what the needs would be, what would be produced, or how the members would prefer to interact. So the building of the (many) sites was an exercise in discovery and iteration. This process worked well, because our discovery path paralleled that of the consortium, so as the consortium became more focused and at points of organizational change, the project’s web presence responded accordingly. We have certainly punched out more code for the Oncofertility Consortium than many other projects, but that development all had purpose ultimately.
Changing Face of the Oncofertility Consortium
You can see in the changing Oncofertility Consortium website front page above that over time the site dropped the emphasis on ‘What is…’ and began to focus more on offering the range of resources and information the consortium was building out. The general user scenarios shifted from directed experiences to browse.
Both of these examples leveraged a variety of technologies intended to make the building and management of websites easier, but we have to understand that only certain aspects of the very large task of putting information on the web is made more efficient by such tools. In the end, building a good website is hard, and it should be.