http://tc.eserver.org/authors/Veen,_Jeffrey A bibliography of works by Veen, Jeffrey in the field of technical communication. en-us Copyright (c) 2005-08 by the EServer. All rights reserved. tclib-editorial@eserver.org (TC Library Editorial Board) webmaster@eserver.org (Geoffrey Sauer) http://tc.eserver.org/images/newlogo.gif http://tc.eserver.org/dir/Veen,_Jeffrey http://tc.eserver.org/33493.html http://tc.eserver.org/33493.html Sometimes, content has many attributes that have different importance to different users. A hierarchy assumes everyone approaches these attributes the same way, but that’s often not the case. http://tc.eserver.org/33263.html http://tc.eserver.org/33263.html A content inventory is a relatively straightforward process of clicking through your Web site and recording what you find. We’ve developed a simple Excel spreadsheet to help you structure your findings, and some tips on how to get through it. http://tc.eserver.org/33283.html http://tc.eserver.org/33283.html This whole category of software desperately needs to be redesigned with writers, editors, designers, and site owners in mind. Here are my recommendations to the folks writing open source content management systems. http://tc.eserver.org/31839.html http://tc.eserver.org/31839.html The CMS idea is enticing. Empowered departments of a big enterprise, all publishing content directly to their customers through standard templates. The site continues to grow, but in a controlled way. And these business units have complete control of what is and isn’t online. Sounds good, but just try putting it into practice. http://tc.eserver.org/25804.html http://tc.eserver.org/25804.html The personal weblog of Jeffrey Veen, a founding partner of Adaptive Path, a user experience consultancy focusing on the impact of design on business. http://tc.eserver.org/25803.html http://tc.eserver.org/25803.html I have always been bothered by how difficult it is to subscribe to RSS/Atom feeds. Consider the user experience -- Someone sees an orange button with an unfamiliar acronym, they click it, and the browser starts spewing undecipherable code. http://tc.eserver.org/25718.html http://tc.eserver.org/25718.html Industry accolades aside, how important is standardization to an individual business like ours? Do Web standards give organizations a return on investment? Does the transition to XHTML and CSS make financial sense? The answer to those questions is yes. http://tc.eserver.org/25708.html http://tc.eserver.org/25708.html Almost every site's search engine could use improvement. Most organizations' Web teams couldn't really affect the quality of their search results--they were stuck tweaking search technologies that had already been purchased and installed. Often, the most dramatic change they could make was in the design of the search and results interfaces. http://tc.eserver.org/25704.html http://tc.eserver.org/25704.html Most open source content management software is useless. The only thing worse is every commercial CMS I've used. But it doesn't have to be that way. http://tc.eserver.org/25711.html http://tc.eserver.org/25711.html Of just under 100 companies, only 27 percent of companies surveyed planned to continue using their Web content management systems as they do now. So why do these CMS projects almost always fail? http://tc.eserver.org/22655.html http://tc.eserver.org/22655.html So, you've mastered Cascading Style Sheets, right? You've memorized the spec, read up on all the tips and tricks, and even understand the theoretical benefits of separating presentation from structure in your Web pages. Your Web sites are filled with gorgeously rendered text and sport fine control of point size, leading, margins, and backgrounds. You change dozens of pages by editing one simple text file. You've done all that, haven't you? Yeah, me neither. http://tc.eserver.org/18944.html http://tc.eserver.org/18944.html I've spent the last year working with clients on a variety of information architecture and design problems. One of the most strikingly consistent issues, however, has been how many of these companies still haven't developed content management systems. I've spoken with enterprises in the Fortune 100 who find themselves sitting on top of 6 years' worth of Web content trapped in static HTML files. They know they need to get this stuff into database and redesign their site into a template-driven system. But their first question is inevitably, 'So, uh, where do we start?' If you're in a similar situation, your first step is to take stock of what you've got. This process, known as a content inventory, is a relatively straightforward process of clicking through your Web site and recording what you find. We've developed a simple Excel spreadsheet to help you structure your findings, and some tips on how to get through it. Start at your home page. Identify the major sections of your site. For example, at adaptivepath.com, we've divided our site into these sections: team, services, workshops, publications, and contact. If I were doing an inventory of this site, I'd start with one of those sections, click in, and see what's linked from it. For each page that I visit, I'd record the information specified in the columns of the spreadsheet. I'd follow every link and navigate as far as I could through the site, making sure to gather data about every possible page on the site. http://tc.eserver.org/18945.html http://tc.eserver.org/18945.html So often we assume that Web sites should be hierarchically organized. We talk about a 'home page' that offers 'top-level navigation' so that users can 'drill down' to the content. It's as if we're programmed to think top down. But what about information that isn't as easily structured this way? Sometimes, content has many attributes that have different importance to different users. A hierarchy assumes everyone approaches these attributes the same way, but that's often not the case. http://tc.eserver.org/18755.html http://tc.eserver.org/18755.html The benefits of transforming HTML from a stand-alone language into an XML version of itself aren't immediately apparent until you understand the inherent value of XML. Since the language syntax is so strict in XML, parsers (the software that reads and understands the code you write) are a lot easier to develop. Ultimately, it will allow browsers to become smaller, faster, and more stable. It also means your code will behave in a far more predictable way: Either something will work, or you will get an error. It will be a marked difference from the voodoo we experience across multiple browsers today.