Thursday, January 19, 2012

Design: Dialogs and error messages

Following up a comment by Matthew Paul Thomas on the Design: Dialogs, long operations, and error messages post, I'm experimenting with ways to show the error message in dialogs directly, without the need of hover or keyboard focus.

The hard part is inserting an error message inside the dialog layout in a way that's not aesthetically horrible. In particular, catering to the alignment issues of both short and long messages is complicated.

For now, I'm thinking about placing the message on the top.



This looks intrusive, as it moves the entire content downwards, but keep in mind that the dialog becomes insensitive during a long operation that can fail. So the user will not be trying to click anything in the moment the error appears.

What do you think? Suggestions?

8 comments:

  1. We should be clear here that we’re talking about an error in completing the task, not in validating the data.

    I like the idea of putting the error message at the top, because that would allow consistency with error alerts. Instead of red centered text, you could use black text left-aligned next to an error icon, just as in an error alert. And if the dialog was already an alert (i.e. already had an icon and intro text), the error text and icon would replace the existing text and icon for the alert.

    (Unrelated nitpicks: “Configure proxy” should be “Configure Proxy”; the frame around the controls needn’t exist; and “Host” and “Type” should be aligned with “Use”.)

    ReplyDelete
    Replies
    1. I loved the icon idea. It also addresses the differentiation issue of your first point: for validation errors I'd use red text next to the wrong input.

      The only issue is that, if I want full consistency with alert dialogs, I'd have to use a dialog-sized icon, and those are gigantic.

      On the nitpicks: I fixed the title and will try to remove the frame (I'm afraid it will make the spinner seem misaligned). I'm not sure what to do on the alignment issue even though I personally agree. GTK does not offer any tool for aligning precisely with the label of a checkbox, and the HIG examples do not seem to support this alignment at all.

      Delete
  2. That lack of alignment in GTK is https://bugzilla.gnome.org/show_bug.cgi?id=454248 — it’s usually faked with an hbox, I think.

    ReplyDelete
    Replies
    1. Hmm... now I'm not sure if I should ignore the issue until the bug is fixed or if I should be satisfied with a non-exact identation. The HIG seems to disregard this completely.

      Delete
    2. To get exact indentation right now, subclassing GtkFrame and overriding it's size_allocate method should be enough. Oh, and setting it's label-widget to a GtkCheckButton, of course.

      Delete
    3. Hmm, I'm going to need more details Lars... How is this procedure going to give exact identation?

      Delete
    4. Hm, I really was a bit light on the details there, sorry.

      The basic idea was this:

      (1) set the label-widget of a GtkFrame to a GtkCheckButton and put all widgets that should be indented into the main child of that frame.

      (2) override gtk_widget_size_allocate for the frame in order to be able to customize its child placement. The children need to be aligned to the computed location of the label inside the GtkCheckButton (gtk_bin_get_child).

      I just tried to hack this but it doesn't work the way I expected (at least not in all cases) :-/ Mostly because the frame doesn't seem to play well with all the new margins and paddings that were introduced in gtk3. The better way is probably be subclass from GtkContainer directly, but that's a bit more work.

      Oh well, I guess my original point (that it would be fairly easy to implement) is moot now.

      Delete
    5. Thanks Lars! I think I got it from those tips, will send you a screen via Twitter soon. :)

      Delete