Menu
▾
▴
openinteract-dev
|
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= ! :) |
|
From: <an...@io...> - 2005-06-30 22:15:08
|
Salve referred to OpenInteract2 as a CMS in his post.. I personally don't see OI2 as a CMS, but an application framework. These are two quite separate things in my opinnion.. You can build a CMS on top of OI2 but I think that OI2 should not even strive to be in itself a CMS. This doesn't make it wrong to design a new HTML widget set for OI2, but I think we should keep in mind that OI2 as an application framework does not impose any specific template engine to the developer. How are we supposed to distribute html widgets which are independent to templating engine? Ofcourse we can implement these templates to only one engine, for example TT2, as a base package, but this raises an even more interesting question: What are base packages for? Are they trying to implement: * a CMS on top of OI2? * a base for a CMS to grow on top of OI2? * a generic but technology specific (TT2 and WWW) base for applications? * a generic base for applications? * a base for Chris' blog? (;)) What if somebody builds an application with OI2 which is not a CMS? And why should we even be doing yet another CMS or even a customizable CMS engine? And as AJAX is now a hot topic - what if somebody would want to use OI2 just as a AJAX backbone (for which it would suit quite well in my opinnion), what role would the base packages play? So what is OI2 and what is the purpose of base packages in your opinnion? - Antti PS. This relates somewhat to the JIRA issue to allow creating an website wihout base packages and I will comment on that more after this discussion :) |
|
From: Salve J N. <sal...@me...> - 2005-07-05 12:01:10
|
Antti M Vähäkotamäki wrote: > Well to make this clear from the beginning - I'm not in any way against > you building new templates. They will be needed for sure. I'm just > trying to look at the bigger picture. > > Salve J Nilsen wrote: > >> Urgh... I'm sorry about that. OI2 is definitly a application framwork >> (where of "CMS" is only a minor part.) I didn't mean to cause this >> confusion. :-\ > > Well what I was thinking was more in the lines of OI2 not being even > partly a CMS. I'm sure you can mold OI2 into whatever you want it to be... :-) > Sure I would heartly welcome a package which would implement all kinds > of CMS functionality on top of OI2, and an another package which would > provide a bucketfull of general TT2 templates which are easily themable > by pure CSS, but I'm not sure if either of these should be included in > the base packages IF they are to provide a general base for applications. I think having a functional website with CMS, news and security features as part of the "base" is not only good, but the Sensible Thing to Do. OI2's CMS features (e.g. page management and publishing, user/group management, interface consistency features, templates, logging framework, etc.) may be a bit lacking (in consistency, standards compliance, visual beauty and so on.) but having them available from a basic install quite important. Who do you think would be impressed by a application framwork one can't test and experiment with? > So probably the bigger question here is the meaning of base packages - > what are they for? They're there so you can get a notion of what's possible to do OI2, and when you've seen _that_, the _real_ big questions show up: How can I use OI2? How can I improve OI2? What should be improved? How easy is it to improve OI2? How can I make it easier to improve OI2? What should be improved so OI2 becomes easier to improve? > Also currently the building block TT2 templates for OI2 website aren't > even in a base package but they are directly in the website's template > directory. This makes them impossible to be substituted or modified > through the management system with packages. I'm not sure if the current > theme implementation can be used to override these (we are using it only > to load a single theme which causes a constant 50ms addition to each > request ;-) ), but if we are getting rid of the current theming for a > CSS only theming, we can't do this anymore and the whole thing should be > rethought. I'm sure you can find or formulate some bug reports that describe what your problems are. <http://jira.openinteract.org/> ;-) (And yes, the theme implementation sucks :) - Salve -- Salve J. Nilsen <salvejn at met dot no> / Systems Developer Norwegian Meteorological Institute http://met.no/ Information Technology Department / Section for Development |
|
From: <an...@io...> - 2005-07-05 22:14:38
|
I'm sorry to be quoting this quite extensively since the former posts did never make it to this list. Salve J Nilsen wrote: > Antti M Vähäkotamäki wrote: >> Well to make this clear from the beginning - I'm not in any way >> against you building new templates. They will be needed for sure. I'm >> just trying to look at the bigger picture. >> >> Salve J Nilsen wrote: >> >>> Urgh... I'm sorry about that. OI2 is definitly a application framwork >>> (where of "CMS" is only a minor part.) I didn't mean to cause this >>> confusion. :-\ >> >> Well what I was thinking was more in the lines of OI2 not being even >> partly a CMS. > > I'm sure you can mold OI2 into whatever you want it to be... :-) Well I just don't see that the products being developed on OI2 as a part of OI2. They run on OI2, they can be used to promote OI2, but they are not part of OI2. >> Sure I would heartly welcome a package which would implement all kinds >> of CMS functionality on top of OI2, and an another package which would >> provide a bucketfull of general TT2 templates which are easily >> themable by pure CSS, but I'm not sure if either of these should be >> included in the base packages IF they are to provide a general base >> for applications. > > I think having a functional website with CMS, news and security features as > part of the "base" is not only good, but the Sensible Thing to Do. OI2's > CMS > features (e.g. page management and publishing, user/group management, > interface > consistency features, templates, logging framework, etc.) may be a bit > lacking > (in consistency, standards compliance, visual beauty and so on.) but having > them available from a basic install quite important. Who do you think > would be > impressed by a application framwork one can't test and experiment with? Again, I'm not saying that developing this stuff is bad and it shouldn't be done. As you state, it's vital that there exists some ready code to experiment with and to reuse when needed, BUT making this code a part of OI2 base is not in any way vital for making it experimentable or reusable. One could argue that it probably actually hinders the reuse value of base packages that they are distributed as bulk and thus their interfaces never need to be polished for reusability. When you use OI2 in production, you probably do not want those OI2 base modules present which you don't use since they take lot's of space in memory when the memory consumption is alrealy huge. And since it is hard to separate them or use them selectively, you are usually better off with just replacing the needed parts alltogether. >> So probably the bigger question here is the meaning of base packages - >> what are they for? > > They're there so you can get a notion of what's possible to do OI2, and > when > you've seen _that_, the _real_ big questions show up: How can I use OI2? > How > can I improve OI2? What should be improved? How easy is it to improve > OI2? How > can I make it easier to improve OI2? What should be improved so OI2 becomes > easier to improve? I don't think that every user who writes his application on OI2 should be an OI2 developer. In fact I think that OI2 developers' main goal should be that none of OI2's users should need to be OI2 developers. I do agree with you that at the moment we aren't quite there yet ;-) but it doesn't change the goal. >> Also currently the building block TT2 templates for OI2 website aren't >> even in a base package but they are directly in the website's template >> directory. This makes them impossible to be substituted or modified >> through the management system with packages. I'm not sure if the >> current theme implementation can be used to override these (we are >> using it only to load a single theme which causes a constant 50ms >> addition to each request ;-) ), but if we are getting rid of the >> current theming for a CSS only theming, we can't do this anymore and >> the whole thing should be rethought. > > I'm sure you can find or formulate some bug reports that describe what your > problems are. <http://jira.openinteract.org/> ;-) > > (And yes, the theme implementation sucks :) Well in fact I'm trying to formulate it by doing this discussion. I have already filed a JIRA issue for a possibility to create a clean OI2 website wihout the base packages. Chris asked me if this was necessary and I'm trying to figure it here also myself by discussing the issue ;) - Antti |
|
From: Teemu A. <tee...@di...> - 2005-07-05 22:25:00
|
>> Well what I was thinking was more in the lines of OI2 not being even >> partly a CMS. > > I'm sure you can mold OI2 into whatever you want it to be... :-) I believe that for a project to become _the_ option for a certain target audience, it should state it's mission and roadmap pretty clearly. This builds up confidence in the platform and provides an answer to the most important question: ok if we start to use it now, how is it going to improve and in which direction? Answering, that it can be anything you want it to be is pretty confusing. Let's revisit openinteract.org first paragraph. Let's call it the mission statement: "OpenInteract is a web application server written in Perl. It features integrated data persistence, security, user and group management, plus an easy way to create and distribute fully database-independent applications." I might also emphasize that it cuts the development time for implementing most of the things you need when writing web applications. Less code, more consistency, extensibility, modularity and easier tracking of code revisions. So if it's intended as a base for web application development, then why on earth does it require you to install an CMS you might have no use for? (never mind a news, comments and a whats new package). If you want to get rid of these, skipping the installation of the SYSTEM package bundle excludes not only the CMS function (page) but also all the necessary modules that are required for OI2 to function. I understand the importance of functional examples like an CMS. Developers should have something to play with to come up with ideas how to use the platform and how to improve it. As such, I believe these should be optional packages, serving as one of the examples how OI2 can be used. As OI2 consumes so much memory and dependencies already, I believe there is no reason to "pollute" the base installation with higher level functionality you might never need when developing a web application, say an address book. It's simply just useless if you are not writing a CMS but something totally different. This is certainly a limit in the application framework if it's considered to be an application framework. It forces you to run code in the application stack you might never need. In my opinion, for the system to function mainly as a web application framework, it should invest development time mainly on that statement. In my ideal scenario, when you install the OI2 base, it would greet you with a welcome message, the documentation package and clear instructions on how to install example functionality like the CMS, news and comments packages to play with. All the other functionality, like security, user/group management, UI widgets etc. are very important for web application development. Higher or more specific implementations should be optional. Although the lower level functionality is important, sometimes these also do not serve the purposes. We replaced/extended most of the user/group/security stuff in our OI2 application called Dicole (demo at http://dicole.net) because doing so served our purposes. For example, in securities we needed more detailed access rights other than action/task level security and SPOPS object security so we replaced the security framework and disabled the OI2 implementation. We could have extended it if given more thought, but afterall, I'm all thumbs up for such low level built-in functionality in the base packages. > They're there so you can get a notion of what's possible to do OI2, and when > you've seen _that_, the _real_ big questions show up: How can I use OI2? How > can I improve OI2? What should be improved? How easy is it to improve OI2? How > can I make it easier to improve OI2? What should be improved so OI2 becomes > easier to improve? These questions can be answered if the base installation greets you as a web application framework and not as a generic CMS. Despite some things I'm not happy with, OI2 is still the best decision we have made when we looked for a new base to build upon. We have done more during this time for our customers than we could have done without. The design of the web application framework is brilliant and I'm happy to help it to be even better. Regards, Teemu Arina Dicole |
|
From: Salve J N. <sal...@me...> - 2005-07-18 16:37:13
|
Teemu Arina wrote:
>>> Well what I was thinking was more in the lines of OI2 not being even
>>> partly a CMS.
>>
>> I'm sure you can mold OI2 into whatever you want it to be... :-)
>
> I believe that for a project to become _the_ option for a certain target
> audience, it should state it's mission and roadmap pretty clearly. This
> builds up confidence in the platform and provides an answer to the most
> important question: ok if we start to use it now, how is it going to improve
> and in which direction?
>
> Answering, that it can be anything you want it to be is pretty confusing.
Argh. I was trying to avoid the public relations discussion... :-\
I'll try to rephrase a little..
Basicly I agree with you, but I also think the question of "wether or not OI2
is a CMS (or has a clear end-user decipherable mission statement)" isn't the
most important question at this stage. Today, I think we're much better off if
we try to make OI2 as developer-friendly as possible.
To do this, it may help to point out that OI2 isn't a _product_, but a
_project_. Asking product questions (e.g. "Does it do A") can be useful, but
not nearly as much as asking project questions (e.g. "Can someone help me write
feature A" or "How can we make it easy for someone to write the A feature").
If we hace a quick look at the state of OI2 (today), it may look something like
this - AFAICT:
1) OI2 is Big and Complicated
2) Although the beta period for OI2 has lasted forever(tm), there's still a
large amount of bugs (currently around 60 in JIRA). :-\
3) OI2 has some good "infrastructure" features but few "application"
features. Developers like the former, users the latter. Who's more
important?
4) OI2 is pretty well documented (I'm guessing 75%), but lacks a lot of
common things that make large amounts of information more comprehensible
to the reader (e.g. ER diagrams, class diagrams, data flow diagrams).
5) The OI2 community is too small and quiet. :-(
6) Contribution to the project is difficult - perhaps due to social quirks
(shyness of speaking in public fora? our inability to follow up requests
on this mailing list? the "Jante law"?), but also due to technical
complexity (finding where to add a feature requires a lot of digging).
7) One _can_ say OI2 has a lacking webpage, unclear about mission and
perspective.
8) We have an underutilized wiki (is anyone actually reading or using it?)
9) The mailing list archives and bugtracker have little sense of connection
between them, the website and the wiki. What can we do to make all this
information less fragmented? Is there a way we could integrate JIRA with
the main site? Or use a OI2-native wiki instead of TWiki?
10) We have only a vague sense of what kind of audience OI2 is for. It seems
to be mainly for advanced web application developers, but we'd like more
people to use it, right?
11) Chris has always been doing most of the significant development, but like
the rest of us, he's swamped in distractions from from doing the Important
Stuff - namely improving OI2. :)
All these points lead to interesting project questions. Ask yourself these
questions, find if some of them interest you, try to answer these, and finally
try to implement the answer. (And should you come across something that stops
you from implementing it, then fix that first)
OI2 is an open source project, dammit. Why bother with the self-scrutinizing
philosophical questions when we can change the world with code? We _have_ the
freedom to do watever we want, and _that_ is why I'm sure you can mold OI2 into
whatever you want it to be... :-)
> Let's revisit openinteract.org first paragraph. Let's call it the mission
> statement:
[deletia]
Sure. Fix it if you have access, write a bugreport if you haven't.
Chris, is it feasible to give people access to improve the website?
> So if it's intended as a base for web application development, then why on
> earth does it require you to install an CMS you might have no use for?
What's more important? That new users and developers can get a site up and
running easily, or that experienced developers have a "clean install" to work from?
Should OI2 _only_ be an application framework, or should it also be usable
("out-of-the-box") as a corporate intranet? Or a collaboration tool for a
volunteer organization? Or a generic frontend for a database? Should we be
allowed to choose?
> All the other functionality, like security, user/group management, UI
> widgets etc. are very important for web application development. Higher or
> more specific implementations should be optional.
Sure. Sounds reasonable. If they're not optional, they at least have to be easy
to uninstall, and doing that shouldn't break anything.
> Although the lower level functionality is important, sometimes these also do
> not serve the purposes. We replaced/extended most of the
> user/group/security stuff in our OI2 application called Dicole (demo at
> http://dicole.net)
>
> [...]
(A little off topic here: I think it would have been _much_ better if you
improved OI2 instead of replacing parts of it. :)
>> They're there so you can get a notion of what's possible to do OI2, and
>> when you've seen _that_, the _real_ big questions show up: How can I use
>> OI2? How can I improve OI2? What should be improved? How easy is it to
>> improve OI2? How can I make it easier to improve OI2? What should be
>> improved so OI2 becomes easier to improve?
>
> These questions can be answered if the base installation greets you as a web
> application framework and not as a generic CMS.
Sure. Fix it if you have access, write a bugreport if you haven't.
> Despite some things I'm not happy with, OI2 is still the best decision we
> have made when we looked for a new base to build upon. We have done more
> during this time for our customers than we could have done without. The
> design of the web application framework is brilliant and I'm happy to help
> it to be even better.
Just do it...
For example, find the parts of Dicole which are (almost) general enough for
everybody to use, and find a way to move it out of Dicole and into OI2 instead.
This would in the long run mean less maintainance, more user feedback for you
(assuming OI2 becomes as wildly popular as we'd like :) ) and more
out-of-the-box and Good Stuff to impress people with. :)
(Enough ranting! I realize I may be a bit boastful for someone who's
contributed as little as I have, but please ignore this fact and see if any of
my points are valid anyway. :)
- Salve
--
Salve J. Nilsen <salvejn at met dot no> / Systems Developer
Norwegian Meteorological Institute http://met.no/
Information Technology Department / Section for Development
|
|
From: <an...@io...> - 2005-07-18 20:35:54
|
Teemu is on a vacation this week so I'll try to answer for him since I
think this is quite an important topic.
Salve J Nilsen wrote:
> Basicly I agree with you, but I also think the question of "wether or
> not OI2 is a CMS (or has a clear end-user decipherable mission statement)" isn't
> the most important question at this stage. Today, I think we're much better
> off if we try to make OI2 as developer-friendly as possible.
I think Teemu was trying to say that setting goals and guidelines is a
very important part of making OI2 developer-friendly. I agree that is it
mainly important for the end users who write their applications on OI2,
but the fact is that we will probably never get people on board who are
just OI2 developers - their motivation will always (at least in the
beginning) be their own application which runs on OI2. It's just the way
open source projects usually work.
Also I think that it is very hard to make something easy to develop if
there are no guides on what is the preferred outcome. It's like coding
with bad specs - you hack up something and hope that it is suitable.
This is not a good way to encourage contributing to OI2 itself.
> To do this, it may help to point out that OI2 isn't a _product_, but a
> _project_. Asking product questions (e.g. "Does it do A") can be useful, but
> not nearly as much as asking project questions (e.g. "Can someone help me write
> feature A" or "How can we make it easy for someone to write the A
> feature").
OI2 might be a project but that does not mean that every piece of code
written on OI2 should part of that project. OI2 is an excellent platform
to extend in the direction of your needs, but those developer needs
which aren't already addressed by OI2 are hardly ever general enough to
be used by most people who might benefit from building their application
on OI2. For this we have packages and an excellent management framework.
The questions from the people who are interested in OI2 are more
probably going to be: "How easy does using OI2 makes it for me to do A?"
and "Has someone already done A on OI2 and could I benefit from it?" and
thus these are also the questions we should be thinking when we develop OI2.
A huge part of addressing the first question id to provide a clear,
detailed mission statement and a bug repository + documentation stating
which features are missing or buggy and need more work.
The second question can be addressed by providing a repository of easy
to use packages or compilations of packages, which can be adapted or
extended to your specific needs.
Answering to the second question is IMO not part of actual OI2
development, but it is a vital part for OI2 to success as an application
platform. I think we should make it an another project which would build
OI2 packages that provide different functionality and then compile a
demonstration application(s) from these packages for OI2.
I think this is the best way we can help OI2 to advance as a project
since the more people write their applications on OI2, the more we can
identify places where OI2 should be developed futrher to achieve our
mission - and we will probably even get help for doing it.
I think that if OI2 has no clear mission, everybody will concentrate
more on building their own missions and OI2 will always remain just half
made everything.
> OI2 is an open source project, dammit. Why bother with the self-scrutinizing
> philosophical questions when we can change the world with code? We _have_ the
> freedom to do watever we want, and _that_ is why I'm sure you can mold OI2 into
> whatever you want it to be... :-)
Open source project is just like any other project: to succeed it needs
good management. Lonesome coders hacking away as they see fit is not
going to end up being everything we all need.
We need to discuss the directions where we are going so that we can
benefit on each others work. I can write a million hello worlds within
an hour by using OI2 and some code generation, but it is not going to
change the world.
> Chris, is it feasible to give people access to improve the website?
To suddenly change the mission statement the way one wants it instead of
discussing it with all the others first? ;)
> What's more important? That new users and developers can get a site up and
> running easily, or that experienced developers have a "clean install" to
> work from?
In my opinnion both are important and they are in no way conflicting
goals. Ofcourse it is very important to have example code or even an
example system you can build upon if it _happens_ to fit your needs. But
building upon the example code should IMO not be the expected usage.
I think the expected usage should be that you pick a collection of the
example modules you need and build your application using those.
> Should OI2 _only_ be an application framework, or should it also be usable
> ("out-of-the-box") as a corporate intranet? Or a collaboration tool for a
> volunteer organization? Or a generic frontend for a database? Should we be
> allowed to choose?
I think OI2 should be _only_ an application framework. Simply said.
I think that if you have built up a corporate intranet on top of OI2 you
should name it OpenInteract2 Corporate Intranet and publish the
compilation of packages you have used in a different site or a project
hosting OI2 apps, which OI2 site can then link to so that those building
their own corporate intranets can have almost out of the box
functionality, but those who are building a frontend for database don't
have to mind their head if they can remove your corporate intranet
package XY from their fresh website install without breaking the whole
system.
There are unlimited uses of OI2 and many of them DO conflict with each
other. This is why none of them should be included in OI2 base install
but somewhere else.
>> Although the lower level functionality is important, sometimes these also do
>> not serve the purposes.
> (A little off topic here: I think it would have been _much_ better if you
> improved OI2 instead of replacing parts of it. :)
What do you mean by improving OI2?
We have only 2 patches against the OI2 cvs tree, of which one is already
obsolete because of the changes in OI2 tree and the other is already
reported in JIRA and is being discussed - we can't just go and commit
the code before discussing with Chris even if we have commit access to CVS.
Then we have our own version of many of the factory classes in OI2, but
even many of those changes are either discussed on the dev list or
reported in JIRA as change suggestions.
Then we have some packages which are used to test some approaches and
which in the end _might_ end up into OI2 as ideas, but are currently
implemented so that they are not near generally usable. On the other
hand they might provide to be immense crap.
Also there is lots of code which will never find it's way into OI2
because it's application specific. I very much doubt that Chris would
want our bloated security framework into OI2 since the whole structure
is heavily dependent on our applications view on groups and users and we
ignore SPOPS securities for management reasons.
If somebody, for some reason, needs similiar group and security
implementation, they are very welcome to check what we have done. It's
in the CVS and it's very liberally licenced. But it definately is not a
general approach that should be provided as the default one for OI2.
On top of our specific focus, we have limited resources and tight
schedules, like everybody in this business has. We just simply don't
have the time to plan and test our approaches as long as we find a way
that might be integratable with OI2. Usually the good ideas grow in time
and they need a lot of experimenting in different directions to evolve
to a general state. We can't just decide that we will make everything as
general as possible to be incorporated into OI2 core even if we wanted
to. We do what we can given the resources, but usually the output is far
from general and reusable Brick. When it evolves, maybe? But the sad
fact is that we can't dump the customers who pay our bread to go on a
crusade to build a better world - we are already making as many stabs as
we can towards that goal.
For example we are not just trying to persuade you to see OI2 as solely
an application framework just because we use it as one. We think that it
would be the right thing to do for most of OI2's users.
> Just do it...
>
> For example, find the parts of Dicole which are (almost) general enough for
> everybody to use, and find a way to move it out of Dicole and into OI2
> instead.
What makes you think that we are not doing it the best we can? The
abundance of my oi-dev posts? ;)
We can't just decide ourselves that OI2 needs this and that and
completely wreck the CVS without asking anyone. We have to discuss and
agree about things - like the things we are talking about in this mail
thread.
- Antti
|
|
From: <an...@io...> - 2005-07-28 02:05:34
|
I once again started wondering what is the role of the action class.. Action implements many functionalities but I think many of them are not necessarily core action functionalities.. Questionable ones are imo content generation, message carrying, url creations, task validation+ url_additional setting and even caching or security. I know that you can turn the above functionality off or just ignore that it is there, but as Chris said, the Action class is quite huge already. If I recall correctly, OI1 had a different class for "handlers" and "actions".. I think handlers were more like special actions with the above functionality.. Why was this separation dropped? I think it would make the structure easier to understand if it would be made clear that "handler"-actions are only one way to use actions. As I have said before, I think that finding a valid task and setting url_additional would IMO be more like actionresolvers task than actions. Also message carrying might be wise to be moved elsewhere since it might be nice to be able to show messages also when redirecting away from an action, or showing messages that sub-actions (like box beneration) produce. Url creation is pretty useless if the action isn't a "handler" and content generation is only needed if the action is supposed to output processed data instead of perl structures. Caching is a good property in an action, but on many occasions it is not used since it is quite a hassle to invalidate caches. Sometimes even security is not needed for an action. I think it would be easier to grasp the concept and usage if there were several action classes instead of just one with a lot of configuration options. I think we might have at least OI2::Action OI2::Action::Cached OI2::Action::Secured OI2::Action::Generated OI2::Action::Handler (unifies the above and adds url handling) Actions execute could then check if the action ->can the extra functionality and thus they could be added just by using the wanted classes as base without bloating the actual Action code. OI::A::Generated could for example pass the return value of the task to a content generator automatically if $self->skip_generate is not specified. Any of you have other views on the subject? =) - Antti |
|
From: Chris W. <ch...@cw...> - 2005-07-31 00:39:59
|
On Jul 18, 2005, at 4:36 PM, Antti V=E4h=E4kotam=E4ki wrote: > I think Teemu was trying to say that setting goals and guidelines =20 > is a very important part of making OI2 developer-friendly. I agree =20 > that is it mainly important for the end users who write their =20 > applications on OI2, but the fact is that we will probably never =20 > get people on board who are just OI2 developers - their motivation =20 > will always (at least in the beginning) be their own application =20 > which runs on OI2. It's just the way open source projects usually =20 > work. I agree with that -- most of us don't participate in the actual =20 development of core Perl, we just use it. > ... > The questions from the people who are interested in OI2 are more =20 > probably going to be: "How easy does using OI2 makes it for me to =20 > do A?" and "Has someone already done A on OI2 and could I benefit =20 > from it?" and thus these are also the questions we should be =20 > thinking when we develop OI2. > > A huge part of addressing the first question id to provide a clear, =20= > detailed mission statement and a bug repository + documentation =20 > stating which features are missing or buggy and need more work. > ... > I think that if OI2 has no clear mission, everybody will =20 > concentrate more on building their own missions and OI2 will always =20= > remain just half made everything. It's true, OI has never had a real mission statement. I suppose I'm =20 the natural person to write such a thing, but that it hasn't been =20 done yet is a good indication that it probably never will be if left =20 in my hands. Is someone interested in coordinating this? > ... > Open source project is just like any other project: to succeed it =20 > needs good management. Lonesome coders hacking away as they see fit =20= > is not going to end up being everything we all need. > > We need to discuss the directions where we are going so that we can =20= > benefit on each others work. I can write a million hello worlds =20 > within an hour by using OI2 and some code generation, but it is not > going to change the world. Also true. > ... > To suddenly change the mission statement the way one wants it =20 > instead of discussing it with all the others first? ;) Probably more to replace me as a bottleneck and change the statement =20 (and site) once interested folks have agreed to it. > ... > On top of our specific focus, we have limited resources and tight =20 > schedules, like everybody in this business has. We just simply =20 > don't have the time to plan and test our approaches as long as we =20 > find a way that might be integratable with OI2. Usually the good =20 > ideas grow in time and they need a lot of experimenting in =20 > different directions to evolve to a general state. We can't just =20 > decide that we will make everything as general as possible to be =20 > incorporated into OI2 core even if we wanted to. We do what we can =20 > given the resources, but usually the output is far from general and =20= > reusable Brick. When it evolves, maybe? But the sad fact is that we =20= > can't dump the customers who pay our bread to go on a crusade to =20 > build a better world - we are already making as many stabs as we =20 > can towards that goal. True for many people I think. It's a delicate balance making your =20 core products open source: if you don't work enough on the core =20 you'll lose the benefits of them being open source, but if you spend =20 too much time on it you won't be writing applications for people who =20 pay you money. As always, thanks for your ideas. Chris |
|
From: Salve J N. <sal...@me...> - 2005-08-01 13:10:31
|
[Sorry for the verbosity of my ranting :)]
Antti Vähäkotamäki wrote:
> Salve J Nilsen wrote:
>>
>> [snip]
>
> Also I think that it is very hard to make something easy to develop if there
> are no guides on what is the preferred outcome. It's like coding with bad
> specs - you hack up something and hope that it is suitable. This is not a
> good way to encourage contributing to OI2 itself.
I'm of course assuming the contributor has some common courtesy when it comes
to submitting significant changes (but since assumption is the mother of all
fsck-ups, we make sure CVS is there to save the day. ;-)
Anyway, I'm trying to postulate that motivating people to do something is much
more difficult than deciding what to do. To do the latter, one only has to have
a look at JIRA to get started, or try to take notice of things that are
difficult to do when creating an OI2 app (I'm sure you can think of more)...
Since we're talking about an Open Source project, we can basically say bye-bye
to extrinsic motivational tools like salaries or the threat of layoffs. This
leaves us with the intrinsic ones, which basically have the drawback of being
highly personal, e.g. the wish to write good code, scratch your itch, help a
friend, pride, reputation or self-education. From the project's point of view,
I'm sure we'd like to allow everyone to make use of their motivation as they
seem appropriate, and AFAIK, the most sensible way to do this is to have an
"including" demeanour towards those who want to contribute - giving them trust
and responsibilities - and to reduce the number of hurdles one has to jump
through in order for someone to actually make a contribution. (I'm sure there
are more ways.)
If we manage to arrive at this point (no hurdles, positive community, etc.) I
think we're basically members of a do-ocracy - "Just do it, we trust you!".
I think that's a good thing. :-)
> [snip]
>
> I think this is the best way we can help OI2 to advance as a project since
> the more people write their applications on OI2, the more we can identify
> places where OI2 should be developed futrher to achieve our mission - and we
> will probably even get help for doing it.
>
> I think that if OI2 has no clear mission, everybody will concentrate more on
> building their own missions and OI2 will always remain just half made
> everything.
Sure. Do you have a suggestion for a mission statement? :)
>> OI2 is an open source project, dammit. Why bother with the self-
>> scrutinizing philosophical questions when we can change the world with
>> code? We _have_ the freedom to do watever we want, and _that_ is why I'm
>> sure you can mold OI2 into whatever you want it to be... :-)
>
> Open source project is just like any other project: to succeed it needs good
> management. Lonesome coders hacking away as they see fit is not going to
> end up being everything we all need.
If you think you're a lonesome coder, then I'm sure you actually are. If you
feel you need management, then I'm sure you actually need management. But if
you take the time to count the members of this mailing list, you'll quickly see
that you _aren't_ alone (even if we're a quiet bunch), and if you try to do
something that's useful for OI2 all by yourself, I'm sure you'll see that we
cab be quite positive to your contribution (if we find the time, we might even
comment and critique it. :)
> We need to discuss the directions where we are going so that we can benefit
> on each others work. I can write a million hello worlds within an hour by
> using OI2 and some code generation, but it is not going to change the world.
Just tell us what you're doing.. ;-)
>> Chris, is it feasible to give people access to improve the website?
>
> To suddenly change the mission statement the way one wants it instead of
> discussing it with all the others first? ;)
If you feel like being efficient, then sure. Just make sure it's an obvious
improvement. (Otherwise we'll revert it and remove your write access ;-)
>> What's more important? That new users and developers can get a site up and
>> running easily, or that experienced developers have a "clean install" to
>> work from?
>
> In my opinnion both are important and they are in no way conflicting goals.
> Ofcourse it is very important to have example code or even an example system
> you can build upon if it _happens_ to fit your needs. But building upon the
> example code should IMO not be the expected usage.
>
> I think the expected usage should be that you pick a collection of the
> example modules you need and build your application using those.
My experience is that one shouldn't expect a specific kind of behaviour from
users... Why not just "expect people to use stuff in new ways", and make sure
the APIs are consistent and clean, everything is subclassable, neatly
modularized and all significant events are logged? I think that would be a nice
start, at least. :)
>> Should OI2 _only_ be an application framework, or should it also be usable
>> ("out-of-the-box") as a corporate intranet? Or a collaboration tool for a
>> volunteer organization? Or a generic frontend for a database? Should we
>> be allowed to choose?
>
> I think OI2 should be _only_ an application framework. Simply said.
Then I'm sure you'll commit code and report issues so OI2 moves in that
direction. :)
>>> Although the lower level functionality is important, sometimes these
>>> also do not serve the purposes.
>>
>> (A little off topic here: I think it would have been _much_ better if you
>> improved OI2 instead of replacing parts of it. :)
>
> What do you mean by improving OI2?
Anything that you have found lacking in OI2 and fixed in your app, could be
made part of OI2 in the core (or as an easily accessible option).
E.g. if you find that the security system is too slow (and determine the reason
is the amount of database access), then you could create a drop-in replacement
for base_security (or whatever is appropriate) so other people also can get the
option to use your "base_security_fast" package. Or you could write the
documentation (to be placed in the as-yet non-existent OI2 HOWTO) which
describes how to configure OI2 to cache security lookups better or how to
create applications that access the slow security features less often.
I'm just making things up here, but I'm sure you understand what I'm trying to
say: When working with an OSS framework, the framework's value grows faster
when everybody involved tries to improve the framework for the general case
before creating the "special case" solutions.
> We have only 2 patches against the OI2 cvs tree, of which one is already
> obsolete because of the changes in OI2 tree and the other is already
> reported in JIRA and is being discussed - we can't just go and commit the
> code before discussing with Chris even if we have commit access to CVS.
Chris is busy. Should everything really have to stop because he has something
else to do? (BTW, This looks like a classic single point of failure scenario...
:-\ )
> Then we have our own version of many of the factory classes in OI2, but even
> many of those changes are either discussed on the dev list or reported in
> JIRA as change suggestions.
Do they solve some general issues? Can the classes you've made be generalized
enough to be included into OI2? Have you attached the code you've made to the
JIRA issue, so others can have a look at it? :)
> Then we have some packages which are used to test some approaches and which
> in the end _might_ end up into OI2 as ideas, but are currently implemented
> so that they are not near generally usable. On the other hand they might
> provide to be immense crap.
Publish them on your own webserver, and let other people decide. Set up a new
category in JIRA, and create an issue there, so people can give structured
feedback. Find other ways to tell us what you're up to. :)
> Also there is lots of code which will never find it's way into OI2 because
> it's application specific. I very much doubt that Chris would want our
> bloated security framework into OI2 since the whole structure is heavily
> dependent on our applications view on groups and users and we ignore SPOPS
> securities for management reasons.
Hm. So you're creating boated application specific code? Tsk, tsk. (BAD
developer! Now go and read "Big Ball of Mud" and "Code Smell" ;-)
> On top of our specific focus, we have limited resources and tight schedules,
> like everybody in this business has. We just simply don't have the time to
> plan and test our approaches as long as we find a way that might be
> integratable with OI2. Usually the good ideas grow in time and they need a
> lot of experimenting in different directions to evolve to a general state.
> We can't just decide that we will make everything as general as possible to
> be incorporated into OI2 core even if we wanted to. We do what we can given
> the resources, but usually the output is far from general and reusable
> Brick. When it evolves, maybe?
Well, I hope you'll find the time to make your code general enough for OI2,
some day... :-)
> But the sad fact is that we can't dump the customers who pay our bread to go
> on a crusade to build a better world - we are already making as many stabs
> as we can towards that goal.
So your customers aren't interesting in building a better world? (Just kidding.
I'm sure you try as best you can. :)
>> For example, find the parts of Dicole which are (almost) general enough
>> for everybody to use, and find a way to move it out of Dicole and into OI2
>> instead.
>
> We can't just decide ourselves that OI2 needs this and that and completely
> wreck the CVS without asking anyone. We have to discuss and agree about
> things - like the things we are talking about in this mail thread.
You could start by creating a separate branch in the OI2 CVS for your
experiments... :)
- Salve
--
Salve J. Nilsen <salvejn at met dot no> / Systems Developer
Norwegian Meteorological Institute http://met.no/
Information Technology Department / Section for Development
|
|
From: Chris W. <ch...@cw...> - 2005-07-31 00:00:35
|
Sorry I've been missing much of this -- I switched mailers for a few weeks (not by choice) and Thunderbird doesn't float new threads up to the top like Mail.app does. Just another dumb user error. On Jul 18, 2005, at 12:36 PM, Salve J Nilsen wrote: > ... > Basicly I agree with you, but I also think the question of "wether > or not OI2 > is a CMS (or has a clear end-user decipherable mission statement)" > isn't the > most important question at this stage. Today, I think we're much > better off if > we try to make OI2 as developer-friendly as possible. That sounds good. I think it would be great to reach out to users but you really need apps for that, and we don't have them right now. > To do this, it may help to point out that OI2 isn't a _product_, but a > _project_. Asking product questions (e.g. "Does it do A") can be > useful, but > not nearly as much as asking project questions (e.g. "Can someone > help me write > feature A" or "How can we make it easy for someone to write the A > feature"). It's a subtle difference, and users usually can't recognize it. (Not that it's a bad thing, just different.) > If we hace a quick look at the state of OI2 (today), it may look > something like > this - AFAICT: This is a really good summary! I'll try to chime in where it's interesting... > 1) OI2 is Big and Complicated > 2) Although the beta period for OI2 has lasted forever(tm), > there's still a > large amount of bugs (currently around 60 in JIRA). :-\ Yes. This is tied in with "Chris does everything and is swamped", unfortunately. > 3) OI2 has some good "infrastructure" features but few "application" > features. Developers like the former, users the latter. Who's > more > important? Right. Maybe people do build apps but are shy to publish? Or maybe since there's no real distribution mechanism the necessary infrastructure isn't there? (Maybe the 'publish to CPAN-distributable module' will help?) > 4) OI2 is pretty well documented (I'm guessing 75%), but lacks a > lot of > common things that make large amounts of information more > comprehensible > to the reader (e.g. ER diagrams, class diagrams, data flow > diagrams). > 5) The OI2 community is too small and quiet. :-( Again, I think this is the issue where one person (me) has been the main developer. Since I'm not contributing as much as I used to it becomes a problem. > 6) Contribution to the project is difficult - perhaps due to > social quirks > (shyness of speaking in public fora? our inability to follow > up requests > on this mailing list? the "Jante law"?), I haven't heard of this. Time to google...wow, that's really interesting. This is a good link: http://www.bbc.co.uk/dna/h2g2/A668694 > but also due to technical > complexity (finding where to add a feature requires a lot of > digging). True. It would probably be useful to have a FAQ-like guide for this. > 7) One _can_ say OI2 has a lacking webpage, unclear about mission > and > perspective. True. > 8) We have an underutilized wiki (is anyone actually reading or > using it?) True. > 9) The mailing list archives and bugtracker have little sense of > connection > between them, the website and the wiki. What can we do to make > all this > information less fragmented? Is there a way we could integrate > JIRA with > the main site? Or use a OI2-native wiki instead of TWiki? Good questions. > 10) We have only a vague sense of what kind of audience OI2 is > for. It seems > to be mainly for advanced web application developers, but we'd > like more > people to use it, right? Right. > 11) Chris has always been doing most of the significant > development, but like > the rest of us, he's swamped in distractions from from doing > the Important > Stuff - namely improving OI2. :) Right! > All these points lead to interesting project questions. Ask > yourself these > questions, find if some of them interest you, try to answer these, > and finally > try to implement the answer. (And should you come across something > that stops > you from implementing it, then fix that first) > > OI2 is an open source project, dammit. Why bother with the self- > scrutinizing > philosophical questions when we can change the world with code? We > _have_ the > freedom to do watever we want, and _that_ is why I'm sure you can > mold OI2 into > whatever you want it to be... :-) ! > Sure. Fix it if you have access, write a bugreport if you haven't. > > Chris, is it feasible to give people access to improve the website? Absolutely! If you're interested let me know. > What's more important? That new users and developers can get a site > up and > running easily, or that experienced developers have a "clean > install" to work from? > > Should OI2 _only_ be an application framework, or should it also be > usable > ("out-of-the-box") as a corporate intranet? Or a collaboration tool > for a > volunteer organization? Or a generic frontend for a database? > Should we be > allowed to choose? The basic applications (like news, lookups, the super-simple CMS) were mainly put there so you didn't install OI2 and say, "Okay, now what?" You'd have something to tinker with and break as well as examples to follow. But since it's easy to swap functions in and out, maybe it makes sense to have a stripped down distribution (*no* apps, just basic user/security stuff) and the version as it is today? It would be doable with Module::Build rules, I think... I really appreciate that you folks are interested enough in OI2 to get involved with big picture ideas like this. Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
|
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! :) > |
|
From: Jeff H. <je...@je...> - 2005-07-01 16:55:29
|
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. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I'm not quite sure how this applies to forms, which is what I'd like to limit my involvement to. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * An extra-wide textarea, which could be used with > WYSIWYG HTML editors like FCKeditor. > <http://www.fckeditor.net/> ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< You need something wider than the current "wide" textarea? ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * A proper calendar widget, e.g. a lightweight version > of > <http://www.dynarch.com/projects/calendar/> ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Yeah, it'd definitely have to be lightweight. The dynarch version is nice, but definitely not fast. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > 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" :) ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Easily. Just a few declarations and the entire color scheme can be easily changed without affecting the layout at all. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * 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>] ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I hadn't considered an optional, additional help link. I guess I imagined that the info box along with explanatory text below any field would be sufficient. I'll see what I can come up with. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * 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). ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I'm personally not a big fan of ems as they do funny things cross-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. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Yeah, this is a nobrainer, imo. It can be difficult to do without adding non-semantic markup like <br />. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * Likewise, everything must work flawlessly without > javascript. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Amen to that. However, have fun with some of the more complex widgets without JavaScript. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > I hope these "requirements" aren't too difficult. > > Are you up for it, Jeff? :-) ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Time is the only issue. [>] Jeff Howden je...@je... http://jeffhowden.com/ |
|
From: Teemu A. <te...@di...> - 2005-07-01 22:59:13
|
A note about info/help boxes next to forms, I've seen in plone they have info boxes so that when you have focus in a certain element, the help for the element appears right next to the element as a layer. This way the layout remains compact and clean. >><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< >> * 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. >><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< You might also want to have: (year, month, day) (hour, minute, second) (year, month, day) (hour, minute) (hour, minute) (hour, minute, second) Then the ordering of year, month, day should be based on users localization settings (OI2 developers problem). Hours might also have [AM]/[PM] option dropdown for US. >> +--------+ +--------+ >> |foo | |bah | >> |bar | [>>] |quux | >> |baz | [->] | | >> |bom | [<-] | | >> | | [<<] | | >> | | | | >> +--------+ +--------+ With some javascript and replacing the form elements with simple divs this is possible to implement as a drag & drop version as well, eliminating the need for arrows. Non-js could be implemented with just one ctrl-selectable select list element. >><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< >> * 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. I guess Salve means read-only versions. For date field, we will have e.g. "11th June 2005". Read-only in forms is probably implemented with the readonly property of form elements or with hidden fields together with a div or something to display the contents of the hidden field(s). > I'm not quite sure how this applies to forms, which is what I'd like to > limit my involvement to. Well if it's possible to separate a long form into multiple segments, each segment accessible through a tab without reloading the page. Non-javascript version could just display the complete form on a single page. > Yeah, it'd definitely have to be lightweight. The dynarch version is nice, > but definitely not fast. So far as I know this is the best one there is out there in the Open Source domain which works accross multiple different browser versions. >> - default-layout.css >> - default-menus.css >> - default-content.css >> - default-forms.css We had layout.css and markup.css to separate positioning (margins, paddings etc) from display (colors, borders etc). >><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< >> * 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). >><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > > I'm personally not a big fan of ems as they do funny things cross-browser. With fonts I guess percents work best cross-browser. Plone.org has very good CSS implementations, see how they use ems and percents. Regards, Teemu Arina Dicole http://www.dicole.org FLOSS in education blog: http://flosse.dicole.org "Discover, collaborate, learn." |
|
From: Jeff H. <je...@je...> - 2005-07-02 04:14:00
|
Teemu,
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Teemu Arina
>
> A note about info/help boxes next to forms, I've seen
> in plone they have info boxes so that when you have
> focus in a certain element, the help for the element
> appears right next to the element as a layer. This way
> the layout remains compact and clean.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
I've never really liked the way Plone does it. Perhaps something similar,
but better.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> You might also want to have:
>
> (year, month, day) (hour, minute, second)
> (year, month, day) (hour, minute)
> (hour, minute)
> (hour, minute, second)
>
> Then the ordering of year, month, day should be based on
> users localization settings (OI2 developers problem).
> Hours might also have [AM]/[PM] option dropdown for US.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
Agreed. I can add some simple styling to accommodate any of the above
varieties.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> >> +--------+ +--------+
> >> |foo | |bah |
> >> |bar | [>>] |quux |
> >> |baz | [->] | |
> >> |bom | [<-] | |
> >> | | [<<] | |
> >> | | | |
> >> +--------+ +--------+
>
> With some javascript and replacing the form elements
> with simple divs this is possible to implement as a
> drag & drop version as well, eliminating the need for
> arrows. Non-js could be implemented with just one
> ctrl-selectable select list element.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
Drag and drop does not remove the need for arrows. Each is necessary to
address the assortment of user interaction styles.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > I'll need more information on what you mean by
> > "View"-versions.
>
> I guess Salve means read-only versions. For date field,
> we will have e.g. "11th June 2005". Read-only in forms
> is probably implemented with the readonly property of
> form elements or with hidden fields together with a div
> or something to display the contents of the hidden
> field(s).
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
Ah, so I'll need some very basic styling to address both read-only fields
and other markup used to display read-only data.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > I'm not quite sure how this applies to forms, which is
> > what I'd like to limit my involvement to.
>
> Well if it's possible to separate a long form into
> multiple segments, each segment accessible through a
> tab without reloading the page. Non-javascript version
> could just display the complete form on a single page.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
Ah, now I understand. My extensive experience building complicated forms
has taught me that you can't really effectively do a multi-page form all
client-side without enormous amounts of JavaScript. It seems the more data
the form must collect the more "conditional" elements found later in the
form become. My personal opinion is that if you have a need to break
something into multiple pages, it's best to keep that functionality strictly
server-side.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > Yeah, it'd definitely have to be lightweight. The
> > dynarch version is nice, but definitely not fast.
>
> So far as I know this is the best one there is out there
> in the Open Source domain which works accross multiple
> different browser versions.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
Personally, if something can't be done about the speed, I'd rather just not
use it at all.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> >> - default-layout.css
> >> - default-menus.css
> >> - default-content.css
> >> - default-forms.css
>
> We had layout.css and markup.css to separate positioning
> (margins, paddings etc) from display (colors, borders
> etc).
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
In my own development I usually break my styles down like so:
Linked:
tags.css
layout.css
form.css
Imported:
tags.import.css
layout.import.css
form.import.css
Optionally, I'll add a home.css after layout.css in the linked section and
home.import.css in the imported section after layout.import.css for the
homepage if the styling that page demands is sufficiently different.
[>] Jeff Howden
je...@je...
http://jeffhowden.com/
|
|
From: Salve J N. <sal...@me...> - 2005-08-01 13:57:15
|
Jeff Howden wrote: > Salve, > >><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< >>I hope these "requirements" aren't too difficult. >> >>Are you up for it, Jeff? :-) >><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > > > Time is the only issue. How are things moving along? Do you need any help? :) - Salve -- Salve J. Nilsen <salvejn at met dot no> / Systems Developer Norwegian Meteorological Institute http://met.no/ Information Technology Department / Section for Development |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X