Phil Windley, former CIO of the state of Utah, has written a very interesting piece on his IT hierarchy of needs and the current outsourcing trend. Windley notes that much of the outsourcing is being done among the "coal-mining" type IT jobs--maintaining the low level infrastructures.
My prediction is that while hundreds of thousands of IT jobs will go off-shore in the next decade, we'll gain more than we lose as we move up the hierarchy. We do a poor job of meeting demands at the top of the hierarchy and there's plenty of work to do. When you think about the real problems that IT should be solving, its amazing how little attention we pay to them. Our goal ought to be to provide every employee with the information they need to do their job when they need it. Instead, we throw an email client and a word processor at them and say "good luck." We can do better and the first step is to embrace the changes that are required to solve the problems at the bottom of the hierarchy---even if that means some pain in the short term.
The real problem is that most CIOs focus on IT rather than IM. The focus is on the technology rather than the people and the information they need.
Email is dead. Granted, this is neither a new or original observation. But, it was reinforced this morning as I spent a couple of hours troubleshooting an email problem.
Many of our sites have automated email features. Emails get fired off to site owners with user feedback and other information; emails get sent to us, the developers, when things go wrong; and emails go to users when the sign up, forget their password, or have other issues. But, as usual, spam gets in the way. It turns out the "from" address I was using had a word in it (no, nothing bad) that tripped up our spam filter. The filter is a pretty simple one...it just does wild-card matching. So, all of the messages sent from this particular site (and I'd imagine a number of others) went straight to dev/null (non-geek translation: they were erased). Of course, these messages just died quietly, without any indication that something went wrong.
One of the solutions is, of course, a better filter. We managed to work around our issue this morning, and eventually we'll upgrade our filter.
The other solution, I'm coming to realize, is RSS. Lots of those automated messages could have been handled by RSS. The error messages could be an RSS feed, as could the user feedback messages. We'll probably still need to send the "forgot your password" messages and other user-specific communication using email. Granted, using RSS does require some additional infrastructure. The error messages would need to be captured (probably to database) and the RSS feed would need constructing. Given that RSS is fairly simple, we're taking a couple of hours of work to set up a system, I think. But, once a system is in place once, it'd be trivial to make new feeds. The other piece of the equation is the RSS reader. I have mine (NetNewsWire) running all the time. But others don't, and they'd have get used to using a new communications tool (granted, they'd see all kinds of other benefits from this...).
(If you're new to RSS, check out the RSS section of my weblog and rss resources page.)
Dave Rau has written up his experiences creating a very nice CSS-based layout. He does a nice job explaining how he broke the layout down into semantic containers, then used CSS to push them into place.
(via CSS Vault)
Jakob Nielsen is back with his annual rant listing the Top Ten Web Design Mistakes of 2003. Its an interesting list, and worth a quick read, I think. One of the things I find interesting about it is that none of the items listed are really deal-breakers. Okay, so "Unclear Statement of Purpose" is a big deal, but the rest of the list just aren't killers. Which is not to say they're not good, useful advice. They are. But they tend to be smaller items that can incrementally improve a site.
I'd love to have a browser that validated pages while you browse. Lots of our sites are password protected (and therefore rely on cookies for access), which means that its tough to use web-based validators. Granted, I could do a "Save As" from the browser, then upload the file to the validator. But...this ain't too convenient.
iCab, a mac-only browser, has this very same feature. If the page validates, it displays a green smiley face. If not, the face frowns and goes red. Cool. Except for one little thing...it doesn't understand XHTML. And we're doing our latest project in XHTML. Argh.
So, I started poking around for a Mozilla-based solution. Checky looked promising. Checky is a contextual-menu item. A right-click brings up a list of a number of validators, and choosing one opens up the validator in a new tab. I'm not so keen on navigating the contextual menu (preferring iCab's smiley face), but I can live with it. Unfortunately, none of the HTML/XHTML validators could handle my password-protected sites (instead, they just validated the "you're not logged in" page that non-authenticated users are redirected to).
Another option is the Web Development Mozilla extension. By picking the "Validate Local HTML" option, I actually can validate the password protected pages. It still requires a few extra clicks, and opening a new tab, but it works. Cool.
Tim Bray wraps up his very informative series of articles on search with a list of requirements for a (hypothetical) ideal search engine.
I'd love to see someone implement this. I've been less than impressed with the open source search engine choices. Some seem rather restrictive (in terms of the input the expect and the output they spit out), and others are hampered by complexity. Bray argues that search should fall into the category of it "Just Works" software. I agree.
What I'd really like to see is something that is fairly easy to set up and run, and will give me results in a structured format (ideally XML). Then, I can slice and dice and present the results in whatever language I'm using at the moment (Python, PHP, ColdFusion, whatever). Plus, I'd like to be able to easily integrate the full-text results with other services..."best bets" results, searches of other directories and databases, and so on. Lets hope someone jumps on Bray's suggestion.
The good folks at Apple's Developer Connection have written an article on best practices in web development. The article covers doctypes, XHTML, CSS, Accessiblity, and JavaScript. In the whole, its a nice overview of the things you need to do to create more "modern" web pages.
The article also manages to squeeze in a not-so-subtle dig at Microsoft's stalled IE development:
By comparison, Internet Explorer for Windows—the most popular browser for the Windows OS—often requires web developers to use a number of non-standard tricks or to accept layout differences. This situation is unlikely to change anytime soon, so for now, web developers have to work around these problems.
I agree. In fact, a few weeks ago I was speaking to a Microsoft employee and I mentioned that "IE is turning into the new Netscape 4." I'm not sure he got the reference (NN4 required lots of hacks to get decent display, and its buggy CSS support slowed adoption of web standards), but he did agree that Microsoft has pretty much stopped development in favor of Longhorn development and that it might not be the best approach. Huh.
Gerry McGovern has written an entertaining rant on content management: Avoid Santa Claus approach to content management.
Taking a technology approach to content management is like writing a letter to Santa. The letter is full of requests for all the coolest tools. It asks for everything. The toys must integrate with this and that. They have to be cutting edge, robust and scaleable. They have to be personalized and customized.
McGovern argues, correctly, that the focus in content management should be on the content, not the management.
The 4096 Color Wheel joins a host of other nice web-based color tools. Notable in this tool is the display of "web-safe," "web-smart," and "unsafe" colors side by side.
CMS Watch's Tony Byrne has published his annual analysis of the Ideal CMS. Only, there isn't just one ideal CMS. Rather, Byrne picks and choose features from 16 packages (commercial and open-source) to assemble his ideal (and hypothetical) CMS.
So, like last year, assembling an ideal Web content management package would require integrating components or attributes from no less than 16 different companies. Note in particular the preponderance of enteprise-tier solutions among the leaders and laggards; there is a lot of turbulence at that level right now. To the extent the enterprise players have become especially good at some things, so have their products become rather dreadful at meeting certain other requirements.
Design firm mediumbold has produced a very nice overview of type (letters, fonts, etc), covering the origins, design considerations, and different styles of output.
The site is very well designed, and only takes a moment to go through the site. It left me wanting to know more...I'll need to check out the resources section when I have more time...
(via Zeldman)
Geeks like to fight, I think. Mac v. PC. Tables v. CSS. Flash v. HTML. And so on.
One of the never-ending debates in the web design world is fixed width layouts v. "liquid" layouts. Fixed width means that designer specifies a width (say, 700 pixels); liquid layouts expand and contract based on the size of the browser window. Designers have also come up with "jello" designs, where some parts are liquid and others are fixed.
Mike Golding has posted an interesting article advocating fixed width design. Also note a nice, lively discussion on the topic after the article.
Update: Nick Finck chimes in with a number of links on the subject.
We've been working on a project that will likely generate a good deal of automated email. The project, an online registration system, will fire off an email, at minimum, when the user signs up for a class and when the class is over. So, I was interested to see Jakob Nielsen's newest Alertbox column: Automated Email From Websites to Customers. The article, which also acts as an advertisement for Nielsen's latest report, does have some useful info. In short:
The Web Standards Project interviewed Todd Dominey about the redesign of PGA.com. Dominey moved the site from old-school tag soup to a XHTML+CSS design. Sort of. It turns out that the CMS used by PGA.com didn't allow much control over the code, and there is still some non-standard junk floating around. But, this makes for an interesting story and a nice lesson about using flexible tools...
Salon's Scott Rosenfeld on RSS:
What if someone had sat you down in 1994 and told you, "There's this new thing called HTML, and it's going to change how we get much of our news and information"? (Maybe you were lucky enough that someone actually did this for you. It happened to me -- though it took more than one introduction for the message finally to get through.)
A List Apart's latest article shows a technique for creating rounded corners using CSS.
The technique looks nice, but a tad complicated. But, then again, so is the table-and-spacer routine...
C|Net is reporting that linux vendor RedHat is now offering educational discounts on its Enterprise products. Nice.
I've heard a number of people say that all of the content on a site should be available in three mouse clicks (or less). The "Three Click Rule" is one of those things that's been around for years, and people often latch onto it. Josh Porter decided to subject this rule to some actual user testing (novel idea, huh?). His conclusion was that the "Three Click Rule" is "misdirected but well-intentioned."
In our studies, users complain about how long it takes to find things all the time. This is one way that users vocalize their frustration. They tell us that if they could only reduce the number of frustrating clicks the site would be better.
However, these complaints aren't actually about the clicks. They are really complaints about failing to find something. When users find what they want they don't complain about number of clicks.
Testing websites can be a pain. Especially sites that require interaction with forms. I haven't found anything that could help automate the process, but I did run across Stuart Langridge's Browser.py. This is a bit of python code that can be used to simulate a browser, including following links and filling out forms. With some work, it looks like someone could create a test "harness" out of this...
James Robertson has published a nice look at the two publishing models used in Content Management Systems (CMS). A CMS can either publish static HTML (or PHP/ASP/CF, etc) files in a batch, or it can dynamically output HTML for each request. Robertson clearly outlines the advantages and disadvantages of each method, then stresses that the specific requirements of the project and organization should dictate which model is followed.
I've swung back and forth on which model I prefer. Now, I think I like the simplicity and speed of the batch model. But, of course, Robertson is right to focus on the specific requirements when making a decision.
Update (12/13): Ian Bicking and Simon Willison have both recently written on the benefits of the static model. Bicking mentioned another great benefit of the static model (and one I hadn't thought of): by producing static files, you can implement a CMS incrementally. And anyone who has ever been a part of a major re-design or CMS implementation knows that this could be a huge deal. Trying to migrate old content into a new system can be quite time consuming, and you face problems with dealing with updates to content. By maintaining both old content and new, CMS-driven content at once, you solve a whole bunch of problems.
Lou Rosenfeld has posted an interesting little rant, playing off of a recent Clay Shirky rant about the Semantic Web. While I don't buy the Shirky argument, I did find Lou's comments valuable. He talks about seeing more and more people look to "metadata" as the answer to all their problems (just like portals and push in years gone by). But, Lou points out that this is complicated stuff:
Why am I so uneasy with large metadata-driven approaches? One problem: in many environments, those espousing metadata as "the answer" don't recognize that there are really two types of metadata to wrangle with: structural (think attributes or fields) and semantic (descriptive values or controlled vocabularies that populate those attributes). Each of these can require an extensive investment to think through, develop, implement, and, perhaps most importantly, maintain. People's information needs are moving targets, as is an organization's content; the metadata that connect them naturally need to evolve as well.
There are ways to approach these problems, but don't let anyone fool you into thinking that it will be easy or cheap.
Selectors make CSS powerful, but they also can make CSS rather confusing for beginners. Fortunately, Max Design has posted a great tutorial on the subject: Selectutorial.
This tutorial joins a growing body of great resources at Max Design. Check out the nice list resources and the float tutorial.