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

[Teemu A. <te...@di...>]

> 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.

Well, I meant that all CSS files are static. Support for introducing additional
CSS files that inherit main CSS properties would just prove useful to make
a tool that allows personalization of the interface by using a tool that
generates a new CSS file for the user. The result is a static file. I'm a big
fan of individual customization and this is the simplest and all we need.
In our toolset I receive a lot of requests from our users that they want to
customize their own space to their liking. It's their space after all and with
small steps I can make a tool for them to customize the layout. They don't have
to write the CSS their selves.

I hate browsing blogger.com and seeing that 95% of people use the same stock themes.
Editing the template is too much for most. With a small tool the CSS parameters could
be changed and an additional CSS file generated to change some basic properties in
the main theme. I bet most would use it. This is what I want OI to support and it
isn't too complicated in my opinion. Not at all. Nothing is dynamically generated
every time.

> This can be done
> easily enough by adding CSS files and/or replacing templates, can it not?

I need a tool for your granny to customize it for herself. Simple stuff. Most
user interfaces have common properties that could be changed at once with inherited
CSS files. Requesting her to write a custom CSS file just doesn't cut it ;)

> 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.

.ini files are fine, also. You are right. We still need a system wide CSS file,
though. server.ini?

> 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?)

User customization doesn't need the table, either. I'm not asking OI to implement
users custom colors etc. I can do it myself. I ask the framework to support
media types to select an appropriate CSS file out of a time based on accessing client
and some additional CSS files I would like to use to provide user constomization
to themes. It's my problem how those additional CSS files are generated.

> 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. :)

Yep. We have gone crazy with our UI in Dicole. I also propose that <table>:s are
not used to align stuff on the screen in OI basic theme. Columns can be achieved
through other means.

> 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?

What comes to my mind is the box model of Mambo (a wacky PHP based CMS). It has
footer, header and the body part which is divided into left, right, middle, top and bottom.
Then there are some basic interface parts like tables, breadcrumps, tree navigation etc.
The nicest thing is you have boxes (similar to OI) that contain all kinds of dynamic data and
some UI through which you can decide in what part of the interface they go:
right, middle, left etc.

In Dicole we went and implemented content of individual boxes in a very detailed way.
For example, if you have a table, you have each cell of the table executing INCLUDE/PROCESS
of customly requested templates. Those templates might even include more templates etc.
It is very flexible and allows nice tricks but you can imagine that a page has easily
about 100-200 includes. You want to keep that amount very low per page.

We generate forms with this system. We have a table template which could include any custom
templates in the cells. So the cells are basically input field templates (values) and simple text
templates (keys). Lots of includes, not good.

> 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?

A very specific widget system allows you to write a UI library that operates similarly
to something like Perl/TK. You can have containers and all kinds of stuff in them.
The UI logic is then written in perl but separated from the business logic. The view,
how the widgets are displayed based on the generated data structure is also separated
for the interface designer. The drawback is that the designer loses some of the control
on how various pages look but well, the result is more consistent and easier to maintain
so.

So with a web based widget UI toolkit, you basically define various parts your application
may have. The most useful part for the UI widget toolkit is obviously the application part
itself (excluding page navigation, footers, login boxes etc). Dynamically generating each page
in a very detailed widget system is very slow in TT because of hundreds of includes, so this
could be optimized by pre-generating applications. Detailed widget systems are to some degree
predictable, so: on server startup (or when a single application action is accessed the first time),
the UI templates for various application actions/tasks get generated once. The resulting output
for each page is a new cached template toolkit template that is able to take in business logic
from the application. Server startup will be slow but this way we have only one template include
for each application task, problem solved.

That's the way I thought I would like to optimize our system but it sure requires a lot
of thinking to implement correctly. We will lose some freedom and control in our templates but
I think the consistency is worth the effort.. and it would be the coolest UI toolkit for the
web ;) When writing a new application for OI, in most cases you don't have to write a single
template. Saves a lot of development time.

-- 

Teemu Arina, CTO

Ionstream Oy / Dicole
Komeetankuja 4 A
02210 Espoo
FINLAND
Tel: +358-(0)50 - 555 7636
skype: infe00
Corporate website: http://www.dicole.com
FLOSS in education blog: http://flosse.dicole.org
Personal weblog: http://infedelic.blogspot.com

"Discover, collaborate, learn."