I'm trying to think about the navigation framework for the Alumni site, and I'm not happy with the experience for content authors.
Background: The MIT Alumni Association (MITAA) website will have navigation information represented as a blueprint or sitemap, which is essentially a tree of links which can be used to generate page breadcrumbs, a site index, and information for a navigation bar on each page. This is a fairly generic need that isn't specific to the MITAA site.
Let's look at the ways to get this done:
Way #0: The Global Navigation File (WSF Solution)
Alfresco's Web Site Framework (WSF) project's proposed solution is to have a single webform-backed navigation xml file which contains all this information. This is simple for the webapp designer, who just has to parse the single xml file at webapp initialization time to represent the sitemap. Unfortunately, it is a nightmare for content authors:
- The sitemap information is completely divorced from the actual content. Every time a page is added or deleted anywhere on the site, the content author must remember to update to the single navigation xml file located elsewhere. This problem is exacerbated by the fact that the process is essentially manual; the web form has no idea which item was updated.
- The particular webform included has unacceptable performance. There is a hard limit to how many levels of navigation there can be (since Alfresco's web form implementation chokes on recursive element definitions in the xsd). Even if a hard limit is acceptable, once you attempt to go down to three or more levels in depth, the user interface experience is ghastly. It is frankly easier to manually edit an xml file than to wade through a single mile-long and deeply nested web form adorned with plus and minus signs and boxes.
This is unworkable for content authors. So, I'm looking for another solution which is... less of a nightmare.
One reasonable idea I'm working with is to have a webform-backed navigation xml file per folder of the web project. This constrains the sitemap to at least somewhat resemble the web project folder structure (and vice versa), but that's probably what most sites would want anyway. This makes the webapp designer's job a little bit more difficult, but still manageable, since the work involved in building a sitemap is just traversing the web site's folders and parsing xml files. It is even conceivable that, through XSLT tricks, the per-folder web form can maintain the single global navigation xml file as found in the WSF solution above.
As for the details of the per-folder web form and xml file configuration, there are different ways to go about this; each, unfortunately, is problematic:
Way #1: One Page Per Folder
One idea is to allow only one page per folder. Then the folder's navigation.xml would only need to define the title of this single piece of content, and optionally a list of title/url pairs for links to external content. The navigation for content under this level would therefore consist of the titles of the content in each subfolder, as well as these optional external links.
This is conceptually very clean and easy to implement with web forms, but it is hard for content authors to get used to. It is a seemingly bizarre requirement and would take training and discipline for content authors to remember to create a separate folder for each page. It's easier for content authors than the WSF solution: at least this manual process involves only local updates; plus, the web form will only have few, non-nested entries, so the UI would be acceptable. But it is hard to think of this as a general solution for existing web sites, since it necessarily involves a restructuring of the content.
Way #2: Hybrid Structure
The idea I was leaning toward was to take for granted that folders will have multiple pages in them, and have the per-folder xml file define titles for each of the pages in the folder, as well as singling out a particular page to be this folder's navigation level's default page. Plus the optional list of title/url pairs for links to external content. The navigation for content under this level would therefore consist of: the titles of all the non-default pages in this folder, the titles of the default pages in each subfolder of this folder, as well as the optional external links.
This is a little more conceptually confused (since the mapping of directory structure to navigation tree is no longer one-to-one and involves a hybrid structure) but not bad. The hard part is getting the web form to be useful:
The web form which backs the per-folder xml file will be too uncoupled from the contents of the folder. You'd expect that, for example, when you first create the navigation page, you'd be shown a list of every item in the folder, and be prompted for titles for each. Or, when you add a page, you'd expect that when you go to the web form, a new entry will be there with a blank title. Instead, the content authors will most likely have to manually keep track of this information themselves, for the simple reason that the web form won't know which folder you're in. That is, there's no way to create an .xsd file, and even if it's totally dynamic in the sense that it's backed by a jsp, which will have any way to anticipate which .xml file you're editing. So we're back with to manual bookkeeping, albeit at a less global level than the WSF solution.
Now, one way to possibly get around this problem... which might even allow the WSF solution to work, is to write my own widget for use in the navigation web form. This ability was introduced in v2.1. Unfortunately, I don't think there's any way to do this that doesn't involve root access to the Alfresco server and/or further modifications to the Alfresco codebase. It would be great if I could drop a javascript widget definition into the Data Dictionary and it would be automatically incorporated into the web form, but this doesn't seem to be possible. Every new project we work on points to more insufficiencies in the WCM. I really don't want to have to extend the WCM for each project. Especially for the MITAA project, since then I'd have to keep updating the Alfresco instance of the consulting company they hired to do their website design.
---
So I'm at an impasse, or at least a dilemma. Right now, I have to decide between One Page Per Folder or the Hybrid Structure (since the WSF Solution is basically unworkable). Or I have to come up with another solution entirely (maybe a navigation file per page? but that only brings up more problems!!!).