All OpenMRS ID accounts have been reset.

Read more and change your password before signing in.
Icon

EXTENDED: OMRS14 Proposals due 30 April! Read more and submit a proposal at OpenMRS Talk.

Skip to end of metadata
Go to start of metadata
Icon

The outcome of this project can be seen here: Feedback Module

Primary mentor

Ben Wolfe

Backup mentor

Burke Mamlin

Assigned to

Gaurav Paliwal

Purpose

The intention of this project is to provide a mechanism for users to communicate with system supporters/admins with system-related (not patient-specific) messages. For example:

  • "The system is running much slower than usual today."
  • "We need a diagnosis term for Sarcoidosis."
  • "This system would be better if I could more easily find my patient's lab results."
    and eventually:
  • "I tried to select BOB SMITH and got this error" (with screenshot and a snapshot of recent log exceptions attached)

Ideally, this is ubiquitously available in the interface in a simple & intuitive format – e.g., a "Feedback" link (or button) or an option under "Help" like "Send Feedback" that pops up a simple form.  When feedback is submitted, the user receives confirmation and the feedback is forwarded to the system administrator.

Interested Parties

Required Skills

  • Experience with java programming
  • Familiarity with JSP and servlet programming

Objectives

  • Build an OpenMRS module
  • Add a "Feedback" link to the OpenMRS header
  • Collect feedback through a modal form
  • Create an administration screen for viewing and managing feedback

Design Ideas

  • This is best served by a module instead of being built into core OpenMRS.   The module should link to an extension point in the header of the page to provide the same access throughout the app.
  • The feedback form could have options like "Report a problem" (default), "Request a new feature", etc. followed by a textarea and a submit button.
  • When the form is submitted the user should receive some form of confirmation ("Thank you for your feedback")
  • The text entered by the user should be saved along with context (e.g., page they were on) in a row in a feedback table created by the module.
  • The feedback table contents should be displayed in a jsp page so that an admin can see all feedback, delete feedback, act on it, etc.
  • Since feedback could contain sensitive patient information, we want to avoid sending feedback content directly over e-mail.

Extra Credit

Ordered by priority

  • You have a bordered box in a popup dialog, which gives unnecessary nested borders. Get rid of the box. Done : http://twitpic.com/5xf02w/full .
  • Allow multiple comments for a feedback item : Done.
  • Allow admin to set an e-mail address to receive notifications of new feedback entriese.g., the admin may wish to receive an e-mail with convenient links to act on the feedback (e.g., single-click options to "delete", "-mark as duplicate", "forward to OpenMRS as bug", etc.)- : Done , screenshots : http://twitpic.com/5xrtr9/full
  • Allowing for the simplest use case of clicking a feedback button, writing a comment in a textarea, and submitting – i.e., provide a default for other fields or make them optional. ( Source : Link ) : Done
  • No need for Index column in predefined subject edit form ... Done , screenshots : http://twitpic.com/5xj1oo/full , http://twitpic.com/5xj1sh/full , http://twitpic.com/5xj1vo/full
  • Why are times not being stored? I only see dates for what should be a datetime column Done: Now changed to the timestamp in liquibase.xml file : http://twitpic.com/5xg0ml
  • Rather than "Add Severity" and "Add Status" perhaps use "Severities" and "Statuses" ... "Stati"? Done , screenshots : http://twitpic.com/5xjho2/full and http://twitpic.com/5xjhpn/full .
  • In case you add a severity after the module has been running for a while, you should be able to put it in the middle of the list, where it belongs. (Same for status.) (adding a "sort_weight" column to each of the two tables?) Done will be seen as of very next commit after commit 22100 .
  • "Creator" should probably display the default PersonName rather than userid ... unless that is a requirement. : Done : http://twitpic.com/5xgc02/full
  • It would be nice for the admin to be able to define what text is shown to the user after they submit. It could just be stored as a global property. - Ben Wolfe ( https://source.openmrs.org/cru/CR-MOD-202#CFR-9188 )
  • In Manage Feedback, change Date Submitted to age (e.g. "yesterday"). Added Support to : http://ocpsoft.com/prettytime/ , screenshot : http://twitpic.com/5xit6d/full  is this okey ?
  • Perhaps show example of "default" selections for subject and severity level. : Done.
  • Can the simple edit forms be done in a popup dialogs?  (same for other one-liner phrases) Done.
  • Provide a simple mechanism for the admin(s) to forward feedback to OpenMRS when appropriate (e.g., bugs reports) – i.e., after removing or ensuring there is no identifiable patient information in the content. Done.
  • Allow the admin to edit templates for e-mail notifications (both confirmation to user and notification to admin)
  • Optionally e-mail the user confirming that the feedback was received with a "ticket number" to uniquely identify the feedback : Done.
  • Put some example subjects, severities, etc into the module.This will let people test it immediately and help guide them towards what kind of subjects/severties, etc they should use. Done.
  • Add a "cancel" to form when editing a subject.
  • Why do I see "feedback.notification.number.error" as the message after adding a subject with an invalid priority?
  • Add a description after the priority input box so users know what/why/how/who/when it is.
  • Make the priority input box a lot smaller.Only needs to be big enough for a few numbers
  • Edit subject page has "feedback.sortWeight"
  • Remove the help text on the edit page, its confusing because it doesn't look like the page changed at first
  • Rename the help sections to all just have the title of "help"
  • Reword the help to be something like "This is used for ...." or "this is meant to be used"
  • The second like should be "Example statuses are: "", "_"
  • When using the "submit feedback" in the upper right, don't redirect the user to the "Add feedback" page after they have completed.Just let them stay where they are.After clicking "submit" it should be like they just clicked the "X" on the modal popup.
  • After submitting feedback either from the Add Feedback page or using the Submit Feedback form, the success message is squished in half and unreadable : This will be solved once defaults are put in the settings.
  • Why do you have both "Manage Feedback" and "Submitted Feedback" in the list of links?  You should only need one : Holding this for now as Manage Feedback is for listing of all feedback whereas Submitted feedback is to list the feedback submitted by currently logged in user.
  • Match the order of links in the local header to those in the admin extension point.Use a LinkedHashMap in the admin extension point java class if you aren't already so that its sorted on order of entry instead of randomly : Already using this, now fixing order now.
  • Rename "setting" to "Settings"
  • Put defaults in the settings boxes
  • Add descriptions next to the settings boxes so users know what they are for
  • Change EMail > Email
  • Email Id > Email Address
  • The email boxes don't need to be so huge
  • The message boxes probably don't have to be so big either. : Assumed this is Feedback Message Content
  • Add "label" html tags on the user preferences pages.  Its a nice little addition to radio buttons to make them more usable by users.  You have to set a certain attribute on the label to the id of the radio button it controls.  Look up that syntax, I don't remember it.
  • --User Preference --> User Preferences-

Resources

Implementation Idea

[Here|https://wiki.openmrs.org/display/projects/General+Feedback+Mechanishm+%28Implementation+Ideas%29]