Archives & Museum Informatics: Museums and the Web 2005: Papers: Spadafora, Web Site Management for Solo Techies and Small Web Teams

Tackling all aspects of an organization's Web site as an individual or as part of a small team can appear to be a project on par with slaying the Hydra. Creating a framework for Web site development and maintenance that encompasses the need for big-picture strategic thinking as well as checklists to help track development tasks is always necessary to deliver a quality experience for Web site visitors; given limited resources, it is vital. This paper explores key aspects of creating such a framework: educating non-technical staff, setting priorities and delivering by deadline, determining when to hire contractors for specific skills, and tips and tools for managing workflow.

Keywords: Web site management, framework, priorities, deadlines, project management

Doing it All, Then Going Home for Dinner

This can seem like an impossible feat, when you are charged with managing an organization's Web presence. You might need to investigate a 500 error, update a schedule of events, and get signoff on design comps – before lunch. Given the volume of requests and the items you identify that need work, it becomes clear that simply keeping a checklist of pending tasks isn't enough.

Building a framework that will allow you to quickly evaluate the importance and impact of projects and then take action on items fitting certain criteria instead of spinning your wheels on an unending list will keep you from feeling overwhelmed.

In this paper, I'll introduce the key components in the framework I have developed through managing a good-sized and fairly complex site. What does that mean? In the past year, our Web site (http://www.jwa.org) comprised 500MB plus of information, served as static files as well as database-query generated pages as thousands of URLs. On-line ordering of materials was made possible for the first time, existing exhibits were expanded, and new content features were added. A major new Web exhibition is in the planning stages. Time-sensitive content, in the form of a This Week in History feature, is published, you guessed it, weekly. The Web team is me, with the help of a part-time contractor acting as Web systems administrator.

Educating Non-technical Staff

"Can our Web site do that?" is undoubtedly a question you've been asked. A more critical version of the question is "Why doesn't our Web site do that?"

"Time, money, and necessity dictate it doesn't," is the shortest answer. It is most likely the accurate answer too, but it probably won't satisfy the person who asked it, so it won't save you any time. Giving a better answer to non-technical colleagues will save you time. Giving better answers to non-technical colleagues will also make is easier for you to get them on board with improvements you'd like to make to the Web site or the new project you’d like to launch, because they will understand why what you want is important.

There are two key parts in explaining what you do to people who aren't technically inclined or perhaps even all that interested:

The other folks at work – the ones not responsible for the Web site – don't want to hear that you set up a 301 redirect: they want to hear that the link they included in a LISTSERV post now goes to the page they expected it to, and not some page saying it can't be found. They don't want to hear that the homepage now validates as XHTML 1.0 Transitional: they just like that it seems to load faster when they are at home with a dialup connection or that they don't have to guess what is a link and what isn't.

At the Web developer, you 'just know' those were the right things to do in those situations, because you knew that they would work. In the first instance, you don't need anyone to understand why a redirect is a good idea; you could just do it. But making changes to an organization's homepage, even if the result is relatively minor changes in visual appearance, normally requires getting approval.

I needed to add an element to our homepage. Unfortunately, the page was so constructed that adding this new element would cause the existing layout to break. The page was designed to have all content display, without scrolling, for monitors set at 800 × 600 resolution; one line of text would throw the whole thing off. The code was also bloated, used nested tables and spacer.gifs to absolutely position elements – in other words, it was only barely human-readable. Fixing it to add the new element would take a long time, and the next time a change was required, I'd have to spend the time all over again. Instead, I wanted to clean up the code and allow for some flexibility in the layout; I wanted to fix it so the next time we needed to make a change, it wouldn't be a time-consuming process.

Yet I knew 'the code is a mess' wasn't a good answer to give my manager when she wanted to know why it would take so long to add this new element. 'I'll save time in the future every time I need to update the homepage' made more sense. Being able to visually demonstrate the problem, so my colleagues could see what I intuitively knew was wrong with the homepage, was even better.

Fig. 1: Code printouts of homepage before and after revision, with page contents highlighted. Colleagues don't need to know anything about HTML to understand the revised version on the left is a substantial improvement.

Folks who are not technology-oriented may ask for things that seem unnecessary, if not downright impossible. Or maybe they are afraid that something they want will be too much work to change on the site. Getting at the why behind their requests often leads to implementing a solution everyone is happy with, even though it isn't what they first wanted.

This past year has marked the 350th anniversary of the first Jewish community settlement in North America. As part of JWA's initiative to ensure that women's stories find a prominent role in the narratives of American Jewish history created during anniversary celebrations, we developed a curriculum, reading guides, and other resources. These materials are available for purchase, but there was no sales functionality on our Web site. Customers needed to print out a form and mail or fax it in – not a very user-friendly option for a Web site. Plus, running the credit card transactions was taking up a significant amount of admin time. Wasn't there some e-commerce thing we could do?

I knew we didn't have the capacity to build and maintain a full-service system. We lacked the programming resources, yet an on-line credit card order processing system would save us a lot of time, and the increased ease in purchasing would probably mean we'd sell more materials. After some investigation, I found that PayPal offers a shopping cart system that is dead-simple to set up and maintain – no scripts to write, no merchant account necessary, no data security worries. While we don't offer email tracking of shipments and some other advanced features, I was able to integrate credit card ordering with the existing site, in short order. The PayPal system is easy to use, and is easy to modify on our end – no more complicated than making edits on a page. Now, half the orders for our materials come via the Web site.

Setting Priorities, Delivering by Deadline

Who decides what is important for your organization's Web site? The executive director? The marketing department? Is it part of anyone's job description? No matter what the org chart indicates, you spend more time on your organization's Web site than anyone else does, so you need to speak up about what it needs.

Given infinite time and money (a position small museums are not going to find themselves in), everything gets done. Given the competing demands of the real world, how do you weigh the relative importance of what happens next on the Web site?

Decision-Making Rules Of Thumb

Usability guru Jared Spool has proposed that in order to build usability into the business culture, proponents need to pitch usability as something that executives will care about (Spool, 2004). In Spool's view, there are five things executives need: increased revenues, reduced costs, increased marketshare, increased business from existing customers, and increased shareholder value. If executives can see how usability practices will have a positive impact on their needs, those practices will be advanced.

These executive concerns from the business world have analogs in the nonprofit sphere. Just as usability practices will flourish if they are seen as adding value, Web projects will have a greater likelihood of success if they are closely aligned to organizational goals. At any given time, you probably have more Web projects under consideration than there are hours in the day to work on them. Whenever possible, these needs can be used as guidelines for deciding if a particular Web project should be undertaken or not.

My goal is to be able to explain how a project fits with these goals, and if it doesn't, I consider that evidence I probably shouldn't do it:

JWA's mission is to uncover, chronicle, and transmit the rich legacy of Jewish women and their contributions to our families and communities, to our people and our world. I consider what effect new content or improved functionality will have on the Web site's contribution to the mission. Then, I think about the time and costs associated with implementing (or not implementing) a feature. It isn't a magic formula, but it does help to identify the biggest bang for the buck, and that is what I advocate to change or add, or else set aside for that mythical time when things slow down.

This year we decided to take content not originally developed with a Web component in mind and create a Web exhibit. The project, Weaving Women's Words: Seattle Stories (http://www.jwa.org/exhibits/seattle) was greenlighted because it was in line with larger organizational goals. In making these women's stories available on-line, we would be fulfilling the transmit the rich legacy part of our mission. We would also be bringing more new visitors to the Web site by providing substantial new content, demonstrating our expertise in oral history, and increasing demand for our forthcoming guide to conducting oral histories. In other words, we'd be getting the most bang for our buck.

Do you know what you want people to do when they visit your Web site? Are there things – tangible items such as product orders or intangible ones like attitude changes – you want them to leave with? Does your content support that? Answering these questions will help you to identify whether you are on the right track with potential projects. Rules of thumb for implementation should be aimed at the sweet spot where Web site visitor goals overlap with the organization's mission.

Learn To Stop Worrying And Love The Deadline

An important component in setting priorities for Web development is having an accurate assessment of how long it will take to go from idea stage to live on the server stage. Some projects are worth doing because they are quick wins – in other words, little or no opportunity cost is involved in taking on the project, and it will have a positive impact. Other projects will be time-intensive, and working out a timeline gives you the opportunity to think through all stages of the project before you start.

Possibly the most important reason to set deadlines is that with deadlines, things get done. Deadlines bring accountability to a project: I will launch X by date Y; in order to launch X on date Y, I need content delivered to me on date A, feedback on the design by date B, and sign off by date C. True, things rarely run smoothly according to schedule, but having a schedule in place creates leverage for stakeholders to get what they want.

What you want is probably content when you need it. Content delivered on date A means you have the time needed to design, code, and deploy by the launch date you specified. Content not delivered by date A shifts the launch date, something everyone will understand because you outlined that in your project plan. This step is important, as non-technical staff otherwise won't know which item will take you a few hours and which will take you a few days to turn around. Setting deadlines gives you the opportunity to make that clear.

I find it helpful to create a checklist of everything that needs to happen, and who is responsible for each piece, when I'm laying out a project. It (hopefully) ensures I'm not forgetting anything, and lets me see how much time I really need. Not all projects require these stages, but my list includes:

For longer projects, schedules should reflect vacation days and holidays. My name is the only one listed next to most action items, but having a project plan that everyone is aware of advances the project's chances of success exponentially, compared to the leaving things at the 'I thought we agreed to do X on the site' conversation stage.

Thinking through the importance of various Web projects and creating plans to implement them ensures that Web site visitors see mission-serving, as well as mission-critical, changes to the Web site.

Outsourcing/Contracting for Specific Skills

The likelihood is that you literally can't do it all on your own: Web server maintenance, graphic design, information architecture, editing for the Web, page coding, backend programming, QA, strategic planning, user testing, documentation writing. There are too many tasks for one person to complete. If you are the only staff member responsible for the Web site, this means you'll need to make decisions about what you can do, what you can learn to do, and what it makes sense for you to manage other people doing. What parts make sense to send out of house?

Hosting

This can be as straightforward as choosing a Web hosting service that takes on responsibility for server maintenance, with you serving as your organization's technical contact with the hosting service. If a Web site is relatively small or static, this may be the only piece you outsource. What matters in not where they are located, but what service levels they offer for the price.

Systems Administration

For larger, more complex sites, additional systems administration is necessary. Mission-critical content needs to be backed up, and the capacity to rollback changes is important: enter a version control system, and development as well as live servers. Again, it doesn't matter where this person is; it matters if he or she can handle the server maintenance issues you can't.

Coding/Programming

How technically proficient are you? Are you comfortable with advanced XHTML and CSS techniques? Proficient enough with javascript or PHP to get by? CGI scripts not something you want to write? Know your limits, and learn enough about the skills you don't have so that you know when you might need them, and you can talk intelligently with someone who does have them.

Design

There is having a 'good eye', and then there is solving complex problems graphically for the screen. Understand the scope of your project, and enlist specialists when the problem is too big or too complex for your abilities. Don't be afraid to hand things over to a design firm to get the look and feel right – you can write the specs for the code they return to you, as you will be the one who needs to maintain it.

Content production

You may suggest ideas, but chances are other people will be the ones to research and write the material that winds up on your Web site. Luckily, these people are likely to be sitting at the next desk. Content writing is their specialty, but content editing – think scannable text for the Web – may still be yours.

Alphabet soup

What about IA, RSS, SEO, UX? Web standards? E-everything? Sorting through all the abbreviations, acronyms, and hype to figure out what you really need to know about and keep up is a nontrivial task. (Strategies for staying current could take up another workshop, no doubt.) Go with your interests, and focus on what will be most likely to lead to improvements of your organization's Web site. One way to keep tabs on new developments is following subject-specific blogs, (Web nerd links, http://12frogs.com/weblinky.html); another is going to conferences and training sessions to learn from others.

Tips & Tools for Managing Workflow

Okay, so there is agreement on what is possible, what is going to get done, and when it will launch – how do you stay on track?

Email Folders

Whenever possible, I get it in writing. This isn't to be a jerk; it is how I keep track of what people have asked me to do. (If they can't email it to me, I'll email it to myself.) I have a requests folder set up in my email, and requests done folder. I know what I have to do, and what things I've already done.

Visio For Real People

I don't use Visio to draw endlessly confusing flow charts of hypothetical visitor paths to the Web site; if only other nerds can understand my Visio diagram, I've done something wrong. Instead, I use Visio to explain how something on the Web site is now, and how I'm proposing to change it. I use Visio to diagram a workflow that works.

Fig 2: Visual representations of the work plan can be invaluable. Here, the white boxes show existing structure, circles indicate problems, and the gray boxes map out how proposed new content will be integrated.

Firefox toolbar

I am not trying to touch off a browser holy war here, as Internet Explorer may have a similar tool. It so happens the one I am familar with, I use with Firefox. This Web developer extension (http://www.chrispederick.com/work/firefox/webdeveloper/) allows you to edit CSS files on live pages, only one of its many time-saving features.

Check-in meetings

Sometimes, nothing beats face-to-face communication with all stakeholders on a project. Everyone gets a chance to ask questions, raise issues, and voice their concerns. Also, no one wants to admit in person they blew that deadline – meetings add another level of accountability.

How to Be a Successful Cat Herder

To say something is 'like herding cats' is to suggest that it is a near-impossible task, particularly one where pieces are resistant to coming together to function as a whole. Competing demands on your time and resources, different ideas for improvements or additions to the Web site – they are all cats.

Project management is what gets the cats together: it is what makes for the highest quality Web site you can deliver with the low-quantity resources at your disposal. You know what needs doing – both requested work, and behind-the-scenes problems other folks can't see, because they are in the code, or turn up when you pore over webstats – and you can put together a framework to keep the cats in line and Web development on track.

Clear communication with your co-workers will allow you to see eye to eye about projects; what is important is understanding the why behind requests – yours and theirs – not the how. Placing Web site enhancements in the context of your organization's mission helps structure competing priorities. Setting deadlines ensures those priorities are realized, by moving them from the realm of could be to will be by this date. Efficient use of the tools at hand and thoughtful outsourcing for skills you don't have the need or budget to develop in-house will allow you to provide a better experience to Web site visitors.

Web visitors, by the way, don't care how many people you have on your Web team. They care about meeting the need that brought them to your Web site in the first place. They should never know it is just you, or just the three of you, or whatever the case may be. What you want them to know is that your site is worth visiting again, because you provided them with a good Web experience.

Yes, but can everything really get done by dinner time?

With the right framework, solid effort, and a little luck, maybe not everything – but everything you planned on getting done.

References

Spool, J. (2004). Web Site Usability 2004: The Big Picture. In Making it Better: User Interface 9 Conference Proceedings. Middleton: User Interface Engineering.

Cite as:

Spadafora, J., Web site Management for Solo Techies and Small Web Teams, in J. Trant and D. Bearman (eds.). Museums and the Web 2005: Proceedings, Toronto: Archives & Museum Informatics, published March 31, 2005 at http://www.archimuse.com/mw2005/papers/spadafora/spadafora.html

Web Site Management for Solo Techies and Small Web Teams

Jen Spadafora, Jewish Women's Archive, USA

Abstract