Forum OpenACS Development: Re: Should an optional service package modify an application package?

Just a quick note that this patterns occurs in other contexts.

I've been thinking of writing a "feedback" package, which would replace the current general-comments and include other types of feedbacks, such as ratings, or any other type of "pick one (or more) from a list of options" type feedback. (Ultimately, this could be extended to do anything survey does - or, obviously, be implemented using survey as some sort of back-end ...).

The UI here would be a link next to the object that says "comment" or "add feedback" or "rate this *object name*".

Another example: I've also been thinking about a list package, which would let users build lists of objects on the site. Sort-of a bookmarks module internal to the site. Think "My favorite books/places to eat/contacts/movies/whatnot", think IMDB movie lists, Amazon shared lists with comments, etc.

The UI here would be a "Add this object to list <dropdown>"  widget next to the object.

The current structure would require all packages that want to enable feedback or allow users to add its objects to lists to 'require' the lists and feedback packages, and put the widgets where they want to.

A more sophisticated solution would be to make it optional to install the feedback and lists packages, and the applications know how to check and provide the proper links.

An even more sophisticated solution would be that the links to feedback/add to list automagically show up even in applications that don't know about them, when you install them.

Does this sound related to your thoughts about DAV?

I would tend to opt for the first, very simple solution: file-storage would simply require the DAV package, and if you don't want DAV support, you still have to install the package, but you can disable or not setup the DAV package, and hence not have DAV support.

Does that help any? I'm not sure I understand the details of your problem.

/Lars

I think for this to work it might make sense to have a "display" function for each package, that would display the object(s). Onto this display function you could then hook additional items as Lars has described them in point 3. Hopefully there are other alternatives as well.
Lars, have you written up any design docs on the feedback idea? What's the path to its implementation?

talli

Whoops, too quick on the submit and confirm buttons.

DaveB and I were discussing that items like forums really ought to be simply "kinds" of general comments. That is, a general comment is simply a package to attach a forum/bboard discussion to an arbitrary article/object. Why should a forum simply be the creation of a general comment to an empty object? (If I am using the term "empty object" incorrectly please correct me)

Perhaps your feedback idea is taking this conception of general comments and its types to an even higher design discussion?

talli

There's no design doc on the feedback package yet, but I think we all agree that general-comments needs replacing, and that we want it to support more than the current general-comments package does, such as:

- anonymous feedback/not requiring login

- not requiring a title

- ratings

- attaching a file

- feedback types/categories

- structured feedback, such as multiple input fields, ratings along  multiple dimenions, etc.

On an architectural level, I'd rather implement this as a thin layer on top of CR than I'd, say, "attach forums to an object", or for that matter "attach survey to an object". But I'd rather see the feedback package than not, so I'm not religious about it.

As far as the path to implementation goes: It's not on the top of my list.

/Lars