October 2007 Archives

After having recently attended the 2007 Cascade Server Users Conference in Atlanta, Georgia, I'm a bit up in arms about whether or not I'll go next year. The reason being, I didn't really feel like I learned anything new. That's not to say that going was completely unnecessary. I made contacts with other users who were doing great things that I'm sure to attempt implementing and I also gave quite a few people advice I would have died for when we began our Content Management sojourn almost two years ago. Those things include:

• Web standards!!!!! (yes, with 5 exclamation points) - Get with it. Tables-based sites are the way of the distant past. If you're not coding in XHTML and CSS you are a part of that distant past. I was floored to see that people are still designing with tables at the user conference. The headaches you have learning and implementing with CSS now will save you CMS headaches for the rest of eternity later.
• Strategic planning - A few hours of information architecture, site structuring, usability testing, etc. will save you tons of hours later in retrofit and shoe horning. When designing a site, you should always take the time to decide who you're making the site for and how best to organize your site in terms of directory structure, not just navigational structure. They go hand-in-hand if you hadn't noticed. If you dive headfirst into an organically designed folder hierarchy, your breadcrumbs won't work, your navigation won't work, your indexing won't work...basically you'll be glad you planned.
• Usability with your CMS in mind - Not all Content Management Systems are created equal...and none of them are perfect. Not a single one will answer all your problems and sprinkle magical fairy dust over your life as a Web Developer. YOU STILL HAVE A JOB TO DO. So when you're putting your site into a CMS, take your system's strengths and weaknesses and run with or destroy them, respectively. That said, sometimes you have to simplify things to a point of mind-numbing simplicity to make it work the best. Our CMS gives us the ability to create all sorts of fancy dropdown menus and selectors on page edit screens, but in the long run, we've found that a simple text field works just as fine, if not better, when we stick an end user in front of it at a keyboard. Which leads me to...
• Just because you can doesn't mean you should - This is a tough one to accept. Case in point: Once we got our shiny new CMS solution up and running and sites were beginning to go in pretty easily we got entirely too focused on putting every site in the CMS. Some of the sites really didn't need to be in there and would function just as well in a database or even as simple HTML pages. It's easy to get excited and think that a CMS will be the solution to all of web life's problems, but you must take care to use the system as it is meant to be used. Again, shoehorns are for feet not web sites.

In the past few years, through trial and error, I've determined there are some rules that are critical for our department. It's been challenging to lead a department that is growing and in a field that is constantly changing. There have been many mistakes and a lot of frustration, but, as a result, there were certain fundamental things that rose to the surface. While some of the details change, the basic list seems to work for us. They've certainly helped us to become a much more professional and productive Web team.

1. Do not build what you cannot sustain.
Anyone who knows me has heard me utter this phrase time and time again. It's important that you don't incorporate things in your site that you don't have the ability to support. This is especially important when using free scripts and such you may find on the Web. Changes occur, things break and you've created something you don't have the ability to diagnose or fix. If you don't know how to build it, how it works and, most importantly, how to fix it properly, DON'T DO IT.

2. Technology should be used to solve problems.
Too often people get excited about the newest technology that's creating a buzz among practitioners. The next thing you know, people have purchased software because everyone else seemed to be doing it and then have to make up projects to justify the purchase. It's my philosophy that this is completely backward. You should first identify your problem and then determine whether software is a solution. When you're too quick to jump on the latest technology bandwagon, you sometimes find that you've actually invested more time and money in a product that it's worth to your institution.

3. Planning is the most important part of the process.
When a project goes badly, the first thing I do is look at what type of planning was done in advance. The lack of a solid plan with goals, priorities and stated expectations is usually the cause of frustration and disappointment for both the developer and the client. While certainly not the most exciting part of the process, any project worth doing deserves ample time for research, planning and preparation.

4. Engage in continuous evaluation.
It's important to make good, solid decisions. It's just as important to look back later and make sure those same decisions are as good today as they were yesterday. Times change, people change, technologies change. There's no crime in deciding that something you did during an earlier time needs to be adjusted to meet today's demands. It's just good business practice. By evaluating what you do, you often find you can discontinue doing something that was a priority a year ago and make room for something that has become a priority today. After all, your plate's only so big, right?

5. Set priorities and make sure your work supports those priorities.
The setting of priorities is an important part of the planning process. However, the priorities affect many other things in your work day and can, in fact, make it easier for you to make decisions. A retreat with the people you work closely with helps determine what those priorities need to be. In many cases, they are actually derived for the priorities of your institution. When planning your tasks or addressing requests for your services, it helps to ask yourself how the work you've been asked to do supports one of those priorities. I try to set 3 top priorities each year and develop a project list based on our support of those items. It's been a great way for me to resist the temptation to develop "project creep."

6. Take breaks.
We are a society of sedentary people. For those of us who work in front of a computer monitor all day, it's very important for both our physical and mental well being to get away from the computer and take a break at least a couple of times each day. I've found that we're all happier, healthier and more productive by taking a little bit of time to invest in ourselves. It's also a great opportunity for the team to bond with each other.

7. Make time for learning new things in your work week.
One of the questions asked of people who want to work in Web Communications is "Do you like to learn?" In our field, things change daily. It's an exciting field to work in if you like learning new things and mastering new challenges. Not so great if this isn't something you're willing to do. Make a little time in each work week to learn something new. It can be as simple as spending time reading a blog you find has value or planning something into a project that allows you to learn a new skill. (Just make sure it solves a problem first. See item # 2.) This keeps you on top of your game.

8. Learn to say no when necessary.
This is one of the hardest to accomplish in our top 10 list. People who work on the Web are largely focused on customer service. That's why we engage in usability testing and user-centered design, right? However, this is a good time to put those priorities into action. You don't help anyone by agreeing to do everything and accomplishing nothing. Plus, you just make yourself feel overwhelmed and unhappy. It's okay to say no in the right way. Organize your work and demonstrate that you are completing priority projects. If pressed, ask if the priorities have changed since they were originally set and ask which one may be moved off the list to accommodate the new request. It makes it easier if you ask the person requesting the service to become a part of the process of deciding what stays and what goes.

9. Know your limits and respect them.
If you do, others will, too. If you are not a programmer, don't pretend to be one. Taking on tasks you're not trained to perform will ultimately do nothing but make you look bad. And stupid. Web developers, from day one, have been expected to be jacks of all trades. This also guarantees you'll be master of none. If you want to add to your skill set, ask for additional training so that you can do a better job and support those areas of priority that have been defined for you. Include others in the development of your site. Maybe you're great at coding and design, not so great at writing content. It's hard to pretend to be a good writer if you're not. Just remember, it takes a village to build a Web site.

10. Spend time with your peers and learn from each other.
This is important and is the most inexpensive path to continuing professional development on campus. This is a great reason to use when asking for time away from the office to attend Web Developer's meetings!