poster presentation:

• presentation handout
• ploneedu poster
• weblion poster

flickr:

• my photos: highedweb conference 2010
• all flickr photos tagged with heweb10

twitter:

• #heweb10

Thank you, xkcd.com.

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