Forum OpenACS Q&A: RFC: OpenACS Roadmap Draft

Please comment in this thread on the draft OpenACS Roadmap I have started. https://openacs.org/storage/view/proposals/roadmap.html

Right now it just has some basic ideas. I need more feedback on what goals OpenACS is working towards and the timeframe. So far I have only showed a couple of people, but to move things forward I want ot have the whole community participate.

I think its important to cover a few areas:

Core Toolkit: Current plans for next release, future plans. Current plans should have a person committed to finishing before the next release and should have a TIP approved or at least submitted.

Applications: Current features, features for next release, future features. This should be the same. If the roadmap says something is planned for the next release, someone should be actively working on it.

The roadmap for the core toolkit should be supported by the OCT, either working on the items or finding volunteers.

All comments are welcome. I would like comments on the structure of the roadmap as well as the content.

Thanks!

I would phrase some of your points more strongly. Furthermore, shall we include a roadmap for the functionality of packages as well? I ask because it makes a lot of sense to go beyond the needs of .LRN with regards to roadmaps for packages. Furthermore, one strength of the toolkit is the large number of pre integrated packages.

The following suggestions are only for 5.3, as 5.2 is already frozen and should focus on bug fixing due to the magnitude of changes seen in the code.

I'd set one goal to make OpenACS Core XHTML compliant and switch the header to XHTML Transitional. This move should go hand in hand with a .LRN cleanup of the HTML code in the packages used by .LRN to make them XHTML compliant.

To make the site easier to manipulate with a CSS, I suggest to wrap every HTML code generated by an < include> with a CSS < div> tag. The ID of the < div> tag should be automatically generated from the package_key.lib_file_name combination with the possibility to override. This should make the integration of code pieces in the CMS parts of OpenACS easy, as you can define the look of these pieces more easily.

For testing, it would be good if we would support a framework that let's anyone write a test by going to a website, clicking around and enter data, thereby generating a storyboard for the testing script to use. There are mechanisms for this out there and Eduardo has proposed some already. This should enable everyone to easily generate test cases once a feature is developed, making sure that no changes break the current system. This should enrich TCL Webtest, which to my knowledge is useful in defining test cases in advance to writing the code, thereby following the ideas of agile development.

The form definition and widget changes proposed by Dave should be based on the ideas you can encounter in Contacts, Assessment and Package-Builder. No need to reinvent the wheel....

As for windows support, due to the fact that AOLserver runs on Windows and both supported databases run there as well, I think we are already there (Windows support I mean). Still I would not recommend it :).

Another topic would be HTMLarea. We should move to the latest working version (Andrew did some tests with the CVS version I think) and maybe support FCKeditor (http://www.fckeditor.net/) which looks nice as well and does not break Safari (it does not support it either, but at least you can add/edit the text). From the activeness of the community I'd focus though only on HTMLarea.

Also I'd suggest to dump spellcheck in OpenACS and enable it in HTMLarea. Or at least turn it off by default. It has been causing a lot of troubles which is one of the reasons most 2.1 sites have turned it off now.

Furthermore, I'd like to collect feedback from people on ad_form and what is annoying in it's code and useage so we can further finetune this centerpiece of OpenACS.

But the main goal for 5.2 should be to fix all outstanding bugs in OpenACS core and collect the suggestions together as a TIP for changes in 5.3. And I'm not talking about only release critical bugs this time :).

"I'd set one goal to make OpenACS Core XHTML compliant and switch the header to XHTML Transitional. This move should go hand in hand with a .LRN cleanup of the HTML code in the packages used by .LRN to make them XHTML compliant.

To make the site easier to manipulate with a CSS, I suggest to wrap every HTML code generated by an < include> with a CSS < div> tag. The ID of the < div> tag should be automatically generated from the package_key.lib_file_name combination with the possibility to override. This should make the integration of code pieces in the CMS parts of OpenACS easy, as you can define the look of these pieces more easily."

These are good ideas. The OCT has breifly discussed cleanup of the HTML and we are not sure what level of HTML should be supported. It might be HTML 4.0 but either way, the point is to have the default installation validate against a specifcation of HTML or XHTML.

I think giving includes a standardized css class naming convention is also a good idea, although it might cause some explosion in the number of CSS classes that need to be defined. It might make more sense to build out a number of functional classes that would cover the most use cases in a default installation and use those system wide. It would then be possible for a designer to define a class for a specific page or include and change that. One problem with defining CSS per include is that is reduces the reusability of the include! If you predefine what it looks like, you can't use it in as many situations.

So I think defining a set of functional classes, but what role a include is playing in a page, main content, sidebar, navigation etc... rather than by the content of the include, will bring the most benefit and flexibility.

"For testing, it would be good if we would support a framework that let's anyone write a test by going to a website, clicking around and enter data, thereby generating a storyboard for the testing script to use. There are mechanisms for this out there and Eduardo has proposed some already. This should enable everyone to easily generate test cases once a feature is developed, making sure that no changes break the current system. This should enrich TCL Webtest, which to my knowledge is useful in defining test cases in advance to writing the code, thereby following the ideas of agile development."

Making it easier to define page-flow and user interface tests by example is a great addition to the automated testing features and we definitely want to get that into the toolkit.

An installer should definitely be part of the OpenACS roadmap and it should actually be more than Just a suggestion.

I have uploaded a new Roadmap with more specifics on projects that I personally am aware of.

I will go through proposed TIPs and put those in where they are missing.

I put in some people's names of who I thought was interested in these projects. Feel free to upload a new revision, reply to this thread or email me if you want to add or remove your name!