Forum OpenACS Q&A: Pull-down menus and other navigation issues
the photo.net board and it's pretty clear that people have strong mixed
feelings about it. ACS is in desperate need of *some* kind of unified
navigation scheme. I like the pull-downs, but I'm open to other
interface solutions. Even more important, I think, is providing a way
to represent one or more web site hierarchies and then let the site
admin auto-generate a UI of preference, whether that's pull-down menus,
a site map, or something else entirely.
In order to do this, we need to be able to tag pages (both static and
dynamically generated) with some sort of structural designation, i.e.,
"this page is item #1 in subtopic x under topic A". In fact, if we're
going to do this much work, it would be nice to be have multiple
tagging systems so that different menu structures could be generated
for different groups of people with different navigational needs. Now,
if you tied in an individualize portal page along with an
individualized menu system, you'll have an amazingly powerful tool for
personalization.
At any rate, the tags would have to be related to titles that could be
inserted into menus (e.g., "New Modules bboard"), and we'd need some
mechanism for fetching them.
Once this is done, people could build any number of add-on interfaces.
Two that I particularly like are the pull-down menus and site maps that
are appended to the footer of every page, but I'm sure people could
come up with other interfaces as well.
Any comments?
It's good to see that you're still thinking of improvements and stuff.
Tagging might be the right idea, but it would be such a strong divergence from pure ACS...hmmm.
But say we got it going. If we do it right, it ought to be generally applicable, right?
I guess this is how I'd do it. I'd build a top-down tool that surveys the site. Instead of using a relational model, I'd build something with a dimensional model.
So, you'd have a fact table with one row in it for every page. The fact table would have dozens of foreign keys defined in it. The foreign keys point to attribute tables. So, the page is not only defined as being a part of the Intranet Module, and is usually called from page X. Also, it would be defined as an adp page, a page that implements Karl Goldstein's templating system, and a page that feeds to page Z. If a clickstream datamart is ever built for the ACS (my dream project if I could ever concentrate on it long enough), web-site activity could be integrated into the system.
Then, any sort of site navigation can be built on top of a dimensional model instead of a relational model. Yes, you could build navigation bars and site maps. You can also build a site-wide search engine that circumvents any efforts at controlled navigation. But, the real power would come in getting extremely intellegint query responses. You could say give me this user's favorite pages, broken by group, as well as some other popular pages, given that these pages are not forms, that they use my specific flavor of formatting, that this user has permission to see them, and they are in the same language this user is browsing in. This can be done with different modules already, but in an extremely messy sql statement (if it's relational). But if we take a dimensional approach--the sky's the limit. If you can dream of a navigational tool, you can probably feed it the right data in one query with this approach.
Of course, you trade elegant code for system resources in this case. You could have a very good baseline for a navigational system, but you're going to have back-office processes building these tables, you could be forced to invest in a seperate data warehouse machine and a hot-swap machine to keep things running on a busy site.
I don't know. It's just a thought. Really, it's a tangent. I am reading these discussion boards because my pull-down menus are choking.
David Richards
That code's so broken it should never have been released, sigh...
I've been thinking a little bit about generalizing the generation of navigation bars (because of a customer site I'm working on) but nothing nearly as grandious and all-encompassing as Dave's thinking about. I'll have to read his comments more closely later, when I have enough time to think about them.
At any rate, what I have in mind is broader in scope than pull-down menus--or any single menu tool, really. Besides being able to swap in other navigational metaphors, (much as I like the pull-downs, they're probably not appropriate for every situation), and besides being able to save a huge amount maintenance labor by having the menus auto-update whenever new content is added, what I'm really after is the ability to reconfigure how the site is organized--or imagined, really--on the fly.
This would be tremendously helpful in my biz of eLearning. Say, for example, that a stock brokerage is building a huge repository of educational content about their products. They want stock brokers, sales assistants, customer service representatives, lawyers--just about any employee who needs product knowledge--to be able to have access to that content.
Of course, not everyone will need access to the same slice of training materials in the same order. Brokers will need to learn different details about, say, IRAs than will customer service reps. And a broker who is hired fresh out of school will have different learning needs than a broker who is hired from a competitor. And, of course, even people with the same jobs and experience levels learn differently, so broker A may need more graphs and visual content, while broker B, who is blind, needs an all-audio program, and broker C, who is an avid reader and a quick study, wants just text with lots of bullet points.
(BTW, I just pulled the brokerage example out of a hat. It could just as easily be a hospital, a large social action group, a car manufacturer, or a consortium of high schools.)
At any rate, with all that content to learn, the last thing the individual learners need to do is spend their time figuring out how to navigate it. It would be nice if the menus could be customized based on input like learner profiles, their personal preferences, pre-test results, and so on. Once you know who they are, then you organize the content so that the stuff they are most likely to want is easiest to access, the stuff they might want later is accessible, and the stuff they really aren't likely to want is completely out of their way and off the main menus.
You could envision the same sort of thing at, say, photo.net. The information needs of a novice photographer interested in taking good family vacation shots is very different than the needs of a veteran nature photographer who posts more answers than questions. I can imagine presenting different menu structures to the two different photographers. Later, the users could customize their menu system based on their own preferences. Or perhaps the system itself could notice what the users do and suggest changes.
As far as I can tell, the first thing you need in order to build a system like this is to have a method for providing at least several different fields of meta-data about each web page that can be accessed by an external system (e.g., a menu generator).
(that's a bit of a lie, the facility is there but the whole toolkit won't be ported to it by 3.3, new stuff will be using it, though).
They're also moving to a document model where titles, navbars and the like will be built as document parts. The Adp page which these are bound to can do whatever it wants to do with the various parts, they're no longer put out by Tcl ns_write or ns_return 200 statements.
This model doesn't quite get the ACS to a place where stuff like Mike's talking about is possible. But it is a step in that direction. The problem with the ACS document model is that the code for each page is still building navbars and titles and all that "by hand", building up an explicit list of links for the context bar, setting hard text in the title, that kind of thing.
Mike's suggesting a greater level of abstraction, and having just gone through the exercise of implementing a navigation model quite different than the standard ACS way of doing things, I can attest that an even greater separation of the generation of navigation and other document header parts than aD's implemented for 3.3 would be useful.
Of course, it only took me a couple of hours to hack together the code to automatically generate the navigation tools the customer wants, along with about a half day of hacking out unwanted <h2>bloody titles</h2> that are glued in the text (this last bit disappears in the new aD model, in 3.3 I would always set the title to "" no matter what the code told me to do). But a more complex navigation model would be a pain in the ass to implement, involving minor rewriting of each and every page in those ACS modules used in the project.
It shouldn't be that hard for users to customize the ACS in this area.
Still, if all this were built, it might take a lot of changes to the ACS 4.0 adp pages, to take all their references to navigational tools out. Then we'd add references to our new navigational tool in the uppermost master.adp file. (The uppermost master.adp file sits near the top of the ACS document model. All pages in the ACS turn to it for any data and presentation information it offers.)
I don't know if I'm writing very clearly. In a nutshell, we could combine the ACS 4.0 stuff with a new navigational module and a new dimensional meta data model to get the kind of results you're thinking about.
If you're interested, we could collaborate on such an idea. I could take on the dimensionl stuff--it would take me a while, but I'm heading down that road anyway. It might look an awful lot like Ralph Kimball's clickstream datamart when I'm through with it. (He talks about it in his latest book--The Data Webhouse Toolkit). You could then build a navigational module that allows an administrator to configure the look and feel of the tool, the interaction of the tool with the meta data, etc.
It could be fun. It wouldn't be quick. I imagine it would take 6 to 9 months to get a pilot version out if we're lucky. However, by then we'd have a stable version of openACS 4.0, so maybe it'd make sense.
