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.
---
In the extreme case, the navigation files would not even be per-folder, but per-file. That leads to:
Way #3: Everything is a Rendition
Every single page in the site would be the rendition of a web form, and that the xml form instance data for each such page will contain the navigation information for that page. So the navigation information is completely distributed throughout the website. In terms of the experience for content authors, it would be largely seamless, since all navigation metadata about an asset would be local to the asset. The only discipline necessary is that content authors would need to make sure to use a web form to create (navigable) content, even if the content doesn't have any structure to it other than just the HTML or JSP. So there'd be at least one "catch-all" web form like "Navigable Content" with two fields: "Title" and "Content", where Content would be one large TinyMCE block of HTML or JSP.
There are a few complications with navigation. One is that there still needs to be an idea of "default" page per folder. In this case, we'd probably just rely on the web server's idea of what makes a page the default. (For example, look for an item named "index.html" or "default.htm" or "index.jsp", etc.) Next, there's no intrinsic way to include a list of optional external links in this system. This can be solved by having a web form called "External Links For This Folder" which would make a special "external.xml" file containing title and url pairs for these links.
Just as in Way#2, then, the navigation for content under a folder 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.
So, this almost seems like the best solution. Unfortunately, I haven't talked about what it's like for the webapp designer. First of all, it essentially doubles the size of the webapp. If you want to be able to include "foobar.jsp" in your navigation, there will be a "foobar.jsp.xml" file in (for example) the same directory which contains all the same information. One way around this is to not actually have the "foobar.jsp" rendition, and just write a webapp filter which processes "foobar.jsp" as a request for the internal content in "foobar.jsp.xml". That may bring on more complications than we'd like, and it looks bizarre.
But the thing which really makes this a possible no-go: the webapp has to do a whole lot of work to build the sitemap. It needs to parse all these xml files... one per navigation entry, and each xml file is large. If the webapp can be written so it stops parsing the xml once it reads the navigation information (and that the navigation information is the first thing in the file) and does not go on to parse the entire content element, maybe that is not a huge deal. Still, it's a lot of file accesses to build up the static sitemap. If this takes too long on the production server, we could be in trouble. There may be ways around this, too: try to jimmy the web form to maintain a single global navigation xml file; alter the deployment step so this file is built at deploy time and published to the server; or something else, maybe.
---
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 or Everything Is A Rendition (since the WSF Solution is basically unworkable). Help!