ScreenRuler Interface Design Question

Which of these options do you prefer?

Option A

screenruler-0881

Glade file for this version.

Option B

screenruler-090

Glade file for this version.

Comments are open.  Glade files are provided in case you want to make a new mockup.

38 Responses to ScreenRuler Interface Design Question

  1. Adam Tulinius says:

    I prefer #2, because it seems simpler, and less thinking to figure out.

  2. cosimoc says:

    The first one looks better to me, it seems to be more polished (thus less confusing).

  3. Tony says:

    I’d go for none of the above, with a slightly modified version of A where the current resolution is prefilled in the grayed out entry widget. I’d retitle the section to incorporate the checkbox:

    [X] Customize Screen Resolution
    Horizontal Pixels per Inch [ 96 ]
    Vertical Pixels per Inch [ 96 ]

  4. Option A is clean and beauty. I think it is more HIG compliant than option B.

  5. Pedro Leite says:

    Check boxes often mean that one or more choices can be made. Although the Option A looks better to me, Option B is more coherent, since radio buttons give the idea of exclusivity.

  6. Another option is to drop the checkbos of option A and set by default the current DPI that can be changed by the user. Then add a button “set defaults” that set all defaults to all options (colors, background and DPI).

  7. I #2 assuming you gray out the custom settings area with the spinners if the user chooses the System Settings.

    I think #2 makes it clearer for the user that he have ONE of the TWO options.

    IMO check buttons are for “turning on/off”, “included/not included” stuff, plus, if #1 had the button unchecked and the spinners sensitive, the user could be thinking before experimenting it that by checking the Detect Automatically he/she was “including” this option and not choosing between it and the spinners.

    Hope I helped!

  8. Benjamin Goodger says:

    Option A, absolutely… Merry Chrismas!

  9. Peng says:

    #1, definitely, although with radio buttons that clearly show the choice. #2 looks cramped and crowded to me.

    Mewwy Chwismukhk!

  10. Patrys says:

    I think the most importantquestion is: which is simpler and requires less reading? That’s the #1 reason we don’t label dialog buttons “yes” and “no”. Also – option 1 uses intents as label which is good while option 2 uses IT gibberish as labels which is bad (and they end in the same word which makes it worse).

  11. ethana2 says:

    A
    Communicates the same thing, and it’s simpler.
    Simpler = better.

  12. foo says:

    Option B looks far more sane.

  13. Vaibhav says:

    Option A.
    Make the user think less. When the user sees “Detect Automatically”, the user knows that I don’t need to think about it and the software will care of it, and only in rare cases would he/she require to make the decision.
    Option B makes the user think, what is System Settings? what is Custom Settings? In this case there is more thinking required before making decision.
    So I vote for A.

  14. Natan Yellin says:

    I vote for A.

    Both “Screen Resolution” and “Screen Pixels per Inch” are too technical for regular users to understand. The first one, however, has the benefit of being shorter and should already be somewhat familiar to most users.

    As Vaibhav said, “Detect Automatically” is also a much better choice than “System Settings.”

  15. Rasmus Kaj says:

    Does setting the resolution here actually set the value “back” into X11 itself? Will another application get your configured value?

    If so, I think A is the nicer one.

    If not, I seriously think the option to set a custom value is a bad thing: just tell the user what the resolution is set to, and possibly say something about how to modify the X11 value.

  16. Wouter says:

    #1 looks much better and understandable.

  17. Since “pixels per inch” is advanced option compared to color selection, I would use progressive dialog and use an expander entitled “Customise pixels per inch” that only contains Horizontal / Vertical pixel per inch labels and spin buttons, beside to a “Read from system” button.

  18. Two comments:

    1) Not everybody uses inches. I think it would be nice if you switched to cm if the locale tells you so.

    2) If the autodetection didn’t work I wouldn’t know how to answer the question, “how pixels are there per inch on my screen”. Do I have to bring out a ruler, and then count the number of pixels? Wouldn’t it be better to reverse the question to be, “what is the physical width/height of your screen area?” ? At least that’s something I would know how to answer.

    Cheers,
    Søren

  19. JustAGuy says:

    I prefer the first option. I do like the idea of the modifications people have added – ask for size instead of pixels – I’ve been using Linux for 8 years, and I’m not sure how I’d find the pixels.
    When I had to change this parameter (about a year ago), I just played with the numbers until I was happy with how things looked. Maybe that’s what supposed to happen.

  20. erich says:

    C) Get the color and font settings from the other Gnome wide preferences. Also, use the automatic DPI detection. It works. Lose the whole dialog, it doesn’t produce any extra value.

  21. Gianni says:

    I was going to say A, but.. reading comments, I think none of the two propositions are right.

    Maybe you could add a “Detect” button, which will put the size at the default (96×96) when clicked.

    No checkbox, no radio.

  22. whyohwhyohwhyoh says:

    i’d like to see B set to the same width as A – it might feel just as ‘clean’ with the same amount of horizontal space between the elements. … i guess i could do that myself with those glade files.

    at the moment i prefer A.

    i’d prefer to set the screen dpi by having a drag-to-stretch graphical ruler on-screen which i can match up to a real life ruler to calibrate things. … yes, like in windows xp. so flame me.

    agree it should be possible to apply these dpi settings to the whole system, or be redirected to an existing system dpi settings dialog instead of having the controls here at all. but that will affect all the screen fonts too.

    by the way, for those who are wondering, it’s xdpyinfo. 😉

  23. R :: B says:

    “Both “Screen Resolution” and “Screen Pixels per Inch” are too technical for regular users to understand. ”

    Ahem! Oh dear me…the app is a screen ruler!

    Option A provides more white (duck-egg blue?) space and is easier on the eye. It is also perfectly succinct. Anyone who needs to tweak the setting will know how to uncheck the checkbox. It wins.

    The words “Custom Settings” to your average half-wit generally translate as “1337 p01ntZ” and invite all kinds of unqualified meddling…

    There’s a reason radio buttons aren’t even used on radios these days…they take up too much space, they’re clunky and untidy and the aforementioned half-wits can’t resist messing with them.

  24. Ramon says:

    Agreed with R :: B and many others above me: A for sure.

    Simplicity is more compliant to Gnome standards i think. Also from a user perspective i personally agree less options are always better. Most information needed can usually be detected or “reasonable/educatedly guessed”.

    If you’d hide the options from the view i think it would be perfect.

  25. For a screen ruler, I prefer option 2.

    For the GNOME text preferences choice where this is set globally, I prefer option 1. (Not that you asked or anything.)

  26. Speaking of pixels, the Close button is 2px off compared to the other elements. 🙂
    – The Nitpick Brigade

  27. Nicolas Mailhot says:

    Hi,

    My advice would be to never expose PPP/DPI tuneables. Inches are not a valid unit in many countries in the world, and even in countries where they are non-technical users will never guess they need to divide screen pixel dimensions by screen physical dimensions to get this value.

    You have reliable ways to detect screen pixel dimensions. The usual problem is physical dimensions. Thus please expose physical dimensions tuneables in the locale unit instead of DPI/PPP tuneables. You can do the divide in your app, and anyone knows how to provide a physical dimension (and will understand he’s cheating when providing fake values).

    If you really want to you can show the result of the DPI/PPP computation but I’d advise against it. This will only confuse people and make them cheat to reach magic values (long after those magic values are irrelevant)

  28. Thiago says:

    First one. Simpler and clear.

  29. Stephen says:

    I feel that B is more semantically correct. However, A looks less messy. I could see a few cases where the user might need to change the resolution value momentarily. So it is important to have it there. I agree with other comments that the width from A would make B less messy looking.

  30. Stephen says:

    Any chance for a package in the Ubuntu 8.04 repos? (I posted a question to the Launchpad site)

  31. thet says:

    i don’t really have a clear opinion on these choices.

    BUT:
    i want you do know that screenruler rocks! i just figured out that it’s available now in ubuntu repository. i use it since 0.6 or so. screenruler is really very handy.
    thank you for this piece of software.

  32. Allan says:

    cool pics

Leave a reply to Benjamin Goodger Cancel reply