Am 11.10.2004 um 02:28 schrieb Geoff Deering:
I spent a few days trying to customise a site and found I was creating more problems than solving them and just did not have the time to address the issues, that could have been solved more easily addressing the same framework where it was abstracted to just HTML and CSS.
i'm not sure if i can follow. you mean you wanted to configure the site (portlets, section items, and similiar things) and got problems, which you would want to solve with markup rather than tools?
personally i find it better to have such things separted from the markup. you gain a lot more flexibility, and easier extensibility, when you use a tool for a specific job, and not markup. it's not a designers job to do that anyway, it's rather something an administrator should do. and in case of CMSes they are often more advanced users, but can't or don't want to touch templates.
actually there are a lot more reasons for tools, like migration, but thats a different topic.
I think this is a problem that CMS designers and Web Application Designers are not addressing properly, there needs to be a sense of design framework in the HTML/CSS interface like that presented by CSS Zen Garden, where it is easy to make flexible redesigns, just working with the basic tools.
so, thats more the topic i aimed at, rather than plone ;)
yep, i think i understand what you mean. and i think my company is working on it (various open source packages for the lovely zope 3), to be more specific, on something that aims at developers, administrators and designers at the same time. creating such a framework is a quite complex and needs some "new" concepts. we call the ones with the biggest impact "pagelets" and "view schemas".
pagelets are configurable parts of the interface, that fill predefined regions, but are able to hold other regions too. that makes it easier for administrators to decide which part goes where, easier for developers to integrate their application tighter without breaking other things, and better for designers because they only end up with the things that are really needed.
with view schemas one is composing a view out of widgets instead of using a hardcoded template. the advantage of that is, you can override a set of widgets with your site specific widget set, and you automatically apply your UI changes to software package you haven't even touched. so it's a sitewide customisation, where all the packages you use just fit in, UI wise, automatically.
so with that tools you could, if you want, be totally different than the initial skin, but without having to change everything you want to put in, which could break the software once you update it. so you could say it's a long term strategy which aims at having the ability to use the latest software packages without much effort.
I think Plone would be used a lot more in the design and CMS communities.
right. plone isn't able to do everything one could want. it's a "classic" cms. but i haven't seen many designers picking up plone yet :)
To a lot of users this is very confusing. It's not easy to identify native form elements.
yep agreed again. thats one of the arguments i'm always bringing when it comes to html forms and styles.
Many of these types of designs go against the basic design guidelines for software and I don't feel they comply with the upcoming core of WCAG2; perceivable, operable, understandable and robust
http://www.w3.org/TR/2004/WD-WCAG20-20040730/#overview-design- principles
again, you guessed it, agreed. (note: Tom Croucher, partner at my company, is one of the WCAG 2.0 editors)
That' my thoughts on it anyway... probably get howled down..
nope, see above :)
regards, michael -- Michael Zeltner Netalley Networks LLP http://www.netalleynetworks.com/
********************************************************* The CMS discussion list for http://webstandardsgroup.org/ *********************************************************
