Forum OpenACS Q&A: Redesign of - New Features

Posted by Ben Adida on
In response to the latest series of community discussions, Talli and
Musea Tech have volunteered their help in redesigning
I want to reiterate that this is the kind of action that really helps
the community! We want more contributions, and the gatekeepers wish to
publicly thank MuseaTech for volunteering this work.

We will begin with a look-and-feel redesign that is underway as we
speak (and which we will expose to the community before a final
decision is made). The effort will continue with feature enhancements,
and eventually a reworking of on OpenACS 4.x (which has to
happen anyways).

So, the floor is open (in this bboard) for concrete, brief suggestions
of features you want to see on Talli, Pat, and Luke will
comment on these, with Talli as point-person in making sense of this
whole discussion. I will remain webmaster to oversee the
general direction, but I'm offloading most of the actual work to
Talli and team on this.

Posted by David Kuczek on
Some people and I have posted a couple improvements in the following thread:

I checked out some features of lately and I think that the drop-down menues and the structuring as a whole are quite nice.

Additionally we should have a well visible link to /shared/whos-online.tcl and an activated chat room, although the openacs-chat is not quite optimal.

Whos-online will make even more sence with a future jabber-integration I believe.

Posted by Jonathan Ellis on
The bboard needs something in between "send me all posts" and "send me posts I've requested notification on."  I've wanted to see "send me all new questions" for a long time.
Posted by C. R. Oldham on
I'd also like some better support for viewing only messages on the bboard that I have not seen yet.  Having done some analysis of the module I know what it would take to support that (e.g. ultimately the database must keep track of whether or not each user has seen each post), but in high-traffic bboards it is really difficult to keep up with the discussions without this feature.
Posted by G. Armour Van Horn on
In several prominent places there need to be clear links to "Get OpenACS." For each major version there needs to be a clear map to get the tarball(s), the RPM(s), a summary of which modules exist and where to get each of them, a summary of which modules are "in the works" and how close they might be to release, a link to installation docs, and probably a couple of other obvious things I'm forgetting.

All these things are probably completely obvious if you already know where they are ...

Posted by James Harris on
I agree with Jonathon above.  A "send me all new questions" option would be very handy.
Posted by Michael Feldstein on
I think the "send me all new questions" idea is great. I would add
that it could be even better if the message with the new question
contained a "Notify me of new answers" hyperlink in it. That way,
if the question looks intriguing, you could subscribe with one

Beyond that, I think we're on the right track in terms of using the
FAQ module. Scoping it to assign admin privileges on individual
FAQs and adding an "Add this to the FAQ" hyperlink to ad_footer
for FAQ admins would both be very helpful. Later on, it would be
nice to assign categories to FAQs so we can group them, but
that's not an immediate pressing need.

Posted by Michael Feldstein on
Here's another thought about making bboard more useful in
terms of making the information reusable:

Generate an anchor link for each post on a thread. That way, if
somebody wants to reference a particular post (from an FAQ, for
instance), they could link directly to it.

Taking this one step further, I recently saw a bboard design
where the subject line, author, and date for each post was listed
as a hyperlink at the top of the thread and connected to anchor
links for the posts themselves. This is handy, particularly if you
have a long thread. And if you want to add the feature of
indicating which posts are new since the user's last visit, you
can easily stick a "new" icon next to the appropriate hyperlinks.

The second part of my suggestion is somewhat a matter of
taste, but at the very least, the anchor links themselves could be

Posted by Don Baccus on
It would be nice to be able to integrate package status reports, etc with packages in the SDM.  Let package owners be able to attach files which are then directly linked from some package page or another.

It would be nice to be able to provide the product-wide status page from within the SDM, as well.

Not real specific, eh? :)

These ideas stem from a note Neophytos e-mailed me, BTW - he has more specific thoughts which I've encouraged him to share.

Overall, let's prioritize/triage our efforts according to our most pressing needs.  I see these as being project support for the OpenACS 4.x effort (which can be applied to maintenance updates of 3.2.x and non-toolkit stuff like the XMLRPC effort, if we get some SDM support),  overall user doc contributions both big and small which the FAQ stuff mentioned above partially addresses, etc.

I *personally* view bboard improvements of being of relatively lower priority, in part because I'd hope that use of the bboard for "help me" messages will die off a bit if we can gather up more of our collective knowledge into easily explored user-enhanced docs, FAQs, presentations, etc.

Posted by Talli Somekh on
Hey guys,
As a protection of the developers that will be working on the site, I would like to ask that we approach this discussion not as a discussion of features in pacakges but of features on a site.
IOW, requests for how the bboard package operates are important and will be logged (Luke has almost finished the bboard port with just a bit of testing still required -- I think he's almost ready to announce it in fact). We'll do our best to accomplish whatever can be done within a reasonable amount of time.
However, it should be remembered that this will only be the first implementation of the new based on openacs4. Furthermore, we'll be pushing the limits of dogfooding by seeing how a high traffic production site will run on this code (which promises to kick ass, but still). So I think we'll be focusing on implementing the functionality that exists and for us, and the community, to fold in the more advanced features in future development.
I suggest that for this version of we discuss features as areas of the site need to be fleshed out or added, for instance:
* Better news coverage<br>
* Better access to documentation<br>
* More clear introduction to OpenACS<br>
* More access to developer resources<br>
* And so on
Sorry to try and cut off a very interesting discussion, but I think it's important to focus the discussion on features and goals that can be achieved within the limits of the current system.
Posted by Michael Feldstein on
Don, even if you are right and the number of "help me"
messages does die off, I suspect that bboard will remain
extremely valuable to the community. We'll still have plenty of
"what if," "how about," and "I just tried" posts that often generate
useful information.

In addition, the "help me" posts that are likely to stick around are
precisely those that we'll want to capture. They may be things
like, "Help me, I just discovered the permissions system doesn't
scale and I need to fix this major bug." We'll definitely want to
capture answers to those sorts of questions.

Bboard has always been the heart and soul of ACS communities
since Phil G started the durned thing. I can't imagine that
changing, regardless of better documentation or enhancements
to the rest of the system.

Posted by Michael Feldstein on
You're making an important point here, Talli, but I do believe that
many of the enhancements listed here, including improved FAQs
and better bboard alerts, are precisely intended for
as much as they are for OpenACS. These are all enhancements
that will help the community communicate better.
Posted by Tom Mizukami on
I think Johnathan's RH RPM's should be available from the software page.

Tom Mizukami wrote:

> I think Johnathan's RH RPM's should be available from the software page.

Overall, the whole approach to the SDM dealing with a 'package' may, in the long haul, need some rethinking in terms of each 'package' (ie product) being available in a variety of forms (tarball, RPM, .deb, self-extracting .exe for Win32, and so forth).

The RPMs I made (and hope to continue to make) for OpenACS just highlighted that issue. I'd rather we looked at the underlying issue of software products being made available in multiple forms, than just a quick fix so a few more people can find my RPMs.

But, Talli is right, let's not go overboard on enhancing OpenACS when what is being talked about is really setting up existing OpenACS4 code to work well for the OpenACS community. There's a big difference.

So, in the interest of concreteness and ease of implementation, yes, a link to each form of OpenACS (tarball, RPM, .deb) from the /software page would be a useful quick hack 😊

As a side note, I've been utterly unsuccessful in using SDM for my RPMs because of the restrictions it places on version numbers, which do not fit the version numbers of my RPMs. I think I mentioned this back in May but had no responses. If allowing a version string rather than a version number can be implemented easily, it would be of practical use to me.

Posted by Luke Pond on
Michael's requests are easily granted with OpenACS4.  The more flexible permissions scheme in the 4.x data model means that content administrators like Michael can easily delegate responsibility for editing different content sections.  Also, the 4.x bboard application is a) fully templated, so it's easy to experiment with the interface, b) already generates anchors for each reply in a thread, and c) offers more notification options.
Posted by carl garland on
A couple of thoughts that I've been meaning to post for a while include:

A link on each discussion forum page that goes to a Posting Guidelines page. This page would have a few basic rules for posting to the bulletin boards not too overbearing and not just a RTFM first page. However it should also maybe include on that guideline page a few links to the basic manuals/faqs that come into existence and a link to the faq/manual index in case people actually do want to do research before posting a question.

On this page should be a few basic rules
  • If you going to ask a question about X .... make sure you include platform/version/and offending code.
  • Make sure you are posting to the correct forum
  • Advise to try to at least search for an answer before posting
  • etc.
This should prevent those posts that have to have 5 or 6 messages posted before any real diagnosis can be made. The current community is pretty good about these things but as it grows and more newbies arrive, this sort of page should help reduce signal to noise factor. Also whenever a post violates the basic ruleset it would be easy for an active community member to respond by posting a Please See Guidelines before Posting Link :)

I also think that we need a more stuctured ASJ type page that would host articles that might be written up by community for documentation on surrounding technologies and be kept kinda separate from the core OpenACS documentation. This prevents obfuscating the different tools docs and openacs docs into one huge it's too much arghhh reaction.

Also there are certain parts of the site that are not accessable by links anywhere but should be ... for instance file-storage, poll, etc. People should be able to get there not only by bboard message links.

All for now ... Farscape coming on one of my few TV shows I watch. ... may JH rest in peace. Catch you frelling later ...
Posted by Troy Bradley on
I'd like to see improved navigation. Links to the home page from "Your Workspace" would be a nice start, as would be ANY persistent (present on most/all pages) navigation bar that includes links to major sections of the site (Home, Software, Discussions come to mind).
Posted by Don Baccus on
As it happens, there is a link to the home page from the "Your Workspace" page :)

But, the smiley's there because in general you're pointing at a well-known weakness in earlier versions of the ACS, i.e. inconsistent navigation, and yes, it would be good to improve navigation on this site.

Personally I dislike the home page/workspace page anyway, and prefer a single home page.  Actually, it's not the workspace page per se I dislike, but rather the fact that most module pages anchor the nav bar  to the workspace rather than home page, which is reality is hardly ever what one wants.

That's a configuration item that can easily be changed.  Would others like the links at the top of bboard pages, etc to lead back home rather than to the (rarely used, IMO) workspacepage?  Obviously there'd be a link on the home page to the workspace page so you could change your user profile, etc, on those rare occasions when you move, get married or divorced and change your name, die, etc.

Posted by Talli Somekh on
Hey guys,

I'm planning on publishing a preliminary RSF (Requirements, Specifications and Features) for very soon (hopefully in a day or two). It will incorporate and address the requests and issues raised in this board.

Some of the outstanding issues, though, have yet to be addressed really. The hairiest one in my view is whether we migrate completely to v4 bboards and try to figure out a way to link to the old bboards or stick with the tried and true scheme (ala aD's bboards which are still in ACS3.4). I am in favor of the migration to the latest and (maybe?) greatest, but that's a feature that really needs to be thought about.

The other point that was raised by Ben was whether should be as vanilla an OpenACS installation as possible. I am of two minds on this one; on one hand it's nice that people can get what they see with a quick installation on the other hand they don't get to see the true potential of an OpenACS system that has been customized.

Any thoughts?


Posted by James Harris on
Talli, in my opinion should be a customised OpenACS installation.  I agree that it would be nice to show visitors what they can easily and quickly get up and running, but I think it is more important to show them the full potential of an OpenACS site.
Posted by Stephen . on
I think old bboard messages should be transfered to any new system. Keep in mind however that the version 4 bboard code is very, very slow. Trial by fire, could be a good thing.

for an example of a low traffic v4 bboard on 'enterprise' hardware...

Posted by Talli Somekh on

Luke Pond did the bboard port and fixed a lot of the speed issues. It's performance has improved dramatically. I'm not sure that this is as much an issue anymore.


Posted by Paul Sharples on
I second James' suggestion that be customised -- in fact it should be the showcase OpenACS site. If OpenACS takes off, plenty of "out of the box" sites will appear soon enough...
Posted by Ben Adida on
Remember that there is a big difference between "showing the full
potential of OpenACS" and "customizing OpenACS." You can customize
OpenACS to do anything you want. However, the more custom stuff you
build on the web site, the higher you set the expectation
for what it can do out of the box. You'll get users saying "hey, you
mean I have to work for 40-60 hours to get to the level I saw on that sucks!"

Thus, any work put into customizing, unless it's minor
details, might be better spent on the toolkit, making it more useful
out of the box, as many have requested....