It's probably better to
somehow obtain their permission to send the failure report to you, vs
doing it silently and unconditionally. Asking them at the same time
if they want to provide an email address is good, though.
Just so you know... how it works now is that the exception is logged
immediately without the email address the first time an exception
occurs. The server returns the id number of the exception, and THEN the
dialog pops up and asks if they would mind supplying an email address.
The user has the choice of supplying the email address and choosing "Yes
Always send it", "Send it this time" (in which case they will be asked
again on the next exception, but their email address is kept so they
never need to enter it again, or the third option is "No, and don't ask
again" in which case they will never see the dialog again for the life
of the app.
If they answer "Yes, always" then they will never see the dialog again
either, and the email address is just included in the original post when
it's sent.
Note that it is programmed this way because there are occasions when an
exception occurs in the onCreate of your activity and the user interface
is unstable, so even if I try to pop up the dialog then, the user won't
see it. When the exception is logged, I use a couple of Preferences to
keep track of what's sent, and all info needed for the dialog box, and
when the Class is created, I check to see if an Exception occurred and
the dialog will popup then (on the next activity created) OR I also have
a function that can be called in the onResume event of each activity to
check to see if a dialog is needed. If you use that function then the
user will get the dialog box almost immediately after the exception
occurs even if they use the back button to get out of the activity that
caused the problem (the only time this doesn't work is if the exception
happens on the onCreate of the main entry activity), and I would hope
most devs have that covered already. The Exception would still be
logged, but the user would never see a dialog box because the user
interface would never be stable.
There is also a "Let me see what's sent" button and a Help/Info button
to give some information on what it is, and what it's doing.
>users are no more apt to trust it than they are to trust the
individual developers
That's a good point, and certainly true right now. I would hope if the
Exception Logger is used by enough devs though that users would see it
and learn to trust it. BUT... if the user clicks on the Help/Info button
I already have the statement that the dev has agreed NOT to spam them,
and maybe that is enough for option c) to be a good option. It's
certainly a lot less website work for me because I already have all of
that code working for myself... I'm just in the process of making it
multi-dev friendly :).
I do use option c) myself, and it works well.... I just have it in my
mind that the other options would be even more effective...but, I'm not
positive and that's why I'm asking for other opinions. The unstated part
of the question is what would other devs find most acceptable?
Sincerely,
Brad Gies
-----------------------------------------------------------------------
Bistro Bot - Bistro Blurb
http://bgies.com
http://bistroblurb.com
http://ihottonight.com
http://forcethetruth.com
-----------------------------------------------------------------------
Everything in moderation, including abstinence
Never doubt that a small group of thoughtful, committed people can
change the world. Indeed. It is the only thing that ever has - Margaret Mead
On 18/09/2010 11:00 AM, DanH wrote:
First off, you are to be commended for putting this much effort into
diagnostics. Even the big players are just catching onto this (as
witnessed by the fact that there's no facility for this built into the
phone). "Real time" diagnostics are much friendlier for the user than
saying "Please reproduce with logging turned on" or whatever, and
generally the information you obtain is more comprehensive and helpful
(since you're more apt to see several instances of essentially the
same bug, but with slightly different symptoms).
There is a slight danger that the paranoid among users will believe
that you're secretly collecting data on them. It's probably better to
somehow obtain their permission to send the failure report to you, vs
doing it silently and unconditionally. Asking them at the same time
if they want to provide an email address is good, though.
In terms of options, I'd say "KISS" -- keep it simple. Unless the
facility is going to be picked up by a "trusted authority" (say,
Google), just have email address be reported back to the developer.
Promise, of course, that the email address will be kept private (and
make any users of your facilities aware that they're making this
promise) but don't bother with the complex forwarding service -- users
are no more apt to trust it than they are to trust the individual
developers, and in fact they're probably more likely to be confused by
the options and not agree at all.
On Sep 18, 12:19 pm, Brad Gies<[email protected]> wrote:
This is a bit long winded (sorry, but I need to explain what I'm doing
before I can ask the question).
Just wondering if I could get a few (hopefully few hundred) opinions on
this :
I developed an Exception Handler for my first Android app (released the
first month the market opened), which logs all uncaught exceptions to my
server, and since then I have gradually refined it and improved. I'm now
using it in my 4th public Android app and a few private apps, and I find
it extremely helpful to find bugs that don't happen to me when I'm testing.
One thing I added that is proving to be extremely useful is an
AlertDialog when the exception occurs asking the user if it is OK to
contact him/her if I need more information to be able to fix the
problem, and a box for them to enter their email address if they agree.
I don't have good numbers for you on the acceptance rate because most of
my public apps already have the users email address and for the private
apps the company enforces their compliance (or supplies the emails for
me to use). BUT... it looks like about 20% of users do enter their email
address if asked, and that is more than enough to be very useful.
I think I can increase the percentage of users that do supply their
emails addresses, and that is what my question is about :). (I will ask
it soon)
First, It has occurred to me that my Exception Logger might be even more
successful for me if other developers were also using it because users
might have seen it before and trust it when they first see it in my
apps. That obviously would only happen if quite a few developers were
using it.
Anyway... sorry it's already getting long, and I AM trying to keep it
from becoming a book. I have repackaged my Exception Logger and will
release it in the next couple of days for other developers to use (the
price is the good one - FREE). I will host the thing on my server (FYI
it's a Cloud based server so we can increase capacity if needed) and any
developers using it will be able to log in and view the exceptions their
app has generated, and sort by time/date, user, and other fields.
NOW.. the question: I think the Exception Logger would be more
successful getting the users to agree to be contacted IF their email
addresses were kept confidential. Actually, I don't think there is much
doubt that would be the case. BUT, there is a tradeoff. Obviously, most
developers would prefer to see the email addresses so they can manage
the contacts a bit more effectively without using my website to do it,
BUT if the email addresses are not confidential, fewer users will give
them.
So here are what I think are the options:
a) keep the email addresses confidential, but developers can send the
user an email using my website, include both a reply address which goes
to my website and then forwards the email to the developer, and also the
developers email address so the user could respond directly to the
developer if they choose. I'm sure this would have by far the highest
success rate for getting contact info .... but means devs have to use my
website to send the first email at least.
b) give the user a choice of keeping the email address confidential
or just giving it to the developer. This should also have a fairly high
acceptance rate by the user, but complicates the process for them
because they would actually have to read the instructions to figure out
how it works, and quite possibly a few users would think they asked for
their email addresses to be confidential, when they actually checked the
other option, and would be upset if they found out later. It's also a
bit more work for me, for maybe very little benefit.
c) Don't bother keeping the email addresses confidential. All my own
apps work this way, and it is useful, but I'm sure either of the other
two options would have a better success rate of obtaining the email
addresses, and therefore would be better for most devs to get
information about problems in their apps.
I don't try the a) or b) options for myself because obviously I could
see the email addresses in my log files if I wanted to look, and it
would be a little deceitful to tell the user their email would be
confidential in that case, even if I did use them properly ... BUT, I
can do that for other developers without stretching the truth at all, so
I think it's worth the effort if other devs want to use it.
So, please let me know what your opinions are.
I'm also hoping to get some idea of how many developers might want to
use this. I've already done almost all the work, so it will be released
even if nobody wants to use it. It freaks me out a little to open up my
server to an unknown amount of use, but I am well setup to increase
server capacity quickly if needed, and I don't think the cost of doing
this will be too horrible (I hope). ...
Sincerely,
Brad Gies
-----------------------------------------------------------------------
Bistro Bot - Bistro
Blurbhttp://bgies.comhttp://bistroblurb.comhttp://ihottonight.comhttp://forcethetruth.com
-----------------------------------------------------------------------
Everything in moderation, including abstinence
Never doubt that a small group of thoughtful, committed people can
change the world. Indeed. It is the only thing that ever has - Margaret Mead
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en