Onlineweb apps feedback

Implementation of Models

• Extreme care must be taken when editing forms. Be careful not to change the meaning of questions. Everyone except dotKom should not be able to edit Feedback schemas, but users should be free to create schemas.

The feedback system as of today is an anonymous customizable feedback solution where every Django Object can have a feedback schema connected to it.

The Feedback schema has two properties, a description and an author. And consists of a set of instantiated questions.

The implemented Question types are RatingQuestion, FieldOfStudyQuestion and TextQuestion, and they are all related to a Feedback schema. The only field that is customizable in the questions are the question text. The questions are related to answers.

An Answer to the Question in relation to the Object.

• Q:"Was the food good?"
• A:"Yes" - when we are talking about "Julebordet"

The feedback Relation has the following convenience methods for getting the questions and answers related to the object:

• answers()
• answer_to_question(question)
• questions()

To ensure that a user only answers once, the FeedbackRelation saves users that has answered in a list, and exposes a method can_answer(user) that returns a True if the user can answer. To limit the users allowed to answer, for instance to every user attending "Julebord", the "Julebord" object can expose a property "feedback_users", and can_answer also checks the users against that list.

TODO a UML-diagram of the models

Forms

I have created a form for every Answer type in the system, and a convenience method for creating a list of forms for a FeedbackRelation, so that we more easily can create the various forms we need.

For now, every field exposed to the user is required for the form to be valid.

Views

feedback/<content_type.app_label>.<content_type.model>/<object_id>/<feedback_id> (the parameters) /feedback/user/auth/1/1 is the feedback schema for a user /feedback/user/auth/1/1/results is the answers to the feedback schema above /feedback/ lists all the feedback schemas

Further work:

• The results view must be reimplemented, with aggregation of answers
• Mean rating, Rating variance and Rating count
• Master and Bachelor count
• Field Of Study count
• If the model has feedback_users display the users that have not answered
• add a "Give Mark" button?
• The feedback schemas need a proper title, should be a combination of the Object title and feedback description.

Templates:

No styling of forms or results view has been done.

It would be cool to use d3.js, or some other javascript lib, to display pie/histogram/line-charts for "Field of Study" and "Grade" questions. Preferably the user should be able to save a local copy of the chart as an image (so they can use it in other documents)

Model thoughts:

Today there is a Many to Many relation between Objects and Feedback schemas. I do not think this is necessary, as our usages of Feedback schemas has been only one for each event.

Do we need to have this feature? It can lead to confusion and is harder to maintain.

Creating shemas

First in the admin page, create a Feedback Schema Then Create a FeedbackRelation to a object Then visit /feedback/ to find the url to the given feedback

-Sigurd

Håkon's Updates

• Marks are given automaticly through the feedback_mail_sender
• Field of study data is pulled from the user object and FieldOfStudyQuestion has been removed.
• Graphs are drawn using the Jqplot jquery plugin.

TODO

• Check permissions for /results
• Check permissions for /chartdata
• Filter bad text answers.
• Permission tests
• Feedback archive