[seek-dev] What to do with Seek provider exceptions?

[Laura L. Downey]

On a related note, I identified that we need to have better error messages
to our users and filed a bug on that.  And we talked about giving graduated
messages such that the initial message to the user is no programmer centric
but that if the user wants more details or technical information, they could
get that also but requesting "details" of the error, e.g., another button in
the dialog or something similar.

The issue here is finding the time to write user-friendly error messages.  I
do have some guidelines I use for formulating error messages.  Matt is there
a specific place I should post those?

Laura L. Downey
Senior Usability Engineer
LTER Network Office
Department of Biology, MSC03 2020
1 University of New Mexico
Albuquerque, NM  87131-0001
505.277.3157 phone
505.277-2541 fax
ldowney at lternet.edu
 

-----Original Message-----
From: seek-dev-bounces at ecoinformatics.org
[mailto:seek-dev-bounces at ecoinformatics.org] On Behalf Of Matt Jones
Sent: Friday, September 30, 2005 1:31 PM
To: Kevin Ruland
Cc: seek-dev at ecoinformatics.org
Subject: Re: [seek-dev] What to do with Seek provider exceptions?

Probably the only messages the user should see are 1) things they can do 
something about, and 2) things that might affect the quality of their 
search.  If they think the searched a data source but an error prevented 
that from happening, they should be notified.  The number of potential 
system errors is probably much greater than the number of appropriate 
user messages.

Matt

Kevin Ruland wrote:
> Hi all,
> 
> This question has probably been rehashed a number of times but I don't
> really know where to look for the answer.  I
> Is there any well defined category of exceptions which are to be
> returned by the query service?  It seems right now, that almost every
> problem in the digir server will end up returning a simple empty result
> set.  This in most circumstances will not properly indicate a problem to
> the user.
> 
> What problems should come back as faults and which ones should be hidden?
> 
> Kevin
> _______________________________________________
> Seek-dev mailing list
> Seek-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-dev
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matt Jones
jones at nceas.ucsb.edu                         Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara     http://www.nceas.ucsb.edu/ecoinformatics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
Seek-dev mailing list
Seek-dev at ecoinformatics.org
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-dev