Don't try this at home.

We've occasionally blogged about what's going live when the new website launches on July 31. Until now, we've summarized it qualitatively.

Last week, we built out the information architecture for all of the go-live features, pages and sites within Cascade. Despite an IA that requires 1,150 rows in an Excel spreadsheet, we finished on time. Andrew, Joel, Mark, and Tina: you always meet the goal!

---------------------
**Warning: Spoiler**
(if you are involved in the build-out and migration of the new site, you may want to stop reading here)
---------------------

So let's go quantitative this time: there will be at least 808 new web pages on July 31. And the vast majority of these new pages will have all new content! Want to know why the number of rows in the spreadsheet exceeds the number of new pages? Because we also built folders in Cascade for images, graphics, and documents in the new sites.

This 808 page total doesn't even count the individual blog entry pages that our brand-new student, staff and faculty bloggers are currently writing. I'm betting we hit 1,000 pages.

And photography - do you really want to go there? Okay, latest count, there are nearly 350 photos (and we are identifying more as I write this).

posted by Susan Evans

Shiny, Slick, and There!

The new hardware and software needed to launch the "production Cascade" at W&M is shiny, slick, and there. Not a day behind schedule, our technical and engineering teams are unquestionably reliable.

I love it when I get an email message filled with acronyms, technical terminology, engineering references, and server names. It usually means things are going well. Roger Clark's Friday afternoon message didn't disappoint - the bottom line, we have the web server and software environment we need (and deserve!) to re-launch www.wm.edu.

Many thanks to Andrew Bauserman, Roger Clark, Clarke Morledge, Eric Myers, Chris Peck, and Mark Windley. I know you were just doing what you do - but chocolate cake will arrive on Monday or Tuesday.

Other readers of this message: your chocolate cake is virtual.

posted by Susan Evans

What's up with Cascade?

An interesting 2 weeks in Williamsburg:
Our new development server is up and running. We've used it to build some sample pages that we can publish to a development web server. And since users will eventually need to login with the same WMuserid and password they are using everywhere, we'll be setting up that connector as well. There's so much more Cascade can do that we're still anxious to see...

Work in progress:
But our own Cascade server is not where the real action's taking place. Our friends at Global Image are doing the heavy lifting for us—customizing their own install of Cascade with our Templates and the functionality we've been defining over the last month. We're continuing our weekly phone calls and email exchanges with Michael Burks about this "Functional Spec."—which we've hopefully nailed down after our recent modifications to the design suite. On top of this, we are now 4 calls into a 3-calls-a-week technical implementation schedule with our programmers, Kevin Zink and Joel Stevens. Kevin and Joel have their jobs cut out for them—walking us through implementation choices and data definitions, building templates and layouts for each of our page types, and helping us understand the magic behind the curtain. Did I mention they have only 5 weeks to get this done?

The two shall become one:
All of the programming, layouts, data definitions and templates from the Global Image server will migrate onto our own test and production servers in early July for Beta testing and sign-off. Then the final phase begins–pouring in pages and pages of content in time for launch.

There's plenty happening behind the scenes. We'll try to keep you updated as things move along.

posted by Andrew Bauserman

The State of Cascade

Thanks to some quick and excellent work from Roger Clark, we have a development instance of Cascade Server! But Roger's work isn't done . . . he will now begin the build of test and production environments for Cascade.

Future blog posts will keep you up to date on Cascade at W&M. Mark Windley and Andrew Bauserman are in regular contact (three conference calls per week!) with mStoner's sister company, Global Image. The new W&M website will actually be built off site by Global Image and then transferred to Roger's shiny, new production instance of Cascade later this summer.

Recently Hannon Hill had some nice things to say about the W&M web redesign project on their team blog.

posted by Susan Evans

Beauty AND Functionality

This face was bred for Beauty. I cannot smell a thing.
(Tiger, the Persian cat in the film Over the Hedge)

We are fortunate to be working with talented designers at mStoner, and equally skilled programmers at Global Image. Design is about beauty. Programming is about functionality. A talented designer considers usability and interaction during the design process. And a skilled programmer considers how best to preserve the look and feel of a design as he or she is programming.

But design and programming are very different disciplines. The programmer literally slices apart every element the designer created. Each component must individually be made functional.

Form follows function - that has been misunderstood. Form and function should be one, joined in a spiritual union.
(Frank Lloyd Wright)

And this is where skilled project managers meet with the obsessive client representatives to hash out the idiosyncrasies of implementation. The culmination of this process is a document called the Functional Specification (or Functional Spec, for those conserving syllables).

Yesterday, the re.web Implementation Team had our first conference call with our project managers—Patrick diMichele and Michael Burks—regarding the Functional Spec. An exciting two hours later, and we have a first draft covering 5 of the 12 layouts to be built within the Cascade CMS as part of our implementation contract.

Getting back to the difference between designers and programmers, here's a real-life issue we are addressing:

William and Mary decided on Concept One for our new homepage. One of the elements of this design is the Rockwell font in the tactical navigation bar (starting with Information For), the primary navigation bar (starting with About) and other text on the page, such as Education Unplugged, Events, William and Mary News and Read More News/RSS.

This raises implementation questions. Since Rockwell is not a font available on all computers or browsers, should these elements all be created as graphics? Or should some of them be created as styled text with some magic web toolkit to make them display correctly. A few web programmers addressed this specific issue in 2004, creating just such a magic web toolkit dubbed sIFR.

One two-hour conference call down, and I can't yet give you the definitive answer on implementation of the Rockwell font. We will probably use creative combinations of graphics and sIFR on different layouts for different purposes.

We just thought some of you might like to know what's going on behind the glass, as we sit around the speaker-phone in our conference room, eyes glazing over spellbound.

posted by Andrew Bauserman

Kindred Spirits

I love driving to VIMS. It's always a relaxing 25 minutes on the Colonial Parkway.

Today, Mark Windley and I spent a couple of hours meeting with Barb Parcell (VIMS webmaster) and Dave Malmquist (VIMS communications director) about their plans for a new VIMS web site. mStoner is creating a new home page design (blue for water?) for VIMS and their site will be part of the new web CMS.

We talked time tables and design choices - and contributed ideas about everything from web writing to project planning. Mark and I promised to share various documents and spreadsheets developed for our own re.webing.

Enjoyed a return trip on the Parkway and fired off a few attachment filled emails to Barb and Dave.

posted by Susan Evans

The Difference Between Theory and Practice

Specific constructive criticism in a comment from Dave X inspired this blog entry. (See Dave's comments on Susan's January 17, 2008 blog entry.) We like to hear what others are thinking. And specific examples are something we can more easily address and use for improving the College web presence.

Dave X references this W3C document. In theory, I agree that URIs should not be as disposable as we often treat them. Our circumstances, however, remind me of Yogi Berra's famous insight: "In theory there is no difference between theory and practice. In practice there is."

Here's an unfortunate truth from the W3C page:
[Excuse] We just reorganized our website to make it better.
[Response]Do you really feel that the old URIs cannot be kept running? If so, you chose them very badly. Think of your new ones so that you will be able to keep then running after the next redesign.

We are moving from a very decentralized structure that has grown organically over time with no central planning or oversight. As we move into a new web environment, there will be broken links. I cannot say how many - probably lots. They may have been chosen badly. Others may result from decoupling content from our org chart (another way to say they were chosen badly). For high profile sites and pages, we may leave redirects behind. But there's a practical limit to creating redirects.

What are our hopes moving forward from re.web?

Some content changes over time. The URL may not change, but the content will. The CMS allows for content versioning, histories, and scheduling to move in current information to existing pages. This doesn't break bookmarks, but may make the bookmark irrelevant for the intended use. But I think this is within the spirit of the W3C article in question.

Other content is more static and can remain in its posted form indefinitely (like a news story about Her Majesty's visit). Blogs have the notion of "permalink", and Wikipedia has the notion of web-accessible versions - both of which are designed to handle some of these challenges. Our hope is that much of our content will live in this form for quite some time.

There is a small subset of content that we ought to treat as an "authoritative source" - that is, the one place that we look and link for specific information. These links should be treated as more "valued" than others, and should be widely referenced. If it should happen that this "authoritative source" moves, a redirect would be warranted.

But these three types of content don't seem to capture all possibilities. Web application (such as facebook or youtube) provide both services and content - and there is no guarantee of continuance of deep links within these systems. If I remove my profile from facebook, somebody's bookmarks might fail. If a video clip is removed from YouTube, the link in the latest re.web blog post will be rendered dead.

As the College web presence embraces some of the elements often lumped under the "Web 2.0" moniker, we may have similarly transient content on our site. Certainly no "authoritative source" should be treated this way, nor the main news stories about Her Majesty's visit. But student profiles, posts within an admission blog, or the like may be. That's just the nature of the web.

I'll make a final point. Because we choose to release content on a web site, does that obligate the site to host the content forever? In the non-web world we see companies like Disney release movies for sale for a limited time only. Should the College never remove stale content? FOIA requires, and the CMS provides, storage and retrieval of historical documents. But I'd argue for the College to have the option to post and remove Web pages when we find it appropriate to do so.

I don't know whether I've convinced any of you of my own opinion on the subject - but I hope you know we are taking your points seriously and will make the efforts we can to keep some continuity for our audience as we roll out a new College web presence.

posted by Andrew Bauserman

Do we need a CMS?

What is a CMS and why does the W&M web site need one?
As Susan Evans (chair of re.web) discussed in her recent podcast, we've been looking at products, talking to vendors and staring at spreadsheets in windowless conference rooms. Why? We're trying to get our heads around what CMS products are available, what features they offer, and which of those features provide us the greatest impact for a dynamic and sustainable web environment. With the help of our friends at mStoner, we've been making progress.

In an attempt to broaden the discussion, and to establish a consistent vocabulary within the College community, let's discuss some of the features we're finding in these products, and how they might make things "better" within the W&M web.

Some Key CMS Features:

In this and subsequent posts, I will discuss specific features (or categories of features) offered by most of the CMS products we are vetting. Again, our goal is to explain the feature and how it is intended to improve our web site.

To get things started, today's post will cover a general definition of a CMS, as well as two important feature sets we've identified:

• The Processing Engine and Data Repository
• Users and Permissions

So, if you are unsure exactly what we mean by a CMS, or wonder how features such as these might be useful to the W&M web presence, read what we're thinking...


posted by Andrew Bauserman

Information Architecture is Key

Information Architecture (IA) is more noticeable by its absence than its presence. For this reason, some define IA by what is lacking when IA is weak—a site map, a navigation system, or search. But IA is more than this.

IA is the blueprint and foundation for the site. It is essential to the site map, navigation system, and search, as well as, for a consistent strategic message. But merely building a site with these features will not produce strong IA.

Solid IA provides a framework, not only for developing these features, but also for the evolution of the site—enabling the site to weather the inevitable changes to message, content, design, and navigational structure—thus providing long-term sustainability for the site.

Without a good IA, we risk deploying an aesthetically appealing, technically sophisticated site with great content which will not grow with us.

Yes, but what exactly is IA? And how will the re.web project address IA within the new W&M web presence? Read what we're thinking...

Posted by Andrew Bauserman

re.web's Technical Landscape Coming into Focus

Here is a summary of the technical landscape of re.web from the perspective of of February 1, 2007 (the day before Groundhog Day).

We are regularly bringing together our best web programmers and engineers to brainstorm about the web architecture and infrastructure that will be needed as we move forward. We are discussing the hardware and software implications for which IT will need to be ready.

We are also conducting prep work so that we will be in a position to provide technical expertise once the project and advisory committees are announced. Activities include:

• developing a list of features we may need in a content management system (CMS)
  


• identifying, reviewing, and evaluating products (commercial and open source)
  


• setting up test environments (servers, databases) to run some of the content management systems we are evaluating
  


• creating a list of functional tasks that those who will test the content management systems will want to try (e.g., create a web page, edit a web page, add an image)
  

We have a team working on the deployment of ClickTracks. This software analyzes W&M web logs (providing data about who clicks on what, how long they stay, etc). Time spent experimenting with ClickTracks is well spent, because the more we know about it, the better the data we'll be able to provide once the project and advisory committees begin meeting formally.

February activities on re.web will include:

• Meeting with Mike Connolly to brief him about the re.web project. Mike is the new Director of University Relations and we can benefit from his expertise.

• Drafting sections for an RFP document.

• Continuation of the technical work described above.

posted by Susan Evans

Surveying the Technical Landscape

We expect to be called upon to talk with the re.web advisory committee about solutions and products to support a W&M web redesign. We're doing a lot of looking at open source content management systems, third party products, and everything in between. Our goal is to educate ourselves about the possibilities so that we can staff an effort to assess and evaluate.

There are a lot of options.

posted by Susan Evans