Menu
▾
▴
[Openinteract-dev] Further work on forms/layout (Was: RE: Building upon your "CSS-Only, Table-less Forms"?)
|
From: Salve J N. <sj...@pv...> - 2005-06-29 18:09:33
|
[Cc: to Chris Winters and the dev-list, so everyone gets to know what we're up to. The topic is an OI2 version of Jeff's non-sucking CSS-only forms that he made available at <http://jeffhowden.com/code/css/forms/>] Jeff, Suddenly, Jeff Howden uttered: >=20 >> <><><><><><><><><><><><><><><><><><><><><><><><><><><><>< >> From: Salve J Nilsen [mailto:sj...@pv...] >> >> I'm in the process of creating a new set of templates >> for an Open Source CMS system called OpenInteract2[1], >> and would very much like to base them on your work... >> >> Would you allow me to do that? >> <><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > > Yes, with two caveats. First, I'd like to be involved in the process.=20 > Second, I'd like to be given credit. Sure! If you have the time to volunteer, then that would be great! (And=20 all credit you're due, you shall recieve. ;-) > I'm not necessarily volunteering to html-code/skin every single form in= =20 > the system, but I am volunteering to build the initial "all cases=20 > visible" sample form to an approved design spec, including upgrading the= =20 > CSS in my current example to handle any new layout requirements the=20 > system/design requires. That sounds OK with me. (It's actually the way I'd like it too. :) To give you some background, you can have a look at our initial thoughts=20 at <http://sourceforge.net/mailarchive/message.php?msg_id=3D11059887>. Feel= =20 free to join the list and introduce yourself! We'd be more than happy to=20 discuss details with you. We haven't created any formal requirements, but I've written down some of= =20 my thoughts on the issue below. Feel free to comment and improve. :) --=3D=3Do=3D=3D-- Forms/widgets requirements: Basically, we need the following "widgets" (which is generally the same as= =20 "forms", except that one widget can consist of several related form=20 elements), in addition to the ones you've created already: * A "date selection" widget, consisting of three <select> dropdown lists (year, month, day). I'd like to replace this one with a proper calendar widget, sometime. * If it's feasible (and you have the time), a "multiple select" widget like this (use a fixed-width font to see the ascii=ADdrawing): +--------+ +--------+ |foo | |bah | |bar | [>>] |quux | |baz | [->] | | |bom | [<-] | | | | [<<] | | | | | | +--------+ +--------+ Where the [>>] and [<<] buttons transfer all <option>s from one <select> box to the other, and [<-] and [->] transfer just one at a time. You don't have to bother with the JavaScript details (we already have that covered), just make it look OK. * We need a widget that can edit hirearchical data in an easy and sensible way. I have a couple of ideas if you're interested in looking at this, but if you're not, then that's fine too. :) * If you still have too little to do, then "View"-versions of the widgets would be nice. Especially for list-type, tabular and hierarchical data. * Others? Other features that would be nice: * Some minimal/clean HTML-only tabs, similar to the feature described at <http://www.w3.org/Style/Examples/007/target.html>, that work nicely with the content area. * An extra-wide textarea, which could be used with WYSIWYG HTML editors like FCKeditor. <http://www.fckeditor.net/> * A proper calendar widget, e.g. a lightweight version of <http://www.dynarch.com/projects/calendar/> CSS/looks/layout requirements: * A clean, minimal design. There's no point in making lots of fancy features and graphics, just enough to make it neat and usable. It's more importnant that the people who'd like to use OI2 can change it without much effort. * All CSS color information should be contained in a seperate CSS file - to make it easy for other webdesigners to create color schemes. CSS related to the forms must be placed in a seperate file too, for easy access/cascading. Likewise for page structure and menus. An example set of CSS files, may be: - default-layout.css - default-menus.css - default-content.css - default-forms.css These should be nicely overridable by appending new CSS files to the CSS @import list. (And thus we achieve "cascading" :) * Looks: The traditional page layout for OI1 and OI2 has been two columns (as far as I know): |<------------------ browser page width ---------------->| |<---------- variable-width -------->| |<- fixed-width ->| | content | | menus | I'd like to change this to a two/three-column layout: |<- fixed ->| |<----- variable-width ----->| |<- fixed ->| | menus | | content | | OPTIONAL | | | | | | menus | Without the optional menus, the columns should look like this: |<- fixed ->| |<------------- variable-width ----------->| The optional menus column is for application "toolboxes" that could contain almost anyting (they may be subject to access restrictions, that's why they're "optional"). The left menu column is for hirearchical lists and/or menus. * The way you structured your forms is a great start. The only thing that could be improved, is to somehow make them variable-width, so they look good in (or even fit well into) the content column: |<--------------------- content column ---------------------->| |<- label ->| |<- form widgets or comments ->| |<- info-box ->| | | | variable-width, with | | | | | | optional help link | | | We also need space on the right side of each form element for an optional [help] link, similar to this: [<a class=3D"help" href=3D"/some/help/url" title=3D"A short help text or explanation">?</a>] * It would be nice if all CSS measurements were in em's and not px'en, so that page scaling works better (increasing the text size in your browser). * The page should look good when serialised (e.g. when turning off CSS), with the left menu columns showing first, then the content, and then the optional menus last. The forms and content must make sense when you look at it serialised, and read out the text aloud. * Likewise, everything must work flawlessly without javascript. I hope these "requirements" aren't too difficult. Are you up for it, Jeff? :-) - Salve --=20 #!/usr/bin/perl sub AUTOLOAD{$AUTOLOAD=3D~/.*::(\d+)/;seek(DATA,$1,0);print# Salve Joshua = Nilsen getc DATA}$"=3D"'};&{'";@_=3Dunpack("C*",unpack("u*",':4@,$'.# <sjn@foo= =2Eno> '2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}"; __END__ is near= ! :) |
