Here are two screenshots from the Preferences panel in the beta version of Cha-Ching 2.
You may notice that the General preference pane uses custom checkboxes, and that the iCal Sync preference pane uses what looks like standard checkboxes. This is weird and annoying.
Custom UI widgets are used to fit into a specific look-and-feel. Cha-Ching certainly has its own look, but the Preferences panel is perfectly standard-looking.
If you are going to use custom UI widgets, at least be consistent. Don’t just use them in some preference panes.
However, the most serious blunder isn’t esthetic but functional. Neither the custom-looking checkboxes nor the standard-looking checkboxes respond to clicking on the label. Wow. You don’t even have to click the checkbox instead of its label on most well-made websites anymore. This is caused by every single checkbox label being in its own label widget of the class
MCEtchedTextField.
I’m no stranger to custom UI for effect. The wildest example is probably the big honkin’ tabs in ThisService –
– which I implemented in exactly the same way, technically, as radio buttons are implemented; using NSButtonCells in an NSMatrix. I did reinvent something as basic as a tab, but it was for good reason: to make absolutely sure that the ability to “pack up” a service was not lost on anyone, and to make it really easy to switch between the two modes without involving one window per mode and then a third “welcome”-style panel, which is a bit heavy and also wrong for an application that isn’t document-based. (ThisService arguably works with documents, but it just produces them. You can’t “open” a service in ThisService.) And when I did implement this, functionality that was already there and that people expect from tabs isn’t lost.
Midnight Apps are competent Cocoa developers and they do the right thing, at least initially. Cha-Ching does use standard checkboxes. (Or a custom subclass, in some parts.) They just overlay the label part with a custom label, and make that label appear above the checkbox, so any clicks land in the label, which promptly ignores it. And the label, if the class name is of any help, is used to provide an etched look, which does absolutely nothing for anyone in a Preferences panel that looks like a standard panel - the etched look just doesn’t look much different. The phrase “snatching defeat from the claws of victory” seems fitting.
I can appreciate, as much as anyone, that this is a beta version. I can appreciate that a lot of effort went into the custom look for much of the application. However, this isn’t a variation of the classic “I don’t like it when the applications look different, and they shouldn’t place effort in making things look good because they could, supposedly, have been fixing bugs during that time, which implies that they knew of droves of bugs that they chose to ignore during that time” argument, which can apparently favorably be reformulated using the words sizzle and steak.
This is the case of an application whose primary selling-point is its UI, missing out on an obvious UI guideline that’s been there since there’s been checkboxes to click on. People rely on this ability. People get understandably upset when it’s not there. And there’s something very wrong about remaking something for esthetic effect and taking away functionality, however inadvertent that might be.
For the ThisService screenshot, I cannot tell whether I am looking at the “Create Service” panel or the “Pack Up Service” panel.
(Of course, I am only seeing a screenshot, and there’s no interactivity or context.)
By Heng-Cheong Leong · 2008.07.29 14:45
Like every other selection that I can think of in Mac OS X, the selected ThisService tab is darker.
By Jesper · 2008.07.29 15:35
I agree completely with your complaints about the checkboxes. When you change the behavior of a core user interface element, it confuses and/or frustrates the user. Just like how on some web pages you can click on the checkbox label and it selects the box (using label element) and sometimes it doesn’t. With a few seconds of typing, you can improve the user experience tremendously. I can’t count how may clicks I’ve wasted in my life clicking on checkbox/radio button labels that aren’t linked to the widget.
I understand that developers are creative beings but it all should be about the user at the end of the day. Function over form.
Hopefully this post is done in time to affect the application to use standard widgets or at least ones with standard behavior. It is still in beta so there’s time to fix this.
By Dan White · 2008.07.29 17:13
But the similar background color of the ‘Pack Up Service’ and the panel makes it to look like it’s the active tab attached to the panel.
By Sebhelyesfarku · 2008.07.29 17:47
Sebhelyesfarku: Good point. The entire color scheme is stolen from Apple’s web site tabs, I found them to work well at the time and still think they do.
I think the selected tab, more than just looking darker or having the more prominent look, looks “pushed in” - I’m having a genuinely hard time imagining several tabs having the selected looks and one tab having the unselected look, which I think is a useful tool of extrapolation. Another tie-breaker could be the dimmed button in the bottom right saying “Create Service”, just like the tab.
Dan: There’s nothing that says it’ll have to be one of form or function over the other. It is perfectly possible to maintain both, which is why it scares me when, in a specific corner of the application, Cha-Ching suddenly doesn’t. Most of the creative inventions in Cha-Ching work for the user, not against it (as they might do in some “crazy Winamp-skin” style apps. Otherwise, I agree.
By Jesper · 2008.07.29 19:02
“Like every other selection that I can think of in Mac OS X, the selected ThisService tab is darker.”
In Safari’s tabbed browsing, the selected tab is lighter in color, rather than darker.
By Heng-Cheong Leong · 2008.07.30 00:06
Good catch. The rest of my arguments still stand.
By Jesper · 2008.07.30 00:40
Ironically, if you had three tabs in ThisService, there’d be no problem. I think I agree with the others that it’s potentially ambiguous, but given the contents of the view, it’s soon clear which one’s active. And a click on the “other” tab would let you know for sure. At which point it fades away and becomes an unusual but tasteful UI variation. ThisService is so small that the user can hardly get lost.
But I totally agree about the checkboxes. While they might have been able to pull off their strange alternate appearance, not being able to click on the label is damning.
Unfortunately, I was going to say “Why didn’t they just subclass NSCheckBox?”, and then I remembered it’s an NSButton. Embarassing to forget, but more importantly it makes it quite a bit harder for them to make custom check boxes that behave exactly like good Aqua ones.
By Jordy/Jediknil · 2008.07.30 18:56
I fully agree with the consistency clause: if you aim for custom widgets, make them ALL custom and consistent. What would be even worse is mimicking the default LnF but not actually using it.
As for the “ThisService” UI, the problem lies in that there are only two tabs. Yes, it is rather confusing to decide which is active and which is not. For three or more, these issues wouldn’t exist anymore. Of course, the button text aids in giving context to what tab is selected, but the distance to it is ‘considerable’ in terms of pixels. Possibly solvable with a bit more texture added for showing the ‘depth’ of the selected/pushed tab.
By inaequitas · 2008.07.30 21:01
Not being able to click on the labels for Checkboxes and Radio buttons annoys the hell out of me too.
By OwlBoy · 2008.07.31 22:56