Ryuno-Ki
assigned
I'm a software engineer from Stuttgart, Germany.
I can't help you here, but it's a fascinating point of view.
I will ask some colleagues to gauge their opinion.
As usual, no reply. We call that Community of Practice here …
I wonder if anyone has analysed this topic from an intersectional feminist point of view, as "technical [details] should seen not heard" feels similar to what may [have been] said of women or servants...
I can't help you here, but it's a fascinating point of view.
I will ask some colleagues to gauge their opinion.
We've indeed seen and discussed that article 😊 It has some good suggestions though seems mostly focused on errrors related to user input (like in forms, which is something we could/should quite easily improve in Bonfire).
I'd also like feedback on how we could improve messages related to unexpected or general errors, such as due to or untested edge case. For example:
- You seem to have provided an incorrect data type (eg. an invalid ID)
- You seem to be referencing an invalid object ID, or trying to insert duplicated data
- The data provided caused an unexpected error and could do not be inserted or updated
- The data provided seems invalid and could not be inserted or updated
- Invalid arguments passed
- The function
post/2in modulePostsdidn't receive data in a format it can recognise - A function didn't receive data in a format it could recognise
- A
withcondition didn't receive data in a format it could recognise - A
casecondition didn't receive data in a format it could recognise - A condition didn't receive data that matched a format it could recognise
- Could not complete this action
- Could not complete this request
- The app encountered an unexpected error
- An exceptional error caused the operation to stop
- An exceptional error was thrown
- An exceptional error occurred
- Something went wrong
- Oops, this resulted in something unexpected
- You need to log in first
- Not found
- You do not have permission to [...]
- We couldn't find an account with the details you provided
- This site is by invitation only
- This link or token has expired, please request a fresh one
- This link or token was already used, please request a fresh one if necessary
- This token was not found, please request a fresh one
- This user account is disabled. Please contact the instance administrator
- Please confirm your email address first
- Reset your password to login
- User not found
- Could not delete
- Bad request: malformed header
- Unknown resource
You'll notice many of these are similar, but because they for different reasons wording them differently helps us identify the problem when reported.
Ah, that's great!
Hm, when I would be tasked with wording them, I would imagine, how it would be situated in meatspace.
Like, you couldn't suffessfully submit something. I imagine a waiter getting back to you, apologising and informing you, that you order couldn't be fulfilled (something was missing - what exactly? your dish is out etc). Basically, avoid jargon, help the audience to understand what they can do to recover from an issue.
Forms are the basic kind of interaction between someone entering information and the service responding to it. That's why you will most likely see error messages in this context.
It's a matter of opinion, but "technical errors should be logged, but not shown to people" seems to be a practice coming from software as a product/service, I wonder if that applies as much to "software as a tool"?
Yes, my background is in „software as a product/service”. As such, I develop mostly for non-technical audience.
Since the testers here might reflect the audience you intend to reach, why not starting a poll with different variants of an error message and see, what resonates the best?
Discovered @dajbelshaw on bonfire 👋 - all good now!
