Menu
▾
▴
[Openinteract-dev] RE: Further work on forms/layout (Was: RE: Building upon your "CSS-Only, Table-less Forms"?)
|
From: Jeff H. <je...@je...> - 2005-07-01 09:23:10
|
Salve, ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > From: Salve J Nilsen [mailto:sj...@pv...] > > To give you some background, you can have a look at our > initial thoughts at > <http://sourceforge.net/mailarchive/message.php?msg_id=11059887>. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I have not had a chance to read the above yet, but will do so when I get a Net connection next. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > Feel free to join the list and introduce yourself! We'd > be more than happy to discuss details with you. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I'm already subbed to way more than I can handle, but I'll give it a go for a short while. If the traffic is tolerable, I'll stay. ;) ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > Basically, we need the following "widgets" (which is > generally the same as "forms", except that one widget > can consist of several related form elements), in > addition to the ones you've created already: ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I expected some controls that might be called widgets that were made up of more than a single control. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * 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. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Already done. It even corrects the number of days available for the month selected and whether or not it's leap year. http://jeffhowden.com/code/javascript/calendar/ I can integrate it easily into the example. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * If it's feasible (and you have the time), a > "multiple select" widget like this (use a > fixed-width font to see the ascii-drawing): > > +--------+ +--------+ > |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. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< My custom CMS uses something just like that. We also have another one like the following that allows controlling the order of the items on the right: +--------+ +--------+ |foo | |bah | |bar | [>>] |quux | [<<] |baz | [->] | | [<] |bom | [<-] | | [>] | | [<<] | | [>>] | | | | +--------+ +--------+ You've got to imagine the angle brackets on the right side are turned 90 degrees clock-wise. I have written scripts to make it so that more than one item can be selected and the ranking buttons still work correctly. I also have enabled additional events like double-clicking to move items out of one list and into the other. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * 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. :) ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I currently use a multi-select with padding to represent the hierarchy. The control also has indent, outdent, rank up, and rank down buttons. It even goes so far as to select all children when a parent is selected. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * 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. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I'll need more information on what you mean by "View"-versions. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * 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="help" href="/some/help/url" > title="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 > > -- > #!/usr/bin/perl > sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# > Salve Joshua Nilsen > getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# > <sj...@fo...> > '2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}"; > __END__ is near! :) > |
