Inert Detritus The Internet's dust bunnies

(Re-)Designing a Preferences Window

(Edit: My apolo­gies: com­ments were closed ear­li­er; they closed auto­mat­i­cal­ly after 2 weeks. They’re open now.)

CPU His­to­ry 1.0 was an obvi­ous work in progress. It shipped with­out mul­ti­core sup­port, with a redraw­ing bug, and with a hor­rid pref­er­ence win­dow design. The first two bugs were fixed months ago, when I pushed a beta of 1.1 to a few mul­ti­core testers. How­ev­er, the third bug was­n’t on my radar until Peter Hosey (@boredzo) brought the Apple Human Inter­face Guide­lines (HIG) to my attention.

With­out fur­ther ado, here’s the 1.0 pref­er­ence window.

The list of things wrong with this lay­out is longer than the list of things right. Incon­sis­tent spac­ing, and no attempt at ver­ti­cal align­ment of labels or controls.

When I added fea­tures (name­ly, mul­ti­core graph­ing) to 1.1, I had to add anoth­er con­trol to the pref­er­ences. Hence, the 1.1 b1 pref­er­ence window.

This is the release that com­pelled Peter to link me the HIG write­up on lay­ing out win­dows. And right­ful­ly so.

After an hour spent mas­sag­ing things in Inter­face Builder, here’s the first 1.1 redesign. (I’ll call this 1.1 b2)

I fixed ver­ti­cal spac­ing between ele­ments, hor­i­zon­tal align­ment of labels and con­trols, and a few oth­er tweaks. It was pri­mar­i­ly a HIG-com­pat­i­ble spac­ing fix to the 1.1 b1 layout.

Still, the lay­out just felt wrong. I vis­it­ed #macdev on IRC to con­sult some oth­er devel­op­ers, and two sug­ges­tions sur­faced. First, a tab-based lay­out (from cia­ren and ccgus), and a boxed lay­out (a com­bi­na­tion of my think­ing and ccgus’s view idea). I set out to imple­ment the tab-based lay­out first.

That’s tabs one, two and three. I split things based on log­i­cal sep­a­ra­tion: gen­er­al, floater pref­er­ences, and col­or choic­es. How­ev­er, as is evi­dent on tab three, I could­n’t find a good lay­out in that tab that used the space required by tab one. Onward, then, I ven­tured, to fix anoth­er lay­out shortcoming.

The sep­a­ra­tions from the tabs made log­i­cal sense, so I want­ed to keep those while junk­ing the extra white­space of the tab lay­out. So next up was a box-sep­a­rat­ed (NSBox) layout.

This is the cur­rent leader in the win­dow design, and most like­ly what I’ll be ship­ping tomor­row. It had the right mix between an all-in-one win­dow, which removed white­space issues with tabs, and clear splits between con­trols of dif­fer­ent types.

I think that pref­er­ences win­dows can be some of the most chal­leng­ing inter­faces to design, espe­cial­ly when one has a small num­ber of pref­er­ences. I know that the pref­er­ences win­dow in my app will def. be get­ting some atten­tion in the next release and it was great see­ing some­one go through the process.

Uli Kus­ter­er recent­ly wrote a bit bout spac­ing in inter­faces, you might find it useful:

http://www.zathras.de/angelweb/blog-spacing-boxes-and-other-layout-things.htm

Chris,

I think you were on the right track with the sec­ond to last one. Take a look at the pref­er­ences for Safari. See how it resizes for each tab. Well guess what! So does trans­mis­sion, which is an open source bit tor­rent client for mac.

http://www.transmissionbt.com/

The “every 1.0 sec” label seems out of place. How about inte­grat­ing that update fre­quen­cy idea into the labels of the slid­er itself? The oth­ers move from “small” to “large”, so that slid­er could be labelled with its lim­its in a sim­i­lar way and get to ful­ly align at last.

A few cri­tiques on the last one: 1. The word “floater” has neg­a­tive con­no­ta­tions. :-) 2. “.0” is redun­dant if you want to say “1 sec­ond”, and “sec.” should prob­a­bly be spelled as “sec­ond” instead. Yes, I know it’s a pain in the ass and it requires a plur­al form every now and then, but who said soft­ware devel­op­ment should be easy?

In addi­tion to the rhythm ruin­ing wrap­ping of “every 1.0 sec”, the fact that all the slid­er labels are all low­er­case is not help­ing matters.

A very nice job on the redesign — it flows neat­ly and is well organized.

I have one sug­ges­tion: Instead of Refresh Rate with a scale from “no label” to “every 1.0 sec.”, how about call­ing it Refresh Inter­val and label the left­most point “10 sec­onds” (or what­ev­er the max inter­val is) and the right­most point 1 sec­ond (or 1.0 if you have that kind of gran­u­lar­i­ty in the set­ting). Some­times refresh inter­vals are lin­ear which makes it easy to infer the actu­al set­ting from a graph­ic slid­er and some­times they are some­thing else (expo­nen­tial or qua­drat­ic for exam­ple). I’m not sure which these are but it may affect how you would best label the setting.

Do you real­ly need pref­er­ences for all of these? I’d pre­fer that you choose taste­ful val­ues (bar width, graph divider) and remove the preferences.

John Muir is right. Also Refresh Rate is the only slid­er where the min­i­mum val­ue isn’t labeled. I know that push­ing Graph Divider all the way to the left will make the graph divider van­ish, just by look­ing at the screen­shot above. But when I do this with Refresh Rate … will it stop updat­ing at all? Or just go real­ly slowly?

As far as the log­i­cal group­ings are con­cerned, I’m very pleased with your end result. Now the infor­ma­tion comes in chunks of unin­tim­i­dat­ing size and they’re even ordered by impor­tance. But to me it seems just the grouped lay­out and the lit­tle cap­tions alone would achieve that nice­ly; I’d sug­gest you try out los­ing the actu­al box­es them­selves, maybe they’re just visu­al clut­ter with lit­tle function?

…it seems just the grouped lay­out and the lit­tle cap­tions alone would achieve that nice­ly; I’d sug­gest you try out los­ing the actu­al box­es them­selves, maybe they’re just visu­al clut­ter with lit­tle function?

I’ve been con­sid­er­ing that, actu­al­ly; that’ll give me more con­trol over the size of the cap­tion text, as well, which I feel is too small at the moment.

I appre­ci­ate every­one’s feed­back, and I’ll write a fol­low-up post regard­ing com­ments and pos­si­ble changes in a cou­ple of days.

An inter­est­ing arti­cle, but I’d point out that it is a good idea to avoid the word “Col­or” in win­dows where pos­si­ble, since you only upset peo­ple if you don’t inter­na­tion­alise it (i.e. it should be “Colour” every­where oth­er than North Amer­i­ca). Or you need to localise it for British/Australian/New Zealand users, say, which most devel­op­ers don’t do.

I note that Apple took it out of the con­text menus in the find­er for Leop­ard — now it is titled “Label:” instead.

Speak­ing of pref­er­ences, is any­one else tired of appli­ca­tion crash­es that can be cured by throw­ing away the pref­er­ences file ?

So my sug­ges­tion is, as long as you’re look­ing at pref­er­ences, how can you val­i­date the pref­er­ences before rely­ing on them ? What hap­pens if you can’t get a han­dle to the prefs ? Or if you can’t write to it. Or if it’s sit­ting on a bad sec­tor ? Could the user pos­si­bly have last opened the file on Jan­u­ary 1, 1970 ? Is a text col­or of [255, 255, 257} ok ? Should any set­ting have a val­ue any­where near $MAXINT ‑1 ?

This goes for the rest of you too.

You might con­sid­er get­ting rid of all the labels under the slid­ers to reduce clut­ter, or replac­ing them with icons (e.g. the Find­er’s View Options). Also, Cap­i­tal­iz­ing Every Word looks weird: if you don’t, it helps users to read labels like sentences.

When I redid the AntiR­SI pref dia­log, which has a bunch of the same con­trols, I had to deal with some of the same decisions.

before: http://tech.inhelsinki.nl/antirsi/antirsi_screen.png

after: http://www.flickr.com/photos/njr/1077793458/in/photostream/

I end­ed up remov­ing the group box­es, but look­ing at it again after near­ly a year, the spac­ing seems a bit off (though it is HIG-com­pli­ant). It seems there needs to be more of a break below the sliders—perhaps a hor­i­zon­tal line would do it.

Kudos for tak­ing the time to improve your UI even for a pref­er­ence win­dow. These atten­tion to details are what make Mac pro­gram­mers bet­ter than those oth­er guys :)

@Jamie Cur­mi — If peo­ple get upset because they don’t like the spelling of col­or i’d say they have some anger man­age­ment issues.

There is one big advan­tage to the tabbed pref­er­ences, it allows you to grow your pref­er­ences with­out mas­sive­ly increas­ing the size of the win­dow. In order to get round the issue of not being able to fill the tabs, make the tab view tab­less and put the sec­tions in a tool­bar, then resize the win­dow height when you click on anoth­er tab. This is used quite fre­quent­ly (eg Safar­i’s pref­er­ences). At the moment the boxed design works but if you plan to increase the size of your pref­er­ences at all in the future, you may need to redesign again.

Regard­ing too much white­space in the tabbed design: I had the exact same prob­lem in one app; and I end­ed up gen­er­al­iz­ing the code I use for resiz­ing NSTool­bar-con­troled pref­er­ence win­dows to also work on occa­sions where the NSTab­View’s tabs were vis­i­ble and con­trol­ing what got displayed.

So it’s still an auto­mat­ic process, and it works just fine. If you want to see this in action, send me an e‑mail — it does­n’t feel right to hijack this com­ments thread by adver­tis­ing my apps. I’d be hap­py to share that code with you.

Nice re-design!

One oth­er option could be a resiz­able tab view (like the pref­er­ences pan­el of Mail).

If I were you, I’d remove at least the abil­i­ty to change colours. It’s a very visu­al part of the pane and why would any­one need to ever change colours?

@Jared Earle—customizing the col­ors I have to con­stant­ly look at is very impor­tant to me in whether I want to use an appli­ca­tion or not. That shade of red would be gone in a heart­beat, before I even got through the tri­al peri­od. Uh, so would the green. And prob­a­bly the blue. In the cur­rent set­up, it’s easy enough for peo­ple to ignore the entire sec­tion, so it’s not real­ly clut­ter­ing anything.

But now I’m think­ing maybe you were jok­ing as a riff on the oth­er comments.

@CB—I’m no devel­op­er, but these type of “before, dur­ing, and after” posts are very interesting.

I’d like to sec­ond what Peter Mau­r­er and Mar­tin Pilk­ing­ton said. And I’d like to add that most Cocoa Apps by Apple itself (Safari and Mail i.e.) don’t have but­tons like “OK” or “Apply” rul­ing over pref­er­ence win­dows — which you did right. Very Hap­py about this. But the “Revert to defaults” But­ton kind of dis­turbs the oth­er­wise clean design. If the func­tion­al­i­ty real­ly is need­ed, I’d put it into the Gen­er­al-Tab or pro­vide indi­vid­ual But­tons to reset the reset wor­thy set­tings. Labels would be an obvi­ous choice i.e.

Greet­ings

Tweet! Five yard penal­ty! Overuse of NSBoxs!

Actu­al­ly, I think your design is still way off the mark. You were clos­er with the tabbed lay­out, and there are sim­ple ways to resize the win­dow to acco­mo­date dif­fer­ent sized sec­tions. You also ignored the de fac­to pref­er­ence design stan­dard of using an icon shelf to select dif­fer­ent sections.

The final design is tru­ly awful; oth­er peo­ple have point­ed out the twist­ed lan­guage (what the hell is a “floater”?) and incon­sis­tent slid­er feed­back (“every 1 sec”). 

If you’re going to stuff all the pref­er­ences in one pane, your ini­tial views were a bet­ter approach, with some tweak­ing to the word­ing and align­ment. The real prob­lem with a sin­gle pane is that it already is pret­ty busy, and that will like­ly only get worse as time goes on and you find oth­er pref­er­ence options to add.

The tabbed lay­out was much clean­er than the final one.

Floater should be “Win­dow”. A floater is a dead body that’s been in the water.

The refresh rate slid­er is entire­ly wrong. The dura­tions should be marked on the slid­er; see the dura­tion slid­ers in the Screen Saver pref­er­ence pane.

Here’s my quick feed­back… prob­a­bly not all that valu­able, since I don’t know your product.

My rec­om­men­da­tion is to open it up a bit with some extra space. Use space as your friend, instead of cram­ming things togeth­er. Ana­lyze the space between every sin­gle con­trol to make sure it’s con­sis­tent. Increase the width of the dia­log so there is some breath­ing room around the controls.

I would remove the box­es on all three areas, and put divider lines between them instead (if you’re not going to move them into sep­a­rate tab panes with the new tab bar on top). Slide the check­box­es to be aligned with the left side of all the slid­ers. Does the first check­box con­trol the sec­ond one and the graph size slid­er? if so, those need to indent­ed. Lose all the extra caps on words and make them read more like a sen­tence. e.g. “Size in dock:” and “Show sep­a­rate graph”. Also test to see how it looks with the labels on the right side of the col­or pick­ers. ([pick­er] Label) Not sure why the refresh rate slid­er dif­fers from the oth­ers in style. I don’t know how the refresh rate works. It might be bet­ter as “Refresh every [field] sec­onds” instead of a slid­er, depend­ing on how it works. I don’t think you need labels on the oth­er slid­ers, if you can see the effect they have as you are slid­ing them. Should “graph divider” be “Divider width”? And should Bar width be in pix­els like the oth­er? Should “graph size” be chanced to just “Size”? And should the size labels on the slid­er be “16x16” or “16px”? Last­ly, I won­der if the but­ton on the bot­tom could be locat­ed on the left, so it’s not in the default loca­tion of a but­ton in a dialog/sheet. Oh, and maybe “Restore Defaults” would be a bet­ter label for the button.

I am also a fan of adding some small descrip­tive text under con­trols that are not imme­di­ate­ly under­stood by their label, to help explain what they do.

Oh, sor­ry, also, you might want to use the reg­u­lar size slid­er con­trols, instead of the small. With extra space added in and around them, they won’t look as huge as they would jammed togeth­er. They should match the size of the labels.

Good luck!

==

Con­sid­er using desat­u­rat­ed (pas­tel) col­ors by default: http://flowingdata.com/2008/04/29/why-should-engineers-and-scientists-care-about-color-and-design (see Tufte’s “Visu­al Expla­na­tions” p 76 or “Envi­sion­ing Infor­ma­tion” p 91: http://openlearn.open.ac.uk/mod/resource/view.php?id=179550 ) Pro­fes­sion­al maps use mut­ed pas­tel col­ors for areas of large cov­er­age, and so should we.

There are three fun­da­men­tal dimen­sions of col­or, and they are not Redness/Blueness/Greenness. Humans find mean­ing in tran­si­tions along Hue (red-green-blue), sat­u­ra­tion (bright-pas­tel-gray) and val­ue (white — earthy — black), and it’s best to con­strain each data dimen­sion thought­ful­ly to a col­or dimension.

This is a beau­ti­ful tool: http://www.colourlovers.com/copaso/ColorPaletteSoftware The three bars on the top far right con­trol Hue, Sat­u­ra­tion and Val­ue respec­tive­ly — mess around with them and see how the col­ors change. I made a sam­ple palette: http://www.colourlovers.com/palette/451571/CPUHistoryFoo?c=1 My rea­son­ing * “Idle time” is emp­ty — it should be trans­par­ent, or the back­ground col­or. * “nice” time is “back­ground, innocu­ous, calm” — it should be a very desat­u­rat­ed sky blue. * “User time” is what you care about. It’s assumed­ly spent doing what you want it do do, so go with green. It should be promi­nent but not pushy, so make it semi-sat­u­rat­ed * “Sys­tem time” is usu­al­ly a prob­lem — you bought your machine to run pro­grams, not ker­nel. So it’s red, and it’s a bit loud­er. * We want to see the com­pe­ti­tion between user time and sys­tem time, so start with two well-sep­a­rat­ed col­ors. So that’s hue and sat­u­ra­tion: two axes, con­vey­ing two vari­ables (hue=segment, sat=urgency). As for val­ue: if this thing sits in front of you it should be audi­ble but not deaf­en­ing. Let’s give each col­or the same val­ue (bright­ness), and let’s set it to 70%, which is the fore­ground col­or of a safari win­dow (90%, the back­ground col­or, seemed intense).

This won’t be your actu­al palette, but if you start think­ing of the col­ors in per­cep­tu­al rather than RGB terms your pro­gram will be pret­ti­er and more mean­ing­ful. Some­one with a bet­ter eye than mine could cer­tain­ly fix the bal­ance of hues… 

So all that blath­er and we still have red/green/blue: my point is that you should choose three taste­ful shades that bear mean­ing and chuck the col­or con­trols. A future ver­sion could inten­si­fy each seg­men­t’s col­or sat­u­ra­tion as its sys­tem bur­den climbs.…

==

• I don’t find “Size in dock” or “Bar Width” that inter­est­ing. A prin­ci­ple of infor­ma­tion design is to “Max­i­mize your data ink”. The graph can fill its full dock slot, so it should; and the bar gaps car­ry no infor­ma­tion (the bot­tom of each water­fall shows its axis) so they should be omit­ted alto­geth­er. Now, a con­trol to occu­py two or three dock slots would be inter­est­ing, but I bet there’s bet­ter uses of your time than crawl­ing through the under­bel­ly of the API.

For resiz­ing in gen­er­al, how­ev­er, the best inter­faces are direct inter­faces: http://physicalinterface.com/view/a‑seat-control-that You can toss out that whole dia­log box if you put a dash­board-style (i)nformation-please but­ton in the cor­ner to expose adjust­ment handles.

The dock actu­al­ly does both: the pref­er­ence pan­el gives you a slid­er which resizes the dock in-flight, while the lit­tle ribbed sec­tion between file and app gives you an expert fea­ture — it resizes the dock with imme­di­ate feedback.

For direct manip­u­la­tion of the time: the faster you sam­ple the more space one sec­ond occu­pies on the screen: at 30 chunks and 0.5 S/s the graph is 60 sec­onds wide, and at 30 chunks and 0.5 S/s sam­pling the graph is 15 sec­onds wide. So, show a ‘scale bar’ that is 10s long, with han­dles to resize it, and report on the sam­pling rate: 0.5 S/s |—-| 2 S/s |—————-| Some­thing like that… The intu­tive vari­ables are, I think, “How much time does this graph show” and “How often does it move over a slot”: so, not “Bar Width” but “Graph Duration”. 

This adjust­ment should be dis­crete: snap to exact rates so I can map graph to a num­ber. 0.1, 0.5, 1s, 2s, 5s, 10s…, with graph dura­tion rang­ing from “one minute” through “ten min­utes” to “1 hour” or something.

If you’re show­ing a refresh rate (my vote) then report a rate: “2 S/s” or “2 Sam­ples per sec­ond” — if you’re show­ing “sam­ple dura­tion” then report a peri­od: “every 0.5 sec­onds” (right now you say rate but show period.)

==

• You should redraw the graph when its scale (refresh rate) changes.

• An exper­i­ment: draw sys­tem time down from the top, user time up from the bot­tom, and nice time atop that. (“Enforce Com­par­isons” — Tufte.) As the graph is cur­rent­ly set up you can’t direct­ly com­pare user time. Dun­no if this will be more or less clear.

• I have a quad-core machine, and I hear there are folks out ther with octo-cores — I don’t think the stacked graphs stay mean­ing­ful at that point.

What do we real­ly want to know? I’d like to know 1) The over­all sys­tem load; 2) user time vs sys­tem time with­in over­all load 3) the vari­ance across CPUs (a 25% load: one 100% process and 3 idle cores, or 4 25% process­es?) 4) how much of the over­all load is com­ing from the pig­gi­est process (judg­ing pig­gi­ness based on “frac­tion of the total inte­grat­ed non-idle time shown on the graph” — basi­cal­ly, how much of the ink is each lit­tle pig­gie’s fault?)

I don’t real­ly know how to do #4, but we do have a cou­ple ways to do 1–3 and max­i­mize data ink. Draw ONE water­fall graph, and seg­ment each User, Sys­tem, Nice bar into (#cores) seg­ments (so, four seg­ments for my quad­core). Then exper­i­ment: you can draw each core with alter­nat­ing shades (remem­ber, we still have the ‘val­ue’ dimen­sion on the shelf), or you could put a 1px bar sep­a­rat­ing each seg­ment. You could even just alter­nate (user-system-nice#1)/(user-system-nice#2)/(user-system-nice#3)/(user-system-nice#4) — the dif­fer­ent col­ors mark the cores — but I bet that looks soupy in the end.

I hope you don’t mind this ridicu­lous­ly nit­picky post — I only went into this detail because I think what you’re doing is neat.

just a small detail: the offi­cial abbre­vi­a­tion for sec­ond is sim­ply “s”. “sec(s)” hurts my eyes.

I’m writ­ing a response post (with new GUI mock­ups) tomor­row morn­ing at the iPhone 3G launch; hope­ful­ly I’ll have it up short­ly before the doors open at 8 AM.

Thanks again for all the com­ments and sug­ges­tions: it’s always use­ful to have new pairs of eyes take a look at a design.