LikeBack - Quick Feedback from Beta-Testers

• What is the LikeBack System?
• The User Interface
• The Server-Side Interface
• What's Sent by the Client?
• Return of Experience
• Embed it into your Application
• Feedback Needed
• Future Ideas
• Version History

What is the LikeBack System?

The system comes from the need to allow users to communicate theire liking of the applications to its developers. Thus, developers know what theire users prefer on theire applications, what should be enhanced, etc.

Basically, how does it work? Whenever the user notice something good he appreciate or something he do not like, do not understand, do not find polished... he can send a few short words to the developers to tell them what he like or do not like. It's only two or three clicks away. It's fast, efficient.

This greatly lowers the communication barrier between the application developers and the application users.
It makes the developers understand and satisfy better the needs of the users.

As an addition, this technology can be used as a bug reporter and feature wish reporter by small programs that do not possess a bugzilla account.

The User Interface

The user access the LikeBack comment dialog throught the application Help menu:

A window is then displayed for the user to choose a comment type and write his toughts:

Whenever the user clicks "Send Comment" the first time, or clicks the "Email Address..." button, the following dialog is shown in order for the user to set up his email address, for feedback purpose:

Then, a dialog informs the user his comment has been successfuly sent to the developers:

For small applications, the number of users who discover the Help menu entry may be too small for the feedback to be useful. In this case, developers can enable the button-bar (see below). The first time the application startups with button-bar enabled, the following introduction dialog is shown:

And here is the button-bar. The bar sits bellow the titlebar of every active windows, making it one-click away for the user to post comment about a sentiment she get at the instant, without the barrier of the user searching the developer(s) email address, firering up a new email window, choosing a title for the email, etc. Clicking one of those icons pops up the comment dialog seen above, with the right option checked, and the text area focused. The current window name is also sent with the comment, letting developers to know what part of the interface the comment refers to. At the bottom of the comment dialog, there is a checkbox for the user to explicitely enable or disable the bar.

The Server-Side Interface

Here is the main screen of the LikeBack developer interface:

Developers can filter data. They can show only bugs, only comments in the language they understand, only comments still to be threated, search a text in comments, etc.

When hovering over the date, the time is shown in a tooltip. On the window name, it shows the whole window hierarchy. And over the email icon, it shows the email address... That email address is clickable, to directly contact the author.

The developer can click the status icon of a comment to change its status. It's to mark comments as solved (to not see them anymore in the interface), as confirmed by one developer (meaning this need to be fixed), or in progress, to tell other developers that someone is currently working on fixing it:

When clicking a comment remarks icon (the yellow sticky notes) or comment id number, a new page let developers to add remarks to the comments. This allows developers to discuss points between themselves:

The server is capable of sending emails to some developers whenever a new comment has been sent. So, comments can be managed with a simple email client. Each developer can configure what comments are sent to him within the E-Mail Options window:

What's Sent by the Client?

When a user posts a comment, here is what is sent to the server with that comment:

• Application version: in order to know if the bug is still valid or not.
• Locale: the KDE language of the user. To try to guess the language of the comment, or to incriminate typo errors to the good translation.
• Window hierarchy: the hierarchy of the window names opened when the user clicked a comment icon. Some comments can be related to what the user has seen or done, so it helps understand the contect of the comment. Note: window hierarchy is not sent if the comment dialog was trigered by the Help menu entry. This is because the user can refer to anything in teh aplication.
• Context: reserved for future use. In the future, developers could call something like LikeBack::setContext("editing a note"), to complement the window name. So we know the user was in the main window, but also roughly what he was doing.
• Comment: the message the user typed.
• Email address: if the user provided an email address, it is sent for the developers to be able to contact him later to get more information about his comments.

Return of Experience

This is the third iteration of LikeBack.
Before publishing it here, I waited to get some feedbacks about that feedback system ;-)

The first LikeBack iteration was published with BasKet Note Pads 0.6.0 Beta 1. So here is what I modified in the second iteraction of LikeBack in BasKet Note Pads 0.6.0 Beta 2, and the experience I got from this system:

• People like to report bugs and dislike comments more than positive comments. So, I do not advise LikeBack for developers subject to depressing. LOL
• It's an easy way to get lot of bug-reports.
• As it's quick to report, you get more reports for small bugs. That helps you polish your application. For instance, little layout errors, english typos... all the small things that would be too heavy to report with traditionnal bugzilla, or even by e-mail, but make your application more professional.
• Even if it's well written to the user that wishes are ignored, some people included feature wishes in theire comments. It's to the developers to do what they want of those wishes: yet another source for the To Do list, delete them...
• I got feedback from people explicitlely telling this is the first software they commented on. Especially non-techy people. Emails, mailing-lists, bug reports... are mostly filled by geek people. This LikeBack system allow to broaden the groups of people who comment.
• Initialy totaly anonymous, some bugs reports were not understandable or needed more precisions. It was needed for the bug reporters to test if the bug was still there after a patch was procuded... Like/Dislike/Feature comments need more precisions in order to understand how the person is using the application to take a good decision concerning usability... So, now, the email is always asked the first time a person send a comment, while she is always offered to post anonymously. Most users attach theire email address to theire comments.
• I've got one report about a typo error. But I was not knowing what was the erroneous translation! So now, the comments also send the locale of the user. Typos errors can be incriminated to the good translation. It also gives us a free bonus: in a team of internationnal developers, they will let the users send comments in whatever language they want. Comments could be automatically sorted and assigned to the person who understands the language the comments are written in.
• The client send the current window name so we have a context for the user message. But some windows can be triggered from a lot of places. It's the case of error windows and the like: KMessageBox dialog names are "information"/"error"... If a user encounter an error he is likely to send feedback while watching that dialog, so we loose the context of the error (from what parent window was it triggered?). Now, a window name hierarchy is sent with the user comments.
• Some users complain about not finding the basket encryption feature. This feature needs gpgme compiled in. We should be able to include the KDE/Qt/gpgme version with the comments, so we know if it is a bug, we could reply to the user on how to compile gpgme support... Of course, this need to be extensible: every developers could include whatever information they need. This is not done by now.
• When developing in a team, the server-side viewing module should allow developers to add comments for every reports. And they can have discussion about a few sent comments. Developers could add "Can't reproduce" or "I found it. Will solve it tomorrow"...
• Add a unique ID for every comments (like in bugzilla) so developers can refer to them quickly instead of using the long timestamp of the comments ;-)

As a user, you can test the interface of the improved version of LikeBack in BasKet Note Pads.

Embed it into your Application

It's currently a KDE 3 technology, for testing and proof-of-concept purpose. But my aim is to integrate it into KDE 4. So in a few months it will be ported to KDE 4.

Since it's not integrated to KDE yet, you have to download it and import it into your project. You then need to instanciate it into your application. Then, you should install it on your server.

Download LikeBack 0.4

Add the files in src/ of the downloaded archive to the source folder of your application. You need to modify the Makefile.am file of your src/ directory to include the new icons. I provided a Makefile.am.section file for you to copy the needed lines in yours. Basically, replace the line starting by "kde_icon_KDEICON" with the one I provided, by taking care of replacing "YOURAPP" with the UNIX short-name of your application.

To setup the client-side object, follow the API documentation. It explains lot of things, and is featured with a ready-to-copy-and-paste code example in the description. If you do not want to fine-tune LikeBack or understand it, just copy this code to your application.

Now, you need to install the server-side. Copy the server/likeback folder from the archive to your web server. You need to edit db.conf.php. Keep $dbType to "mysql": nothing else is supported at the moment (if people want more, they can code it ;-) ). Put your server host, your database, your user and password.

Everybody can post new comments but, of course, only authorized developers can view them. Edit the file admin/.htaccess and make sure AuthUserFile points to the .htpasswd file in the same folder. Then, edit the file admin/.htpasswd to include all the user names and encrypted passwords. To crypt a password, use the command htpasswd2 or use a website that offers such services.

Finally, open a webbrowser to the address admin/install.php to create the database. Remove the file admin/install.php to avoid any wrong manipulation in the future :-)

You're ready: try to post a comment to see if you can view it in the admin page. The source code of your application must be configured to join the script send.php in order to send comments.

Feedback Needed

After having used LikeBack in BasKet Note Pads, got experience and returns from it, and modified it to fit better the needs, I'm releasing the system for other developers to be able to use it, but also in order to get feedback from other developers. So it will be in good shapes for KDE 4. I need feedback from the following three groups:

• kde-core-devel: is it possible to integrate it into KDE 4? What do you think of it?
• kde-usability: have a review of the user interface.
• Application developers: integrate it into your application, and tell me if it is sufficient, what are your needs, what extension need to be done, is it re-usable enought...

I think KDE as a whole would benefit from LikeBack being enabled in beta-releases of applications. It helps people report more bugs, more small glitches they had experienced, in order to improve the whole quality of our desktop...

Future Ideas

Here are possible or planned enhancements to the system, from the biggest priority to the lowest:

• Client side:
  • One first-time message PER DESKTOP, and not per application (kdeglobals instead of to the app's config). Little reminder passive popup the next times (& show examples). Remember what examples were shown and then show the message again if it should show the functionnality of a new icon...
  • Integrate "Report a Bug" with "Send a Comment"
  • Reparent icons on window change
  • Tell the user on contact failure
  • When no internet connection, place in drafts folder
• Server:
  • Use AJAX in showing and sending remarks, so it's quicker because no list reloading have to be done
  • Manage duplicates (two clicks maximum, no reloading)
  • Assign priority
  • A button to validate and send the comment to bugs.kde.org
  • RSS feed?
• Other ideas:
  • A way to include extraneous information, like the KDE, Qt, libraries versions, in an extensible way.
  • Let users attach a screenshot to describe better bugs... A picture is worth thousand words.
  • Provide a button for user to explicitely send usage statistics: the maximum number of documents opened at once, the state of the configuration options...
  • Let developers to add application contexts to know what the user was doing before commenting.
  • Include usability surveys. A new button to display a form to fill a user survey. Check on internet if it is still active, of course. Or simply open the browser to that survey. It will be a more easy way to adversive usability surveys that news in RSS feeds, and better to touch a broader number and diversity of people.
  • Perhapse send the application name as well. So, a central KDE LikeBack server could be used by developers of small applications. Those developers can do not have the necessary hosting, PHP extension enabled, or database access. That central KDE server could aggregate comments from many applications, and redirect the comments by email to the developers, even if it does not store the comments in database.

Version History

• 0.1: First release as a proof of concept. Released in BasKet Note Pads 0.6.0 Beta 1.
• 0.2: Enhanced version, taking into account the feedback and experience got from the first jot. Released in BasKet Note Pads 0.6.0 Beta 2.
• 0.3: The server interface has been worked out, no more a simple table listing comments. Done in order to release LikeBack to other developers.
• 0.4: changes made after the feedback received of both kde-core-devel and kde-usability:
  • User Interface:
    • The dialog is now available in "Help -> Send a Comment to Developers". Also make LikeBack includable in applications without windows
    • Reworked the layout of the commenting dialog according to usability advises (including a Cancel button ;-) )
    • LikeBack dialog have a checkbox "Show comment buttons below window titlebars" to show the button bar (hidden by default)
    • Added a button [Email Address...] in the dialog
    • Added the Ctrl+Return keyboard shortcut to send the message (Return create a new line in the text area)
    • Sentences like "Please write in English or French." and not shown anymore if the user locale is one of the mentioned ones
    • No more configure menu: user can turn off button bars in the comment dialog, and change email. And "What's This" is quite useless
    • Only like/dislike buttons by default
    • Added a feature wish icon, removed setAllowFeatureWishes(), initial message shows a wish example too
    • Include the bug icon in the likeback icons to install, and modified it for non-technical users to understand it
    • Use smileys for like/dislike icons, as advised by usability people
    • The Tab key in the text editor switch focus to the Send button
  • API:
    • Developers can hide each buttons (patch from Aaon J. Seigo)
    • A much better API (no more static functions and separated the button-bar into its own private class)
    • D-ptr-ified the class LikeBack, and moved private classes in a private file
    • Complete API docs
    • Relicensed as LGPL
  • Developer Interface:
    • AJAX-enabled status change (no more reloading of a big comment list for so little changes, more efficient)
    • The server can send emails to several developers at once on new comments. It was buggy in 0.3.
    • Background color of admin header to dark blue, to match the background image (was black)