Google Allows Search Queries To Interact With Apps

Android 5.0 Lollipop brings lots of new features that are quite useful for end users and … more

Lenovo Officially Owns Motorola, Following ~$3 Billion Deal

Google is now officially no longer the owner of American phone manufacturer … more

Microsoft Band Fitness Tracker Announced, Available

The wearable market has been around for a few years, with Pebble and Samsung smartwatches … more

Forums Added for the Oppo R5, Oppo N3, and Xiaomi Redmi Note

Just yesterday, Oppo unveiled a pair of rather unique smartphones, the Oppo … more
Post Reply

[GUIDE] How to give constructive feedback to developers

OP joe_coolish

15th November 2010, 06:28 PM   |  #1  
OP Recognized Developer
Flag American Fork
Thanks Meter: 229
 
753 posts
Join Date:Joined: Mar 2010
Donate to Me
More
In the world of software development, applications pass through many phases before being released, some of which include designing, planning, coding, testing, Alpha Release, Beta Release, Release Candidate, and finally Release. This guide is intended to help the people involved in public/private beta tests that do not have experience programming, but would like to give valuable feedback to the developer.

Disclaimer
This guide is specific to programming for the Windows Mobile Operating System, specifically for the .net Compact Framework 3.5. However, the main concepts should translate over to other platforms and frameworks.

In the beginning...
First off, programming is hard. Building applications that run smoothly and are bug free require considerable amounts of time and energy. In short, software development is an emotional investment on behalf of the developer.

Because software development is an emotional investment, developers will easily take offense to criticism. This is where rule number one of giving constructive feedback comes in:

Rule number #1, When Giving feedback, be polite!


During my time on XDA-Developers I've been very happy with level of professionalism demonstrated by its members, but every once in a while I'll see a comment like, "This app sux!" or "Eff Dat shiz!".

Always remember, rude comments only distract other users, cause contention, and cause the developer to become less motivated (less emotionally involved) to produce software. If the application is not working on your device, remember the developer is the first person who will be able and willing to help you resolve your problem, so they should be the last person you want to offend. [1]

This is where the term Troll comes from. A troll is not the ugly monster that lives under the bridge, but is someone who is like the fisherman that "trolls" the river for fish (or heated response in the case of internet trolls)

Rule number #2, be constructive!

What's interesting about this rule is that the phrase "be constructive" in itself is not constructive. So how do you "be constructive"? Labeling a comment as constructive is not deterministic, or in other words there is no formula to test whether or not your comment is constructive. The rules in this guide will attempt to give you some pointers to giving constructive comments, but in the end, only a mix of common sense and human reasoning can determine if a comment is constructive.


Some examples of non-constructive comments
  • The app is broken
  • "It" crashes all the time!
  • I get an error message, plz help!
  • When will the app be finished?
  • etc
Rule number #3, if the app crashes include details about the crash

Let's be honest. Programmers aren't perfect. In a list of common excuses given by programmers in response to different bugs, the number one response was "Well, it works on my machine!". If you are a developer you know this is true! I catch myself using this phrase all the time! But, what can we learn from this? Well, first, the crash/bug you are having might not have ever been seen by the developer (if it had, chances are they would have fixed it!). Because of this, you must include as much relevant information about the bug as possible.

What is considered relevant? That is the million dollar question. I will attempt to give some guide-lines on how to determine what is and what isn't relevant.

Rule of thumb: When in doubt if info is relevant, include it.
It is hard to include too much information (hard, not impossible), but it is very easy to provide insufficient information to the developer.

What did you do?! Is it reproducible? What did you expect to see?
The crash isn't your fault. But if the developer doesn't have the steps to take to reproduce your error, they can't find the bug!

When you get a crash, first thing you need to do is try and remember as many steps as you can to reproduce the bug. Then, restart the app and follow the same steps to try and get the crash screen again.

You need to tell the developer if the crash is Always reproducible or only sometimes reproducible. Then you need to create a list of steps to get the crash. Try and always use an ordered list when doing this. It makes it easier to read and follow.

Finally, tell the dev what you were expecting to see and what you actually saw. Some bugs don't crash but instead produce results that aren't exactly what was expected. For example, "I clicked on the 'Read' button, it won't let me read the page!" Well, the bug in this case could be that the word "Read" is ambiguous and really means "have Read" as in "I have read the page already, so mark the page as 'Read'". This is a "What I expected and what I got" error. All the info that is required is the steps to reproduce, what you were expecting and what you got.


What is your device/ROM/Windows version?
Sometimes this is necessary, so if your device is not in your signature, include it! If it is in your signature, include it anyways!

The Crash Screen
If you are lucky enough to get a crash screen, most likely you will be able to supply enough information from the error message to the developer for them to figure out what went wrong.

If you receive the following message (or a translation there of), you must take an additional step in order to get the real crash message:
Quote:

"An error message is available for this exception but cannot be displayed because these messages are optional and are not currently installed on this device. Please install ‘NETCFv35.Messages.EN.wm.cab’ for Windows Mobile 5.0 and above or ‘NETCFv35.Messages.EN.cab’ for other platforms. Restart the application to see the message."

This error message means you don't have the right software installed to display the crash message. To fix this, load the appropriate cab onto your device. Message cabs are located at: C:\Program Files (x86)\Microsoft.NET\SDK\CompactFramework\v3.5\Wind owsCE\Diagnostics

If that directory does not exist, install the Power Toys for .NET Compact Framework 3.5 and check again.

Anatomy of the Crash screen.

Here is a crash details report from my XDAFacebook application. I will describe each part and what they mean, what's important and what the programmer is looking for:
Quote:

XDAFacebook.exe
ObjectDisposedException
at Microsoft.AGL.Common.MISC.HandleAr(PAL_ERROR ar)
at System.Drawing.Graphics.DrawImage(Image image, Int32 x, Int32 y)
at XFControls.XFPanels.XFPanelList.PanelPaint(Graphic s g)
at XFControls.XFPanels.XFPanelBase.OnPaint(PaintEvent Args e)
at System.Windows.Forms.Control.WnProc(WM wm, Int32 wParam, Int32 lParam)
at System.Windows.Forms.Control._InternalWnProc(WM wm, Int32 wParam, Int32 lParam)
at Microsoft.AGL.Forms.EVL.EnterModalDialog(IntPtr hwnModal)
at System.Windows.Forms.Form.ShowDialog()
at XDAFacebook.SplashScreen.SplashTimer_Tick(Object sender, EventArgs e)
at System.Windows.Forms.Timer._WnProc(WM wm, Int32 wParam, Int32 lParam)
at System.Windows.Forms.ApplicationThreadContext._Int ernalContextMessages(WM wm, Int32 wParam, Int32 lParam)
at Microsoft.AGL.Forms.EVL.EnterMainLoop(IntPtr hwnMain)
at System.Windows.Forms.Application.Run(Form fm)
at XDAFacebook.Program.Main()

The first line: XDAFacebook.exe is the application that crashed. This is important, because if the application relies on multiple .exe files, the one that crashed needs to be known. Always include which .exe crashes.

The next line is the type of exception that was unhandled: ObjectDisposedException. This is also very important. Always include this in your report. If anything, this is the most important piece of information.

The next part is called the Stack Trace. In 2 sentences, the stack trace is an ordered list of methods (or functions) that pin-point where the in the code the crash happened. Think of it as turn-by-turn directions to the line that caused the crash.

The stack trace lines have 2 parts, the NameSpace and the Method. The NameSpace is the series of "Strange word followed by a Period". The method is the "Strange word followed by parenthesis that might have strange words inside". In XFControls.XFPanels.XFPanelList.PanelPaint(Graphic s g), the NameSpace is XFControls.XFPanels.XFPanelList and the Method is PanelPaint(Graphics g)

Some of the lines aren't important. Most of the lines are. The most important lines are usually at the top and will have NameSpaces that looks like the application that crashed (or don't look like they come from Microsoft). The best thing to do is include all of the stack trace, but it is also good to know what exactly you are telling the programmer.

Here is basically how I would read the stack trace above:
Quote:

Hey, your application XDAFacebook.exe had an ObjectDisposedException exception that was thrown by the System.Drawing.Graphics.DrawImage(Image image, Int32 x, Int32 y) method, which was called by FControls.XFPanels.XFPanelList.PanelPaint(Graphics g) inside the XFControls.XFPanels.XFPanelBase.OnPaint(PaintEvent Args e) method.

If any of those lines weren't in the report, I wouldn't be able to get the full picture. So, unless you have a good understanding of the application's source, include the full report!

Developer Defined Messages

Developers try to handle as many errors as possible. In the case that you get a Message from the application signifying some kind of error has occurred, supply the message the occurred, the steps you took to get the error and your "What I expected and what I got". If the message isn't enough information, the developer needs to change his message.

Also, check for any debugging options which the developer may have included, such as a log file. These either tend to be automatically generated files in the install directory, or they exist as a viewable panel within the application. Check with the documentation or ask the developer where these log files exist [1]
Rule number #4, be smart.
I should put this higher in the list, because it really should be the first thing you need to do.

First thing you need to do is make sure you have the latest version of the software installed. Also do a quick search of the thread to make sure that the bug hasn't already been reported. If it has been reported, I personally don't mind a quick "I have the same problem, here are the steps I had to reproduce..." with a link or quote of the original error.



This guide will be updated as I come up with new observations and as people respond with questions/suggestions. Please tell me what you think of the guide and always try and be constructive when you are beta testing software!

Thank you

**updates**
[1] 12/7/2010 (Thanks meltwater!)
Last edited by joe_coolish; 7th December 2010 at 08:29 PM.
The Following 47 Users Say Thank You to joe_coolish For This Useful Post: [ View ]
15th November 2010, 10:57 PM   |  #2  
y0himba's Avatar
Senior Member
Flag In a house.
Thanks Meter: 43
 
399 posts
Join Date:Joined: Sep 2008
Donate to Me
More
This is one of the best guides I have seen on any forum. This holds not only true for feedback about a program or your program, but jsut about any post or feedback on an Internet forum. Thank you very much for posting this, and I hope more folks read it.
16th November 2010, 05:27 AM   |  #3  
oldsap's Avatar
Senior Member
Thanks Meter: 10
 
1,092 posts
Join Date:Joined: Apr 2006
Quote:

Rule number #1, When Giving feedback, be polite!

this is one of the things most people forget to observe when commenting.
18th November 2010, 01:25 AM   |  #4  
OP Recognized Developer
Flag American Fork
Thanks Meter: 229
 
753 posts
Join Date:Joined: Mar 2010
Donate to Me
More
Thanks for the comments. Yeah, I hope that this list can help with the beta testing process.
The Following User Says Thank You to joe_coolish For This Useful Post: [ View ]
18th November 2010, 03:45 AM   |  #5  
Cyclonezephyrxz7's Avatar
Senior Member
Flag Paramus
Thanks Meter: 14
 
672 posts
Join Date:Joined: Dec 2008
Donate to Me
More
If I were a Mod, I would so Sticky this for all to reference in the future.

[Hint Hint]
19th November 2010, 05:25 PM   |  #6  
Senior Member
Thanks Meter: 9
 
308 posts
Join Date:Joined: Mar 2009
More
Hungarian
I did a Hungarian translation quickly. I am checking errors and all, I will upload a version without accents, unless someone tells me how to conver ביצő etc etc.
20th November 2010, 02:45 AM   |  #7  
MichelDiamond's Avatar
Retired Recognized Developer
Thanks Meter: 272
 
2,222 posts
Join Date:Joined: Jul 2009
Donate to Me
For this great Feedback Hint - Topic I can only give my Feedback: "EXCELLENT" !!!

Thanx for this work - I directly linked it to the CHTS FAQs

Keep up your great work!
Micha
1st December 2010, 02:47 PM   |  #8  
OP Recognized Developer
Flag American Fork
Thanks Meter: 229
 
753 posts
Join Date:Joined: Mar 2010
Donate to Me
More
Quote:
Originally Posted by MichelDiamond

For this great Feedback Hint - Topic I can only give my Feedback: "EXCELLENT" !!!

Thanx for this work - I directly linked it to the CHTS FAQs

Keep up your great work!
Micha

Thanks! I hope that other devs can benefit from this guide I've seen the quality of comments rise a little in XDAFB thread since I've posted and link to this. Hopefully as more people learn what we need and look for, we can improve our software faster
1st December 2010, 03:04 PM   |  #9  
orb3000's Avatar
XDA Portal Team / Senior Moderator
Flag T r a v e l i n g Likes: HTC & XDA Dislikes: apples...
Thanks Meter: 3,041
 
22,287 posts
Join Date:Joined: Feb 2007
Donate to Me
Great one!
2nd December 2010, 01:27 PM   |  #10  
meltwater's Avatar
Recognized Developer
Thanks Meter: 325
 
2,066 posts
Join Date:Joined: Jan 2009
Quote:
Originally Posted by joe_coolish

Thanks! I hope that other devs can benefit from this guide I've seen the quality of comments rise a little in XDAFB thread since I've posted and link to this. Hopefully as more people learn what we need and look for, we can improve our software faster

Nice one!

Sometimes it is easy to forget that the user does not know your software inside out like the developer does.

I would also add to: Developer Defined Messages
Check for any debugging options which the developer may have included, such as a log file.
For instance, your XDAFacebookDebug.xml file.

Also you could add to Rule1:
If the application has causing some serious problems on your device, remember the developer is the 1st person who will be able and willing to help you resolve your problem.

Post Reply Subscribe to Thread

Tags
constructive feedback, feedback to developers
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes