[Javascript] JavaScript error reporting (was: Object reference usage (was Javascript and FF))
tedd
tedd at sperling.com
Tue Sep 1 17:24:55 CDT 2009
At 1:21 PM -0700 9/1/09, Paul Novitski wrote:
>At 9/1/2009 06:19 AM, tedd wrote:
> >So why not leave in production alerts?
>
>I think it helps here to differentiate among at least four audiences
>for our JavaScript programs -- ourselves during development and
>deugging, ourselves after launch, our clients the website owners, and
>website visitors.
A good division of audiences, but I have a hard time dividing myself
into before and after launch. :-)
---------
>I don't think it serves good purpose to inform a website visitor of
>low-level problems. I build pages that work without JavaScript, then
>add JavaScript as an enhancement.
I realize graceful degradation, but that really isn't a part of the
"Why not show errors?" question. Alerts require javascript and if
javascript isn't there, then the user doesn't see any errors anyway
and thus my question is moot.
---------
-snip--
> It would be irritating for visitors to have to click
>on alerts, a lot of the messages would be next to meaningless, there
>would be nothing they could do about the errors directly, and they
>would be left with a negative impression of the site ("It's broken").
That depends upon how the errors are presented. As a visitor to a
site, I would rather see an explanation as to what went wrong rather
than just have something not work right without an explanation.
As for users doing something about it, I agree that most users
wouldn't normally do anything. But we still ask users to enter data
properly, right? I don't really see the difference in asking a user
to enter a date correctly (Y/M/D or M/D/Y) or telling them that
something went wrong with the date they entered -- if you see what I
mean?
This more of a human engineering problem.
---------
>Only a few of the grumpiest or geekiest would go out of their way to
>complain; I think most would simply leave, not come back, and not
>recommend the site to others.
I don't know -- do you have data to support your conclusion?
Let me ask you this, which is better on a car's dashboard, an
idiot-light or a gauge? I like gauges. It doesn't mean I can fix the
problem, but it gives me more information about what's wrong and
makes me feel better. I can speak with authority to the mechanic by
saying "This shows low oil pressure" rather than pointing to the
idiot light that reads "Engine Needs Service Soon." I hate that light.
---------
>I feel that website visitors should be
>shielded from a website's dirty laundry; it's our business to provide
>the client's content agreeably on whatever level of functionality.
Again, I don't know. However, I do think that most of the "dirty
laundry" can be sanitized for the viewing public. I also believe that
if you inform your visitors as to what's happening (i.e., site is
temporary closed for repairs) it's better than not (i.e., viewer sees
a blank page).
---------
>I think it's a fair generalization to say that the vast majority of
>website clients are not technically web savvy and I tend to lump them
>with website visitors as far as low-level error reporting is concerned.
It's also a fair generalization to say that the vast majority of
clients have problems with spelling and grammar, but I tend to inform
them when they make a mistake. So why not let me know when I make a
mistake? I have clients who inform me when they see something wrong
and the sooner the better, am I right or am I right? Nothing is worse
than the "Emperor's new clothes" syndrome.
---------
>After a website has launched and I've moved on to other projects, I'd
>rather use XMLHttpRequest to log the error in a database and/or send
>myself an email to alert myself to internal problems rather than to
>bother the visitor -- or the client, in most cases -- with runtime alerts.
That's a good idea -- namely, to have a system in place that lets you
know when something goes wrong. I would like to know how to do that
-- I'll look into it.
Because without knowing there's a problem, you can't fix it. And
without alerts (or what you suggest) you'll never know there's a
problem because no one will see the alerts and report the errors,
which is/was my point.
Plus, we haven't discussed the documentation side of this.
In php, due to security concerns I usually have one session variable
that controls all error reporting. During development it's turned on
and afterwards for production it's turned off. However, all of the
alerts are still there for future programmers to review. To me, it's
just another part of the documentation.
The only difference between php and javascript is where the script
resides and who can see it. Considering that javascript provides no
security from prying eyes, then security concerns cannot be an issue
-- not that you said otherwise.
So, the only real difference we have here is IF the users (including
the client) can see any errors generated. Of course, this is only a
theoretical discussion because we never release scripts that have
errors anyway, right? :-)
But the discussion here is to the concept of including users' and
clients' experiences as ways to improve the code rather than trying
to hide errors from them. I am not suggesting using users and clients
as beta-testers (like M$ does), but simply including them as part of
the continuing process to improve the code.
Now what do you think?
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
More information about the Javascript
mailing list