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.

 

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," _fcksavedurl="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?

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?

 

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.

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).