Holy crap, this really resonates: The Slow Web by Jack Cheng.

Having recently about had a breakdown caused by the fast web and our fast culture, I am glad to see that I am not the only once thinking about this. I love the graphic of the hummingbird vs. the snail. I need to be a lot more snail-like these days to get a grasp on the thread of my life.

Right. I realize that I haven’t blogged in over a year. I am working on remedying that, and have a bunch of half-finished projects to prove it. More on that later.

For now, here is my entry for the Handcrafted CSS Nashville Rebound Contest. The colors look a bit yuck surrounded by this site’s colors, so you can click on the image to see it on its own.

I’m a little late to this conversation, since I am on vacation for Thanksgiving, but I thought I’d weigh in on the CSS framework discussion started by Jeff Croft.

I’m pretty sure the only reason why this is getting so much attention right now is because of the final few paragraphs of Jeff’s original article, which suggest that the only reason folks are against frameworks is that they are afraid frameworks will make their jobs obsolete:

My gut feeling is that many folks who make their living off writing semantic (X)HTML and CSS are getting scared. They’re realizing that CSS and HTML are actually pretty darn easy, especially with the aide of tools like frameworks. They’re realizing that the only hard thing about writing CSS is troubleshooting lousy browsers — and they’re realizing that lousy browsers are fewer and farther between than ever, and getting fewer every year. They’re realizing, quite frankly, that their skill set may be less valuable in the future than it has been for the past couple of years. I’d love to be proven wrong, but until someone speaks up with some good reason why CSS frameworks shouldn’t be used, instead of simply asserting that they shouldn’t, I’m convinced these folks are just trying to drum up some false job security.

This is a bit of hyperbole and flame-bait, and it’s not surprising to me that it has been met with some anger. But I have made posts like this myself, and am not going to hold it against Jeff, who I’m pretty sure didn’t mean to offend lots of his friends and colleagues in one fell swoop.

My experience with CSS frameworks is limited to Blueprint. I have briefly looked at YUI, and felt that the logic behind that system was at odds with the way I think. Just a different approach from what I am used to — nice looking shoes that just don’t fit me. Blueprint fit a bit better, and I had decided to use it for the redesign of this site that has recently launched, so that I could evaluate it in a real-world situation.

The most potentially useful part of Blueprint for me was the grid piece. I already have preferred ways to do a global reset and typography that work well for me and are well-honed. According to Jeff, this is in fact a personal framework. Well, maybe, if you want to start playing with semantics. To me, a framework is a standard that folks from all over the world agree on and utilize, like Rails or Django or jquery. But whatever. What I found missing from the grid piece, and also from the grid generator and layout generator, was a way to create a liquid grid. This was an important requirement for this site, which has always been liquid, and has been a place where I could show that liquid sites can be designed well and that the issues commonly cited as reasons not to go liquid can easily be overcome with a little thought. I belong to the Jeremy Keith school of liuid design. 🙂

So, I ended up writing my own grid and not using Blueprint. For professional front-end developers, I suspect that this is a common occurrence — there are well-established specifications for a project that make the use of a framework impossible. I have found that the exceptions are more common than the rule in the work that I do, and CSS frameworks may work best for the rule. I may try to work with a framework again in the future, if I have a project that is suitable for them.

For the record, I don’t feel threatened by them. Even for front-end folks, there’s much more that goes into what we do than the simple chunking out of code, and most folks that I know are constantly on the lookout for tools that make the code writing process more quick and efficient. If frameworks turn out to be one of those tools, they will happily be adopted by me and my colleagues.

In the last couple of days I have soft-launched version 4 of Interllectual.com. Any craziness you have been seeing with the RSS feeds should be resolved now.

My goal with this version was to bring all the different aspects of my life together in one place, and to have the site feel like it represents where I am in my life at this point. Colors are brighter that they were before, and animals play a huge part in the site as they do in my life. There is a new logo-mascot, and my mammal and bird life-lists are a major feature. I have a backlog of data to fill in to the animal section, which is my favorite part of the new site. Brian and I spend a lot of time bird and mammal watching, and now we have a place to record what we’ve seen and to feature photos and videos we’ve taken of the critters. I have a bunch of videos from Australia that will be going up soon.

I also have a lifestream (the Diversions section) that pulls in my data from my other online forays— my tweets, links, books I’m currently reading, etc. And of course there are also the articles which I plan to devote a bit more time to in the near future.

The site is now running on ExpressionEngine, and I will write more about that soon. I still have a bit of work to do with some of the finer details and the IE6 compatibility, but I wanted to get the site out there and let everyone start enjoying it. I call this version “Finnegan”, which is the name of the owl. I’ve always wanted to name one of my pets Finnegan, and now I have. Finny is wise and shares his wisdom with us all in his “Thought of the Day” in the footer of the main page.


As promised, here is a follow-up to my previous post about our test of the emergency alert system last week.

We advertised the test on the HSU home page during business hours with a red box in the “promo” area:

HSU's home page, with red box announcing that a test of the emergency alert system would occur that day.

Then, at the appointed time, I switched the HSU home page into emergency mode for 15 minutes. A notice was displayed that explained the test, and what HSU constituents should do during an actual emergency:

HSU home page with large, red emergency notice posted.

(These screenshots were taken by Karine Joly of collegewebeditor.com, who has many great articles about higher ed emergency communications. I forgot to take screenshots during the drill :/ )

What we learned

  1. Our chief of police rocks. Yes, we knew this already, but our Chief of Police, Tom Dewey, really needs to be commended. He has worked extremely hard on this system, which includes not only the web notices, but also notices on the campus NPR radio station, a telephone information line, text messages sent out to any constituent that chooses to sign up for them, and bells ringing, a recorded announcement, and signs placed around campus to warn folks of the emergency. He has been able to bring together staff from all parts of campus as key parts of the system, and his coordination has been amazing. Every part of the system worked on the first test, which is incredible. There is fine-tuning to be done, but Tom has done a great job pulling this all together.
  2. Our bells need to be louder. This is part of the fine-tuning— the bells couldn’t be heard on some parts of campus, so we are looking into amplification systems and ways to broadcast the bells from various parts of campus.
  3. Black text on red doesn’t work on the web. Tom has out together a color-coded system of signs for campus, and the intention is for the web notices to also use that system. There are 4 colors: red for campus or area closures and tests of the system, orange for tsunami warnings, yellow for national or regional incidents that don’t directly affect campus, and green for all-clear notices after an emergency. When I put together the styles for the web notices, I decided to scale back the background color from the really bright colors of the signs to aid readability. This unfortunately made the red notices kind of pink, which wasn’t really what we were looking for. So I made a quick change at the 11th hour to the colors you see above. That combination doesn’t meet accessibility standards for contrast, however. So, although the goal was for black text on red, we will have white text on red, which will be much more readable and allow a color of red that says “emergency” and not “be my Valentine”.

So, all in all, the test was a success. The plan is to have one of these tests per semester so that everyone is always up on what our roles will be if we ever have to implement the system for real.

Other refinements

We have added 20 boilerplate notices to the campus CMS for all kinds of potential incidents, from a forest fire in the campus forest to a shooter incident on campus. The notices include information such as whether folks should leave campus, whether classes are canceled, whether staff and faculty should remain and assist or leave, and whether the residence halls should evacuate. Public Affairs staff can choose the appropriate boilerplate notice to start from and adjust it for the particular situation at hand, saving time.

The CSU has also put together a roll-over system for all 23 universities to deal with situations where our web server is taken out of commission. If there is a major earthquake on campus taking out our server, for example, humboldt.edu will resolve to a server in Long Beach so that we can still use the web as a communication vehicle. I and several other folks on campus can log into that server and manage the site from there. If we are also out of commission, either from being physically incapicatated, or from our whole county being offline due to a major infrastructure failure (this happened last week…), we have a buddy campus that can also log in and make updates for us.

So, I feel that we are about as prepared as we can be for an emergency situation. Let’s hope we never have to actually put all this to use.

Oh, hello. Yes, it has been quiet around here for a while. There is work being done behind the scenes that is taking much longer than anticipated, but I digress.

I wanted to alert any of the university web pros that are interested to the fact that HSU will be testing its emergency alert system tomorrow, September 27, 2007 from 10:45 to 11:00 am Pacific Time. This will include switching our web site into emergency notification mode.

I have developed two emergency templates— one for low-level emergencies such as power outages, tsunami warnings for the county (campus itself is out of tsunami range), etc, and one for high-level emergencies such as campus shootings, major earthquakes and the like. The low-level emergency template will be used tomorrow, and retains HSU marketing messages and most functionality. The high-level template removes all images and marketing, as well at most functionality, in anticipation of high server loads. Folks from the Web Office and from Public Affairs have the ability to switch the main site to one of these emergency templates and post emergency messages.

I will follow up after tomorrow’s test with screenshots and an analysis of how well the system worked.

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.


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.


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:


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


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"}



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:


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


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.

This site is powered by WordPress and styled with ZenPress