As John announced yesterday, I have taken over Bite Size Standards. We relaunched yesterday with a new format for article submissions and a streamlined editing process that will hopefully allow us to keep this resource running smoothly.

Why I wanted to Bite Size Standards to continue

I firmly believe that web standards are the foundation of successful web design and development. There is a whole new generation of folks entering into this field that need to learn best practices, to say nothing of the scores of sites you can find on the web that do not use standards. There is still a market and a need for web standards education.

I am also seeing less and less written about standards, as the leaders in this field get too busy to write, or move on to exploring other topics. This is a natural evolution, and it may be time for the next generation of standardistas to step up and contribute. I feel that’s where I am in my career now— I know enough to give back to the community that gave so much to me.

The new format

It was import to me to put together a project to which anyone can contribute. So, as of now, anyone with a good idea can contribute an article to Bite Size Standards. If your article is deemed appropriate for BSS and passes the technical review for accuracy and quality, we will publish your article. Details can be found in the Contribute section of BSS.

I hope that this gives a platform for everyone to share their knowledge and ideas, and I hope to see some articles coming in from my readers here at Interllectual.
——-

Peter recently asked me if I prefer Textpattern (TXP) or ExpressionEngine (EE), and I thought this would make a good subject for a post to bring this blog back from oblivion.

There is no short answer to that question. I love both CMSs, and lately have been choosing between them based on the project at hand. I recently switched HSU’s site from TXP to EE because the latest versions of TXP wouldn’t work with the configuration of our server. If TXP had still been an option I would have stuck with it. But partway through the project, I realized that EE was really better for the job, due to some of the project’s parameters.

I haven’t abandoned TXP though— I just finished a project for HSU’s Vertebrate Museum that uses it.

So, here is a quick breakdown of what I see as the strengths of each.

Textpattern

TXP’s admin interface is much easier to grasp than EE’s, especially for clients that may be using a CMS for the first time. It is clean and logical and easy to get around.

The Textile integration is very nice, and again this is very useful for clients that don’t know HTML. Textile can be added to EE with a plugin and some configuration, but TXP has a nice Textile “cheat sheet” right next to textarea where you compose your articles that makes using it really easy for newbies to use.

The TXP community is amazing, updates are frequent and always bring great new features, and the forum, wiki, and plugin sites are really useful.

ExpressionEngine

When comparing EE to TXP, the first thing that comes to mind is that EE has more. More functionality built-in, more options, more flexibility, and more to configure and learn.

This can be a good thing or a bad thing. Some projects don’t need all the flexibility that EE offers. Some clients will be confused by all the admin options. However, for me as the person that runs a large university site, all this functionality built-in is a godsend.

EE allows you to fine tune your RSS/Atom feeds, gives you intimate control over tag, template, and query caching, lets you manage the database from the admin interface, and has very sophisticated member options. It also has extensive flexibility with custom fields and relationships among data. It has a built-in gallery, configurable moblog and XMLRPC modules, word censoring, capcha support, and find & replace for posts and templates. And that is just the stuff I have learned about. It is truly an amazing piece of code.

Of course, it is also not free. Some of the things mentioned above are available only in the paid version, although most of them are found in the free core version. I think the price is very low for the amount of flexibility EE offers, and the excellent responsiveness of the support staff.

But, sometimes what EE has to offer is just too much. Not too much money, just too much… stuff. TXP, while still being very sophisticated and flexible, is much more in line with the “less software” approach championed by 37signals that is taking off all over Web 2.0. Much of EE’s functionality is available in TXP through plugins and extensions, which you only have to install if you need them. In some cases, this is a better approach.

How to choose?

Before deciding on solutions, I make sure I understand the problem. What are the specs of the project? Who is the client? What is their skill level? How much traffic will this site see? What is the budget?

For smaller sites or sites where laypeople will be managing them once I am done with my part, I choose Textpattern. For sophisticated projects or projects where the clients are like me and want intimate control over every little detail, I choose ExpressionEngine.

I’d like to hear your thoughts on this as well— what tools do you use and why?

For the first article in my series about building the new HSU site with ExpressionEngine, I thought I’d write the compliment to my earlier article where I explained how I built HSU’s A-Z index with Textpattern.

Setting up the framework

The first thing I did was set up the framework: a weblog (EE’s name for a container for related posts) called “siteindex” with 26 categories named A-Z where I would publish the entries, and a template group also called “siteindex” with 26 templates named A through Z. Naming the template group and template pages in this way creates clean urls— the url of the page with the A entries will be humboldt.edu/siteindex/A.

Then I entered all the data for the index into the weblog, categorizing each entry under the alphabetical letter of the page that I wanted the entry to be displayed on.

Coding the templates

One of the great things about ExpressionEngine is that it allows for user-defined variables that can be used within EE tags. These become a really convenient way to manage a group of templates that are essentially the same, differing only in the category, weblog, etc that is called by the EE tags.

So, I start out each if the 26 template pages with:

{assign_variable:letter="A"}
{assign_variable:catid="54"}

The first line sets the letter of the index page, which I use in the </code> tag of the page and in the <code></p> <h1></code> tag:</p> <pre><title>{letter}: HSU A-Z Index

and

A-Z Index: {letter}

.

The second line sets the category id for the weblog category “A”, which happens to be 54 in this case. I use this within the EE tag that produces the table cells with the entries filed under A, with siteurl, dept-name, loc, phone and fax being fields of data entered in the siteindex weblog:

{exp:weblog:entries weblog="siteindex" category="{catid}" orderby="title" 
sort="asc" status="open" disable="member_data|pagination|trackbacks"}

{dept-name}
{loc}
{phone}
{fax}

{/exp:weblog:entries}

The template also includes all the the other code to layout and format the page, and is repeated 26 times. Luckily, EE provides include templates that allow me to write all this code only once and call it on each of the 26 template pages:

{embed="includes/siteindex"}

So, each of the 26 pages actually only contains the following:

{assign_variable:letter="A"}
{assign_variable:catid="54"}
{embed="includes/siteindex"}

with the letter and catid varying for each letter of the alphabet.

The real advantage of EE

The best part of the A-Z index in EE is that it is now the official repository for department names and urls on the main site. EE has an amazing feature called relationship fields, which allows you to refer to information posted in one weblog from within a second weblog. So whenever I need to list a linked department name, I can refer to this siteindex weblog rather than duplicating the information. This has already proved to be a huge time saver for me, as several departments have changed their name since we went live with the new site. I changed all the references to these departments in a few seconds by changing the name in the siteindex weblog.

I will be writing more about how I used relationship fields in the near future, so stay tuned.
——-

I have been thinking lately about how the whole Web 2.0 movement will affect University web sites. A lot of attention has been paid to Web 2.0 in terms of marketing to the “millennials” and public relations, for example see Karine’s excellent series about RSS at collegewebeditor.com. I am more interested in what Web 2.0 can do for me, however— I have a mountain of information I am responsible for, and constantly on the lookout for any tool that can help me manage it more efficiently.

The most intriguing new technology to me right now is microformats. And my interest seems timely, because today alone there were at least 3 articles about microformats in my feedreader.

I have to admit that I was skeptical about microformats when I first heard about them a year ago. I didn’t quite see their relevance to me, I think in part because they were really focusing on social software at the time. The emphasis was on XFN and VoteLinks, which were probably highly relevant to most of the blogging crowd in the audience at SXSW, but not to me. I am an antisocial blogger, without even a blogroll to use XFN on.

But after spending some time reading through microformats.org, I realize there are several microformats out there that have the potential to benefit an institution, if, and this is a big if, the tools get built to take advantage of them. I’m going to go over a few of them and how I see them working for us university web folks. If you have more ideas or brainstorms, by all means comment and share.

hCard

hCard is probably the most widely supported microformat at the moment in terms of tools available to consume them. hCards are analogous to vCards, holding contact information for individuals or institutions. The applicability of hCard to the university is obvious— the contact information in our footers, our phone and email databases, and the ever-present “Faculty & Staff” pages in academic department sites could all benefit from using this microformat. It would be great to be able to grab an hCard for my address book when I finally figure out who in HR can answer my question about benefits. The Firefox Tails plugin can recognize hCards on a site and if you’re on a PC, TailsExport will download them to vCards that you can use in your address book. It would be great if more browsers had plugins to do this; Jon Hicks proposes one for Safari here. There is even an hCard Creator that will build an hCard using information you enter, making it very easy to convert information to the correct format.

hCalendar

hCalendar is another microformat that Tails and TailsExport can comsume, and also another with obvious translations into the world of higher ed. It would be extremely helpful for me to be able to export our academic calendar, complete with all the one-day holidays I always forget about until it’s too late to plan a trip, into my iCal or gCal. Or how about dates of paydays from the fiscal calendar? There are also campus events, athletic events, fundraisers, etc. A prof could even put a calendar together for her course, leaving the students with no excuse for forgetting when assignments are due.

hResume

hResume is a draft that has some interesting potiential. One of the projects we’re always trying to get off the ground is a Faculty Expertise Directory; a place where public or the press can go to figure out who to consult about earthquakes or Native American culture, etc. If faculty published their vitae on their personal pages or their department’s web site, a parser could be written to search our site for hResumes and populate the faculty expertise directory based on information in the “skills” field. A directory that populates itself sounds like heaven to me. Which leads me to the next microformat.

Rel-directory

Rel-directory is a draft that “is specifically designed for building a directory in a distributed manner and for making links to any directory listing explicit.” We, like many universities, have an A-Z Index of web sites that is the preferred navigation method for people on campus. It is a nightmare for me to keep up to date. But if the authors of those web pages used rel-directory on links to the page of the A-Z index that they should be listed in, the magic parser could go through and find the sites for me, and pull the directory information from the handy hCard that they have published with all the contact information. There is not much advantage to publicly displaying a link to the directory, and this may be a stretch of what this microformat is designed for, but it is fun to think about.

Other Microformats

There are a few other microformats out there that would be extremely easy to implement and potentially have a payoff somewhere down the line. Adding rel=“home” to links back to the main homepage or homepages of sub-sites can be done in a snap, and these could be used someday to produce on-the-fly site maps. Adding rel=“payment” to links to online giving sites is easy and could potentially cash in (pun intended) on future technology that highlights ways to support site authors. Rel-license may be useful for disambiguating copyright issues for images and other materials used in class. XOXO which is used to mark up outlines, can find many homes in the halls of the university. There are also working groups on rel-citation and meeting-minutes, which our sites would eat up.

There was some talk on the UWEB-D and WASP Education Task Force listservs about coming up with a microformat for course content. I’m not sure where this discussion went— if you know, please leave a comment and fill me in. While I think a course content microformat may be too ambitious, I would really love to see a course catalog format. What other microformats would you like to see? Any ideas on other ways to use the existing ones? And, who wants to tackle writing a few parsers so these brainstorms can become reality?

Our latest effort at HSU went live a week or so ago: First Year Connections. This project was a challenge, in that it highlights 5 separate programs that are administered by 5 different groups on campus. Those of you that work at Universities probably are rolling your eyes in sympathy right now, thinking that this is the formula for a nightmare of a site. And it has been in the past, but this time we were actually able to pull off a really great campaign that includes both printed materials and a web site. I thought I’d document our process here, as much for myself as for you, my five readers, so that I can remember how to pull this off in the future.

First, I have to credit the clients for realizing that it would be helpful to the audience (students that have just been admitted to their first year of study) to give them information about all these programs in a single publication/site. They were able to see beyond their department walls and understand the big picture here. They were also able to set aside their previous efforts and let my department do what we’ve been trained to do.

I am part of the Graphic Services department, which means that I work with professional graphic designers. When I first got the job I thought that this might be a bone of contention— I’ve heard lots of horror stories about how print people don’t understand the web and yadda yadda. But it has been quite the opposite. I have learned about print design and they have learned about the medium of the web, and we have worked well together, each bringing our own skills to the table.

So the first thing we did was sit down with the clients as a department— web and print folks all together— and talk to the clients about the project. We talked about the goals of the client and the users, what kind of publications and web sites from our university these users have already interacted with, what questions they would have, and how we could make the process of sigining up to a bunch of separate programs as easy as possible. We went over the ways they have handled this information in the past and talked to them about what worked and what didn’t.

Then we started brainstorming about the form the campaign could take, both in print and on the web. How can we get the main message across in an interesting way? How can we make signups easy? How can we make a complicated set of programs understandable to the students? How can we spark their interest to want to learn more? And how can we do it all with the limitations we have in terms of time and budget? Ask questions like this to a room full of creatives, and the energy and ideas will flow.

We came up with a print poster that contained basic information, great photos, and a clear call to action for students to go to the web site to learn more and sign up. We really focused on the writing of the poster, borrowing a young creative guy from PR to help us. That step was a major boon to the project— we finally had words that fit with the designs we were doing, words written by someone who understands marketing and young people rather that by the director of the program or one of the employees that processes the registrations. We also removed as many of the acronyms of the programs as possible. There are so many that I can’t even keep them straight, let alone a student that hasn’t even been to campus yet.

For the web site, I took design concepts from the printed piece and adapted them to the new medium. I focused on user interaction— how a student would move through the site, and how to orgainize the large amount of information that is there. Since the print piece was a poster rather than a booklet, the bulk of the information went on the web, including course descriptions, fees, testamonials, and signup forms. So the architecture of the site became essential.

We then spent a lot of time working out an interactive signup form, that allows folks to sign up for the various programs in one place. The form sends the essential information to the various separate departments involved, while being transparent to the student. I can’t stress this enough. Students don’t care who is in charge of what on campus. They just want to do what they need to do and move on. This was a major goal of ours, which we largely met.

The project has been a success so far, and it is one that everyone involved is proud of, which is some feat. There is some refining to be done for next year, but when is the first iteration ever perfect? Goals have been met so far— signups are way ahead of where they were last year and almost all feedback is good.

It’s nice to feel victorious. Too often university projects are ruined by politics, budget, and territoriality.

I thought I’d document the process that I have been using lately on my university web designs, since after about 2.5 years of refining I have come up with one that actually seems to work well for me and my clients. This is shaping up to be another series; in this part I’ll talk about starting at the beginning.

A key part of the beginning of the design process is having access to a group of talented, creative people who have expertise in an area different from your own. They could be writers, graphic designers, programmers, system admins, art students, etc. I would try to stay away from faculty members (did I just say that?!) unless they are unjaded and not pressed for time. The two key qualities of the group members is creativity and expertise in some area. If you work as a team of one like I do, you may have to get creative in getting access to these folks, but it will probably be worth it. Chances are that some exist within your parent department, and others exist in those departments you have to work with all the time (IT if you reside in PR, and vice versa).

The process starts like this:

First, define the actual problem you are trying to solve. Try to remove all technology and design from this definition. For example, “we need an interactive way for folks to look up campus buildings and their locations” is better than “we need to use the Google Maps API to provide campus maps” and also better than “we need to update our online maps because they are outdated and ugly”.

If you do “client” work for academic or administrative departments, you will need to guide them during meetings to get them to tell you what it is they really want to accomplish. Why do they want to redesign their site? What do they want to get across to their users? What is the most important message they want to convey? This may sound strange to folks in the for-profit world, but university clients often come to me for web work without a clear vision of what they are trying to do, much less why they need to do it.

Once you get the problem boiled down, start talking about it with the aforementioned creative folks. They will start brainstorming ideas— “wouldn’t it be cool if“s— and will likely bring up points that you hadn’t thought of. Write things down, even if you don’t think they’re technically possible. Folks may come up with resources, other sites they have seen that they like, a cool thing their friend is doing, etc.

Often, from these conversations, I learn that the problem is not what the client thought it was, and what’s more, it’s not what I thought it was, either. The day I realized this was a real eureka moment for me. How can you make an effective site if you’re solving the wrong problem?

Once you figure out the problem you can start working on the best technology to tackle it, and then you can start working on your standards-compliant accessible code. And then you can usability test it and blah blah blah. The point here is not to get caught up in your own little corner of expertise before you get the big picture nailed down. I have spent a lot of time going back and fixing sites— sites I built— that are ineffective simply because they’re trying to do the wrong thing. Many times this is because I didn’t talk to anyone else about what I was doing, and many times it is because I took the client’s request at face value and did just what they asked for.

This first step— defining the problem— is much harder than it sounds. And, even though it doesn’t call your coding or CSS skillz into play, it is probably the most important part of the whole process.

How do the rest of you get to the root of the problem? Any tips or techniques to share?

I have spent the better part of the last couple of weeks looking at every university or college home page in the US. I did this as research for a new direction we’re thinking of taking the HSU site. It has been a year and 1/2 since our last redesign, and by the time I’ll be able to get something new up it will have been two years.

This seems to me to be the ideal redesign schedule for an institution our size. Long enough of an interval that all the whining from the last redesign has stopped, the gaps and shortcomings have become obvious, and the university has new priorities. But also short enough of an interval that the design doesn’t look overly dated and still functions.

It was obvious in my tour of US higher-ed sites that some of them have been around for a lot longer than two years. This isn’t surprising— I think that a two year redesign schedule is pretty much the quickest it can be done. But it was surprising to see how many sites are obviously still around from the mid-to-late 90s. But I digress.

I promised myself and my colleagues out there in RSSville that I would never point out specific sites and talk about why they suck. There are many, many reasons why this might be the case. Instead, it is much more productive to point out sites that are doing things well. And what better time to do that then when I’ve spent so much time going over so many University sites?

So I give to you a little essay about my favorite higher ed home page at the time of this writing:

Mills College: Designing to your audience, not your administration

When I did my survey (using this list on this page of UT Austin’s site— kudos to whoever keeps that up. Is it you Glenda?), I focused on just a few things: the overall graphic design of the home page, what kind of information was included on the home page, and the navigation structure. If a home page grabbed me, I explored the site further. If it didn’t, I closed the tab and didn’t return to the site. There were just too many sites to spend very long on each one, so I definitely could have missed a gem if the home page wasn’t compelling.

When I got to Mills College, I stayed for a good 10 minutes. Something about it just clicked with me. It is not the most sophisticated design out there, and the elements that are included in both the design and the navigation are typical. But as a package, it works very well for me.

I started to think about why this is. Why do I like this site so much more than the hundreds of others I looked at? And then I realized that two other sites that made it onto my list of “Good Sites” were Simmons College and Smith College. All three of these institutions are small, private, liberal arts, women’s colleges, and the designs are similar on first glance. They even have a similar color pallete. And then it hit me: I like these sites because they were designed for me. I am their audience. At least I was 16 years ago (omg, say it ain’t so!) when I was looking for a place to call home and continue my education.

While I didn’t go to an all women’s college (I just liked the boys a little to much…), I went a small private liberal arts college. I was drawn to the personal, small, intellectual atmosphere. Mills is able to convey that atmosphere to me through their home page through subtle details, without literally spelling it out. I want to talk about a few of these details and how they work together for me to add up to a very effective design.

First, the banner. While the metaphor of Polariod pictures may be a bit played out, they pull it off well here. They use interesting cropping on the photos, which feature interesting looking women. They didn’t water down the photo subjects for the web site— they are showing what at least seem like actual students. There is a nice fade effect when you click on a photo, that isn’t obtrusive— there are too many sites out there with distracting flash headers. But the best part of the header is that the two photos together create a dynamic tag line for the college no matter what random combination you choose. The photos on the left contain handwritten verbs, and the ones on the right have nouns. So when you click through the photos, you get a series of compelling phrases, such as “Create Action”, “Celebrate Community” and “Experience Change”. Very nice.

The second set of elements that drew me to the site was the handwritten titles, and the doodles embellishing typeset titles. These give the site a personal feeling and make it feel like a fun, interesting place to be. If I were to look over the notes I took in college, I would find similar doodles in almost all of the margins. This is a huge departure from the corporate feel of many higher ed sites out there. It is easy to imagine an administrator thinking that doodles and handwritten headers would make the site seem frivolous. But in the context of a good design, they give the site a personal, intimate feeling.

Third, I love the color palette. If I could do one thing to improve the state of higher ed web sites, it would be to somehow convince administrators that the school colors in most cases shouldn’t be used on the web site, and in all cases the web site shouldn’t be limited to the school colors. School colors were made for athletics. They were designed to show up on uniforms and distinguish one team from another. They were also designed to provide a harsh contrast between the lettering and the background color of an athletic jersey, so that names and numbers can be read at a long distance on a playing field where everything is in motion. These same traits make them unsuitable for the web. They are too intense and the contrast is too harsh. They usually make a design look awful, because they are wrong for the medium. My school is as guilty of being stuck on the school colors as the next, but looking at Mills, Simmons, and Smith, it is obvious to me that breaking away from the school colors can lead to a much better design.

Lastly, there are all the photos of those interesting women. I can probably appreciate that aspect better now than I could when I was 18, but it is nice to see a bunch of folks that look like they could be my friends. This is probably why the women’s colleges drew me in— all the photos look like they could be of my peers. This is an important realization for me in a couple of different ways. First, from a diversity perspective— I didn’t notice a lack of photos that hit home for me on most other sites, but when I ran across one that got it right for me, it made a huge difference. If you are at an institution with a diversity initiative, imagine what kind of powerful message your photos are conveying. Also, there were a lot of sites out there with no photos of people, and a few with no photos at all. These really lacked the personal feel that made a difference to me. One of the graphic designers in my department asked the other day if we need to solve every design problem with shiny, happy people. Well, I’d say that this can definitely be overdone, but done well it is much more compelling than any less human solution.

Finally, I feel that I must point out that everything is not perfect on the Mills site— if the site were done using web standards I would be able to give it higher marks. A goal for the future, perhaps.

But all in all, nice job Mills! I’d love to know the process and thinking behind this web design— if you’re out there reading let me know.

And just to drive home the main point a bit harder: if you design with your audience in mind, you will end up with a more effective site. Mills nailed it for me— it is the kind of place I could see myself going, and that I would recommend to the 18-year-old women I know.

As I looked over my projects at work the other day, I realized that I am working on close to 25 redesign projects. They are in various stages of the process, but a good chunk of them are stalled while the stakeholders deal with the site’s content.

It may seem like content should come first— that the content should be the driving force behind the project. But in the university web site setting, I am finding that the motivation for these redesigns is often not content-driven. I am finding that when folks ask for a “redesign” of their site, this can mean on of four things with respect to the content:

1. Re-skin

In this situation, folks have realized that the graphic design of their site is old and not up to the quality of other sites at the university. The site was often built by a student about 5 years ago, and it is starting to show its age. They want an updated “look and feel”, but they don’t want to do any work on the content of the site. They essentially want their site skinned.

Unfortunately, the student that built the site 5 years ago used the worst tag soup you’ve ever seen. There is no way to skin these sites without recoding them. And since I am going to be recoding, I want to make sure that the content is presented in the most effective way. There is no use recoding a design that isn’t working in the first place. So I talk to the client about these points, and see how they feel about taking some time to work on their content.

Often, they just haven’t thought these things through (they have jobs of their own, after all) and see the benefits of doing some work on the content and layout. So, I work on the layout, give them some ideas and prototypes, and they approve a design. Then I wait for them to refine the content.

2. Just Give Me a Template

These folks want a new graphic design, and have no idea what they’re going to do with the content yet. They realize the site has some content problems, but they don’t want to deal with them right now. They want me to set up a set of templates for them and hook the site into a content management system so that they can deal with the content later themselves.

No problem, I say. I just need a basic idea of how your site will be structured and the kind of content you will be presenting in order to build you an effective set of templates. And then I wait for them to sort this out.

3. Re-arrange

Here, the clients want to update the graphic design and refine the information architecture. They realize that folks are having trouble finding one or two key pieces of information on their site, so they want to make some changes. I spend time going over their content with them, and make some suggestions as to how to make the site more efficient for their users. We come up with flowcharts of content and navigation, layouts, and graphic designs.

Inevitably, these site require the writing of a few key items. I wait for these to be developed.

4. Redesign

Then, there are folks that want to truly redesign their site. They have a set of goals and objectives that they want to achieve, and they want to tear the old site down and come up with a completely new site that speaks to these goals. They realize that they will need to rethink their content and re-write large parts of it. We do brainstorming, thumbnailing, prototyping, and come up with some good solutions. These are fun projects to work on, as they get all the creative juices flowing.

However, we still end up waiting on that content.

What’s the Holdup?

Why do so many projects stall at the content stage? I think there are several reasons. First, this is the one stage where we as web designers can’t just do the work ourselves. We just don’t have the expertise to write effective copy about the client’s field. We need their involvement here, and our clients are busy. This is one more thing that has been added to the pile on their desk. So, the point at which the web site content makes it to the top of the pile comes down to a matter of time and priorities.

Second, often the person on the client’s side that ends up with the task of dealing with the web content has no idea where to start. They don’t spend their days surfing the web like I do, and they don’t have a good idea of what makes effective web content. They are lost, and feel like their drowning under a monumental task that they have no idea how to tackle. They need some help and some guidelines.

Third, it’s hard to write good web content. Even the folks that are dedicated to the site redesign and to working over their content will need some time to do this. The content needs some care, it can’t just be pumped out and published without some serious thought, revision, and testing.

And finally, as with everything at the university, politics come into play. The site redesign may have been mandated by a supervisor, and the folks in charge of actually making it happen may be swamped. Or they may not really care. Content may have to be approved by all the faculty within a department or another large committee. (And we all know what committees do to efficiency…) There may be internal politics affecting which content actually belongs to this client, as opposed to some other group. Folks may be in the middle of changing jobs or dealing with organizational changes. And on and on.

So What do We Do About It?

I am looking for ways to help clients deal more effectively with their web content. While there are some issues, like workload and politics, that I just need to learn to work around, it seems like there is some education I could be doing to make things easier for all involved. So how do you deal with these issues? Any insights to share? Any techniques that work for you? Let me know! I’m sure these issues aren’t unique to universities, so examples from outside the ivory tower are welcome as well.

The new design of this site relies heavily on boxes of equal height. I did a lot of thinking about how to accomplish this, and a lot of playing around with different methods during my design process, so I thought I’d share with you the ones I chose to use and why.

CSS Method

The most obvious use of equal-height boxes is on the front page, where I show excerpts from the most recent articles in each of the three main sections of the site, followed by links to some older articles and the section archives. It was important for the design that the “coffee”, “cocoa”, and “margarita” columns all be the same height, and that the title of each of the subsections align with each other across the three columns. I was able to accomplish this and more using my trusty friend, the em.

I like to specify font size and line height using ems. This allows users to increase their browser font size and still maintain the line height relationships that I have set up. I found that doing this also allowed me specify heights of boxes in terms of ems, and be confident that my text would be cut off neatly in between two lines. An example would probably help here:

The first question I had to tackle was “How do I get all three excerpts to be the same height, when I can’t predict the length of the title?”. The title may be anywhere between 1 and 4 lines long, depending on my mood at the time of writing. I knew from my CSS font specifications that the

elements containing the titles were 1.2em in size, and had a line height of 1.2em, with a .5em bottom margin. I also knew that the

elements containing the body of the excerpt had a size of 1em and a line height of 1.5em. So I knew there was a way to specify the height of the excerpt such that the bottom of the box would always fall between two lines of excerpt text. I could then hide the rest of the excerpt with overflow:hidden and have equal height excerpts.

Well, I fired up the calculator widget and started doing, as Steve likes to put it, “The Math”. After about an hour of calculations, resulting in a spinning head and much frustration, I decided to determine this height by trial and error. Which worked like a charm, giving me a height of 12.3 em for the excerpts, which allows sufficient text to show no matter how long title, and always cuts off between two rows of text. So hey, presto, I had three equal height excerpt boxes.

Follow this same method, I was able to set equal heights on the boxes containing the “More drinks” titles, and have all three of the archives links align. And I also used this method on the “Best of” and “Elsewhere” sections, keeping them equal heights as well. I then realized that since I had all heights specified in ems, I could also get the tab on the right containing the navigation to be equal in height to the three other main columns on the page, an added bonus that I wasn’t anticipating.

The best thing, though, about this technique, is that the columns are flexible. If a user increases their font size, the columns still hold up, up to a certain point. There is some text overlap at large font sizes, which I still working on, but at most font sizes the layout should hold.

Javascript Method

Another place I rely on equal-height boxes is on the article pages. I want the left-hand navigation column to be equal to the height of the column containing the article text, so that the dotted border always extends to the bottom of the article. This time I can’t use ems, because there is really no way of predicting how long I’m going to ramble on in my articles.

The border was problematic no matter which column I placed it on, because the article may or may not be longer than the navigation. So there would be some instances where the border wouldn’t extend to the bottom of the page if I just chose to put the border on one of the two columns and do nothing else.

So I looked for another method. What I needed was to force the height of both columns to be the same height as the longer of the two columns. Luckily, there are some folks out there who have published Javascript methods to do just that. There are several scripts out there, as a quick Google search can show you. The one I ended up using is from paulbellows.com.

The reasons I chose this script were twofold. First, it uses modern DOM scripting methods, and second, it recalculates the column sizes when the browser window is resized. Since this site is liquid, the second was important to me, as resizing the window can have a huge impact on the length of the columns, and if the script didn’t account for that, there could be some messy looking results.

The one flaw of this method is that the column sizes aren’t recalculated when the text size is changed. So if a user increases the text size of an article, they are left with text overlapping the boundaries of the box until they resize or reload the page. I haven’t been able to find any way to overcome this, although I am continuing to look. If you have any pointers, let me know.

Conclusion

While not the most elegant solutions, there are ways to create equal height boxes in today’s browsers without using tables. I look forward to the days when we can rely on using “CSS table display properties” and/or CSS3 multi-column layouts to achieve this (aside: check this blog out in Firefox 1.5 alpha— CSS columns, cool!) , but until then, we’ll still have to keep coming up with creative solutions.

Most University web sites are mediocre at best. How can this be, with the bevvy of experts in computer science, business, marketing, psychology, sociology, and visual design that a University affords?

In Part 1, I explored the problems created by the large and varied user base of a University’s web site. In Part 2, I discussed institutional inertia, and it’s implications for university web sites. Here I tackle the subject of university politics and the decentralized nature of the University web site.

Decentralization

It is almost impossible to make a general statement about the number of “webmasters” a typical university employs. About the only statement I can make with confidence is that there is always more than one. The actual number depends on such factors as the size of the university, the number of vice presidents or colleges, whether the institution is private or public, and legacy org chart structures— with a liberal dose of politics mixed in.

Often, major units of the university have their own webmasters, but this is by no means a rule. It is common for a university to have some units with their own web staff, and some without. Even among those units with their own staff, there is no rule as to whether the staff work for all of the individual departments within that unit. If a department doesn’t have professional web staff available to it, the maintenance of the web site often rests with the administrative assistants, who are given the task on top of their regular duties.

Decentralization of the university web site is not surprising, given the independent streak typical of many folks in power within an institution of higher learning. They want to have full control over their piece of the pie. This may be a good thing or a bad thing, depending on the situation. Decentralization may be essential if there are not enough staff in the university web team to do all that needs to be done. It may also be preferable for units with specialized functions to perform, such as Admissions or the Registrar’s office, that rely heavily on web based workflows. However, decentralization can also lead to a web site that for users seems fractured and convoluted.

One of the challenging consequences of decentralization is that there are folks of all skill levels working on web sites within the institution, ranging from highly trained web professionals to folks with virtually no web training and no interest in learning any more than the basics of wsyiwyg software. This creates logistical problems for those trying to coordinate the university web presence. University web, graphic, and accessibility standards must be reduced to the lowest common denominator so that everyone involved can understand and implement them. This is especially difficult if there is no CMS in place to help control some of the graphic and code structure centrally.

Decentralization also makes it difficult to even communicate with all the web developers on campus to get across institutional goals and priorities. Some universities have implemented a formal committee of web developers with regular meetings to deal with this issue. Although this is one more committee to add to the org chart, and one more meeting to add to the rotation, it is essential that all the web developers communicate with each other to minimize repetition of duties and to strengthen the overall site. How can plan (let alone an information architecture) for the web site as a whole be built if the left hand doesn’t know what the right hand is doing? Yet, there are institutions where formal web developer meetings are seen as unnecessary.

Perhaps the most frustrating result of web site decentralization, however, is borne by the users. The web site is not developed in a user-centric manner— each faction develops according to own internal goals (or abilities), without thinking about the big picture. A department-level web developer often doesn’t consider how a user gets to their site, under what conditions they use it, or where they need to go when they leave. They instead post information that they, the departmental staff members, think is important and set up a navigational system that makes sense to them as insiders. Users are expected to traverse organizational hierarchies that are often obtuse to find what they need on the web site, and frequently have to go back to the university home page and start over when they need to move on to a different activity.

For many institutions, decentralization is here to stay. Dealing with it effectively becomes the important challenge. Communication is the key to this— web developers communicating with each other, and everyone communicating with the users, who use the web site as one big whole, not millions of subsites.

Politics

This section has given me writers block for months now, because I haven’t been able to think of a way to discuss University politics that wouldn’t be a very bad political move on my part. So this section will be short and sweet, and let me state for the record that what I’m discussing here are generalities that don’t necessarily pertain to my particular situation. Also, this article, and this entire site for that matter, expresses opinions that are my own and not necessarily those of my employer, my husband, my cat or my mother. My dog shares all my opinions, because that’s what dogs do.

I have been on the University Web Developers Listserv for quite some time now, and one of the most frequent question posted there essentially boils down to “Who owns the University web site?” Does it fall under IT or PR or Marketing? Is it a technology or a communication tool or an essential student service? The truth is that it is all these things, and that a department can gain a lot politically from “owning” it. Department managers will fiercely defend their claim to the website, and thier colleagues in other departments will try to usurp control of it.

Until administrators realize that the web site should fall under the Web Office, and that it is enough of its own discipline that it can’t be effectively housed in one of the aforementioned places, I fear that those battles are going to continue. And they are not good for the website.

Another political minefield is the University home page. Many, many people within the University want a link to their program/department/service web site on the front page. The web team gets to field these requests, try to balance them against university priorities, and make reasonable decisions about what to include. These decisions are then either accepted, or moved up through the chain of appeals until they get to a political ally that reverses the decision. And the web team then tries to add them to the home page in a way that isn’t confusing for users and that won’t offend the “owners” of the other links on the homepage.

And then there is a snowball effect of additional requests, from folks who consider their program/department/service to be just as important as the one that was just added. And on and on…

I try to end all of these sections with potential solutions, but I don’t think there is a solution to politics. It’s just too much a part of the way humans behave. A well-crafted policy can help with some of the home page decisions, but there will always be exceptions. So the best solution I can offer here is a love of the web, a sense of humor, and friends standing by with the margaritas.

And thus ends the saga. What are your thoughts? Strategies? Words of Wisdom?

Note: The title of this series came from emails I receive periodically from students. To paraphrase, they say:

Your website sucks!!! I can’t find anything I need! I have to use search to find anything and Google can do that for me. The webmaster needs to do some more research.