Consider an automated build system that stores results in a database and offers tabular display of results via dynamic html in response to http GET requests. Lots of different users want to see different subsets of the results, so there are parsing scripts in PHP each of which accepts multiple optional filtering parameters and values. For example, (I'm leaving off the http part so nobody here actually clicks this example URL):
display_results.php?componenent_name=my_comp1&build_type=build_type1&build_owner=fred
Even if the list of all possible parameters and their permitted values are listed on some help page, when the user is creating a request URL, s/he may not have that documentation at hand. Instead, depends on memorizing the valid parameters (including their spelling) and the allowed values. Sometimes s/he will get that wrong.
Question
From the point of view of end-user usability as well as developer maintainability, which of the following options is best in response to such user errors:
- Ignore invalid parameters or values
- Ignore invalid parameters, return nothing for invalid values
- Return as much valid table data as possible plus an error message (with correct usage)
- Return just an error message (with correct usage)
- Make best attempt at auto-correction
- Other (explain)
For example, if the database contains data for build_type1 and fred and joe for three components called comp1, comp2, and comp3, and user (erroneously) writes:
display_results.php?name=comp1,comp2&build_type=build_type1&build_owner=john
- Would return all results (because ignored wrong parameter name "name", invalid value "john")
- Would return nothing because no data for john
- Would return all results for build_type1 plus messages "no build_owner = john" and "maybe you meant 'component_name'"
- Would return just messages "no build_owner = john" and "maybe you meant 'component_name'"
- Would return comp1 and comp2 results for build_type1 for joe
- Other (describe)
I'm defining usability as consistency with widely-used, well-behaved web apps that are out there -- if users are happy with those they would be happy with the app I'm describing too.
I am asking this question because I am a key user of such scripts, make a good number of enhancement requests, and want to get some backing for further requests.
=== About the interface -- free-form or "builder page". Yes, I am talking about free-form. There is a "builder page" in the system but (a) it never offers all the options that all users seem to want and (b) I have not been able to push through a "create permalink" enhancement request.
=== Thanks for chosen answer -- not enough space in comment:
Thanks @pygorex1! You gave an answer that puts my question in the context of a well-known software construct -- the API. And gave a good (if perhaps exaggerated ;-) ) example of the impact of violating these principles. Finally, something had been bothering me about these scripts' APIs, and when you mentioned "self-documenting", you connected it up for me. What was bothering me was that when there's little documentation (because it's costly to keep up to date) and with partial results returned on user error (mine!), I don't learn anything about the system. "Self-documenting" is probably the most succinct justification for the error-handling design you've recommended. Easier sell to users and maintainers!