Forum OpenACS Q&A: OpenACS forums

1: OpenACS forums

Posted by xx xx on 11/17/02 01:42 PM

This thread reminded me of this and this.

Reuven made an article that is useful for newbees and evangelism (and others). I think, his request for a (content/graphics) designer forum was an intelligent one too. What is the current action on this subject?

I liked his idea because it is user-oriented instead of program-oriented.

'They' say, if you want to 'sell' a product (the OpenACS project), you have to address the needs of the users. Current OpenACS-forums are aimed at the needs of the project.

Sure, by now, I'm fine with the current forums. However, is there any follow-up on the earlier threads?

2: Re: OpenACS forums (response to 1)

Posted by Ben Koot on 11/17/02 11:26 PM

Aldert, I think you have a good point here. I think just about everything people would ever want to do with ACS has been discussed numerous times. All the solutions you can think of are hidden in the BBoard, but we lack a follow up procedure. The same goes for bug reports. 70 % of the bugs are unassigned to anybody. The result is endless repetition, which I feel is something we have to avoid. although I hate to form new management layers, it might be usefull to organize a kind of User Governance board, responsible for end user recomandations being followed up. many problems newbies have can be solved relatively easy, without requiring discussions on the bboard.

Cheers
Ben

3: Re: OpenACS forums (response to 2)

Posted by Bart Teeuwisse on 11/18/02 05:03 AM

Ben, Aldert,

as you know the OpenACS community is an open source community entirely made of volunteers. Each member contributes what time and skills he/she can. Specific topics move forward when someone feels compelled to take it upon themselves to work on it. Tasks remain open when no one steps forward.

The two of you express a need to improve the accessibility of OpenACS information. Both of you have experience running OpenACS based sites. I see an opportunity for OpenACS end-users like you to get more involved in the community. End-users could help organize the wealth of information embedded in the forums and publish it in more accessible form on the OpenACS site. For example, expand the Projects section (https://openacs.org/projects/), make sure the information is search-able and help keep it up to date. Content management really, using the various OpenACS packages installed on the OpenACS site. You will gain valuable experience deploying OpenACS assisted by first rate developers who in turn receive your feedback.

My suggestion to end user who would like to help is to contact the team that developed the new OpenACS site (https://openacs.org/about/site-credits). Polyxena and Roberto Mello are your best bet when it comes to content authoring. Drop them a line, put forward your suggestions and see how you can get involved.

I personally would like to take this opportunity to let the team know that I'm available for bug fixing and design concepts.

/Bart

4: Re: OpenACS forums (response to 3)

Posted by xx xx on 11/18/02 09:48 AM

Bart, I know.

But, the community has decided on new forums and volunteers have offered their time. What I asked for is an update.

I expanded this request by asking whether the community is interested in making the goals of the forums 'user-oriented' (see links).

Recently, I offered my time for transl-aiding and testing a new release, but I would be willing to participate in a Project Section project too.
Yun Yamog has a good project and I think many newbees would be willing to add their experience to a document/project in a way Roberto suggested a moment ago. However, let's follow-up on earlier decisions first.

5: Re: OpenACS forums (response to 1)

Posted by Jun Yamog on 11/18/02 11:07 AM

HI Aldert,

I have updated the doc with your corrections. There are also updates. In particular

- Context Bar stuff - Jeff Davis please kindly comment on this.
- Avoid using upvar (revised)
- Tcl style guide (added) Guru developers please comment on this.
- return_url stuff (revised)

6: Re: OpenACS forums (response to 5)

Posted by Jeff Davis on 11/18/02 11:21 AM

the property name for the context bar is now context and should be passed as a list of lists (same format as for the ad_context_bar call). Passing context as an html fragment works for now but is deprecated and should go away.

The reason for this is that we want to allow deisgners to present the context bar in different ways by changing the sitewide master and passing html fragments prevents doing this.

Here is an example:

set context [list [list "search?q=foo" "search"] "results"]

and in the .adp you would have

<property name="context">@context@</property>

One tricky thing with this is that hardcoded context in the .adp file should have quotes if it is anything other than a single word. eg:

<property name="context">"one result"</property>

7: Re: OpenACS forums (response to 1)

Posted by Reuven Lerner on 11/19/02 11:16 AM

I'm glad that Aldert has raised this issue again.

I'm currently working with three graphic designers on unrelated sites that use OpenACS. In all three cases, the designers are confused by the templating system, baffled by the documentation, and intimidated by the existing forums.

We've moved openacs.org over to the new software. We have the new forum system installed. I think that it's about time to create a newbies/designers forum in which people can ask questions. I'm being asked an overwhelming number of questions about OpenACS templates. I often don't have the time to answer these questions -- and more importantly, I don't have all of the answers that they need.

The sooner that we can set up such a forum, the better it'll be for all of the non-programmers who are starting to use this system. And if you're looking for volunteers, I'll happily be in charge of the forum. It cannot possibly take more time than the phone calls I've been receiving...

8: Re: OpenACS forums (response to 7)

Posted by Jeff Davis on 11/19/02 11:56 AM

I am definitely interesting in working on making OpenACS more design friendly and I think a forum specificly oriented towards design and user experience would help.

I have been working in that direction but am hampered by the fact that I am a terrible designer and don't really have a good handle on what we should do. I think a design forum where people ask questions and make suggestions would raise the level of awareness for the developers about design issues and hopefully we will get to the point where changing the design of an OpenACS site is not such a perilous and often mind numbing task.

My view is that we should be ripping out most of what passes for design in the existing toolkit and making the whole thing much more CSS friendly. To do so we would need to first figure out a scheme for class names and id's, what does and doesn't need to have a class name, and also how to handle per package and per subsite customization. It's something we probably can't do without some reasonable tech savvy designers helping and a new forum might be a good way to kick off the effort.

Getting further off topic, beyond removing the per package master templates I have also been trying to make the html we generate xhtml compliant and cleaning things up generally. You can see an example of style sheet switching on my blog page, which is also proof of my claim that I am a terrible designer :)

9: Re: OpenACS forums (response to 1)

Posted by Tom Jackson on 11/19/02 06:51 PM

Jeff,

Moving to CSS for style would be a great help. I was horrified to see the 'style' approach used in the calendar package. One problem that keeps raising it's ugly head when we have these discussions is backwards compatibility. I still use Netscape as the canary to find bad HTML, but judging from the access log of a few sites I manage, I would say most have moved on to more stylish pastures. But yesterday I had an interesting idea, similar to the having and eating of cake metaphor. The idea was to move the adp templates into a separate user directory. A basic OpenACS install would use the default directory to look for templates, however style minded folk might switch to using the new css based directory. Still others would copy and edit their own version of the ui.

As you know, I am a big fan of separating the tcl/db grunt code from the presentation code. Not everyone is, and we have useful, necessary apis like ad_form. However I still feel the long range solution for OpenACS is to create data structures in one file and pretty it up based on some other file. Since it seems agreement what is pretty is hard to come by, I suggest the new file structure:

packages/package/tcl
packages/package/www
packages/package/sql
packages/package/adp
packages/package/adp/plain
packages/package/adp/css
packages/package/adp/custom

Right now we have plain. Moving to css will take effort, and in the process we will destroy the plain, but working, ui. Custom sites will always make their own adjustments. As it stands now, these adjustments make updates from bug fixes, etc. difficult to incorporate into the running website. This method would allow webmasters the ability to get the fix into the plain or css adp, test it on their site with their data, and roll it into their custom page if they like the result. Of course it also keeps those pesky designers away from the tcl files :).

10: Re: OpenACS forums (response to 1)

Posted by Dave Bauer on 11/19/02 08:11 PM

Tom, I have been thinking about similar ideas. This sounds like the start of a good plan.

ad_form (and the form builder) do not generate the HTML, the use a form template. So there is still the code/design split when using the form system. Using a centralized form template makes it easier to have consistent forms throughout the site. You can also specify a different formtemplate which will override the default one when you put the <formtemplate> tag in an adp file.

11: Re: OpenACS forums (response to 1)

Posted by Tom Jackson on 11/19/02 08:49 PM

I guess I need a couple of you to hold me down long enough to digest ad_form and the form builder. Every time I try to tutor myself in the details my brain turns to mush. No, actually my brain is revealed to be composed of mush.

Anyway, the proposal for moving the adps must be backwards compatible: i.e. the files in the same directory should probably be used if they exist, and there isn't an ad_return_template call in the tcl file specifying otherwise. But don't I remember that now the adp is sourced first, not the tcl file? Seems like there might be incompatible changes necessary.

It also seems like a per instance directory should be used. I'm not trying to design anything here, just throwing out ideas.

12: Re: OpenACS forums (response to 1)

Posted by Dave Bauer on 11/19/02 09:08 PM

I moved the customized ADP discussion here: https://openacs.org/forums/message-view?message_id=62643