Re: [Openinteract-dev] OI2 + CSS + XHTML thoughts

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Teemu Arina wrote:
> Salve,
> 
>> - We create a single set of CSS files that describe the look of all
>>  standard page components and widgets, using CSS classes, ID's and
>>  cascading/inheritance as appropriate.
> 
> Modified themes (different color schemes etc) could be implemented 
> with inherited CSS files. That way I could create user specific 
> themes, so the user could select the colors etc. she/he wants and the
>  code generates an inherited CSS file, with only the color 
> definitions in it.

If I understand you correctly, you'd like to generate CSS files? (as
opposed to generating CSS dynamically per-request.)

I was thinking more in the direction of _not_ to generate any CSS
_at_all_ - that all CSS files are static.

Generating CSS would be useful only for the simplest alterations, like
colour schemes, border width and such. CSS is even now such a complex
beast, that creating code to generate it would more likely increase
total complexity instead of decreasing it.

Furthermore, I'm imagining (semi-) dynamic CSS customisations are mostly
useful for user-configurable (personal) themes and not much more. I'm
having trouble seeing how this kind of feature is enough for the people
who would like to make the OI2 UI adhere to their company website
profile. The people who like the default layout can probably find the
correct CSS file and change colors and looks there, and those who don't
most likely won't appreciate the added complexity when they start adding
CSS files and changing templates.

Personal themes is IMHO simple fluff, mostly to make the "ooh! shiny!"
people happy, and not much more. But we _should_ allow OI2 to easily
adhere to an established website profile in a company. This can be done
easily enough by adding CSS files and/or replacing templates, can it not?

>> - We only allow different "themes" by adding alternative CSS files,
>>  and referring to them in the usual manner from the XHTML 
>> documents.
> 
> Exactly, my previous point. I guess we need a table:
> 
> theme_id = ?
> base_theme_css = ?
> theme_css = ?
> media = ?
> title = ?
> description = ?
> 
> Based on that, appropriate links to CSS files coul be generated to 
> <head>.

Hmm... I was thinking more in the direction of having a standard set of
CSS files for all pages, and then let each application add stylesheets
on it's own, either by using an "append_style"-like method, or perhaps 
by tweaking a configuration file (e.g. the app's action.ini file). No 
tables should be needed at all.

But that may be short-sighted of me. What are the arguments in favour of
having CSS metadata in the database? (other than enabling user 
customisation?)

> We also might need a mechanism to introduce CSS files for different 
> media types (for example, hiding certain navigational goodies from 
> small screen terminals) and browser types.

Right. The mechanisms I proposed to do this were the "append_style" and
"append_alternate_style" methods.

> Our experience is that it's possible to write a single CSS file that
> is cross-browser compliant from NS4 to latest 
> opera/safari/ie/mozilla, but requires enormous amount of work 
> (several months) to get right if the page is even a little bit more 
> complicated.

I actually like the minimalist style OI2 currently has, even if it's not
among the prettiest. If we try to keep the layout as simple as it is now
(just the content/forms, and the concept of "boxes") I'm sure we can
tidy up the look and reduce the number of templates without adding too
much new functionality. :)

And as long as we KISS, we'll hopefully stay out of the compatibility
trap. ;-)

>> - Likewise, there should be _no_ ECMAScript/JavaScript inline in 
>> the templates. We'll only allow references to separate .js files so
>>  the browser can load them. If we need to use JavaScipt triggers of
>>  some sort (onmouseover, etc.), we add these from the JavaScript 
>> files by manipulating the DOM tree.
> 
> A reason to include meaningful id properties to most central tags.

Exactly. :)

>> - We should also make sure all XHTML documents are using UTF-8 as 
>> charset. This may be our first step in making all of OI2 use UTF-8
>>  :). In order to ease transition to UTF-8, we _may_ want to try to
>>  use HTML entities whenever common eight-bit characters are used 
>> (e.g. in I18N msg files, templates and error messages.)
> 
> I've got four thumbs up here. Gettext in the I18N side ;)

Gettext vs. Maketext vs. [alternatives] most likely deserves it's own
discussion. I'm sure Chris and others have some thoughts about that. :)

>> - Keep the templates as simple as possible, trying to reduce the 
>> "depth" of INCLUDE and PROCESS calls. A maximum depth of two or 
>> three levels should be strived for.
> 
> Oh yeah.. Template Toolkit isn't very good at executing multiple 
> levels of INCLUDE/PROCESS. With Dicole we implemented a fairly nice 
> widget framework out of TT templates, resulting in quite a lot of 
> depth. In theory it was great but in practice too slow. We have had 
> to optimize certain parts by adding a partly compiled template for 
> certain heavily used applications which have complex views.

Hm. Yes, I can imagine the templates can become quite slow if we don't
take care... Do you have any thoughts and experiences on how to create a
good set of templates?

At met.no we're thinking about dropping the "forms in tables" paradigm 
entirely, and replace it with CSS-formatted definition lists, then 
removing any "single includes" (files that are only included from one 
template), require all widgets to have a label, and drop the distinction 
between widgets in rows and plain widgets... In sum, this should reduce 
complexity and depth significantly. :)

We'll show you the code when it's ready. ;-)

>> - If we can avoid breaking the widget API, fine. But when we have 
>> good reasons to break it (e.g. removing the old base_theme-specific
>>  stuff), then we go ahead and break stuff.
> 
> Break, smash and kill it. Basic header, body and footer templates are
>  enough, maybe some other commonly used sections in body can be 
> separated for easier modification/maintenance.. but don't do what I 
> did (widgeting everything) =)

I kind of like the idea of widgets. It lets us do the basic stuff easily
while keeping the resulting HTML consistent, and if I need to do things
my own way, I still can.

What kind of alternatives would you suggest?

>> - Likewise standardized a way of telling about program state. (e.g.
>>  a place on the webpage where one always can expect to see "where" 
>> in an application one currently "is", at any given time.)
> 
> Sitemap? Easy to generate out of registered applications if they 
> include REST parameters and titles for each..

That's true. A generated index page would also be useful - perhaps based
on keywords gathered with other tools? (e.g. from user-contributed tags
with Chris' delicious_tags package, or something automatically gathered
using an indexing tool like Plucene?)

But with "program state" I was thinking more of Jacob Nielsen's
usability heuristics[1] where he suggests lots of relevant things for us. :)

- Salve

[1] http://useit.com/papers/heuristic/heuristic_list.html

-- 
Salve J. Nilsen <salvejn at met dot no> / Systems Developer
Norwegian Meteorological Institute           http://met.no/
Information Technology Department / Section for Development