Design: rethinking the style preferences

Back in the Acessibility: Contrast, colors, and fonts post, I explained how the color/style preferences changed depending on "contrast mode" being on or off:

Following a suggestion by Matthew Paul Thomas, I now merged the two versions into a single one, using a GtkComboBox.

This new version allows both modes to share all possible options. It also reduces interface complexity by eliminating the need for checkboxes in non-contrast mode.

I'm still wondering whether I will make a list of suggested colors available. I have no idea what they would be. :)

Design: To Label or Not To Label?

So, after Lars pointed me to the right direction, I think I managed to perfectly align widgets with checkbox labels. The next blog post will give the full details, but before that I have a small design question... Is it just me or the group labels are now visually redundant?

Compare

with

What do you think? Should I eliminate the labels or keep them for consistency with other windows?

By the way, I am aware that the entire authentication group should technically be inside the general group, but I couldn't figure out how to do this without making the layout look very unbalanced. Specially now that I'm aligning the widgets with the checkbox labels. Suggestions are welcome.

Design: Dialogs and error messages (2)

Following feedback from our favorite crazily-smiling designer and that great orange psychopath artist (I'm assuming the avatar is a self-portrait), here's the current state of the proxy dialog.

The italics were a personal touch.

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?

Acessibility: Contrast, colors, and fonts

As part of the goals for the current rewritings and refactorings of Polly, I'm trying to neglect accessibility a little less than I did until now. Because GTK offers great a11y support by default, this basically means taking some extra care when I edit widgets on my own instead of relying on the theme. One such care involves playing well with high-contrast themes.

Instead of a one-size-fits-all design, that would inevitably lead to some lowest common denominator aesthetic choices, the next versions of Polly will allow a --contrast command-line parameter that causes some subtle changes in the interface.

One of those changes involves the color of the error bar. In normal mode, it simply has our good old universal error color, red.

In contrast mode, the red is replaced by a color taken directly from the theme, ensuring readability while still drawing attention. Below you can see what how contrast mode looks when using the HighContrast and HighContrastInverse themes.

The other change I have implemented involves a new feature: I am going to introduce optional background color coding for unread items and mentions.

In contrast mode, where the choices of color are much more limited, I offer an alternative: marking unread items with bold and marking mentions with italic. This wasn't a very hard choice, since bold is a very common way of showing unread items in mail clients.

So when contrast mode is enabled, this is how the preferences window looks like.

What do you think? I'm not an accessibility expert, so I would love some feedback.

Design: Dialogs, long operations, and error messages

Polly has a lot of operations that can take a long time to complete or can go wrong, so it's important to fit throbbers and messages somewhere in the interface. Since some of those operations happen in dialogs, I wanted a consistent way of handling those cases.

After some experiments, I settled for using the lower-left corner. The images below show the three states a dialog can have. Whenever a potentially long operation starts, a spinner is shown. If everything goes well, the spinner simply disappears and the window returns to normal. Otherwise, a stock error icon is shown.

The icon tooltip contains the error message, as seen below. For accessibility, the icon is also keyboard-focusable so the mouse is not needed to pop the tooltip.

The only thing I didn't like about my original implementation of this approach was that, for error -> throbber -> error transitions, sometimes the operation was so fast that the throbber wasn't shown at all, leaving the impression that nothing happened. See the video below.

So I added a small delay of 100ms before making the error icon appear. This delay is not large enough to annoy the user into thinking the operation is taking longer than necessary, but it's large enough to keep the visual changes below the flicker fusion threshold in practice.

What do you think? Suggestions?