Forum .LRN Q&A: .LRN Gardens

Collapse
Posted by Bruce Spear on
What would it take to do this:

http://www.csszengarden.com

to Openacs/.LRN, and would it be worth the trouble?

(I think the answer is "yes".)

Collapse
2: Re: .LRN Gardens (response to 1)
Posted by Talli Somekh on
Lots of work.

This has been discussed, namely touching pretty much every file in the OpenACS. Jeff Davis has studied the problem better, though.

It's certainly important, just lots of work.

talli

Collapse
3: Re: .LRN Gardens (response to 1)
Posted by Bruce Spear on
Thanks Talli, for the quick response, and now I think I might better pose
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

Collapse
4: Re: .LRN Gardens (response to 1)
Posted by Jun Yamog on
Hi Bruce,

There is not much technical hurdle.  But the real problem is the great task of transforming the files to use css and into valid xhtml.  OpenACS started in the time where css was more of an after thought.  Through the years it had none css friendly html output and even non valid xhtml.

The newer packages are more css friendly and xhtml.  Atleast that is what I try to do.  Also if I will work on heavily on a package I will try to put it into css to my best of effort.

I think right now we need two things:

- a champion for the cause of making things into css and xhtml.  this is no joke its going to be a real long time.
- volunteers to do the work. lots of it.

I think the work on making things into css is not fit for the opensource model we have.  I doubt you will find the top gurus here spending their time in making something that doesn't require them to think.  Another issue is that the display is something that is always customized on a project.  So most of times this is the part that does not get contributed back to the source.

Yes I agree with you, it would be nice to transform the whole of OpenACS into the newer standard of css and xhtml.  But the problem is more financial and political rather than technical.

Collapse
5: Re: .LRN Gardens (response to 1)
Posted by Ben Koot on
It looks like Nima is also looking into this issue and has found some answers. https://openacs.org/forums/message-view?message_id=153958. This more or less adresses my earlier posts regarding design.
Ben
Collapse
6: Re: .LRN Gardens (response to 1)
Posted by Rafael Calvo on
Bruce
Thanks for that beautifull site! quite impressive.

I think this is an extremely big issue. Accessibility *has* to be a priority if .LRN is to become mainstream.
An interesting example is what plone has to say:

"Plone is standard. Plone carefully follows standards for usability and accessibility. Plone pages are compliant with US Section 508, and the W3C's AAA rating for accessibility, in addition to using best-practice web standards like XHTML and CSS."

Can we say the same? How hard it would be?

cheers

Collapse
7: Re: .LRN Gardens (response to 1)
Posted by David Kuczek on
Nime, what kind of changes did you make concerning css... Can you give us some examples?
Collapse
8: Re: .LRN Gardens (response to 1)
Posted by Jade Rubick on
I think if you'd like this to happen, you'll need to do a couple of things:

1) Write up documentation in DocBook style (it's not hard, there is documentation to do it) on how future packages should be written to ensure compatibility.

2) Write up a staged implementation, which won't require everything to be fixed at once. Each stage should get us closer to the goal, but be able to be completed in small time chunks. Then volunteers can contribute to achieving these smaller chunks, and they can be checked off the list.

I would look at Joel's release criteria as an excellent example of this. If you or someone else is willing to organize it in this way, and provide some initial manpower, it will move in that direction. Otherwise, it won't happen until someone else takes it up.

Collapse
9: Re: .LRN Gardens (response to 1)
Posted by Paul Doerwald on
I think this is absolutely worth the trouble to do. The benefits of XHTML/CSS will be realized for a long time to come. Combined with OACS I18N it would be an extremely powerful package.

In my own experience doing limited XHTML/CSS with OACS, the easiest way to do it is to start at the modules. One by one as the modules become XHTML/CSS, the entire toolkit can be migrated. It's a long road to get there, but there's no reason we can't start now.

The Zeldman book is a good start to understanding the "why" of XHTML/CSS, and Eric Meyer on CSS (New Riders) is a good "how" book, which shows practical, page-by-page examples.

Now there's just a matter of "how" to do it in OACS. I spent a bit of time working on exactly this with Dirk Gomez on Calendar at the Berlin bug bash in February, and Bruce has suggested this issue for the Copenhagen bug bash in March. With enough discussion, I'm sure we can come up with a system that works OACS- (and dotLRN-)wide.

Collapse
10: Re: .LRN Gardens (response to 1)
Posted by Bruce Spear on
Thanks everyone for the helpful comments and encouragement!

I very much like the staged implementation model whereby volunteers may contribute easily in the course of their other business and in bite-sized, manageable pieces.  From there the problem is one of coordination. I'll check out the standards for documentation and release criteria, thanks Jade!  What else might developers need to know?

Thanks, Paul, for the reference to the Zeldman and Meyer books.  Of the two, I prefer the Meyer book (http://www.ericmeyeroncss.com/) because it is a detailed, no-nononse tutorial that shows you how to apply the principles Zeldman advances.  The first chapter offers strategies and procedures for the redesign of existing pages, and so speaks directly to my fiddling with the current .lrn site.  The second chapter shows you how to build pages from scratch, and so speaks to others.  I find it wonderfully accessible, quite precise, and instructive.  But maybe others have their favorites to recommend, and how might we build a rough consensus on our direction?

I suspect I'll want to start collating these things somewhere, maybe on the new .lrn site.  But as we've just started I am sure there are many more things that ought to be considered.  Has anyone started to do this with .lrn/openacs, do we have a working model of code redesign already?

Thanks!

Collapse
11: Re: .LRN Gardens (response to 1)
Posted by Jun Yamog on
Hi Bruce,

We need a champion for this for the long haul.  For starters we need someone and somewhere to put all the defined ids and classes for OpenACS.  I use already a few of my own.  And Jeff Davis may have some other ideas.  I already use a css form template and list template used by the form builder and list builder.

What we need is a coordinator and champion for this.  Here is a first hand example.  A real one.

I am about to work at news, bookmarks and general comments.  One of the things I need to do is to make it more xhtml and use css.  I might not be possible to do it 100%, but its a good start.  And these changes has a good chance of being put back to oacs.  The question is for me as a developer.  What do I use.  Have a set of my own classes and ids already.  Lets take for example the error in a form.

I use the following css.

div.formtemplate div.oneelement label.witherror

What if another developer use something similar but a little different.

div.formtemplate div.field label.error

Both are semantically the same.  But since we are a little different our form XHTML will be slightly different.  So we can't interchange the styles.

But the above can be avoided if there is someone or a doc to look up to.  That is one thing we really need.

I think I will follow the css guideline docs even if it says

#login-box

But what I really have is #login-area

Collapse
12: Re: .LRN Gardens (response to 1)
Posted by Bruce Spear on
Hi Jun!

Thanks for the comments, and so we dig right in!

Let's say you've defined the problem accurately: "we need a champion or a doc to look up".  For the moment WE can play the role of champion, with the understanding that by WE we mean everyone who is contributing to this forum, and go right to the question of documentation.

Jade reminds us that the issue has long been joined, and I believe in his last post and the reference to DocBook, he is pointing to the OpenACS Documentation Guide, https://openacs.org/doc/openacs-HEAD/docbook-primer.html and that means DocBook XML.  I'll risk moving right ahead, presenting a fair target, and inviting correction.

As I understand it, the problem now comes in three parts: authoring, mediating conflicts, and developing a repository.

1. As I understand it, authoring DocBook XML means using our favorite xml editor, such as XMLSpy (http://www.docbook.org/wiki/moin.cgi/DocBookTools has a long list of such tools), to record our use and share it with others with an eye to submitting our work to the depository format. This step each of us can take on our own using the editor of our choice and then we cut-and-paste our work in to the forums and/or repository.

2. Mediating conflicts means a champion playing a mediating role, hashing things out in a forum, or by default/benign fiat when one of us researches a component, chooses a course of action, and submits his or her result to the repository.  Let's assume we will work this out over the next few weeks as the community discovers what we are doing, discovers our more or less terrible errors, and corrections us as we start to build the repository.

3. So I think the question of the moment is: what can We decide on or build (in the next couple of days) for a repository such that you, as the one taking the lead in the particular features you are working, can deposit subject to further review.  Sounds like a job for edit-this-page to me, an eventually, and as you make your deposits in xml, a specially designed, searchable database.  That is, the premium now must be on your easily integrating this extra work into your workflow so you keep making money and having a good time and we get the benefit of your regular contributions.

As I understand it, then, the immediate question is: where can we set up an edit-this-page so you can start dropping your candidates for community approval.

OK, that's a nice little proposal for a discussion forum.  I am now expecting either a Miracle Worker to come up with A Great Idea or for it to start Raining Cats and Dogs.

Collapse
13: Re: .LRN Gardens (response to 1)
Posted by Jade Rubick on
Ideally, someone with write access on OpenACS will give you an edit-this-page instance, and you'll be set.

If that doesn't happen, I'll be happy to set one up on rubick.com for you.

Collapse
14: Re: .LRN Gardens (response to 1)
Posted by Bruce Spear on
Caroline has offered to set up etp for us on the openacs site, and when she's done that we can move forward.
Collapse
15: Re: .LRN Gardens (response to 1)
Posted by Bruce Spear on
Good news!

Caroline has set up an edit-this-page for us on the OpenACS site, and I've taken the liberty of creating a page called "Bookmarks, Jun Yamog", thinking portlet/design owner might be a handy way to keep track of things.

That's an invitation to you, Jun, to start putting some of your work on it and inviting the rest of us to comment/contribute, when you/we are ready.

The next question might be: Might someone know how to create a style sheet and html, that we can edit, so we can see what it looks like?

Collapse
16: Re: .LRN Gardens (response to 1)
Posted by Jade Rubick on
Collapse
17: Re: .LRN Gardens (response to 16)
Posted by Deirdre Kane on
I do not have an "edit this page" link on https://openacs.org/projects/openacs/packages/css/

Should I?

Collapse
18: Re: .LRN Gardens (response to 1)
Posted by Bruce Spear on
Thanks, Jade, for adding the url.  It looks to me like you have to be logged on to see the "Edit This Page" button; otherwise, you see just the text.
Collapse
19: Re: .LRN Gardens (response to 1)
Posted by Deirdre Kane on
I am logged in and I do not have "edit this page."
Collapse
20: Re: .LRN Gardens (response to 18)
Posted by Caroline Meeks on
Hi Bruce,

For someone to see the "edit this page" link you need to use the "permissions" link to grant people you want to work with "admin" on the page.

Collapse
21: Re: .LRN Gardens (response to 1)
Posted by Bruce Spear on
Thanks everybody for the help!  DeeDee and Carolyn: the permissions page says you have inherited permissions, but are you telling me now that you need direct permissions, too?

The bigger problem is: I thought full wiki functionality included the ability to add html, so I thought it would be easy to cut and paste here css and html so we could see what a new design might look like.  That appears not to be the case with edit-this-page, or?

More generally, now that we've gotten this far, I think we might want to go back a step and think about what we'd like to see happen.

First, wouldn't we want to have a repository of present code and an arrangement that would allow for fast lookup?  I am thinking of how TopStyle shows you code in one window and sample text in another. It might be helpful to think of it this way: how do we prepare a style sheet that someone like myself who has worked with css and is about to dig in could quickly find his or her way into the problem.  We would have this repository and an intro on Jade's documentation list and away we go.  Put in those terms, the issue is also one of opening the code up to others, and when I say this I am thinking of one of my clients, a professor, who has already started messing with the code to change portlet names, add images, etc.: that is, we are after not only good design, but accessibility, and good design through increased accessibility.  And we worry about accessibility because we want our early adapters to own the technology and contribute to the catalog of good designs and readily make the transition from intermediate to advanced users.  It is not that I haven't been to design school and can't build a decent design, but that once my users start participating in the design -- which they do with the current wonderful interface customization features of .lrn -- they start contributing all sorts of things that we professionals might not readily see.  Besides, the customer is always right, and if they are happy and use the stuff in their classes then I, as .lrn sysadmin, am happy, too.

Second, I think we want a way to drop a file onto the site so others could see and comment on the design, and that's where the Zen Gardens site model really shows its stuff: designers download the current css style sheet and upload their variation: the code on the sample page can then be viewed through this lens.  The Zen Gardens site features dozens of designs, serves as a showcase, and I like to think that such functionality would serve as a fine repository and community building function.  I'm not sure of how to do this other than simply adding such files by hand myself: I'd like to be able to upload my file and then see it linked on the .lrn gardens site so that I click on it and can see immediately how it works with the current array of style sheets.  If edit this page doesn't do it: what would?

I'd also like to find an explanation of how the current styles have been built so we might know better how to improve on them: this might involve some of those who have built the current styles sharing some of their notes.

Collapse
22: Re: .LRN Gardens (response to 1)
Posted by Jade Rubick on
In some ways, I think you might be getting a little ahead of yourself (please take no offense).

Before we get to upload all the designs, and work on that aspect of things, we have to standardize what the classes are named, where that's kept, etc..

And a doc needs to be written up so developers can move towards that standard. Otherwise, no packages will meet the standards, and the Zen Garden isn't possible.

I could be totally off base here, that's just my impression.

Collapse
23: Re: .LRN Gardens (response to 1)
Posted by Don Baccus on
You can start by looking at the existing class designations for the OpenACS standard CSS sheets in CVS HEAD.  You'll find things like "portal", "portal-head", "portal-body" which are shared by Lars's new default index page for acs-subsite and my "top-secret" (meaning mostly I was busy on other things in Guatemala) work on portals (the standard portlet style uses the master template css classes).

There's a bunch of other classes, like for stuff spewed by the  templated list utility Lars wrote not too long ago.

So ... Jade's right - don't get ahead of yourself!  We need to build on the incremental progress already made in moving towards the definition of standard css classes in a logical, well thought-out way.

When CSS stuff is properly defined and we have a reasonable default design for OpenACS and .LRN we can then start looking to supplying a library, if you will, of other designs folks can plug in just by switching CSS files.

Collapse
24: Re: .LRN Gardens (response to 1)
Posted by Paul Doerwald on

I think a good set of classes and id's in a master CSS is a good start, but I don't think it covers all the cases. There are far too many different layouts that you might want to do on any given page that can't be covered by a single big CSS file unless you start creating module- and page-specific classes in that large file.

I suggest trying to use the "Cascading" part of "Cascading Style Sheets" and have a master.css, modulename.css and pagename.css. I'll also comment on an override.css below.

master.css would hold font declarations, site-wide colour declarations, some classes for "normal" forms/tables/lists, etc. Elements that are likely to be used in a consistent way by every page and every module.

modulename.css would handle classes/ids specific to that module. For instance, calendar has some specific needs that aren't reflected elsewhere in the site. It doesn't take too much imagination to consider uses for module-specific CSS declarations — colour coding for bug statuses in the bug tracker; graphics and colours for new messages/postings in the forums; etc.

pagename.css would handle page-specific layout. div id 'b' floats to the right of id 'a' and 'c' appears underneath with a border around it. These things could be specified in a module CSS but they really don't belong in a site-wide CSS, especially when you consider the myriad possible namespace collisions.

Finally, override.css is where the real power of the "cascading" of CSS can be experienced. I haven't thought much about how this might be implemented, but the basic idea is that a course teacher could use this file to set CSS display attributes for her particular course. She can declare all the classes she wants the way she wants because the highest specificity CSS declaration wins. Control is restored to the site administrators who don't want her fooling around with the institution's logo by declaring the logo !important.

Similarly, an individual user could use override.css because he doesn't like that the owner of the bug tracker gave the "overdue assigned-to-me bugs" the "blink" attribute. Fixing that is just an override away.

It's still too early to suggest exactly how the classes and ids get laid out. My suggestion for finding the right approach would be this:

Using the "Eric Meyer on CSS" book as a guide on "good" XHTML/CSS coding a few module owners should start converting their modules to true XHTML/CSS. That means no <br> tags (this is a hard restriction to live with!), avoiding tables for layout, using id's over classes where possible, etc. When they're done and they have a bunch of CSS files, they start comparing notes on what they discovered. Each of them will have put together a "master.css" of declarations that they think belongs in the master. Whatever set of id's/classes they agree on should become the definitive master. Where possible they should align class and ID names. Through this process they'll end up with the start of a "Best Practices OpenACS/CSS" document. They'll all have to adjust their code and CSS declarations to match the Best Practices, but that will be a quick job because all of their pages will be valid XHTML and will require no further markup except adding additional IDs and classes.

In terms of specifics, it might be a good idea for a few people to work on converting a module to XHTML/CSS. Bruce and I briefly discussed doing this on some module when we're in Copenhagen at the end of the month. This work would get submitted back to the community for peer review to solicit comments. Perhaps some other module owners could try their hand at it as well. The next step could happen in Heidelberg where a couple other modules are attempted and a "Best Practices" document is written. Perhaps we could finish a first version of master.css as well.

What do you think of this approach?

Collapse
25: Re: .LRN Gardens (response to 1)
Posted by Don Baccus on
Yes, we definitely need module-specific .CSS files ... in fact the existing CSS I'm talking about is acs-subsite specific and  contains classes and ids (both are used currently) for elements that appear throughout a subsite.  navbars.  template list builder elements.  portlets (boxes).  stuff like that.

And we do have module-specific .CSS in some cases, for instance calendar.

So incrementally we're moving in a direction not much different than you're talking about, absent page-level CSS (do we need a standard way of specifying that?  it would seem to work against thematic unity within a package if one goes hog-wild) and the "overriding" notion.

I don't think there's any disagreement about continuing to push in the CSS direction ... just questions about who will do the work and when.  Including design of the structure, i.e. classes and ids.

Since Lars and Jeff have done more thinking/working on this than anyone else I'm aware of to date they definitely need to be part of any discussion on this topic.

Collapse
26: Re: .LRN Gardens (response to 1)
Posted by Jun Yamog on
wow lots of reply!

I agree with most especially Paul.  I like his general approach, master.css, module.css etc.  Also the fact that if we do code pretty ok, that means no using html for layout.  We should be ok and compare notes at a later time.  A champion for the css cause should be good.  So things can be accelerated, in the meantime I think we are ok.  We take small steps towards in css/xhtml.

I have edited the etp page, removing the subtopic.  I don't think its right to have a subtopic there for me.  I created a link on page to this thread.  Maybe we can put css related threads on that page.

Collapse
27: Re: .LRN Gardens (response to 1)
Posted by Bruce Spear on
Wow!

Thanks guys for the MOST EXCELLENT contributions!

Jade: I think my role here as relative newcomer is to champ at the bit and for those that know better to say "hold your horses!", and as has happened, "this is a better way to do it".  I agree, moreover, to the need for decent documentation along the way and as a goal, too.  So, I think we're reading from the same page.  Jun: thanks for making the link on the etp, that feels right to me at this point.

I am especially gratified by the concrete contributions of Don and Paul, and I'm looking towards the Copenhagen meeting as the place where a handful of us might  work some of this out in detail, posting what we are doing as we proceed.  I'm also as eager as Don is to hear from Lars and Jeff and suspect they'll be playing a leading role in this as we get going: as I wrote, it was from watching them work on css in Berlin that I felt confident that I could head in this direction with good company.

Good work!

Collapse
28: Re: .LRN Gardens (response to 1)
Posted by Don Baccus on
Actually the Copenhagen meeting would be an excellent time to discuss this given that Lars lives there, and that the meeting's coming up in a couple of weeks ... yes indeed!
Collapse
29: Re: .LRN Gardens (response to 1)
Posted by Jade Rubick on
It's good to see a team coalescing around this.

Bruce: thanks for spearheading this!

I like Paul's suggested approach, personally.

Collapse
30: Re: .LRN Gardens (response to 1)
Posted by Bruce Spear on
Thanks for the encouragement everyone!  Paul and I are discussing some goals, such as buiding a user interface that allows:

1. Dotlrn Gardens.  We would have alternative master styles that would be systematically applied across the application like any other skin system: users could stroll through the garden and switch on one after another a canned arrangement as they might like.

2. Roll Your Own.  From there we could offer user-friendly customizations of specific portlets and class/my space pages, similar in function to the current page customizations, where you can move things around, choose a logo, and change labels and font styles.

What would the engineering goals be?

1. Clear separation of database, logic, interface, and with the additional layer of a css functionality that speaks to the interface (as Paul has suggested to me) but staying out messing with the interface templates themselves.

It would be great to have others contributing their user and engineering goals so we might compile them and develop our strategies accordingly.

Also, as I am working my way through "Eric Meyer on CSS" and thinking of where I may next want to go I am thinking that there is a great distance between this hands on tutorial and the many wonderful, finished designs of the Zen Gardens and what I might do well to study is an interface design book, one that would help me compare and contrast different interface and web site designs and learn their principles of organization.  I'm wondering if others have come across anything like this.  I find all sorts of books on the topic on the publisher's lists, but I can't scan them online like I can in a bookstore, and the local bookstores don't have more than one or two of such things.  I'm looking for something along the lines of Lynda Weinman's "Creative HTML Design", I'd guess, but more sophisticated, meaning, tuned to the dynamic database-driven web sites that concern us.  Any suggestions will be greatly appreciated!  Thanks!

Collapse
31: Re: .LRN Gardens (response to 1)
Posted by Raad Al-Rawi on
Bruce

I remembered a couple of posts from a while back that might be of some use:

https://openacs.org/forums/message-view?message_id=113678

https://openacs.org/forums/message-view?message_id=116947

Collapse
32: Re: .LRN Gardens (response to 1)
Posted by Nima Mazloumi on

A proposal for how we might improve the use of CSS in OpenACS/dotLRN.

After some very interesting consulations we (Nima, Bruce, Andreas, Paul, Brademer, Denis, Lars) had during the bug bash in Copenhagen we came up with some ideas on how to make OpenACS fully css-able. We solicit your comments, advice, criticism, and blessings.

Before I start once again many thanks to the friends in Copenhagen who made this bug bash possible. Special thanks to Joel - you are a great release manager.

So this is the suggestion we would like to make:

1. Conception

We think that three or four style levels will be needed to allow for basic levels of site-wide stylistic consistency while allowing for individual application or portlet flexibility.

Level 1: Site-wide master layout sheet.

A master layout style that defines how to place the standard elements of the site. Think of them as header, footer, navbar, page. This sheet is used for templating purposes. So making changes here will change the position these elements.

Level 2: Site-wide master style.

A master style sheet that defines the most used elements used all over OpenACS/dotLRN. These are for instance

  • headings
  • html lists (ordered, unordered)
  • bold/emphasized elements
  • anchor tag (visited,...)
  • default text (font type, size, ...)
  • ...

Level 3: Builder Styles.

Default styles for the builders we have in OpenACS/dotLRN. These are:

  • formbuilder
  • listbuilder
  • portlets
  • ...

This already happens on package level but is still different from normal packages since the builders can be used everywhere within the plattform so their style sheets have to be included in the master template (as is done already).

It is important in the longrun to have more and more of such builders for standard components used in packages. Thus you can make development easier on the one hand but also enforce a consistent look and feel for the whole site.

Level 4: Application-specific styles.

There are a few packages, like calendar, with features needing styles that might go beyond inheritable upper level styles. There are now two different ways to define these package level styles

  • on a page level so we will have for each adp also an css
  • on package level within the resource folder

This will allow developers the freedom they need in special cases.

2. Steps to get there

2.1 First step

A dummy page is created using existing material to define a consistent style that can cover about 80% of what is described above without a single change required inside the packages.

The materials include:

  • default-master template for the layout elements we have
  • forms.css and lists.css for the builders we have
  • default-master.css for the standard elements required for the site

The resulting dummy page will include most of what is required in the site and serve as test case for

  • consistency of look & feel for all styles
  • consistency for all style classes defined for the site

At this stage we will have a proof of concept which can be discussed broadly in the community.

2.2 Second step

Once all suggestions, comments are taken into the consideration and compatibility is tested for browsers the styles and the default master template will be commited to CVS.

2.3 Third step

Create a style guide that explains in detail the design classes defined and how and where changes need to be made to change the look and feel of the site and of a package a developer is working on.

2.4 Final step

A design release is suggested for OpenACS/dotLRN doing nothing but fixing the code to make it fully css conform. For this purpose we need to define rules on how to transform the files.

These rules deal with

  • embedded style elements html tags
  • deprecated html tags like b, font...
  • ...

Once these rules are defined those that can be automated should be implemented as service package in OpenACS the other rules that require semantic knowledge have to be decided manually. This effort could be done in two ways: a css bash or decentralized through each package maintainer. While both approaches have their benefits the first also creates a platform to create a common understanding of css within the community and to share knowledge and best practise faster.

3. Moving towards XHTML

During the whole process the limitation of the efforts are set by only changing what is reusable whe we introduce xhtml to OpenACS in the long run. So we have to find out if there are any conformance issues that are required to ensure that all the work that is done won't be in vain.

 

Writing code, building community.

A number of us worry about how best: 1) to solve the technical problem, 2) build a consensus, 3) and build a development model that will encourage as many people as possible to contribute. We hope community members will respond to all three elements of this problem. We also hope to schedule some time working on this problem at the next Bug Bash in Heidelberg.

Many thanks to all who have contributed thus far!

 

Collapse
33: Re: .LRN Gardens (response to 1)
Posted by Dave Bauer on
<blockquote> It is important in the longrun to have more and more of such builders for standard components used in packages. Thus you can make development easier on the one hand but also enforce a consistent look and feel for the whole site.
</blockquote>

Builders are mainly includable templates, so making more includable components is a parallel goal.

Also on builder styles, it is probably good that the styles are defined for each builder, but they should be set at whatever level is appropirate. Probably default should be to set the styles at the subsite level.

It looks like a good plan.

Collapse
34: Re: .LRN Gardens (response to 1)
Posted by Nima Mazloumi on
Bruce, how far are we with the dummy page? can we use that to move to level one?
Collapse
35: Re: .LRN Gardens (response to 1)
Posted by Bruce Spear on
Thanks for the email, Nima.  I must report that since we last worked on this page I have been completely pre-occupied with insuring my local project's survival.  I have been looking forward spending my debugging time in Heidelberg immersed in the preparation of the dummy page and the next steps we might make with Dotlrn Gardens with the same longing as a normal person in Berlin, in the darkest days of January, for a brief moment slows in the hammering of paper with inked rubber stamps just long enough to dream of a nice cool drink in front of the banana plantations on a warm sunny beach on La Palma.
Collapse
36: Re: .LRN Gardens (response to 1)
Posted by Bruce Spear on
I'm wondering how best to move this project forward, and I'm trying to figure out where the obstacles lie. I'm not sure the obstacle is technical. Don, Nima, Paul, and others clearly see a way, if not the way. Following a few conversations I had about it in Heidelberg, I've got a couple of theories and wonder if others might give me a reading or offer others.

First, what we're talking about is much more global than our mostly bite-sized, ownable portlets or bits of functionality. Its nature and scope might better be considered to be on the level of the localization project.

Second, few among us are trained in design, we are programmers, and so when we build something that works we look right beyond the simple graphical elements to marvel instead at one or another display of powerful functionality, saying, "that's totally cool" when, to other eyes, it is not clear which button to push and in what order.

Again, please don't get me wrong: I think programming a marvel wrought out of pure air by wizards, and I want to know how to do what they do.

Why does does often seem to come at the end? Working on the form, we came up with all sorts of lists of new functionality, but we did not exchange a bunch of sketches or build elaborate user scenarios or personas. It is as if design is considered decorative, that functions lie deeper -- and having studied databases and marvelled at how we move things back from our tcl to our sql files, I almost believe it.

Design work appears to be proceeding mostly on the level of packages, and my impression is that individual developers get to it when they have reached a certain the limit, or when they are hired to build a site, at which point they hire someone else. In a curious way, it is as if, by hiring all these graphic designers on a site-by-site basis, we have not brought either their their designs nor their know-how back into the community. But it means we have a css system operating on the package level, which surely increased design costs.

The result is an uneven experience, tremendous usability problems, and additional costs to find remedy. For instance, the calendar in dotlrn 2.0 attracts the eye powerfully because it offers an intense combination of color and proportion. Dirk and others tightened it all up real nice and slick, so when I get there I feel like I am in a cool place and mostly know what I'm supposed to do. But when I go to upload a file or add something to the forum, I find myself, design-wise, in a completely different universe: I am looking at lists, white space, and various widgets floating about such that I actually have to read and interpret the text: the design is not helping me at all -- sorta like the way Donald Normal talks about the touch-tone telephone having lost its center to the point that no manner of documentation can help you find your way.
Deeper still, try reducing a community page to just one forum and the file storage module, like so many for small groups, count all the navigational and other elements and imagine some sort of signal to noise ratio: in this case, our design is incredibly noisy.

I need help with this question because we in the UAB are trying to develop a sense of priorities and proportion, and we are trying to figure out how best to proceed and even begin to play a leadership role. We have spent some time working on the forums, and forums interest many of us and many of our users a lot. But there are a lot of interesting projects, like assessment, that have good constituencies working for them for good reasons. I'm wondering if, instead of lobbying for one piece of functionality, we might better work on those elements of the infrastructure that affect all.

So my question is: is the problem with css/xhtml bigger than our desktops, something more "global" than most of us typically work with, and so become a task that lies sorta beyond our general expertise, interest, and organizational form? Wouldn't a refactoring for css/xhtml both help reduce graphics design consultant costs (fewer places to make global changes) AND make Dotlrn look much better out of the box AND be something that would benefit everyone?

You see what mischief I am up to: what do you think?

Collapse
37: Re: .LRN Gardens (response to 36)
Posted by Lars Pind on
Bruce,

I think you've got your head screwed on right.

Basically, what we need is what's called a "style guide" that outlines global interface elements, how they're used, and an initial design for them.

Then that needs to be translated into our default HTML and CSS.

The goal should be that the interactional elements are so solid that you generally don't want to change the HTML, but can change your fonts, colors, and detailed design through CSS alone. At least for most sites.

And yes, this is a global effort, which is going to require coordination, but more than that, I think it requires someone who knows what they're doing: An information architect and a designer, both experienced.

/Lars

Collapse
38: Re: .LRN Gardens (response to 1)
Posted by Ben Koot on
For starters I came accross this site that semes to cover most topics pretty well http://www.webstyleguide.com/index.html

Cheers
Ben

Collapse
39: Re: .LRN Gardens (response to 1)
Posted by Carl Robert Blesius on
Ran across a comment on standard compliant pages here
http://www.designbyfire.com/000085.html

The comment links here:
http://golem.ph.utexas.edu/~distler/blog/archives/000165.html

Summary: another reason for standards compliant pages is MathML support.

Collapse
40: Re: .LRN Gardens (response to 1)
Posted by Torben Brosten on
The House of Style[1] seems to be working to similar goals, and has incorporated much of the knowledge into software. I haven't had a chance to try the software, but it looks very promising.

Continuing some discussion from above:

I stay away from the # id tags. They are stipulated to only be used once per page, which is exactly the opposite of what is trying to be done here. When presenting a consistent looking page, re-use the same styles. Use the class attribute to avoid  the 1 use per display constraint.

I haven't had a chance to see how css is being handled for 5.1 yet, and probably should wait before presenting this thought. That said, here it is:

First, the zoned breakdown of css files above seems appropriate, especially if a parameter exists at the subsite and package level to specify a custom css file. Helps reduce the work in updating an openacs/dotlrn website.

Use the adp templating for specifying css where possible.

Sometimes, the templating system doesn't work, because the output has been created before reaching the template. For example, in the ecommerce package, images are returned pre-wrapped with links, and sometimes prices and other output is returned in blocks of html making it difficult to customize or adapt to css without creating new procs.

Maybe ad_div and ad_span procs can be created to easily, consistently wrap smaller bits of output when it is too confining to have the style determined by the adp template. (I think) most output is known to either be inline or block style at the tcl level.

Or, how about this: [ad_css $output $div_or_span_or_other_tag $class_name_or_attributes]. In the tcl, a check could see if the variables are defined in the template, and if not, use some defaults provided there.

For example, [ad_css $output $type $classname]  where the div or span tag is not carried through to output when $classname is empty/null.

Of course, this would only be when templating functionality is not directly available to strategically modify proc output.

1. http://www.westciv.com/style_master/academy/browser_support/

Collapse
41: Re: .LRN Gardens (response to 1)
Posted by Ben Koot on
An interesting article on (re) design,taking Useit as an example.... http://www.boingboing.net/2004/05/24/design_critique_of_j.html  .... Five designers, who have clearly been scorched by Nielsen's legendary rants about the primacy of usability over design, take on Nielsen's AlertBox house-style in a kind of overblown, gushy tone, and undertake to remodel Jakob's image so that his site is both usable and beautiful. It's funny, subversive and in the words of the Cos, "you may learn something before it's done. Hey! Hey! Hey!"  The full post is here...
http://www.designbyfire.com/000094.html

Ben