nus-pe-bot
commented
2 years ago Team's Response
This is an intended behaviour as we wanted the error message to be detailed but we also did not want the result box to be so large that it takes up too much space in the UI.
In this case, we put the important details of the error message at the op so that the user does not have to use their mouse to view the important parts of the error message. They will only have to use their mouse to scroll down occasionally when they want to see more details of the error message. Furthermore, this is unlikely to be an issue for experienced users as the details at the top of the error message is enough to tell them what exactly is wrong with the command they had entered.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: Hi devs,
Do note that most of the error messages in fact does cause an overflow in the CommandResultsPanel. This is seen as a clear inconvenience to MOST new users as it would only be natural to expect the users to want to see the WHOLE error message rather than be happy with seeing half an error message and assume that all the relevant information has been shown in the first half of the error message. While this may be true and obvious to you, the devs, that only the first half of the error message is useful, it is not obvious to the user.
ADD:
EDIT:
DELETE:
TAG:
And the list goes on and on.
This issue is a result of poorly planning the length of your error messages and the size of the UI box. It is quite simple to redesign the UI to have better placement of the tabs, command boxes and appointments. This is not a major constraint that you are working with that is very hard to solve. Hence this is simply an oversight in the planning phase. I will insist that this is still a FeatureFlaw with Severity: Low or possibly even Severity: Medium as it will affect some users who are new to the application and need to better understand the error messages and that this is a common occurrence as users will tend to get error messages from mistyping commands often.
Besides that, from a UIUX standpoint, it is not a clean look to have the CommandResultsPanel always having to overflow.
Thank you!
A standard add command with no odd inputs will result in the error message to be sufficiently long to the extent that it will not fit a single view in the command results box. This will require the user to scroll through the error box to be able to properly read the error message.
As a result this is NOT optimized for CLI as something such as seeing the error message and finding out how to properly write the command will already require the user to scroll. Besides that it can clearly be optimized better by simply giving more room for the error box.