[Openinteract-dev] RE: Further work on forms/layout (Was: RE: Building upon your "CSS-Only, Table-less Forms"?)

[Jeff H. <je...@je...>]

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