A proposal to replace technical error messages with user-friendly alternatives and practical troubleshooting guidance. External Image
Abstract
This proposal advocates replacing technical error messages within Decentraland with more accessible descriptions and a list of possible solutions to allow users to resolve problems independently.
Motivation
Error messages with technical language (especially when entering the world) can be frustrating for visitors and may discourage them from returning again. Providing simple, non-technical error explanations and possible troubleshooting steps can improve user satisfaction and retention.
Specification
Potential error messages will be rewritten in everyday language and each message will be accompanied by a set of recommended actions that users can take to resolve the problem. In the event that, due to complexity, it is not feasible to assign a precise description to each error message, a generic reason will be shown. This message should also appear alongside tips for possible solutions, such as checking your computer’s time synchronization, ensuring VPNs are not in use, and other relevant steps.
Impacts
Anticipated impacts include reduced frustration among users when these incidents occur and possible resolution of the problem by the user.
Implementation Pathways
Implementation will involve the development team rewriting error messages and creating a list of tips or comprehensive troubleshooting guide that will be included in the same place where the error appears or alternatively in the Decentraland documentation.
Conclusion
By implementing user-friendly error messages, we can reduce user frustration and discontent, improve the overall experience, and potentially decrease the volume of support requests on the Discord server.
I put no because robust error coding is a huge endeavor. Without a list of specific error conditions and depending on how the code is written this could easily be a 1/2 million dollar project no problem. Every line of code has to be examined and every possible error without a list of specific ones. If in the end the actual problem is something in a JSON object - how can describe that in clear way. The best approach here is if you find a specific scenario such as wallet is not connected and the error produced is something like you’ve shown to handle that specific instance of error. Some times this technical error message is best to help the developers fix bug issues more quickly too.
A much better use of money would be to revamp the procedure when users report real errors. Currently the procedure is as follows. 1 - try to get rid of the user with a quick answer like reinstall the client and try again - see how dedicated they are. 2 - accuse the user of being a liar and ask them to make a video recording of the issue. 3 - if the user is annoying and still here fix the issue if it’s a quick easy fix. If the issue is complex and requires a good deal of setup to reproduce ask the user to do half your job by recreating the issue again and gathering log files which may or may not contain information that could jeapordize their security.
@OGContraBand thanks for the clarification, I see more and more that solving this will not be viable today, other friends have also made comments similar to yours.
Yeah depending how far you want to go it can be double the code-base. Like if you’re launching a rocket in the code it’s going to double the amount doing error coding. I mean you wouldn’t do it as the last step in that case but just a reference. The thing to do is make a list though. In those few cases where there error is something the user can quickly change if you have a list like that, it changes everything.
Many times I see things that are clearly wrong and I try to push it with the DAO to solve them, however it is curious how small inconveniences like this can represent such great complexity.
It really frustrates me a lot when I get a message that doesn’t solve my problem. I feel like the same thing must happen to others, but if it’s not feasible I understand.
I agree with this change, but this is not the appropriate channel for this type of request. Changes to the UI or added features are not governance proposals, and should be submitted through the proper channel. If we keep passing these proposals, we are setting a precedent for rewarding users with DAO badges for benign contributions that don’t fit the scope of that award.
I agree with you, but I’m not sure that’s what is happening in practice. This is the description on the badge: This wallet belongs to a DAO member that authored, published, and got approved by the Community at least one binding Governance Proposal in the Decentraland DAO.
