Subdomains vs. Subdirectories

Well, here’s the deal. There are theories all over the place these days about whether you should organize Web sites using sub-domains (e.g. “http://something.umw.edu”) or sub-directories (e.g. “http://umw.edu/something”). WordPress Multi-User forces you to make a choice of one or the other UPON INSTALLATION. No pressure…

I’m setting up a development environment within the umw.edu domain on a University-owned server. As a result, in order to get the sub-domain functionality going, the network and server administration folks need to get involved, which may constitute more overhead for them in the long run. It’s another line of code to the DNS, but, there are always network implications for things like this. I don’t like doing things that involve having to bring in a multitude of folks to support it, and to respond to what can appear to be idiosncratic requests. So, I feel it’s my duty to research whether or not the bang for the buck of a subdomain structure is worth it.

SEO Consideration

With the acknowledgement of the unfortunate fact that SEO field is more art than science, a moving target, and at any point in time, full of spurious claims, but I digress. There are indeed some ways to help search engines get to your stuff quicker :) Using a subdomain, supposedly, has search engines treat that section as a separate site, with equal importance, or of comparable organizational weight, as the parent site.

Using this rationale, it is easy to see why UMWBlogs uses sub-domains. Blogs by individuals within the domain are of equal weight, and each constitute, essentially, their own web environment, deserving to be crawled as a “root” site unto its own. Interlinking, and crawls between blogs that lead to the “network effect” of the social web, would arise from the individual choices made by the bloggers. If your blog is relevant, it gets linked to, and its ranking goes up because the quality of the content is compelling. So, rather than a top-down measure of your blog’s importance, you have a more organic measure of your blogs relevance. In essence, the information architecture is 3-dimensional and always changing.

With a large-scale university site, this type of status may not apply to each area of content. For instance, I would not consider the Web site for, say, the EagleOne card office (e.g. eagleone.umw.edu) to be on the same level of importance as the College of Education (e.g., education.umw.edu). That is because, within an organization, although there are ongoing shifts and reorgs, at any point in time there is a certain fixed and hierarchical relationship between organizational units, and certain areas of information that will always be more important to external audiences requiring predictable, easy pathways. Hard-linking within a directory structure, supplemented by the more organic linking that occurs over time, may be a better way to go in that instance.

But, here’s the rub…

With WPMU, my understanding is that it’s one or the other: Subdomains or subdirectories. Upon installing the app. Sigh…

Ideally, a combination of the two would be best. That is, chunking the site into its major organizational (or content) areas, and then having a sub-directory structure beneath each one. This could, for example, play out as follows:

  • umw.edu
  • umw.edu/admissions
  • umw.edu/about
  • umw.edu/directory
  • etc.

AND

  • education.umw.edu
  • education.umw.edu/advising
  • education.umw.edu/dean
  • etc.

At this point in time, if we were to set the sub-domains in stone, we may regret it down the road — cgps.umw.edu anyone?

To get to the combination of sub-domain and sub-directory, my understanding is that we’d need a SEPARATE WPMU INSTALL FOR EACH SUB-DOMAIN. Can you spell maintenance headache? (Of course you can — we ARE at a University, afterall).

I found a plug-in that purports to do this:

http://wordpress.org/extend/plugins/wordpress-mu-domain-mapping/

I’m always hesitant to use a plug-in for what seems to be core application functionality, but, hey, it’s a development environment! Still are there folks out there who have tried this plugin, and what kind of success have you had?

Incremental Process for Eventual Web Re-Design: Start with the Data

In the process of the site redesign for UMW, we will go through the usual committee process. However, I’m wondering if the project itself that this committee will be charged with could be a more iterative one.

Many folks who came into Web design in the early 2000s, and today, are from a print communications background. This has led, I believe, to a notion that a “Web site” is like a piece: You plan it, edit it, publish it, go home.

But we all know that a Web site is like a shark: It has to keep swimming or it dies (Yes, I’ve seen “Annie Hall”). To that end, is there any reason why we can’t test drive ideas live, read analytics over a period, then make adjustments as we go along?

UMW Blogs is, by it’s nature, incremental and organic in growth. It comes from the content up, not from the home page down. It’s nice that folks redesign the home page now and then, and I love those little flippy things in the primary navigation, but the little flippy things are not what’s cool about it.

We have a unique opportunity in that the current site is so stale that any change to the home page would be seen as a welcome sign. I’m proposing that, based on the following data over the past year, maybe the committee would want to test drive a few before a wholesale change:

  1. Visits to “Featured Faculty” encompass 0.8% of the home page traffic.
  2. Get Recognized gets 1.0% of the home page traffic.
  3. The home page links to only 6 of the pages that are in the UMW Top 20 for the year (measured by page views since we have many repeat customers internally). Not included is a link to the library, which is a consistent #3 in terms of site traffic.
  4. The most visited page linked to from the home page is the “Student/Faculty/Staff” page.

What does all this tell us? First of all, I’m using Google Analytics data here in the broadest sense, settling on a single piece of data over a period of one fiscal year (6/30/2009 through 7/1/2010). But, at first blush, we can conclude:

  1. The majority of site users are internal.
  2. Of the links we provide that are geared towards external users, the two least popular features take up a majority of the real estate.

This is not to say that the perennial argument about who is the primary audience for the site should be questioned. We should strive for a more externally-facing site. And, although the click-throughs to the “Resources” page indicate that folks are using the site internally, that should not really affect the real estate on the home page all that much.

So, I’m going to propose that some adjustments be made to the current home page to see if it can be made more efficient for external users. The externally focused links in the top 20, in decreasing order of traffic, (factoring out the home page and the resources page), are:

  1. Admissions (22.8%)
  2. Directory (17.3%)
  3. Academics (14.9%)
  4. About UMW (9.1%)
  5. News Release (with photo and teaser at bottom) (5.4%)
  6. Student Life (4.8%)

In addition, if you simply compare by site visits for the year, UMWBlogs site visits amount to 17.4% of the UMW Web site visits. That’s popularity we can “leverage” (I used that term to make Jim Groom happy). That would put them just under Admissions for popularity.

Are you sensing something here?

Here is my proposal for an interim change to the Home Page (which, of course, would need to go through the proper channels). I submit the following suggestions for your comment:

  1. Replace the “Featured Faculty” section with an RSS feed of faculty blogs on UMW Blogs. This would give more Faculty home page exposure, and eliminate the overhead of writing a story and producing a single web page for faculty. Faculty members could opt-in,  or, we could settle on a taxonomy of tags to select for home page inclusoin. It would end any resentment about who gets to be on the home page, too :) Added bonus: The content always changes.
  2. End the “Get Recognized” Campaign on the home page and replace with a navigational Flash animation that shows our campus, people, and mission, and links to Admissions, Academics, Athetics, About UMW, and Student Life prominently.
  3. Upgrade and standardize the look and feel of the primary pages linked to from this graphic.
  4. Re-work the text navigation to put all internal links in one place, and clean up the navigation on the right.
  5. Since most home page traffic goes to the Admissions site, and not to the “application” site (which has an “apply now” button prominently displayed), I’d take that button out. It’s kinda cheesy anyway (I have no data to back that up).

Do you think these adjustments would be a good idea? Do you have any other thoughts? I’m all ears.

When is Simplicity Simplistic?

Vignelli's Doomed MasterpieceIn the early 1970s, Massigmo Vignelli re-designed the NYC Subway maps, making them beautiful abstractions of streamlined simplicity. The idea was based on a notion that the existing maps were too complicated to read, and that riders wanted simplicity.

Unfortunately, the Vignelli maps were pretty quickly scrapped because they were so divorced from user reality (the streetscape was completely out of scale) that folks had trouble locating where a street they entered from in their neighborhood actually was located on the map. They didn’t want streamlined. They wanted clarity. Dumb designers (actually, Vignelli was one of the 1970s greats, and the maps ARE beautiful.)

As with the NYC subways, University cultures and processes are difficult to understand and navigate. What is it about navigational design for a University site that makes it almost impossible to find anything? I wish I had the definitive answer, but in this space, I will begin to unpack this issue. For now, I’d like to address the issue of overanticipation.

This phrase came up when we were designing the TeachUMW Web site last semester. Our group (The Provost, DTLT, Teaching Center Advisory Committee members, and myself) was designing a site that preceded the actual program for which it was to be the initial online communications vehicle. As a result, we really had no way to anticipate information architecture when there was, well, little information to go by.

The structure of the site had to address the possible architecture of a conversation that had not taken place. This included not only which tools to provide (wikis, blog posts, event calendars, etc.) but how to structure access to them to enable new conversations to begin and branch out. Sounds like social networking, right? Right. So we used Drupal, a content management system that enables social networking. Since much of our conversation on campus is done within committees, task forces, and the like, Patrick Murray-John tweaked the application to allow these tools to be deployed based on membership in, or participation in discussions with, a particular group.

This all seems fine, but there was a piece missing, and we kind of knew there would be. There is no tool for users to create static Web content in the form of traditional information architecture: sections with sub-pages. An administrator can do this if they want, but we avoided it for the masses, at least at rollout. Why?

After much debate over this issue, we had to face a hard reality: How could we anticipate information architecture for static page content when the structure of the program was not yet in place? If we were to have a capability for static content, we had two choices:

Let the users develop their own static information architecture
We had seen how the UMW site had become like the wild west, with an information architecture so byzantine as a result of democratizing these decisions. One person’s “registration” is another person’s “academic catalogue” is another person’s “course listing.” The one who gets to make the decision is the person authoring the content. This person is an expert on their content, but completely unaware (nor should they be) of where that content fits into the overall architecture of the University. As a result, folks go to the search box. It’s kind of amusing to note that, during the design process, Jerry Slezak sarcastically suggested that the home page for TeachUMW simply BE a search box. That sounded great, until we realized that Google already exists.

Anticipate the information architecture as best we could
Never does the term “the best laid plans” seem to play itself out more than in over-engineered information architecture. The entire discipline is about anticipation of the user experience. When the user at a University is not only a consumer (like at Amazon), but one of MANY stakeholders with a wide variety of relationships with the University, this is almost impossible. People visit the site for hundreds and hundreds of reasons, representing students/prospective students, faculty/prospective faculty/retired faculty, parents, administration, staff/prospective employees, alumni/benefactors, Forum attendees, Gallery visitors, etc. And each of these groups breaks down by further granularity in their relationships with the University. Residential student or commuting student? Full-time faculty or adjunct? Administrative Faculty or Classified? State resident or out-of-state resident? If you are able to unpack that into a single information architecture that makes sense, I’ll call the Nobels and you are a candidate for the next Peace Prize.

The classic solution to the above is to have what’s known as a hybrid information architecture. We categorize by audience (alumni, student, etc.), and also by topic (Academics, Admissions, etc.), and sitewide supplementary navigation (directory, AtoZ index, search). What if I don’t want to take a second to determine if I am a student, faculty, staff (I may be more than one), or if what I’m looking for is within any of the topics that have been presented as the top level appropriate topics? Lots of folks don’t want to take the “beat” it takes to determine that. It’s cumbersome. As a result, the search is where a user will go. We simply cannot, at a single point in time, determine within what structure most users will be able to find where what they are looking for fits in.

So, let’s throw up our hands? No, but it fails so badly that I believe we should be willing to blow it up and start fresh. To that end, I offer the following possibilities if the University plans on taking the opportunity for the Sharepoint migration to mean more than simply a backend switch. Here are a few ideas:

1) Transactional Structure: When I go to a site, I kind of know what it is I want to be doing there: Research, purchasing, exploring, chatting, etc. What if there were a way to invite folks in based on the transaction they are planning with this visit?

2) Welcome Boostrapping: Attack the site design issue as an interative one. I’m not talking about “tweaking” so much as an annual, systematic analysis of analytics resulting in a well-researched plan of attack for upgrades and improvements deeper than cosmetics. Be open to wholesale change when indicated and be willing to “kill your darlings” if they don’t work.

3) Customer Service vs. “Design”: We like to have Web committees to talk about Web design. We are better served to have customer service committees to talk about ALL University transactions and relationships, and determine where the Web site fits into that initiative first. That way, any Web design changes and improvements are based in more than anecdotal preference, are coordinated sitewide by Enterprise Designers, and are part of a bigger picture that serves the University community.

4) Tagging Content: Let’s stop asking departmental Web managers/authors to anticipate fitting the content into a structure. It’s too overwhelming a task, and has led to the “wild west” phenomenon we see now. Let them do what they do best: Author accurate content, have it vetted, and publish it to the Web. Enterprise designers should develop a taxonomy for tagging, and templates to contain, aggregate, and display content based on tagging. Authors should be asked to select from a pre-determined taxonomy a list of tagged content based on its transaction type, audience, concerned offices, processes, etc. The CMS will present it as the Enterprise designers intend, based on the University’s customer service initiatives.

5) Expiring Content: Authors should be asked to set a beginning and end date for content so that old content GOES AWAY when it’s no longer needed.

Keep in mind that I say all of this knowing how instrumental I’ve been in creating the mess that’s now there. But the mess is a sign of progress. There is so much content by so many people, and that’s a mixed blessing, not a curse. In the long run, that’s a very, very good thing. We have just come to a point where we need to re-address not just the scalability of the technology, but the scalability of a dynamic information architecture based on solid information and a customer-centric focus.

In short, it’s not just about streamlining entry points based on aesthetics and anecdotal notions of simplicity. We saw how that worked for Vignelli. It’s not about shying away from complexity. It’s about embracing it, and making it work for you. With current CMS solutions, that is now a very real possibility, if the University has the will to start anew.

The Visible University

Every time a University Web site is re-tooled, there is this tug of war between those who see it as a marketing tool, and those who see it as a part of their working environment. A couple of years ago, when implementing the portal, we debated whether internal policies and forms should be taken off the public web site altogether and placed in the portal, behind authentication.

There were two arguments against this, one philosophical, the other pragmatic. Philosophically, the notion of a public institution having its policies available for the public to see, and for colleagues at other institutions to refer to, seems to be philosophically correct. I know when I’ve worked in drafting or re-drafting policy, searching for other institution’s policies is a big part of that process.

Pragmatically, folks on campus set the UMW Web site as their home page out of habit, and may not want to sit and parse the difference between what is considered internal vs. external. What seems obvious to communications or IT folks may not be obvious to an administrative user who just wants to access something “off the web.”

As we discuss re-tooling the public site within a possible Sharepoint framework, a big part of that discussion has brought up this topic again. Once again, I am torn because of the considerations stated above. So, I have to wonder, if we are to fulfill both the philosophical and pragmatic concerns for keeping it all public, what is NOT working in the current environment to make it all seem so cluttered?

I believe it’s a matter of information architecture and presentation more than anything else. Keep in mind, I built the system that’s now a big blob of burgeoning content. Of that, I am quite proud. Visually, we absolutely achieved the questionable “Holy Grail” of design standardization, with every department page on the site looking, with little difference, identical.

There are two reasons for the lack of variety: Lack of time and resources. I was given two months to achieve full conversion of the new design throughout the ENTIRE SITE. All that was in my office at the time was me and one part-time PHP programmer. Second, I reported to IT and as a result did not have the official “authority” to advocate for distinction of design based on content. The University Relations position at the time was that EVERYTHING was to look the same. A rather literal interpretation of standardization, but I was not organizationally positioned to reason why.

The mandate for standardization was met by the solution, and the limits of standardization, as a result, are pretty obvious: There is no real visceral distinction that tells someone we are in a different universe of content now, a universe that pertains to your needs in the workplace vs. you visiting our site to learn about us.

So, I’m wondering if these divergent needs of clean marketing tool and public policy-wonk transparency can be addressed using a middle-ground approach. Does the “internal” environment as we are discussing it, need to necessarily be protected via authentication? Can it merely break off and be another public Web site (visually and navigationally) populated by internally-relevant content?

There is bound to be content that is relevant to both internal and external audiences. Matter of fact, it’s kind of mathematically impossible for that NOT to happen: a 50/50 chance over 20,000 unique URLs? I think it might happen once or twice…Where do we tell folks to go when it’s in a gray area?

The advantage of using Sharepoint with a public and private face seems to me to be that we can decide along a continuum of content which is absolutely confidential, to content which is most relevant to internal audiences, to content which is absolutely relevant to external audiences. But it’s a continuum, and I don’t want to draw the line any further along than the line of confidentiality — which is really what authentication is for. Authentication is about declaring yourself authorized to see something. It’s not a cheap fix for information architecture and intelligent, complex Web design.

Where I understand the “clutter” argument of keeping the internal content in a separate place, and even advocated for it years ago, I’m now converted to the other side. Not only am I convinced that making such distinctions is not scalable or enforceable, but I am convinced that we owe the Citizens of the Commonwealth access to how we conduct our business and spend their money.

In the 1980s, I worked as a Building Code and Zoning consultant in NYC. I became fascinated with how the zoning came to be, how the codes evolved, all the different versions, how some buildings got “grandfathered” and variances were granted. One of my favorite things was to be assigned to research the history of a building undergoing alterations. They NYC Department of Buildings kept everything on microfiche in those days. Anything older than 1978, and you’d get the original blueprints.

Aligning the construction standards with the prevailing codes at the time gave me a window into how the city was constructed (organically, really) and when things got SO out of hand in terms of density that the codes needed to be overhauled to keep the place from going up in flames.

All this is to say, even something as mundane as a travel and reimbursement form is some future window into how business is conducted in this day, this time, in the Commonwealth. I’m not sure it’s up to me to make a decision that I want to hide that from the public.

The University’s public Web site IS a marketing tool. But, the larger Web is a community, and the Web site of a public institution is part of government transparency, and, however mundane, part of history, just like those old microfiches and dusty building codes. Thinking of it another way, in the absence of all the “man behind the curtain” kind of day-to-day policy stuff, our public Web site will make us look like a product rather than a place. It’s subtle, but I think it would strip us of some of what makes public institutions so cool.

There is a way to have both. We just need more time this time to develop a more complex information architecture, and get away from the frantic, simplistic notion that design standardization is paramount. When it serves to confuse, it ain’t pretty anymore.