Forum .LRN Q&A: Re: .LRN Gardens
the question differently.
We will likely soon want to re-design the .LRN interface, and as I
understand it the issue for us now is: at what point we address web
standards, the efficient use of css and xhtml, and enjoy all the advantages
of consistency, minimum file sizes, accessibility, and flexibility which
Zeldman and others describe. Tell me if I'm wrong, but the question is not
"if", but "when", and since it is "when" we are facing a question of
priorities.
I'm writing from the point of view of users, and I'm
seeking some professional advice. We have been exploring one task and
problem after another and finding our way, including addressing very
specific issues of naming, recommending specific features for individual
portlets, and prioritizing portlets for extra attention. I want now to
suggest that we explore interface and interaction design more deeply, but before I do I
need some technical and community advice.
As I began to research the functions and design of my favorite portlet, the
forum, I had quickly to confront the problem of building a prototype, sought
to come up to speed by reading Zeldman and Meyer, and so now stand with a
certain attitude before what looks to me like a wonderful pile of
.LRN/OpenACS code, and since I'm an amateur it looks to me like a pile of
pickup sticks, and since I'm alternatively brave and foolish I'm
contemplating where and how I might best dig in. I've made a very few, nice
changes to my implementation's interface, but with every change I've made
I've wanted to achieve consistency across the application, I'll have to do
it all again when I upgrade to .LRN 2.0, and as it stands that's not an easy
thing to do.
Shouldn't it be much easier? Readers of Zeldman know where this argument is
going to go. A consistent use of html and css, an interface that would
allow for stylistic changes more or less as readily as we can presently
rename and move portlets, and a collection of designs akin to Zen Gardens
would present an awesome opportunity for users to help us help them as they
would help themselves as well as present a compelling example for those
considering .LRN adoption.
That's the argument, and the rest is basically fill.
I know, I've watched Zen Gardens fall apart on my Netscape 4.7, but there
are workarounds for the laggards, and I look forward to the day when a
Rafael Calvo, assembling a showcase of .LRN/OpenAcs implementations, has
only to collect each site's css file by visiting its login page, present
this css as a list of options for viewing our .LRN/OpenACS standard
installation, and thereby demonstrate our system's consistency, flexibility,
responsiveness to user needs, and the tremendous creativity of our
developers, too, who have designed some dazzling implementations and the
system that informs them, too. Can anyone imagine a better demo?
I think this best done "on the fly", collectively, following a transitional
design model that encourages decentralized, individual contributions and
provides a coherent way to do so: we want to harness the energy and
participation of our many developers by making it easy for them, as they
work on their current projects, to contribute to our emerging standard and
portfolio of variations.
Now let's get down to some technical questions. Would this best be done by
developing protocols for moving html into css and then moving the css out
into a separate file? How might we develop a transitional model to do so?
Wouldn't we want to make transparent each portlet and template's basic
design, the structural html we would not want to change, and make it easy to
look up and contribute to an emerging .LRN/OpenACS standard css terminology?
I'd very much appreciate hearing some expert opinion on how this might be
done as well as some advice on if we might want to do this on our way to
tackling improvements in specific portlets and functionality.
Thanks!
Bruce
