While developing an enterprise application I faced a problem of communicating various error/warning/notification messages to the user while they are filling out some form or performing other actions within a dialog. I have been using simple pop-up boxes whenever I needed to communicate something to user but it was not flexible or powerful enough as sometimes the messages were too long or complicated for a simple pop-up box.

Attempt to solve.

So I started to experiment with other ways to communicate the user and I settled with using read-only text areas to output all messages for the user. Here is what it looks like with some example error message in it:

.

Questions.

I am not very experienced in developing enterprise-level GUI so I would appreciate some comments on this solution. Is it a comparable replacement to pop-up boxes? What would be advantages/disadvantages of such solution? Is there any other solutions to my problem? If this text area is to be used, how and where should be placed in a dialog? What would be the recommendations on the text area's behavior?

Would you please refer to some source on why I should not? This is GTK+ UI, btw, which is the default UI for GNOME 2, which is the DE that is going to be used on the production computers.
–
SkyDanJul 2 '12 at 19:14

1

It's ugly, amateur-looking, and out-of-place. I once had an argument with Java devs about the quality of UIs. They told me that it accepts custom visual styles and it's a sign of a lazy dev & inexperienced designer when the UI is default.
–
dnbrvJul 2 '12 at 19:17

1

Ah. GNOME... In that case, you can stick to it. GNOME's UI style is notorious for its "quality". On Windows & Mac, please avoid it at all costs.
–
dnbrvJul 2 '12 at 19:18

I think it looks lovely for a simple, functional app. Often gloss and shine can be distracting in a place where you really just need something to get to the point.
–
Matt LavoieJul 2 '12 at 19:25

5 Answers
5

There's nothing inherently wrong with this technique. I do have some comments that should help make it feel more familiar to people though:

Set the textarea's background colour to the window background colour instead of white; that'll help users understand that they can't type into it as they normally can with a text area.

As stated in Gilbert Le Blanca's answer, your error message is very long. As a first step, try writing a much shorter error title and displaying it larger/bolder above the error description; that allows the description to be reduced in size, makes the errors feel more familiar and reduces the effort required to understand what went wrong (don't forget to include in your description a call to action explaining to the user how to fix the error).

You can make the field less overwhelming by collapsing it down to a single line of text (especially when it's not in error state) and then use a disclosure arrow to expand it and show more info.

Here are some ways to clarify your approach to users and avoid confusion:

Page Layout and use of textboxes

I would recommend not putting error messages in text boxes because they are inherently confusing. Some users may try to add notes or comments to the text box or may try to get past the error by removing the message itself.

The text box may lead a user to wonder if submitting the form again would submit the error message as well, which again might lead to them to #1 if they want to try and submit the page's form again.

I would visually separate the 'OK'/'Cancel' buttons from the message through color/distance, or move the message to the top of the page. Due to their proximity to the error message, some users may try to click these buttons to get rid of the error message, which wouldn't work and would therefore lead to confusion.

Clearer error messages

The message 'The payment field must be filled in correctly' clashes with 'The order is closed'. Are you asking me to correct the payment field this time around, or are you telling me not to try again at all?

If you do want to refer to the payment field being 'filled out incorrectly', my eyes immediately moved up to the form to see what I entered for 'payment'. Unfortunately the form doesn't give me any clues. So, if you want to stop the transaction from happening, move the user away from this page (don't show a form that cannot be filled out). However, if you just want them to correct their payment info, put the message's first part and their original input in the form so they can at least see which input is incorrect.

Be clearer on what you want the user to do. Should I try again? Should I leave and do something else?

Back in the days of Cobol and CICS on IBM mainframes, a text error message at the bottom of the screen was the only method we had to communicate with the user. The entire error message had to be 79 characters or less.

You can use a text area at the bottom of the form to communicate errors. I don't think it has to be quite as large as in your image. One improvement would be to have a relatively short error message with a link to a longer explanation. Users accustomed to the system would recognize the shorter error messages, while newer users can click the link if they wish.

Link? Is it an appropriate GUI element in desktop application? What would be the sample behavior? Expanding the message, when the user click on it?
–
SkyDanJul 2 '12 at 19:32

@Ganga: Link to what? I was there developing CICS applications. The link could either open up a help window, a popup screen, or a help page that explains the error in more detail.
–
Gilbert Le BlancJul 2 '12 at 19:35

You mention using a link. I was wondering about details of this solution, not a link to some source.
–
SkyDanJul 2 '12 at 19:40

@Ganga: I have no idea what programming language you're using. You simulate an HTML link in whatever manner is convenient in your programming language to a help window, a popup dialog, or a help page, whichever is the easiest to do in your programming language.
–
Gilbert Le BlancJul 2 '12 at 19:42

I loathe modal windows because of how disruptive they can be to a users flow, so I think that moving away from them is definitely a step in the right direction. However, with a little windowed app like this you don't want the window size continuously changing on the user so dynamic display of information can be tricky. Additionally, having a big text box there when you don't need it isn't very attractive. And so the dilemma.

I would personally try to place the display in a box (that could potentially have a scroll bar) right below the payment section but above the action buttons. It being right above the buttons should help with users reading it before they try to continue and it being only half the window should help save some of that wasted white space real estate.

I would also incorporate an ! icon in front of the text to bring attention to the fact that it is an error or warning.

Technically some platforms implement text labels as read-only, transparent-background text fields; the issue AFAICT is that it appears to afford text entry when it shouldn't, not that he's happening to use a text area to solve the problem. Is there something I'm missing that you're aware of?
–
Kit GroseJul 3 '12 at 4:21

1

Correct, I'm commenting on how it looks. If it looks like an editable text box, when it's not, odds are it will confuse someone.
–
DA01Jul 3 '12 at 6:08