Hobbs on Tech - Management, CMS, and Multilingual

Client choice via a la carte menu (using spreadsheet)

hobbs — Tue, 16 Sep 2008 20:30:49 -0600

Sometimes you want to give your client a variety of options to choose from the next phase of a project. For instance, if you are developing a web site for a client, you may wish to discuss a variety of possible features to implement. Since it can often get confusing for both the client and yourself when negotiating different features, one approach is to give the client a spreadsheet where they can try out different combinations of features to figure out what they want to pay for (this is especially useful when both you and the client have far more ideas than will fit in the budget). By also providing the option of tentatively planning for future phases (as well as tentatively indicating items that the client will probably never want), the client can better envision what they will get in the future as well.

One useful way to present this is in a spreadsheet where the rows represent the features and the columns represent different possible phases -- a particularly straightforward method for the client is to allow them to mark an "X" in columns to indicate what features should be delivered when (see example spreadsheet below). This can be accomplished using the DSUM function in Excel and other spreadsheet programs (the example below uses EditGrid, although it can be downloaded to Excel if you wish).

Here is a non-interactive example sheet (you can also play with an interactive version of this spreadsheet, including moving around the selections of features in each column/phase -- WARNING for Firefox users: if you are using Firebug disable it before going to the interactive version due to a bug in Firebug):

Why Data is Different

hobbs — Fri, 25 Apr 2008 13:22:08 -0600

But isn't it all data? Although web content certainly is an important type of information available on a web site, Data needs to be treated differently. Here I'm talking about Data with a capital D -- I thought the Wikipedia description was good: "Data refers to a collection of organized information, usually the results of experience, observation or experiment, or a set of premises. This may consist of numbers, words, or images, particularly as measurements or observations of a set of variables." Here are some of the ways that Data is different:

People expect Data to be available in different Formats.
Users want to manipulate the Data.
You don't totally control your Data, since it is available in different Channels.

There are several implications of this including:

Formats. You may wish to standardize the formats that your data is available in. Is all your data always available in csv (if that's what you standardize on)? This includes both the formats themselves (Excel, Stata, etc) and also the method by which the data is requested. For instance, is there one place that users can directly get all your data? Directly doesn't mean some thin layer with links to databases each doing its own thing. An example consistent format would be a web service with a published set of parameters by which the data could be requested. Ideally, all the institutions data would be available from this one web service.
Manipulation. Sometimes people just want to see your data, but usually they will want to manipulate the data. By providing your data in consistent formats, then it will be easier for your users to utilize your data. Other users will expect that *you* provide the tools for manipulation of your own data.
Channels. Ideally you will work to directly feed data to primary channels. For instance, if you feed data directly to services like Swivel then you both get more use out of your data and also can ensure your data is available in its highest quality (not watered down by other people copying and pasting your data, for example).

Beware False Precision in Tagging

hobbs — Sat, 08 Mar 2008 08:01:00 -0700

The prior post Taxonomy Mappings: Be Careful When Integrating gave some examples and described the problem of taxonomy mappings. Related to that is false precision in your tags. In thinking about this more, it occurs to me that there are probably two useful rules of thumb to keep in mind whenever tagging/pulling content (whether the content is automatically tagged, or mapped from another taxonomy, or mapped by hand):

You can't tag in a course grained taxonomy and pull based on a fine-grained taxonomy (for example, if you have a system that only tags to "Washington, DC Metro Area," then you won't be able to pull by "Washington, DC" since any content tagged in the system may only be relevant to "Alexandria, VA").
You can't tag in a fine-grained taxonomy when you only are using coarse information to determine the tagging (for example, if all you know about a group of content is that they're all animals, you can't tag each of content to frogs, cats, dogs, etc).

In both of these cases, when you pull by the fine-grained taxonomy there is a false sense of precision (and you can get grossly wrong.Another way of stating the rules of thumb above:

You have to originally tag (or possibly go through the effort of retro-actively tagging, perhaps through automated concept extraction) all content to at least as fine-grained a taxonomy as you're going to pull from,
without artificially tagging more precisely than you are accurate.

Of course, by far the most preferable treatment is that all content, across the various systems you want to pull from (onto the same web page, for example) is tagged to the same, fine-grained taxonomy (or at as fine grained as you ever expect to need to pull from). Otherwise you'll have to resort to taxonomy mappings, or retroactively tag content.

Why Short Delivery Cycles for Products

hobbs — Thu, 07 Feb 2008 19:24:45 -0700

The natural temptation on planning a product's roadmap is to plan far into the future. That temptation arises for reasons such as wanting to please clients by telling them you'll give them what they say they want, wanting to relay the internal technical teams' plans to deliver something far in the future, feeling that you already know the list of features that users want, and not wanting to feel like you're planning all the time. In my experience, that is less successful than trying to only plan and publicize a short time horizon out (and not even promising anything outside that time horizon). Here are some of the reasons:

You're always delivering something. In other words, the user regularly sees progress.
Related to the above bullet, it forces you to think of creative ways of solving your users' problems. If you know you have to deliver something in the next month, then you have to carefully explore the requirements, prioritize, and come up with some unexpected solutions.
Quick responses to what you release:
- When something needs to be tweaked that you just released, you can quickly move to the next iteration.
- If your idea turns out to be a real stinker, you can drop it before you spend a lot of time on it.
- If you have an unexpected hit of an idea, you can quickly continue to refine it.
Inevitable slips don't end up cascading tons of other deliverables (if all you promise is delivering 10 features in the next three months, then if three slip it only affects those three -- if you had promised 10 each quarter for the next year, then if three items slip in the first quarter then probably 37 items slip for the year).
Combats somewhat against almost everyone's natural propensity to procrastinate. If there are always items that need to be publicly delivered, then it's harder to procrastinate than if you have some huge delivable a year out.
A regular period that people expect a progress report. Some advantages: a) the potential "embarassment" factor makes you pay close attention on a regular basis, and, moreover, b) your clients know they will be engaged in the discussion of your progress.
The further out you plan, the less accurate you are about the schedule.
You can respond more quickly to changes in your industry or competition. If you've already publicly planned a year out, then if, for example Web 4.0 hits the scene quickly, you've either got to upset a lot of people that are already expecting a bunch of features that year (by slipping those to make room for Web 4.0 now) or not even consider adding the Web 4.0 features until after the year has passed!

I partially read the following a while ago that helped convince me to push toward short delivery schedules: Agile and Iterative Development: A Manager's Guide by Craig Larman and Getting Real by 37signals.

Notes from a job search

hobbs — Thu, 07 Feb 2008 18:33:21 -0700

After kicking the job search into high gear over the past three months or so, I'm happy to be joining Welchman Consulting as a Senior Consultant later this month. As their web site states: "Welchman Consulting helps organizations develop effective Web Operations Mangement strategies that optimize the quality and impact of their Web sites" (see this powerpoint presentation on Web Operations Management).

This was an interesting job search, so I thought I'd mention things that worked and didn't work, along with some of the most interesting places I interviewed with.

Some of the places I interviewed (and how I found the job in parentheses):

Google Switzerland (through a blind resume submission at google.com), where they've started an engineering center (which manages it's own portfolio of global products). I really enjoyed interviewing with Google. The process was an intense game. After thinking I bombed two phone interviews (with excellent questions like "How would you improve gmail? OK, you're about to pitch your idea to Larry and Sergie now: Go!"), I ended up being flown out to Zurich for an interview there. The best part of that interview process was the technical portion of the interview, which was mostly algorithm analysis (involving the Fibonnaci numbers) and then a sequence of "how would you compute that? How would you compute it faster? faster! faster!?" The worst part was with a product manager about a fussball tournament problem -- I just was not reaching a breakthrough on how to solve the problem and the interviewer just stared at me sweating for 20 minutes (side note: they're a little too nuts about fussball -- during a break some guy got a bit too upset with me about not playing fussball well enough on his team). Anyway, the process was a lot of fine and quite a mental game.
iapps/Bridgeline (from Potomac Tech Wire, a local DC mailing list). Iapps has been developing web sites in the DC area for years now, and was recently bought by Bridgeline. I was most impressed by their performance/incentive metrics which seemed reasonable and well-aligned to drive a strong, profitable company. Also, their hosted CMS is quite strong.
LTU Technologies (through a colleague). This is a visual search and filtering company, with offices in D.C. and Paris. With more and more user-generated content, being able to identify offensive images becomes increasingly important. Also, forensics and identifying stolen property are other applications of their technology.
Welchman Consulting (met through work). When I met folks at Welchman Consulting, I was immediately impressed by their knowledge and ability to articulate their ideas. I kept an eye on their site and contacted them when I saw a Senior Consultant job announcement. Their focus on Web Operations Management seems timely since so many large organizations now have moved into Content Management Systems but are facing quality/management issues.

Tools used and my subjective impression of their effectiveness in my job search (1 being totally unhelpful and 10 being a sure thing):

Blind inquiries to interesting people I found at various institutions: 2
Joined a couple relevant associations / special interest groups (not totally fair to include these since I didn't dive into actively participating in them!): 2
Blind sending in resumes through job boards like dice.com, theladders.com, simplyhired, etc: 4
Using linkedin.com to reach out to colleagues of colleagues at places I was interested in joining: 5
Sending blind resumes directly to organizations' job submission system: 6
Various talking directly with friends/colleagues/vendors/clients (good old networking): 8
Specialized mailing lists (such as Potomac Tech Wire and a non-profit CIO list): 8
Publishing this blog: 9

Talking about my job search with trusted friends, colleagues, vendors, and clients has found me most of my jobs. Perhaps that's the reason that specialized mailing lists are also helpful: you already know something about the person when they apply (or it would be easy to find out something about them in the small pool). I found starting and maintaining this blog helpful in the job search for a couple reasons: 1) it forced me to think about what it is that I know and am good at and 2) it was a very quick and easy way for potential employers to learn a little bit about my skills (although it is a surprising amount of work to maintain the blog).

Interaction Publisher: Mashup Editor Comparison / Roundup

hobbs — Tue, 29 Jan 2008 20:12:48 -0700

Since posting Enabling the Interaction Publisher, I've done some more research on mashup builders. I found a lot of excellent resources (see end of this post for a list), but felt that a summary of what's out there would be helpful (this is what I would have liked to see when I researched this). Although lists of tools exist, I wasn't getting a sense of the overall space. Note that I believe that mashup editors are only part of enabling the interaction publisher: the other parts being standardized access to data (particularly all data from one institution) and deeply embedding these types of tools in content management systems (for instance, using topic-driven templates already in your CMS to drive mashups that are driven by those topics).

Some of the particular variables that are probably most relevant in what tool you should use for your particular application / situation:

Is the expectation that you will quickly have a mashup, or that you are building out an infrastructure for your institution? Does this need to be behind your firewall? Do you need guaranteed uptime? Basically, do you need this to be hosted (quick and easy, get-me-started-now) or will you build out and manage the infrastructure?
Do you want the end result of your efforts to be another data feed, a map, or other types of user interactions like data grids? What should the output be?
What types of inputs do you need to pull: structured (if so, generic XML, or just RSS/atom specifically), unstructured (like web pages), or direct database connections?
How are the mashups built? Do you need totally non-technical people to create, or do you just need to support your power users? What is the mashup building environment for building the feeds (create-a-flowchart like Yahoo Pipes and Microsoft Popfly?)?
What are the browser requirements for people to use / consume your mashups (for instance Microsoft Popfly requires both Silverlight and recent versions of just Firefox and IE)?
Can a mashup be embedded into an existing web page? I didn't find enough useful information on this to fill this out meaningfully in the table below, so perhaps this is something to add in the future.

Although I was hoping to put together a fuller spreadsheet of all the tools out there, I selected a subset that was either easy to start using or had very clear documentation (I used all to at least some extent but AquaLogic Pages). At any rate, here's a brief (and admittedly incomplete) table comparing different mashup builders along the criteria listed above (please comment with any corrections/additions):

Mashup Builder	Hosted?	What outputs?	What inputs?	Building Environment	Browser Restrictions	Can be embedded?
Apatar	N/A (run from desktop)	A wide range including: RSS, Text, Salesforce, File, MySQL, Amazon S3	A wide range including: RSS, Text, Salesforce, File, MySQL, Amazon S3	Visually create a flowchart	N/A	No
AquaLogic Pages	No	Interactions: Data Table, Record List, Text, Map,	RSS, web services, user-created data	WYSIWYG	?	Partially? (only within BEA environment)
Dapper	Yes	Feeds: XML, RSS, HTML, JSON. Interactions: Google Gadgets, Google Maps (more)	web pages or RSS	Pointing at the parts of the screen you want scraped and/or filling in forms	Depends on output	Yes
Google Mashup Editor	Yes	Hosted web page (within GME environment)	RSS, GoogleBase, or user inputs	coding	?	No
Microsoft Popfly	Yes	Interactions: Gobs, although much of the focus seems to be on playful things like wak-a-mole	web pages, RSS	Visually create a flowchart	Silverlight + Firefox 2 or IE7 (!)
QEDWiki	Either (although install option didn't work for me)	Wiki pages	XML, RSS	WYSIWYG + filling out forms	?
StrikeIron SOA Express for Excel	Desktop (extension to Excel)	Excel sheet	Web Services, especially StrikeIron services	Excel	N/A	No
Yahoo! Pipes	Yes	Feeds + Interactions (Maps / Lists)	Feeds / CSV / some other specific web sources / limited generic XML (reference)	Visually create a flowchart	Didn't see official reference, but seems to run on Firefox 2.0, IE6, and Opera 9.24

I found the easiest to use were Apatar, StrikeIron SOA Express for Excel, and Yahoo! Pipes (if you just want to play with something to get a feel for mashup editors, I'd recommend starting with these), although each is entirely different. Although QEDwiki has a great intro video and appears to be able to do a lot, I got the least far actually using it. Although I'm sure that someone that knows Dapper inside and out could create a feed from scraping pages, in practice I didn't manage to get it to do the two tests I tried (for example, in trying to scrape country pages from the World Bank site, it wouldn't let me since the different pages were coming from different domains although they were driven from the same CMS). Popfly seemed interesting, but doesn't appear to be geared toward the enterprise and has very specific browser requirements. That said, these were just initial impressions (and initial ease of use may be irrelevant for a particular application) -- the main purpose of this post was to put together the matrix above just getting a feel for the current overall state / scope of mashup editors.

Here are some excellent resources on mashup editors:

Approaches to Exposing Institutional Data and Other Content

hobbs — Tue, 15 Jan 2008 20:56:56 -0700

I've been thinking about and researching how an institution can share its data, documents, and other content. Obviously your data and content is already exposed via the web, but providing the data in a more structured way allows more users (both internal and external) to manipulate the data in interesting ways, for example in mashups. There seem to be a few ways to share data from an enterprise with a lot of content:

Straight RSS/Atom. Although straight RSS/Atom (with no custom extensions / namespaces) may not be that interesting, it's obviously a useful way to get your content out there. Typically straight RSS/Atom is fairly time-based and might in effect show some history (news items like "John goes to work" and then "John goes home") rather than some state (like "John is now home").

Common repositories / services such as Swivel and StrikeIron. Rather than exposing your data/content directly to the outside world from your site/servers, you can use an intermediary. Swivel allows users to create their own graphs on fata from either official sources or any user-supplied data. StrikeIron is built into mashup editors like QEDwiki, and also has built an extension to Excel to call their services. You probably would want to provide data to these services through an API of your own, but you could get started with Swivel for example by directly uploading the data.
Specialized XML formats for particular types of content. Examples include OpenSearch for search results and SDMX for statistical data. These specific XML formats both allow a level of sophistication for people specializing in your type of content and allows tools built for this type of data to consume it. This fits in with the following item, which, for historical reasons may or may not be XML-based.
Institution-to-institution services. Sometimes you need to provide a point-to-point interface with another institution. In that case, you may need to support all sorts of unusual formats and delivery mechanisms. Hopefully you could leverage your various systems' web services to just transform the data into the formats you need.
A common API that your institution follows across all types of content. This one is the most interesting to me and one that I alluded to in my previous post on interaction publishing. Especially if your institution has various repositories, one possible approach would be to slap up a page that has links to the different instructions for referencing each. But, to make access as easy as possible, a common API with consistent parameters that can be queried against all systems would be preferable (for instance, queries such as "give me all your documents and data on Chad" via url requests like http://xml.example-domain.com/apis/type=docs,data&country=td). Potentially the returned XML could be in a simple format such as RSS extended with a custom namespace (so that other tools such as Yahoo Pipes, and even feedreaders, could easily consume the data).
Microformats. Probably most useful to future browsers or other tools like the Firefox Operator extension (or for services that crawl sites such as Google), microformats allow you to just change your existing HTML a bit to expose very common types of data like address and calendar events. For example, instead of your HTML having "100 Main Street, Anytown, USA" it would be marked up as "<div class="adr"> <div class="street-address">100 Main Street</div>, <span class="locality">Anytown</span>, <div class="country-name">USA</div></div>" and then define the CSS to show it as you wish. For example (with sloppy CSS):

100 Main Street

Anytown,

U.S.A.

See how this page appears in Firefox Operator (also notice the tagspaces):

Taxonomy Mappings: Be Careful When Integrating

hobbs — Thu, 10 Jan 2008 19:10:21 -0700

Sometimes you need to pull content from multiple systems into a single page, and you want to pull from both systems based on some metadata, perhaps by topic. For instance, let's say you have a site that you want to pull data from a document repository and a news archive, and you want the the user to use a pulldown to select the topic they want to filter the content by (for example, by "Politics", "Entertainment", "Travel", "Europe", and other topics). Sometimes out of the box the two systems will share the same list of topics, but more frequently than not they will not.

One deceptively simple approach when systems do not share the same list of topics is to have some sort of mapping between the taxonomies of the two systems (for instance, "Travel" = "Vacations", "Politics" = "Domestic Politics", "Europe" = "EU", etc). I fairly frequently hear something like this when discussing integration between different systems: "We have a mapping between these topics, so there shouldn't be any problem." But just because you have a mapping doesn't mean that it will be satisfactory for combining information from multiple systems. I thought it would be helpful to think through the issues some and write out some examples.

One taxonomy's controlled vocabulary being more specific than another

Let's say you've got some content in two systems that you want to pull into one page. Perhaps you want to find out all the fathers in both systems. If the taxonomies available were the following (and you didn't have other metadata on gender, for example), then you could not do this:

"Relationship" values site one	"Relationship" values on site two
Father	Parent
Mother
Sister	Sibling
Brother

A simple and meaningful mapping between the two would be something like this (allowing you to find all the people across systems that are a parent, for example):

Father or Mother - > Parent
Sister or Brother - > Sibling

Note that the other direction makes no sense (it's tough to be both a sister and brother, and you wouldn't know which to pick when translating between systems). So, although you may have a mapping between the systems, it does NOT neccessarily enable the types of queries you want to do.

A slightly more realistic example

Of course that was a simplified example to illustrate the point, and you usually have overlapping, something like the following (still a forced example though):

"Location" in system one	"Location" in system two
SF Bay Area
Palo Alto	Silicon Valley
(other cities in Silicon Valley)
Richmond	East Bay
(other cities in East Bay)
Sausalito	Marin County
(other cities in Marin County)
San Francisco	San Francisco
South San Francisco

Let's say these two systems had a selection of companies tagged to these controlled vocabularies. What kinds of queries would probably be meaningful?

All companies in Silicon Valley
All companies in East Bay
All companies in Marin County
All companies in the San Francisco Bay area

Obviously, you couldn't query on cities since system two has virtually no cities. But what about San Francisco? Isn't that on both lists? Although at first blush it may seem that you could find all companies in San Francisco across both systems, looking at the list more carefully it becomes apparent that they almost certainly have different meanings: the first taxonomy only has the broad San Francisco Bay Area and then cities, and the second taxonomy is just listing areas within the San Francisco Bay area. So San Fancisco in system 2 probably includes San Francisco proper as well as, for example, South San Francisco. So you can do this query (but *not* query on all companies in San Francisco):

All companies in San Francisco and the immediate area (including South San Francisco)

Part of the issue is that often you have much larger taxonomies that are more difficult to analyze (for example, for a taxonomy that includes all cities in California, or the US). It would be very difficult to go through and determine the meaning of the different values of the taxonomy.

What to do?

In practice, you probably won't be able to deeply analyze all the mappings between your systems, so you'll have a mapping but might only have a feel for how good it is (and in what direction). Perhaps the most dangerous mapping, and one that is hopefully fairly easy to identify, is from a more general taxonomy to a more specific one (the first example above) and should be avoided entirely. Of course if the systems do not even having taxonomies that are close, then this will be obvious and require changes to at least one of the source systems. The second example above (overlapping but not quite lining up) might a type of taxonomy matching that's not be that bad but just require documentation/labeling (just use "San Francisco and South San Francisco" in a pulldown to select areas of the Bay Area) and careful design (obviously don't allow the user to select a city if you need data from both systems, or you could clearly show in the results that the information is just from System 1). But figuring out the relationships between the taxonomies might take a lot of work. Some potential general approaches: be careful and a) where possible try to access globally well-understood and clear values (like zip codes, lat/long, ISO country codes, etc) rather than fall into the trap of just trying to use two taxonomies since they're called the same thing (this is probably easier in something like a location than a topic), b) force all systems to tag to a neutral reference source (this could, with a lot of work in defining rules, be automated with something like Teragram for example), or c) seek out a metadata expert since they have some best practices of mapping between flat or networked taxonomies. Also, when you are designing a system in the first place (even before being faced with a new integration), try if possible to use metadata for your content to well-understood values (especially easy for geographic tagging).

Interesting 2007 and Opportunities for 2008

hobbs — Fri, 04 Jan 2008 07:39:27 -0700

The following seemed noteworthy and interesting enough in 2007 to highlight (although most were not new in 2007):

APIs and Mashups.Ever since the Google Maps API came out, web APIs appeared to have a lot of promise. This year this really seemed to take off, with more sites publishing APIs (see Programmable Web's list, although Programmable Web also notes that almost 50% of mashups are using Google Maps) and richer tools for using/mashing them (see Yahoo Pipes, Microsoft Popfly).
Microformats. What a great idea: instead of waiting for a grand unified theory of the semantic web to totally transform websites, just make small changes to your existing markup to describe common, high-value information like locations and contact information. References: the book, microformats.org, wikipedia page on semantic web, the firefox Operator and Piggy Bank extensions, Can your website be your API?,and Bill Gates talking about microformats.
Drupal. Drupal drives this site, and I have been especially impressed by its clean architecture for adding new features/modules and by the strong community supporting it (hence the clean as well as powerful out-of-the-box experience). I wasn't as impressed when I briefly played with Drupal a year or two ago, so I sense that Drupal really now has a critical mass behind it. References: my post about my first month using Drupal, the Drupal development book, and drupal.org.
Sophisticated analytics for the masses. Although tools like Omniture SiteCatalyst are still more sophisticated and customizable, Google Analytics is really amazing, especially for a free tool: very nice user interface, sensible defaults, campaign tracking, user-defined dashboards, good reverse DNS lookup, and fast. See the Analytics Talk blog for more on Google Analytics.

I also see a lot of opportunities for improvement in 2008:

Continued performance improvements. Ajax and more widespread javascript (such as pulldown/popup menus rather than having whole new pages load for many menus) has helped many sites speed up, but let's face it, in general using web sites is fairly slow. One example site that's particularly slow in the UI is Rhapsody, which I use every day but the performance has just got to improve (an aside: basic cellphone call quality still isn't at acceptable performance levels in my opinion, but they keep improving year by year). Hopefully Adobe AIR (previously Apollo) or some other runtime environment like it will help deploy applications that interact directly with local files and with less server trips for a dramatically faster experience for our usrs. Also see Yahoo's Exceptional Performance resources for ways to speed up existing pages.
More sophisticated offshoring models. The naive view of offshoring goes something like this: if someone costs $X per hour in your country and $X/3 per hour in another country, then it would seem to obvious to give the work to the offshore resource. Sometimes this works. Highly repeatable tasks are the most obvious (for example call centers). Also, it often works when you can hand off a specifications document and then wait for the implementation, although this Wall Street Journal article (subscription required) on the outsourcing problems of the 787 points out interesting issues there too: like your outsources suppliers outsourcing to their own suppliers, quality control/process issues, and taking for granted expertise/background built inside Boeing when handing off to suppliers. If the task isn't highly repeatable or very tightly specified, then the overhead of communications/management is very high. I would also expect that places that are currently considered "offshore" will be developing innovative products themselves (see this blog post: State of Innovation in India).
Improvements in single sign on and passwords. If I go to Amazon and then B&H now, I have to log on twice. Worse, if I go to very small sites I have to create a separate username/password (it's one thing to trust Amazon with my password, but why should I trust a very small site with that information?). I plan on adding OpenID for accounts on to this site, and I would encourage others to add it to theirs (many platforms such as Drupal now support this). OpenID allows the user to decide who they trust to keep/authorize their account information (notably password) and you chose what information to give to different sites. Once you log in once, you don't need to provide your password again when you go to a site using OpenID. Hopefully at least smaller sites will start adopting OpenID, but it would be great if this was adopted by larger players as well. I'm still hoping for a replacement of passwords entirely, perhaps by graphical methods, (how archaic is remembering a bunch of passwords, or, worse, if you force users to use "strong" passwords and change them a lot, then they'll just write them down?), but at least reducing the number of accounts you have would help.
Mashup building for the masses. Although APIs and mashups have taken a big stride forward, I hope to see some standardization in APIs and enhanced mashup editors that allow less technical people to create their own interesting (not only with maps!) mashups. See my Enabling the Interaction Publisher post.

Link Repository: Structured Link Checking

hobbs — Wed, 19 Dec 2007 18:25:39 -0700

Especially as a content management system grows to have a large amount of content, it would be nice if you could do structured link checking. One of the problems with link checking in general is what to do with the reports once you get them. Of course, for a very small site you can easily scan an entire site with tools like LinkScan ($) and Xenu Linksleuth (free, but ads are put in the reports) or even monitor 404 requests and use single page tools like the LinkChecker Firefox extension. But with large sites you can end up with reports that are hard to know where to even start fixing links. This is especially true for CMS-driven sites: the same bad link may appear in only one piece of content that is displayed throughout the site. Or you could wind up linking from lots of content items to a url (possibly outside your control) that changes.

I envision getting a report with a list of the bad links, where a user (with appropriate global rights) could indicate the correct new link which would get reflected in all content items (or left menus or other components surrounding the content) that used that link. This list could be prioritized by the cumulative page views that contained that bad link, or by the number of pages that contained that link. Another approach might be to provide a prioritized list of content items that have bad links (preferably directly linkable to edit mode of that content item. At any rate, note that we're not talking about pages here but content items or links -- the user can quickly take action that will correct links on multiple pages. A long list of pages (specific urls) with bad links are confusing, but, more importantly, aren't as quickly actionable.

Here is how normal link checking reports look and how more useful reports might look:

Before / Existing Reports (where do you start with a report like this, where content items may drive multiple pages?)

Report indicating bad links where the user can immediately correct them (and apply the correction everywhere)

Report indicating which content items have the bad links(content items linkable to edit them directly)

http://badlinkone.com is referenced on http://example-site.com/page1, http://example-site.com/page35, and http://example-site.com/page102
http://badlinktwo.com is referenced on http://example-site.com/page1, http://example-site.com/page1023, http://example-site.com/page2439, http://example-site.com/page5192

Etc.

http://badlinkone.com is bad. Change everywhere now.
http://badlinktwo.com is bad. Change everywhere now.

Etc.

Bad link http://badlinkone.com is referenced on Content32 and Content507.
Bad link http://badlinketwo.com is referenced on Content32 and Content209.

Etc.

One possible way to implement this is to change all the urls into some logical link in your CMS. Assuming your CMS stores straight HTML rather than a more structured format, then any url the user enters could be changed to a macro (if the user could put in a hard link directly into the HTML without the system changing it, even if there was an option for creating a logical link, most users would probably just skip the logic linking). For example if the user put in this HTML:

<a href="http://hobbsontech.com>Hobbs On Tech</a> then the system would replace it with !link(123,"Hobbs On Tech")and put in its link repository that link 123 was http://hobbsontech.com. When the page was generated then the correct link could be replaced in the HTML (so of course the end user's browser should never see the "123" in the HTML). If the page linked to was in your CMS, then the macro could be different and just indicate the unique key for the content item being pointed to (this would depend on whether the context that the content appeared in was relevant). For example: !cms_item(123,"Hobbs On Tech")

Related items that a link repository might help with:

Reporting on content use. A link repository would allow other interesting reporting, such as the most linked-to content items in your repository.
Easily move content. In some cases, it may be easier to move content if you had a link repository. For instance, you may sometimes need to restructure your site resulting in the links changing. With a link repository, you could automatically change all the links so that the move did not result in broken links (of course this would work best for intranet sites where there were limited links outside your control to your content).

Of course, this would add complexity (and possible failure points) to a CMS. Do you think it would be worth it?

Enabling the Interaction Publisher

hobbs — Tue, 11 Dec 2007 22:34:10 -0700

New sites with dynamic, interactive functionality using data from different sources and allowing the user to interact with the data are exciting to see (examples: geo.worldbank.org and carma.org). But how do we unleash this functionality so that non-programmers can create interaction like this? We have content management systems that allow more people to easily add content to sites. But I think we should be driving toward an environment where users can a) take data from a variety of sources and b) create interactive sites based on this data. Maps are the most prominent example, but interactive tables are also important. Let's review where we are now:

We have sites already applying Google maps and other interactive functionality to various data sources (examples above).
Programmers have resources/examples/documentation for creating these types of sites (see Programmable Web for example).
Various APIs have been exposed for interacting and using data (examples).
We have tools like Yahoo Pipes that allow advanced users (probably not needing full-blown programmer skills) to create mashups. That said Yahoo Pipes is now focused on consuming/dealing with RSS feeds (the Fetch Data Module is supposed to more general XML, I had problems getting it to do so -- if you look at examples using DC crime data, you see it's RSS with some customization). In addition, this is a hosted solution, so you're at the mercy of Yahoo if you host a mashup with them (I noted Yahoo Pipes having problems accessing feeds intermittently even in my brief testing).
There are probably other similar examples of specialized tools, but I know of Swivel, which allows you to create your own graphs of data.

Here are the types of interactive functionality that I think we should be allowing non-programmers (let's call these folks "Interaction Publisher", riffing off the role of "Content Publisher") to create:

Interactive data tables. Interaction Publisher should be able to point at one (or multiple) data source, and indicate which columns/attributes to display in a table. The Interaction Publisher should also indicate which attributes should be selectable (in pulldowns for example) be the end user. Of course some theming / design and annotation should be possible.
Interactive maps. Interaction Publisher should be able to point at a data source, the attributes containing the locations, and what data to show for each location (along with the extent of the default map and formatting). Also, please can we get rid of the points / waypoints / circles that indicate arbitrary points that are used to indicate data for a large area (for example, a pointer to the capital for a country), and instead highlight the whole area (for example, the whole country). Ideally the Interaction Publisher will be able to indicate further interaction with the map (for example, displaying different layers of a map -- if not full-blown layers, then at least indicating different sets of waypoints to display).
Custom data. The Interaction Publisher should also be able to easily publish their own data/content, and pull their data into an interactive feature (for instance, this could even be a simple search on a little database / resource center the user has). An extension of this would be including some mechanism for overriding other data sources data points (of course this should somehow be indicated on the map/table so it isn't misleading).
Wizard-like functionality. The Interaction Publisher should not have to resort to XPATH, XSL, or programming in PHP / Perl / whatever.

Sounds nice -- but how would this be possible? One possible step is for institutions to expose their data in a consistent manner (at least each institution exposing its own data in consistently). This would involve something of a meta-API, where you are consistent about:

Attributes that can be queried. Perhaps the list would be just topics and countries, for example. The topics lists should be something that the outside world will understand rather than an organization-centric list. If you have multiple topics lists, then it would be preferable if all systems were moved to a single topics list (even if that meant two topics lists per system).
Simplicity and consistency in APIs. Perhaps all your XML APIs are at http://xml.example-domain.com/apis/ (with an html page just listing all the APIs there) and then APIs to different systems like http://xml.example-domain.com/api/documents and http://xml.example-domain.com/api/web with example calls like http://xml.example-domain.com/api/web/api-version=1&topic=agriculture.
Consistent exposure of non-standard attributes. The issue of consistent query parameters was covered above -- this means that all systems are queried on the same parameters. But of course some systems will need to provide other attributes (such as, say, "Population"). This could be done in a custom namespace in RSS as the DC crime data (see xml) does in its Atom feed (which Yahoo Pipes, for example, can consume). This could be documented, and the consumer of the data could handle this.
Custom databases would also preferably comply. Perhaps there could be an http://xml.example-domain.com/api/core/ for institutionally, centrally supported repositories and http://xml.example-domain.com/api/special/ for one-off databases. This would still allow easy access of data by Interaction Publishers.

Some potential ways of inching toward the goal of the non-developer Interaction Designer easily being able to publish dynamic, interactive features would be:

Start by using javascript libraries. There are several javascript libraries out there (examples: Dojo, mootools, Prototype / Scriptalicious), but most seem to be too low-level (concentrating on opening/closing panels, transitions, and the like) to be useful for interactive data features. Possibly a library that has higher level features including interactive table such as EXT JS could be used as a first step. It would require touching some code, but perhaps a CMS, for example, could include in its documentation with code snippets indicating what needs to be replaced (for example, where to put in the url to the source XML).
Create some simple wizards in CMSes. So that we aren't relying on, for example, Yahoo Pipes for hosting our interaction, we may wish to start including simple wizards in our CMSes. For example, one could be for interactive tables that just had one data source and three columns.
Push for stronger hosted interactive feature builders. For example, Yahoo Pipes perhaps could include some of the features mentioned in this email (for example, a tool for creating interactive maps, or a tool for creating a pulldown of options to drive a Google map.

Here's a little chart displaying some of the ideas in this post (also see pdf version):

I'd really like your comments on this post. Specifically:

Is the role of Interaction Publisher important?
How could we enable this role?
What ideas above do you think would work and which would not work?
Is their a need for a separate generic standard XML from RSS feeds, or should an institution's RSS just be extended to include custom portions?

Selecting a Content Management System (CMS)

hobbs — Mon, 10 Dec 2007 10:27:04 -0700

There are already various sites comparing features of content management systems (for example the CMS matrix), so this post aims to help set a framework for selecting a Content Management System (CMS). Aside from standard things to keep in mind when selecting a technology, there are some particularly important items for setting the tone of your CMS selection:

Standardization / Governance. Is one of your objectives to standardize the look and feel of your site, or to try to ensure there's a consistent quality across your site? If so, then before you start moving into the new system then deciding who will make the decision of what goes up and how the decisions will get made is important. Sure, an advantage of a CMS is that anyone can publish, but this can lead to inconsistent quality. I'm not just talking about how workflow: for instance, who makes the call about adding a whole new site section?
Stakeholder buy-in of objectives. This one is of course part of any technology decision, but some key factors in deciding about a CMS are: a) if you've decided to standardize aspects of your site, make sure everyone is bought in (otherwise people will try whatever they can to get out of the standard), b) if people's jobs are going to change (for instance, people that are doing hands-on HTML coding may not be doing that anymore), then is everyone clear on this?
Envision key use cases. After you're in the middle of migrating your content/systems, you may lose sight of why you undertook this in the first place. Laying out key use cases in advance allows you to both not loose sight of the goals and also let's you more easily claim victory. Key use cases might be something like "Will be able to allow any staff member to publish a piece of content, resulting in it automatically appearing on the home page as well as the relevant country page, and also appears in country's RSS feed and email alerts". Of course, you also should list key use cases that you don't want to go away like "Compare statistics across different areas of the site in a consistent manner."
Make sure everyone understands the complexity of a move to a new system. See this post that lists some of the complexity.

These are some of the particular factors to consider when selecting a CMS:

Tagging. For a large institution, you may have issues keeping consistent quality in your tagging (and you may wish to consider an automated concept extraction tool to help in the tagging). At any rate, you will want to think about a method of tagging that will work for everyone (and ensure that your system will support this).
multilingual/internationalization support. See this page that describes different levels of multilingual support. Some more advanced types of features to consider are Administrative Title and Interleaving Languages.
distributed or centralized content entry input. This relates to the issue of standardization above.
community/support.
multiple site support. If you need to have multiple sites, what kind of functionality do you need? For instance, does content need to flow between sites? Do the different sites need to enforce a consistent look/brand?
integration with other systems or all-in-one. A key decision will be how you are going to integrate with other systems, and, if integration is not as important (for instance for a smaller organization), then ensure that your solution supports the different functionalities you need.

With everything on the web moving so fast now (who knows when Web 3.0 will be the next thing we're all moving to), consider moving to a CMS environment that will allow quick innovation and new functionality. Some specific approaches to this:

Try to pick a CMS that is innovating quickly. Of course, what you really want is to pick what CMS will be a winner in the future, but the best we can do now is pick a CMS that is quickly adding new features. Looking at lists like Joomla's extensions page for any CMS that you're interested in should help with this. Of course, it needs to be easy to add any new modules/extensions when they are released.
ease of upgrading to new versions of the core CMS. Obviously hosted, SaaS solutions have an advantage here.
ease of writing your own new functionality. Would the CMS allow your team to program (in some lightweight language like PHP for example) their own new functionality? If you don't have the skillset, is there a pool of developers outside your organization who could help? Is there useful documentation on how to write your own new functionality?
support to expose/share data. We have RSS as a mainstream feed now, but what about richer XML exposed for more structured data? More and more, we'll need to support people outside our organizations utilizing our content/data to write functionality on their own sites, combining your data with other organizations' data.
integration with outside systems. If a CMS already has integration with other types of systems (for instance, stats, newsletters, email alerts, membership databases, etc), then it may be easier to move to future leaders in these different spaces.

Why It's Hard to Migrate Content

hobbs — Sat, 08 Dec 2007 13:06:46 -0700

You know when it's time to move into a new house or apartment, when you look at the stuff you need to move and think "Why in the world do I have this bread machine? I haven't used this in years and I forgot I even had it." Or you dread moving your old clunker of a TV, thinking of the new fancy flat-panel TVs? Well, it's the same thing with migrating to a new system, for instance into a new content management system. Only it's harder. When you're moving and you're pressed for time, you may just start tossing stuff into boxes to be moved, even when you know you don't totally want all the stuff (one reason: you'll need to negotiate with a spouse about getting rid of something, and there's no time for that). This isn't that big a deal, since it's just moving more of the same stuff. Or, if you have a huge sectional couch that won't fit in your new place, then perhaps you can just sell it to the next homeowner. When you're moving content, you have all sorts of extra things to think about including:

It's not just content. Content on a site doesn't just live in some abstract ether, but it is linked into a larger site context. This includes left navigation, headers, footers, and special site behaviors. Of course moving the site context of a simple site like hobbsontech.com would be relatively easy to move (re-creating the the menus, configuring the overall style, etc), but the more sites you have, the more there would be to do. This is especially relevant for sites with a lot of custom dynamic functionality. For instance, if you have comments on your current site's content, then you'd have to figure out how to embed it in the new framework (or just leave it behind). Chances are you have a lot of functionality distributed throughout your site that may even be hard to inventory.
Metadata and taxonomies. You may have to re-create taxonomies in another system, and there may be incompatabilities you have to work through.
Internal references to other pieces of content. Your content probably refers to itself (for instance, a press release may refer to your product description page). This somehow has to be reflected in a new system.
Structured content. You may have structured content (for instance, a document that has multiple chapters), which you'll need to figure out how to handle in the new system.
Outside references to your content. Other sites, as well as search engines, will have links to your content. You'll need to have some strategy to deal with the links from external sites.

In the end, a lot of this has to do with the web of information that's involved in the content of a web site. And this isn't counting the types of technical issues that would come up with any technical migration (differences in size limits for fields, encoding differences, etc.). Of course there's the issue of why you even have all this stuff to move in the first place (and the more stuff you have the more hassle it is to move). This blog entry has focused on why it's difficult to move all this content, but of course one of the morals of the story is to have less stuff in the first place. In the case of the web this would involve better governance of what goes on the web, and clearly defining what the focus of your web site should be. Hopefully, just like when moving houses, any discussion of moving content would also include discussing what stuff you need in the first place. Unlike houses, having extra or duplicate stuff doesn't just inconvenience you but it is a disservice to your users. I'll leave the issue of the old TV and desiring the new flat panel to a future post (on survivorship bias).

Standardization and Large Web Sites

hobbs — Sun, 02 Dec 2007 19:52:16 -0700

Very large sites supporting a large number of units/stakeholders can easily turn into a hodge-podge of styles, user interface elements, and quality. One of the toughest discussions with clients, however, is why they can't do more customization (even if one of the core requirements of the system is to help enforce standardization). What are some of the reasons *not* to standardize:

specific business needs of different groups (not to be confused with a group just wanting to differentiate itself somehow, for instance with a different look, that does not help the web visitor at all)
professional development (for instance a developer might be interesting to do a mashup)
personal expression (liking particular colors for example)
experimentation (don't know in advance what's going to "stick," so try a variety of things)

In my opinion, the first and last reasons are the most compelling (and the third not being a good reason at all for an enterprise-wide system), although one of the problems with experimentation is the frequent expectation that an experiment could quickly be rolled into the normal standardized platform (that's probably a post on its own!). Here are some reasons *to* standardize:

consistent brand for the user ("am I still on the same site? Is this high quality content?")
consistent UI for the user ("do I know how to use the site?")
better support for new site admins or transition of support between sites
single sign-on. It's confusing for a user to have various accounts with the same institution.
standard statistics. Different statistics packages can have entirely different ways of counting something as basic as a page view. Standardizing no a statistics package can help ensure you're comparing apples to apples in your web analysis.
better search. If everyone does their own thing, then there may be more fragmented information which would mean search results aren't as good.
stability / support. As anyone who works with software/systems knows, the more functionality or special customization you put into a system, the more effort it takes to maintain it. Also, the system will probably be less stable. This one is also very tough to discuss with a client (and another probable future blog post) since they tend to only see their particular need.

Some possible methods of standardization:

Governance. There needs to be a group with the power and influence to say "no" to requests that undermine the quality of the user experience of the site at large. This ideally is not the technology group since there would appear to be a conflict of interest.
Clearly define exactly what is inside the standard and what is outside.
Technology. The content management system used to manage the site can be set up such that users can only make changes that comply with the standard.
The right level of customization. Standardization shouldn't be an excuse to totally control every aspect of everyone's sites or to not allow any innovation.
Hooks into core shared functionalty. You may decide that a single sign on for users of your site is desirable. If so, then perhaps the system could be set up with an API such that tools developed and commissioned by other groups could work with the core functionality.
Standardized access to data. Ideally, you could define a standard method of each system exposing its core data, that even people outside the institution could utilize for mashups, etc. By providing the data in a simple XML API, this could facilitate both internal and external usage of data.
Another potential approach is to have separate branding for the official, blessed content and for the organization-centric content. For instance, you may have multiple units in your institution all looking at the topic of taxes. Ideally you would have one official web site that makes sense of your institution's view of taxes overall, and preferably this would pull information from all the units. The various units still may want their own site, but this is less useful for the end user -- so perhaps these units could have their own sites branded differently (and perhaps all requiring a standard link back to the official site) to clearly indicate it is the view of a particular unit with your institution.

Of course, all of these are easier said than done when trying to get a large number of units into the same system, but perhaps some of these could be initiated even after a large suite of sites have been implemented in a central content management system.

Search Engine Optimization Basics

hobbs — Sun, 02 Dec 2007 06:11:50 -0700

This post doesn't attempt to cover more obscure aspects of search engine optimization (SEO), but covers the basics that are really easy to overlook when you work on your site. Also, since Google is the major search player, I just refer to "Google" rather than trying to be more generic.

Step 0: Has Google indexed your site at all?

Go to google.com and do a search on site:your-site-name-here, like "site:http://bhphotovideo.com" to see if byphotovideo.com is indexed by Google. If there are no results, you're not indexed. Some ideas to get indexed: a) put in links from sites / pages you already have (for example, your profile on linkedin.com), b) get other sites to link to you (for example, you can comment on other peoples' blogs linking to your site), c) for blogs, use pingomatic to automatically update other services of your site, and d) submit your site to Google for indexing (not sure that actually does anything though?).

Step 1: What are you trying to accomplish?

This one sounds so obvious and silly, but it's very easy to overlook. It's useful to just write down the search phrases you'd like to find your site. Of course the more specific the better, since generic terms will be very difficult to get high rankings on. For example, I knew I wanted people to find this site if they typed my name and a little about me (for example, "David Hobbs CMS").

Step 2: Make sure your keywords are in the title and header tags, as well as in the text users will see (and preferably in the domain and url)

You may not have control over the domain and url (if you are in some content management systems), but you should at least make sure to have the title, header, and main text contain your terms.

Step 3: Track your progress.

Type your search terms into Google and see how high in the rankings you appear. If you have already gotten good results (first page of results?), it may be time to set your goals higher. For instance, for this site I'm now interested in shooting for more topic-based search phrases such as "multilingual CMS" (currently the 14th page of results). Also, you will want to look for dips in the performance of your search phrases. This is especially relevant to test before and after any changes you make to your site/system. If you're working with a client on their site, by having the metrics (and search goals) before you start you'll be able to more objectively discuss the search performance of their site. Another angle is to look at the terms that people are using to actually find your site. You may find interest in your site from unexpected angles that you may wish to further enhance (for instance, people are finding my site with phrases such as "annotate excel graph", so I may put a more generic introduction to that blog entry).

Repeat.

The first step, to get into the Google index at all, involved getting links to your site. As you proceed, of course you also want to have higher and higher quality sites link to you. As mentioned in the previous step, your search goals will also probably change, and you'll want to add/reword/reconfigure portions of your site (per Step 2 above) to optimize for those new goals.

Drupal after a Month

hobbs — Sat, 01 Dec 2007 20:40:03 -0700

Now that I've been using Drupal for a month (Drupal is driving this site), I thought it would be a good time to write up my impressions of this open source CMS. Obviously this is before I know the tool in depth, and also before I become jaded or a zealot. For reference, over the past seven years I've worked with a couple custom CMS systems, both driving very large and small web sites, and I also have used Wordpress (not a CMS) for two other personal blogs. Also, my emphasis using Drupal for this site has been as a blog so I haven't fully explored all the CMS features. I really like Drupal for many reasons including:

Very easy to add features to a site. You download a module, set some parameters, and then you have a new feature (instructions). Examples of useful features that I've added easily to this site: feedburner redirects (Feedburner module), CAPTCHA checking for form submission to block robots (CAPTCHA module), email forwarding posts (Forward module), SEO and human-friendly urls (pathauto module), links to digg and other services (Service Links module), and full name listing as author for blog posts (Authorship module). That's not counting the really useful core modules that I've enabled for the site like the ability to pull in / aggregate other feeds (Aggregator module), comments (Comments module), automatically pinging services such as Technorati (Ping module), search (Search module), some web access statistics (Statistics module), the ability to create different taxonomies/categorizations (Taxonomy module), and the ability to automatically have features of the site turned off under high load (Throttle module).
Built-in performance and throttling. You can set how aggressively you cache, and selectively set which features get turned off under higher load.
Upcoming features. Since Drupal has gained some momentum, one feels the inevitability of new features being added as time goes on. Also, since it looks to be easy to add new modules, you could add a module yourself if you wanted.
Nice modularization. I haven't read the documentation on how to develop modules, but, just seeing how modules work when installing them, the pluggability of modules seems very nice. Once installed/enabled, modules aren't just stovepipes. For example, when in admin mode the CAPTCHA module shows a message next to every form on your site asking if you want CAPTCHA there. Also, it appears that modules can easily write to the log screen, and are all controlled from the same core administration screen. When writing a post, the different options are embedded right on one page (for instance, the pathauto module automatically indicates, and lets you override, the alias it plans on giving your post).
Flexible themes. I'm using the Garland theme, and I liked how you can set your own colors and other things are parameterized like your logo.
Multiple taxonomies. You can create easily create your own category lists.

Perhaps above everything else, it just seems that the details have been done very nicely in Drupal. Overall a site in Drupal appears to be easy to administer. These are some items that weren't as smooth: a) didn't get the Backup module to work quickly enough (was faster just to use scripts to do it rather than get the module to work), b) still don't fully understand the file upload/download environment (especially for counting the downloads), c) by default you're in raw html editing (yes, you can install a web-based HTML editor, but the ones I tried so far don't seem very useful), and d) getting the transparent logo needed for the Garland theme working quickly. A note to people currently working in a large, complex enterprise content management environment: I highly recommend playing with Drupal to get the creative juices flowing and also to work in a less constrained environment. Also, it's nice to work from a clean slate on a new site (although I've already bumped into a place where I wish I had set up the site differently in the first place). But of course working in an enterprise environment has a host of other requirements that have to be dealt with (for example standardized look across sites, security, single sign on, integration with internal repositories, existing systems, and standardized administration).

Client-centric metrics

hobbs — Wed, 28 Nov 2007 21:45:45 -0700

Here's an example of a practically-meaningless statistic from a user's perspective (this is from a free version of a monitoring service by host-tracker.com checking hobbsontech.com, I believe for a valid HTTP response, every thirty minutes since November 21st):

Straight off, let me say that for troubleshooting this is useful. If someone tells me they couldn't get to this site at noon yesterday, I can quickly check to see if the site was totally down for long enough that the monitoring would catch this. In a more sophisticated environment, one can quickly check to see if a particular server in a cluster, for example, is bad and needs to be dealt with or taken offline. But this kind of metric shouldn't be confused with client-centric metrics, and you should try setting your sights on statistics that come closer to the user experience. Some key things to keep in mind when defining client-centric metrics:

Don't use averages. Users don't think in terms of averages, but in extremes (for instance, "yesterday I saw a page with outdated content"). So, your goals should be in terms like "page loads in less than five seconds within institution's firewall 99% of the time, and within 10 seconds 99.99% of the time." Note that all those 9's in the example above are not about simple uptime, but a percentage of time that a metric is met. Also see Amazon's CTO's description of measuring at higher percentiles (one reason he gives is to ensure high value clients with more complicated, personalized pages, have good response times).
Don't use planned maintenance windows as an excuse. Service downtime experienced during maintenance windows should be calculated as downtime. Of course, planned maintenance is still important, since you can warn your users of downtime (and you can hopefully pick times that are lower-impact). But it's still downtime. Of course, if a server is down but the service is still available, then you shouldn't ding yourself in your client-centric metrics (and you should congratulate yourself in doing things in a way that allows downtime of server(s) without downtime of the service).
Try to base your metrics on the way a user experiences your system. This will usually involve more sophisticated analysis of responses from the server(s). For example, don't just check for a successful HTTP response from the server (for example, I could create a page that returns a successful HTTP return code but says "This site is down for maintenance"), but check that the page has a valid left navigation, header, and piece of content(s) (perhaps using screen scraping techniques). Also, aside from a troubleshooting technique, don't consider server time for generating pages, but the time a user would actually experience in downloading a page (including pulling in all the components of the page, and, if possible, the time to compute/render a page). If you cache your pages, don't get too hung up on the performance of just cached pages (the end user won't know if it's a cached or dynamic page they are getting, so your metric has to consider the dynamic pages as well). Another example of client-centric metrics for a large system with a suite of sites: length of time between content publishing and appearance in all relevant pages.

But probably most important is to identify client-centric metrics as early as possible, and create a method of tracking these. If possible, you could install a large display outside a manager's office with the metrics in red when you aren't meeting the goals. Here's a table listing some example before/after types of client-centric metrics:

Not client-centric	More client-centric
Excluding maintenance windows, the server uptime this last week was 99.9%	99.7% of all pages in the last week loaded completely (good header, footer, and content area)
Excluding maintenance windows, 99.9% of all pages were generated within 1 second by the server	99.1% of all pages in the last week loaded within 5 seconds inside our firewall
1,000 content items were published yesterday	The 1,000 content items published yesterday appeared on all relevant pages within 30 minutes 99.9% of the time.

Administrative Title

hobbs — Mon, 26 Nov 2007 20:35:38 -0700

If you don't speak Thai and get a message like "the Thai news page is totally bonkers," you won't be able to help troubleshoot very easily since it may be difficult to even *find* that page. If you have multiple timezones that you're dealing with, you could waste time getting clarifications/etc about which page it is they are talking about (of course a url + screenshot + indication of exactly what's wrong would be great in the first place, but upset users often don't send this level of detail). Being able to search the Thai site in the backend on "news" may allow you to quickly find that content/page for troubleshooting. If you have a large site with lots of languages, you may have one common language that all of the institution's staff knows. For instance, English might be the institutional working language. In that case, it might be best to always require an English title in addition to the actual title of a piece of content. Of course, if you *always* had an English version of every piece of content, then you could just use that English version for back end administration. But chances are you will have content that is *just* in a non-English piece of content. In that case, having all non-English content tagged with an English title could be helpful (which could automatically get set to the existing title of the English version of the content if the English version exists). Also, you should probably decide early on if you're going to have other backend features in English or in the different languages. For example, if you have a common institutional working language, then you should probably have all the names of the sites in the administrative backend in *English* in addition to the site's actual title in the site's language.

Responding to urgent user issues

hobbs — Tue, 20 Nov 2007 15:40:14 -0700

In any system that's actually used (!), you're going to get user reports of problems that need fast response such as access issues (as oppossed to enhancement or bug fix requests). Unfortunately, a common and very difficult type of problem is an intermittent issue or one that you cannot reproduce. That said, even in that case, here are some rules of thumb in responding to a user report:

Identify whether or not you saw the problem (and never, ever, just close a ticket just because you don't see the issue -- at a minimum contact the user first *before* declaring something couldn't be reproduced).
If you cannot reproduce the problem, then try to walk through the exact steps with the user on your desktop (or by sharing their desktop). Of course, the user may resist this since they're already frustrated if they contacted you. But as we all know a problem may only occur in a very specific situation (that you never do), although it may be the *only* way that particular user does things (so the user feels this always happens). Of course, if there is another way of doing the same thing, then suggest a workaround.
Clearly indicate if you *did* something for the problem to go away.
Ask for confirmation that the *user* thinks the issue is resolved (this one is important but easy to overlook).
Make it clear that the user can get back to you with any follow-up questions.

An example response that isn't very useful to a user: "Try now" and nothing more (the user doesn't know if you did anything, and they might think you don't believe anything was wrong in the first place).

Screen Scraping

hobbs — Sat, 17 Nov 2007 22:08:55 -0700

This may not seem very Web 2.0 (O'Reilly wrote web services is 2.0 but screen scraping is 1.0), but I think there are a variety of reasons that screen scraping is still helpful, including:

Need to be closer to what the user sees
Don't have access directly to the database or a web service that will provide you the information you need (or you won't have access soon enough)

For example:

Testing whether your web pages are looking the way you expect. Sometimes testing this from the back end just isn't going to cut it, and you need to analyze the HTML to see if the page looks reasonable.
Writing a report that doesn't already exist on top of some reporting tool (for instance, on top of a defect-tracking system that you don't have access to the code for).
Creating archived versions of sites. Sometimes using HTTRACK, for example, isn't enough on its own (for example, when you need to pull in full-sized videos from the source system as oppossed to the streamed version on the web). Also, you can use Perl to wrap around HTTRACK so that you have a standard way of passing options to HTTRACK.
Seeing which of a large set of your sites are indexed in Google.
Testing your RSS feeds to determine if they have the right number of content items, etc (I guess this would be more "RSS scraping" than screen scraping).
Importing from a static site to a CMS (less and less commonly needed nowadays).

Often, if there's a direct DB connection or an RSS feed or some other XML interface that you can use, then it probably makes sense to use that. Even in that case, the archiving and web page testing cases would probably benefit from screen scraping.