8

One limitation of a program that I maintain is that the end-users often don't know what changes have been made. To remedy this I would like to show my users a simplified list of changes made to their program. Is there a good methodology/approach to follow that would create a easy to update list that could then be fed into the user interface?

For example: Should I store everything in a XML file that is read into a form? Should the change history go into a database?

Note: The program is Winforms (C# 4.0).

UPDATE

Based on the excellent feedback I have decided to use SQLite as my information storage and will provide the users with a chronological list of changes in a TreeView control.

Improve this question
2
  • 1
    Just let them know when you've moved their cheese.
    – JeffO
    Oct 13, 2011 at 0:07
  • You might want to ask this on UX.se
    – Ilari Kajaste
    May 28, 2013 at 4:54

3 Answers 3

Reset to default
13

Users don't generally care about things the same way you do. While you can be lazy and simply publish your bug list, it's far better if you take a little time and highlight the changes in the user's language.

This means losing detail. For the ones who want all detail, you could include a full list of issues addressed--but in general your release notes should only show, in this order:

  1. Major new functionality, in the user's language.
  2. Changes in workflow, possibly with a justification. E.g.: "The print dialog has been streamlined; you can now find page layout options on the print page, instead of their old location under Document Options."
  3. Major bug fixes, in the user's language. E.g.: "Crashes are less frequent when opening files over 2 GB" rather than "Fixed buffer overflow in mt_file_read for inputs > 2GB"
  4. A summary of any minor changes to workflow and tiny new features
  5. In general, users don't care about minor bug fixes, so just say "and bug fixes" or the like. Again, you can provide a link to the full details for the programmers in the audience. ;)

This is more work, and your users will really appreciate the attention to detail.

Improve this answer
1
  • 2
    +1 - User langague is definitely important. I am going to focus on user relevant (not me refactoring a method/class/etc) changes that affect how they use the program.
    – John M
    Oct 12, 2011 at 17:30
5

Any decent issue tracker generates release notes (based on the closed stories in a release). Embed that as a text file and show it anywhere you like in your app.

Improve this answer
1
  • 1
    +1 usually there is a separate field for release note so the issues in Alex's answer can be avoided
    – jk.
    Oct 12, 2011 at 14:15
2

The first question you need to answer is if your users care. There's no need to implement any functionality or user interface components in order to add something that users don't want or need. That's just more code that needs to be tested and validated. If there's no requirement for this information to be displayed in the application, you're just gold plating the requirements - a known antipattern.

If your users do want this information, you need to determine how to make it available. That should be driven by the users, through requirements that they provide. You seem to want to present it as a tool accessible through the user interface. However, there are many other options that should be considered, and discussed with your users (or the subset of users who might want this information). Possible options include a "changes since last release" in the README or user's manual, a changelog file alongside the README or user's manual, or a web page on the product's website that describes the changes in the latest version with the ability to view changes between latest versions. Depending on the file format that you use for the changes, you could either open that file using the OS-specified application or parse the file and display it in a user interface as well.

Regardless of how you deliver it, don't do it because you want to, but because your users want it. Otherwise, you're just creating work for youself that adds no value to your product.

Improve this answer
3
  • They will want the functionality occasionally (did you make the changes we asked for?) - I will also benefit with a chronological list of changes - amazing what you can forgot in 6 months.
    – John M
    Oct 12, 2011 at 17:30
  • @JohnM Have they told you that they want the functionality? Have they told you that they want it viewable from inside the application? Don't gold plate. Complete only the established requirements, and achieve them in the simplest possible manner.
    – Thomas Owens ♦
    Oct 12, 2011 at 17:35
  • Making the list viewable from the application could be as simple as adding a clickable link to the URL the change information on the companies website in a menu or about dialog (such as a LinkLabel control). If you truly need offline accessy, you can always link to a static HTML file installed with the application.
    – Stephen C. Steel
    Oct 12, 2011 at 21:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.