Home | Priorities | Giving | Council | Alumni Efforts | Foundation Challenge

You might be able to guess that this is the main navigation for an alumni site of some school. But aside from Home, can you formulate a clear idea of where any of these links will lead?

Supposing your goal is to join this institution’s alumni association. Which of these links would you follow first? Would you follow any at all? And what exactly is a Foundation Challenge, anyway?

You see this all over the Web: critical navigation distilled down to as few words as possible–preferably a single word. Design teams hold meetings in which everyone struggles to come up with the right word to describe a category of activities, a diverse collection of information, a whole branch of services. It’s mind-numbing work, and for a good reason: few single- or two-word descriptions are up to the job. The result is navigation written in a sort of cryptograph that’s maybe understandable to people within the organization but that users must decode by pogosticking all around the site.

This overcondensation of information started with the earliest table-based Web designs, the going mindset at the time being

1. the zeal to keep page dimensions small enough to be seen in their entirety on very small computer screens
2. the assumption that users are never willing scroll under any conditions

The accepted practice was to design Web sites roughly as squares about 600 pixels to a side. Navigation was encased in minute rectangles, stacked in attenuated columns, or paired with distracting and largely useless graphical buttons. Sites of any volume frequently had architectures many layers deep to accommodate the brief amount of signage available in each section.

Eventually, better equipped and more informed Web design delivered us from these claustrophobic dimensions. But the wording of links seems to be slow in recovering. Navigation still frequently gets squinched into little bitty wafers. One of the worst offenders of this is the nearly universal horizontal top navigation sandwiched just below page banners or conflated with the banner design itself. Aside from often falling prey to banner blindness, this type of navigation frequently allows for nothing but the briefest of signage.

Contrast this with the findings of Jared Spool et. al., which show that links of around 7-12 words are far more successful at creating a strong scent of information. This wording can, and often does, include associated text, such as “To see previous issues of Dairy Digest, visit our archive.”

Of course, length alone doesn’t determine whether links will actually help users make correct navigational choices. It’s the wording that must make it abundantly clear what information lies ahead. Wording that instills confidence in the navigating user: Yes! I am heading in the right direction!

I discovered a fine example of this in the late ’90s when I worked on the marketing team in Penn State’s Office of Undergraduate Admissions. Our team spent several months gathering marketing data on student’s applying to Penn State (and their families) to learn what information worked best for them — and how best to deliver that information on the Web and in print. At the time, we had a pretty good idea that the phrase “Prospective Students” meant little to them, and our research confirmed this. But what we learned in addition was that widely used “Future Students” also missed the mark. In the end, we found that “Students interested in applying to Penn State” or “Students interested in attending Penn State” spoke to our audience much more clearly, and that’s what we used in our materials.

The next time you find yourself or your design team wording navigation by casting about for le mot juste, entertain these questions:

• Is the site design imposing too much of a space limit on navigation?
• Who are we helping by condensing the text of our links down to one or two words?
• Do we actually knowwhat trigger words work for this audience?

Granted, sometimes strong scent of information can happen in one or two words within a tiny wafer somewhere near the top of the page. More often, it cannot.

This presentation also is published at http://docs.google.com/present/view?id=ddjp8wn9_1389hk6r9md3.

This presentation is also published at docs.google.com/present/view?id=ddjp8wn9_1271dnxfh2cg.

Here’s how the attack appears in server logs:

The code creates a cursor of all the user tables and all the character columns in the database. It then appends a string to each of the columns, making an ungodly mess.

Mark Kruger’s post goes into a great deal of helpful detail about how this spider operates. If you do a Google search on this attack, you will quickly get a feeling for how widespread this is.

If your site is getting hammered, and you need to buy time while you fix vulnerable code, there are scripts such as this one posted in ColdFusion Developer’s Journal on August 8, 2008, which can be modified to thwart this most recent attack thus.

Be aware that this only buys time. The most effective course is to make sure your queries are protected with cfqueryparam. Ben Forta’s primer on cfqueryparam provides a very good start on protecting code from SQL injection scripts. While you’re fixing your queries, don’t forget the ORDER BY clause, another frequently overlooked vulnerability.

It can be time consuming checking all your queries if you have a large amount of ColdFusion code to wade through, not to mention nerve-racking if you are doing so while the attacks are rolling in. Fortunately there are tools such as QueryParam Scanner that will peruse your code and return a list of any unprotected queries. Unzip this application and place it in a directory in the Web root of your development server. Go to the application in a Web browser, follow its directions, and you will quickly have a report of any vulnerable queries.

• For more links on this particular attack and how to thwart it, go to http://delicious.com/rpruyne/coldfusion.

::: view the slides

play the screencast

listen to the podcast

subscribe

Frequently, potential adopters of Plone at universities tell me that they have a difficult time convincing administration within their organizations that Plone — or any open-source content management system, for that matter — is worth the investment of time and effort. Or in the case of Penn State’s WebLion services, any consulting fees that may be involved.

With that in mind, I’m sharing the following example proposal for adopting Plone at the university department level. If you are striving to convince your organization to adopt Plone, feel free to make use of any part of this material for your own justification.

In this example, the department currently maintains a home-grown content management system based on proprietary tools - a situation perhaps not as widespread as complete reliance on static HTML, but nonetheless rather common. In addition, this example assumes a one-person Web shop, also a very common situation.

The Proposal

Issues with Current System

• Home grown = high maintenance. Our current content management system has served us very well through the years. However, any fixes, upgrades, enhancements, and added functionalities must be hand coded by the Web Administrator. Creating, maintaining, and adjusting Web administrative forms (used for managing Web content) can be very labor intensive. For example, it can take approximately 2 weeks to install and configure a Web-based WYSIWYG editor for use in all forms. Likewise, all public-facing pages displaying content in various ways are hand coded.
• Limited scalability and extensibility. The current CMS was built specifically with the departmental Web presence in mind and is supported by one programmer (the Web administrator). Since the CMS was developed, the department’s Web presence and related requirements have grown exponentially. This puts a strain on the existing CMS and requires an increasing amount of intervention.
• Built over top of a (proprietary) relational database.
  • This database model is not ideal for managing Web content. Ongoing alterations rely upon revising database tables along with writing, maintaining, and revising SQL queries for all additions and changes in the management and presentation of content.
  • The proprietary database server is complex to install, configure, and back up and routinely requires patches to address security vulnerabilities. It also requires two separate server boxes, one for production and one for backup.
• Built with proprietary middleware (programming software used to display Web content). With each new version, the price of this software continues increases.
• Lacks workflow and versioning. The current CMS lacks this functionality except for an e-mail notification system that pings the Web Administrator with some details when content is added or changed. It would take six months to a year to build full workflow and versioning into the databases and applications of the current system. Without workflow, content errors and problematic HTML code have the potential to go live on the Web site, to be caught and corrected after the fact. (Diligence of the Web administrator currently prevents this.) Versioning, which allows one to revert back to previous versions of Web content when necessary, also is not a feature of the current CMS.
• Lacks other higher-end administrative functionalities. The current administrative forms lack many features that would ease workload on both the Webmaster and content providers. (e.g. full Web-based image handling and full-feature placement of, and linking to, files (pdfs, excel sheets, etc.) is not present. This means that the Web Administrator frequently must step in and manage this content for befuddled content providers. As an example, editing, uploading, and placing images and their captions can take about 10 hours each week.
• All programming support falls to Web Administrator, who in turn has no programming support. This programming is far too mission critical and sophisticated to give to temporary, part-time, or inexperienced workers. Furthermore, because no one else uses this particular CMS, there is no programming/support community addressing its framework.
• Continuity regarding staffing can become an issue. Future Web administrators or Web programmers coming to the department would have to learn how the current CMS works as they go along, using in-house documentation.

Bottom Line - Current CMS

• The department has outgrown it.
• It grows increasingly labor intensive.
• It generates unnecessary expenses.
• It does not offer the functionality that an enterprise-level CMS would provide and from which the department could greatly benefit.
• It does not benefit from a larger support community.

Advantages of Plone

• Open Source. Because Plone is open-source, it is available at a relatively low cost, is infinitely customizable, and is supported by a global community with a considerable amount of cohesiveness and expertise. More about the open-source model…
• Enterprise-level. Plone provides a robust collection of tools and features out of the box. In addition, Plone is completely customizable, and its functionality can be extended by a wide array of add-on products.

Some of what Plone offers:

• Built-in database and Web server using the Zope framework. The Zope object-oriented database is ideal for Web content management:
  • Extremely flexible, not requiring constant database-level intervention when making site changes.
  • Integral with Zope framework, requires no installation or maintenance of separate engine.
  • Extremely secure, robust, and portable.
  • Does not require writing and revising database queries.
  • No hand-coding and constant revision of administrative forms. These are an integral part of the Zope/Plone environment and frankly are better than anything a lone Webmaster could build in any realistic time frame.
• Platform-neutrality, running on Windows, Apple OS, or Linux.
• Ability to work with other databases as needed.
• Workflow and versioning, RSS feeds, Site mapping, News and calendar management, and many other enterprise-level content-management tools.
• Administrative forms that are extremely user friendly (and browser friendly). These forms are integrated in such a way that even content providers with a low level of comfort with the Web can manage content, images, and other files quite easily. Plone’s ease of content management can take many hours of low-level, routine work off content providers and the Web Administrator. Example: Basic photo handling alone can take up 10 - 15 hours a week of Web Admin time. This is largely automated in Plone. Example: Helping certain content providers upload and link to files such as pdfs can take up another 10 -15 hours each week. Handling such files is *much* more simple in Plone.
• Web Standards compliance. Plone also has undergone accessibility and usability testing, generates user- and search engine-friendly URLs (not the long, unreadable, varible-passing URLs frequently generated bu dynamic sites). It is also relatively easy to customize Plone to meet organizational usability and accessibility requirements. Plone’s visual editor also strips out problematic and noncompliant code copied from MSWord and other sources.
• Add-on products. Everything from blogging, to digital asset management tools, to courseware packages can extend Plone’s functionality.
• Enormous amount of support and documentation. This is one of Plone’s greatest strengths. While Plone can involve a significant learning curve, the Plone community is vast and provides support through its extensive documentation; its online forums and chat rooms; its smaller, localized groups such as WebLion and users groups; and training opportunitiesof stellar quality.

Some additional advantages:

• No more hand coding a CMS from the ground up. Although developers always have the option to build customized Plone products, programming is minimal compared to what is required when building and maintaining a home-grown CMS.
• No costs involving proprietary middleware. Switching to this open-source product can save at minimum $5,000 to $6,000 over the next few years.
• Professional development opportunities for current Web staff. The Plone community provides many opportunities for collaboration on training, products, and documentation.
• More continuity regarding staffing. There are many, many Web professionals at within this institution and elsewhere who can step into a Zope/Plone environment at any time and be up to speed very quickly with department-specific customizations.

Summary

Adopting Plone will result in dramatically increased efficiency while saving money both in the short and long run. In addition, this powerful CMS and the related open-source community opens up numerous opportunities for the departmental Web presence and its users.

Related Links

• What is Plone?
• Plone.org
• WebLion at Penn State
• Plone Receives Kudos from CMS Watch

If your Web site has content copied and pasted from one page to another, it is very likely that Google is filtering out some or all of the involved Web pages from search results. The reason: The Google search engine does its best to optimize user experience by returning unique content. Because no one wants search results listing page after page of the same stuff.

Higher Education and other organizational Web sites tend to needlessly replicate content. This happens perhaps most frequently when information is repurposed as marketing material. The same content ends up appearing at its original source as well as at one or two marketing pages. Unfortunately, if this marketing material resides above the core content in the site hierarchy - and it usually does - it can end up replacing the core content in Google rankings.

The result is that your users, who once were able to sail directly to the information they need in its entirety and in the best context, now have to wade through marketing fodder to find it.

This can be made worse, believe it or not, if the marketing page helpfully adds a “for more information” link back to the core content. The reason: this is exactly what content spammers do. Their raison d’etre is to dump content in multiple locations with links from one content dump to the next. Fortunately Google has gotten quite good at recognizing this pattern.

What can you do to prevent replicated information from killing search placement of your critical material? There’s always the option of adding a robots.txt file to the directory containing the page you do not wish to have indexed. But to my mind, this is a skewed solution. More than 50 percent of users arrive at their destination via Web searches. So why go to the trouble to develop a Web page and then purposely block it from searches?

Better, if at all possible, is to keep redundant content to a minimum on your site. And this means redundant page titles, meta-information, and the like too - this repetition also can cause filtering. If you are still running a “text only” version of your site, LOSE IT. Switch to using Web Standards instead. Write fresh content when developing marketing pieces and similar information, keep it brief, and link to core content rather than redistributing it.

The added benefit is that you are no longer confusing your users with seemingly duplicate pages. Or, for that matter, thudding them over the heads with repetitive verbiage.

More Information:

• Google’s Webmaster Guidelines
• Google’s Guidelines on Duplicate Content
• Duplicate Content Penalty: How to Lose Google Ranking Fast
• The Perils of Duplicate Content, SearchEngineWatch.com
• Duplicate Content Issues and Search Engines
• Understanding SEO issues related to Duplicate Content
• The Illustrated Guide to Duplicate Content in the Search Engines
• Duplicate Content Issues: Yahoo and Google

If so, you will be rewarded with a wide scattershot of commentary, much of which is neither accurate nor usable.

In fact, implementing this ilk of “user feedback” can be detrimental to your site’s health.

Think about it. If you were overseeing the construction a classroom building, would you conduct focus groups and surveys to determine what materials should be used, where the doors and stairways should go, how strong the load-bearing walls should be?

No? You would rely on qualified architects?

Then why on earth would you open the door for individuals who have no understanding of how the Web works to step in and have a direct hand in your site design?

When this type of free-form user feedback enters the site design process, it sets certain machinery into motion that is difficult to manage or to stop:

• You now have a deluge of recommendations, few if any of which have come from individuals knowledgeable of the Web. You must now wade through these, looking for what is sensible and usable. And figure out what to do with the rest.
• The more disruptively opinionated of your users - and all Web sites have these - now have the expectation that they can step in and change the course of your Web site by popping off a few comments.

There is a better way. To get truly useful feedback, you must conduct usability studies.

Conducting a usability study does not have to be a difficult or complex. You do not need to set up a bank of video cameras, purchase expensive software, or wade through stacks of data. You also don’t need to employ a great raft of subjects. Remember, all users of your site have much in common, so, even if your resources are limited to conducting only three or four studies during a design or evaluation process, you will be far better off than investing time in the scattershot approach.

What precisely is a usability study? Follow these references to learn more:

• Jared Spool’s User Interface Engineering Site
• Don’t Make Me Think: A Common Sense Approach to Web Usability
• Shoot the Focus Group