Forum OpenACS Development: General Comments changed for the worse

1: General Comments changed for the worse

Posted by Matthew Braithwaite on 12/14/01 11:15 AM

The changes to the General Comments UI between OpenACS 3 and OpenACS 4 seem to me to be entirely for the worse. If others agree, I'd like to do some work on changing it back to how it was before, or at least adding options to do so.

My specific beefs are:

The old ``Add a comment | Add a link'' interface has been replaced with the single command ``Add a comment''. There is a way to add a link, but it is very obscure. You must first add a comment and confirm the comment. Then the `view details' interface permits you to add a link.
After adding a comment, the user is presented with the baroque `view details' interface to modifying his comment. There must be some way to avoid this. If `Add a link' were restored, and the user were permitted to make attachments on the comment confirmation page, for example, that would do the trick.
The revision control knobs are over the top for ordinary users, who probably don't want more than the single command `edit this comment'.
On the comment entry page, there used to be some helpful text explaining what General Comments are for and not for, and listing some alternatives (such as sending email to the author of the page). This helped to discourage first-time users from using GC to do stuff like pointing out typos.
Attached hyperlinks and image attachments are only accessible through the `view details' link. That is, they aren't displayed on they page to which they apply, with the comment text. This guarantees that virtually nobody will see them. I also don't see why non-image attachments can't be listed with the comment text. Why do we need a `view details' link to begin with? (For comments that I own, the link should be called `edit'.)

2: Response to General Comments changed for the worse (response to 1)

Posted by Don Baccus on 12/14/01 03:20 PM

I agree - let's see what others think. This same general approach to attachments exists elsewhere in the toolkit. For instance to add an image to a forum post, you must edit your post - and if user's aren't allowed to edit their posts (a bboard parameter) there's no way for them to add an image or non-image attachment. I think that either or both of wimpy-point ("wp-slim") and glossary also rely on the "edit" page for the adding of attachments. But glossary uses GC so I may be confused, it may just be true of comments added to a glossary item ...

So my first suggestion would be that you spend some time investigating other packages for the same UI flaw - *if* you have the time and motivation to do so, of course. It would be nice to simplify the addition of attachments throughout.

The other issue is timing. After my whirlwind tour through the toolkit over the last two weeks, changing about 150 files in order to improve performance and change the tree_sortkey scheme, the code's finally starting to stabilize again. This means it's about time to start getting serious about a beta release.

Changes such as you're discussing probably need to go into our next release cycle rather than delay the current one, which has been delayed more times than I can remember already. We really need to squeeze out a real release.

At least ... that's my opinion. What do you (and others) think? Of course we're going to continue to work on the toolkit continuously, this is just a matter of release timing.

3: Response to General Comments changed for the worse (response to 1)

Posted by Jon Griffin on 12/14/01 06:32 PM

This is another classic case of AD not following their own guidelines.

One of the main advantages of the 4.x (tcl) branch was packages. This meant that if someone implemented a cool package, you could just make it a dependency and be guaranteed that its methods would be used.

Of course in reality, everyone wrote their own thing and it looks as bad as ACS 3.x from a proc point of view. Remember how many functions that did the exact same thing there was in 3.x? Some 4.x examples:

acs-references and places
general comments and home brewed per package
acs-messeges et. al.
acs-datetime and home brewed
news, cms-news

You get the idea. It will be much harder to keep this straight in the OpenACS realm as there is really no central god to stop me (or you)from doing whatever you want and reinventing the wheel.

Personally, I think that some other services need to be added to the core and one of the hopes I have for the documentation team is some central location of all procs/plsql of all publicly available packages on the OpenACS site. That way if I am going to write a package that needs some functionallity I can see if someone else already wrote it (being the lazy programmer I am). If it isn't written maybe there is something I can sub-class and use with a dependency.

(Note to myself...) I need to write about the evolution of acs-event, events, calendar and etc. This was talked about for a long time at the LA office and since (I believe) I am the only one left from those discussions still using ACS, it could be a valuable lesson in general purpose services built for open ended superclasses. Although its real intent was for events and calendar, acs-events should have the capability to deal with any similar problem (including room reservation, which has been mentioned in other threads).

One of the main reasons I still use ACS is this promise of reusablity. There really aren't any other systems that do the same thing, and now that the OpenACS community has gotten its collective hands around it, it is even better than it would have been as AD's ugly step-daughter (we all know that the java version emits much better html 😉 ).

4: Response to General Comments changed for the worse (response to 1)

Posted by Kjell Wooding on 12/14/01 08:03 PM

I am of the same general opinion as Don, that these type of
changes (UI) should wait until the long-awaited release is out the door. I'd be sure to get your comments into the SDM, however, because they are valid concerns, and the kind of thing that shouldn't be forgotten about.

And "forgetting" is all too easy to do with the flurry of a release between here and there.