As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
My coworker and I constantly argue about button sizes. I like to have buttons that have a fixed size (ie if minimized/maximized the button sizes dont change,other controls may but not buttons), width= text in it and height=27 -30 pixels.
My co-worker prefers buttons that are only 20 pixels in height and the width is docked to vary as screen is resized. that is to say,when a screen is maximized the button elongates itself.
Personally,I don't like buttons that resize. I was wondering if anyone else want to chime in on this UI argument?
For what it's worth, according to the Vista UX Guidelines the default button size should be 14 x 50 "dialog units" (about 28px by 100px on a 96dpi monitor), with about an 11px border from the side.
Regardless of how you feel about Microsoft as a company, I think they do a good job with an uniform UI. If you are working on Windows apps then I think this guideline is a must follow.
I vote for buttons that do not get wider as the form gets wider. Personally, I think it is just ugly and makes the buttons harder to use because your eye is no longer drawn to the text in them.
Also, with 16:9 and 16:10 ratio monitors becoming popular, those buttons will be abnormally wide ;)
Please don't resize the buttons...
I think it would depend on exactly what else is going on in your app. If everything else resizes horizontally, maybe it would make sense?
The only way to know for sure is usability tests. Get real users, sit them down, have them try it out and see what they think, and whether they are confused (or annoyed). Asking a bunch of developers and designers can only get you so far.
It's not the size of the button that counts, but what you do with the button.
Resizing buttons based on the screen is fine if they stay in proportion and they still need to have a cap - this is normally done when the form is launched and not during any resizes. However, resizing the buttons when the window resizes - that's a no-no.
When thinking about button sizing that need text captions (i.e. not icon type buttons) it's always good to allow at least an extra 60% for non-english text, if you ever expect to localise the app.
I agree that some scenarios where localization of an app is needed requires you to take into consideration the button size.However that still does not call for buttons that stretch to 75% of your screen in width(height remaining the same).
Usability wise I think it is import to keep buttons in a consistent size and position.
The button should be anchored, the user should not have to hunt for it. The user should not have a "woah, why are the buttons so big now" moment. Remember "Don't make me think"
To me it sounds like one of those times when a developer wants to resize buttons because they can, and the code ts cool, not because it would make a better user experience.
Buttons that resize would annoy me.
I'm no designer, but that just doesn't sound right.
Actually, that would drive me nuts and make me very angry at you.
Resizing is bad, IMO, but do be sure to anchor buttons to the appropriate corner(s).
Buttons should not resize, for a variety of reasons. Firstly, it would be a hell of a task to style and implement resizable buttons. QAing them would be a nightmare, probably.
Secondly, much of usability is based on pattern recognition; people look for familiar concepts when they seek information. When you show a user a bunch of different button sizes, you risk confusing them; they might think some buttons are more important than others.
I am not opposed to buttons that are liquid with the amount of text inside them, though. Sometimes a button just needs to be a bit wider to accomodate text.
That being said, the text inside a button should be clear, concise, and to the point. If you are having to create buttons that are super wide to accomodate the sentence you put inside them, you need to cut-down the label to a word or two that the user can understand quickly.
If you create buttons, please make sure the text has enough space left. Because if you want to translate the text into an other language (than english) you will probably need more space.
We use a fixed size for buttons but there are some exceptions (just because our software has to be translated into several languages.),
Related
I am fairly new to Mac and iOS programming, and have recently decided to get really serious about developing applications for both platforms. The first step I took was to register to the Mac and iOS developer programs, download Xcode and study a book about Objective-C. I spent the last 6 weeks familiarizing myself with Objective-C, its syntax, concepts and the Foundation framework, and was purely developing command line applications for those purposes.
Now, the next step seems to be Cocoa and developing applications that offer graphical UIs, which I'm now looking into. Now, here's an issue I am having with this: as I am completely blind, I cannot visually see the screen. Thus, I use VoiceOver, the screen reader built into OS X and iOS. Maybe some of you devs have heard of VoiceOver at some point, as Apple has specified a variety of accessibility guidelines that concern VoiceOver. On that note, thanks a lot to all of you who abide by those guidelines, your effort is greatly appreciated!!! :-)
As for Xcode, it actually works really well with VoiceOver (VO). Adding in new UI elements is also no big deal, I can just copy them from the library and paste them into the view. However, I cannot drag them around and set them up in an appealing fashion, or at least I haven't found any way of doing it just yet as I'm just starting out!
Now, I really would like to know if there is any 'textual' way of arranging UI elements. I know the inspector has a great variety of options, but I'm not sure yet if any of them would let me, say, change the coordinates of an UI element by hand. Also, I've read about the new constraints which help create a consistent layout, but at this point I'm not really familiar with how they can be used or if they would be at all helpful in my case.
Also, I do realize that producing an interface that is 100% appealing to a sighted end user may not be possible for me, as it's hard for me to decide on color selections or to design a logo. Thus, I would probably need to hire someone for those things. However, if it would be possible for me to just specify the layout roughly, that would already help me a lot!
Thanks for any ideas / suggestions :-)
Robin
I'm not a blind user myself but I've worked with VoiceOver so hopefully some of this will help. I'm making this a community answer so feel free to add tips from your own experience if you've worked with UI layout in Xcode with VoiceOver.
When editing UI in Xcode there is an Inspector where you can change the size and position of the views. The shortcut to get to the Size Inspector is Alt+Command+5. The same shortcut works with VoiceOver.
You said that you were coding for both iOS and OS X. On iOS the y-axis starts in the top and points downward (so a higher y value means that the view is lower on the screen). This means that x and y specify the upper left corner of the view and the width and height extends to the right and down from there.
On OS X it's the opposite. The y-axis start at the bottom and a higher y value means that the view is higher on the screen. In both cases the x-axis goes from left to right. This means that x and y specifies the lower left corner and the width and height extends to the right an up.
Further, each view is positioned relative to their parent instead of absolute coordinates. This means that if you position a view at x=10 and y=30 and then position another view inside that at x=5 and y=10 it will have an absolute position on the screen that is x=15 and y=40.
If you can picture the layout in your head then you should be able to do it like this but it may still be hard to do.
Update
At the top of the hierarchy these coordinates relate to the size of the window. On iOS you have fixed sizes (320×480 for the iPhone and 1024×768 for the iPad). Depending on if the device is in landscape or portrait one of these is the width and the other is the heigh. You usually subtract 20 pixels from the height to account for the status bar. So the coordinate where y=0 would be directly below the status bar.
On OS X you can change the size of the window yourself. I will try and explain where to find it.
At the top level. Navigate to the "source code group" and interact with it. There you should find a "navigation bar group" and a "table" and a "scroll area". Interact with the table. In that table you should find a list of Placeholders and a list of Objects. One of the Objects will be the "Window". With the Window selected, all the inspectors will change properties of the Window. You can quickly jump to the Size Inspector by changing to any inspector and then back to the Size Inspector. For exaple type Alt+Command+4 and then Alt+Command+5. The first two elements in the Size Inspector should be the Width and Height of the Window.
This discussion will inevitably go off-topic, but here are my ideas:
Consider specializing in something else. There are so many things a programmer can work on. Many, if not most, programmers can enjoy long, successful careers without ever having to arrange any UI elements. Frankly, I don't think that this is particularly exciting, unless you have more of a designer mindset.
Alternatively, whatever tool you are using to arrange the elements, this layout is probably saved to some file, probably in some XML-like fashion. Find this file and edit it.
If you want to get really good at arranging UI elements, consider first hiring several people to do multiple arrangements for you. Then analyze the numbers and come up with some kind of formula that will be a good heuristic for such an arrangement. Or perhaps somebody has already come up with this kind of formula.
We are implementing a Windows 7 application that displays a pop-up in the taskbar's notification area.
There are two version of the simple form.
and the compact version:
Which one is closer to Windows's UI guidelines? Is there a good reason to prefer one over the other?
The second one looks better to me. It's hard to put my finger on the exact difference between them, but it looks like there's more horizontal padding between the borders on the first one.
That's not consistent with the standard UI or the sample pictures in Microsoft's handy UI documentation/guidebook.
For example, there's very little horizontal (or vertical) padding in these two notification area pop-ups:
The standard border padding for windows (according to Microsoft's UX guidelines) is 7 DLUs (about 12 pixels) all the way around. When in doubt, I suggest using that.
Beyond the UI/UX guidelines, it's also important to consider functionality. A pop-up window should not take up the entire screen, so using space as parsimoniously as possible is always a good idea. Since the extra padding doesn't really add anything to or make your dialog more usable, it's superfluous.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am the only dev in a very small IT shop and as such I have no one to turn to when it comes to the look of my applications. I am left to my own devices as to what looks good with what and what matches what.
This got me wondering, where do other programmers get their color ideas?
Am I the only programmer who likes all of his apps in grayscale?
What are some sites, books, apps, tips and tricks to giving your custom built application some vibrance and life that end users MIGHT actually appreciate?
I suggest Adobe's Kuler. You can bring in an image, like a logo, and have it suggest a set of 5 colors that work well together. Lots of different options. Also lets you save your palettes. You can then browse through other people's color combinations.
I too prefer my apps in greyscale, although a hint of colour doesn't hurt. For example, meta.stackoverflow.com looks kinda weird to me after spending a lot of time on stackoverflow. If you're looking for just colour ideas, I'd check out these sites for colour suggestions:
http://www.colourlovers.com/
http://kuler.adobe.com/
For typeography:
http://webtypography.net/
Maybe also pick up some good design books? (I like this one http://www.amazon.com/Designer-Grid-Lucienne-Roberts/dp/2880466784)
Contrast is one of those things that can make or break the design of a site. Some colors don't go well together. Red text on a green background, for example, may seem like it'd be a high contrast and easy to read combination, but it's not. And it's ugly. At the same time, you have to be careful with colors of the same hue as well. Light gray text is hard to read on a white background (that one is a little more obvious).
This page talks a little about contrast ratios and provides a good tool to check for it:
http://snook.ca/technical/colour_contrast/colour.html
They mention that you should shoot for a contrast ratio of 4.5:1 with small text. Any less than that and you risk the possibility of users having trouble reading your site.
There's another tip I can give. Whenever you're choosing 2 colors to go next to eachother, pick a boring color that lacks saturation (white, gray, black, or a really dull color) and then pair that up with a color packed with lots of saturation (blue, orange, red, green, etc). In general, this will look better than trying to put two exciting colors next to eachother in the same design (unless you're designing a comic book site).
And then this site has a cool gallery where you might find some inspiration and good color combinations:
http://www.cwd.dk/
But I'll tell you that my methods have changed drastically since I first started out. A little creativity is good, but I now place more importance on usability than anything. I try to keep every design I do simple and usable... kinda like Stackoverflow. I only mention that because my focus on usability tends to influence my design decisions.
A couple of my favorite sites on usability and optimization are
http://www.useit.com/ and
http://www.websiteoptimization.com/
If you are programming for some platform it is better to follow that particular platform's guidelines. (And not to alter system colors without a reason)
If you are programming for the web you might appreciate following a theme from some major web-application, such as gmail.
I have used this one in the past:
http://colorschemedesigner.com/
I would recommend turning on the tooltips (go to 'About & Help' > 'Show Tooltips') so you can see the descriptions of the different types of color schemes offered when you hover over them.
Personnally, I'm a big fan of UI Frameworks like DevExpress which implements skin technology. So, the user has the possibility to switch to his favorite look. For us, it is just five lines of code and our users are always satisfied to have this option. Vista, Office 2003, Office 2007 are just a small set of different options offered to our customers.
Give your users the most bizarre bling colour scheme
(like a combination of purple, green, glaring red, pink)
and you will be assured of a deluge of suggestions from your users.
Even though your colours are bizarre, you have to ensure that the pages are still technically usable but aesthetically unbearable. Ensure the words and widgets are visible so that lettering should use darker colours like crimson, blue or dark grey on light coloured backgrounds. Pastel the background so that they won't impede the user's sight.
If you wish to defend the reputation for your taste of colours, place a "Contact web master" link which leads to a disclaimer saying your colour scheme is deliberate because you are forcing users to design and submit and vote on a colour scheme. Why not write a cheap lil' web app to facilitate the voting too?
Ask your users. Just that. Just ask them, and take their advice. They're the ones who'll have to be staring at the color scheme for hours or days on end; take their advice.
Update: I'm not suggesting that you give your users the complete range of options; the way this usually works is with a small group of users, generate a few styles of the site that seem reasonable, and ask the small group to pick the one they like the best. That way, there's a coherent look to things, but you still get user input from your end users.
I take you have some users. I suggest asking them what they would like in colors.
Aside from that, to deliver data effectively you have to keep visual clutter to a minimum. Gray is a time-tested agent for helping with that.
I see from your comment that gray is despised. Well, you could spell it "grey" -- British-isms are are classic chic. Seriously, you need to go for three pastels in this situation.
I would say stick to what you're comfortable with and make them grayscale but just add hints and accents of colour.
Adobe Kuler is a good tool for which colours to use.
Stick with greyscale, and use colours only when they can have some meaning. E.g., use bright red for negative dollar amounts, blue for email addresses, bold black text on a yellow background for phone numbers, etc. This sort of thing really helps users find their way around your app, especially when there is alot of information.
Have a look at AVIVADirectory.com
"The Canonical List of Online Color Resources for Designers
(updated periodically with neat stuff)"
Just a massive list of links and resources about pretty colours.
And lets just agree to disagree on the 'u' in colour, ok ; )
Also, a +1 for colorschemedesigner.com mentioned earlier by John Rasch
I asked some friends on the Internet who pretty much represent the userbase for my apps. The general consensus is that certain shades of blue and cyan are nice. Not entirely unlike the default in MSN Messenger 8.5. I then used that to colorize what started as grayscale.
That's where I get my ideas.
I'm involved in writing a touchscreen application for a medical device. The program is kiosk-like, in that the start menu, etc, will not be accessible to the user, and the user will use an onscreen keyboard to type any text in the rare event that they need to. The spec'd screen size is 1280x1024.
The question is this: What's the minimum touchable button size for a reasonable interface? I'm thinking that an American dime is a reasonable minimum size in all directions, with the reasoning being that a dime is about as small as we can expect people to feel with their fingers (it's got a diameter of 17.91 mm, according to the almighty Wikipedia).
Or is a dime a bit on the large size?
EDIT: Some extra knowledge about our users. They have to have both hands, because of the nature of the device, and they will not be wearing gloves. They would have to be able to manipulate film cassettes of up to 14x17 inches in size (again, due to the nature of the device), so I feel reasonably confident that they have some manual dexterity.
There's a lot of factors that go into this that can require the buttons to be a lot larger.
Based on my experience, I would use something no smaller than a US Quarter--a dime is really too small for repeated use. If users will wear gloves or other things to "fatten" the finger, you will need even larger buttons. If you have users who are disabled or have poor motor control (more common than you would expect), a dime sized button is absolutely useless. Keep in mind that some touch screens are not particuarly accurate. I've worked with some that were up to 25 pixels off near the edges.
Also, how often are they pushing the buttons and how many buttons will be on the screen? Having to hit many small touch screen buttons in sequence will drive users crazy. That's among the reasons you'll notice that many touch screen systems such as ATM's are starting to have buttons that are in excess of 1 inch x 2 inch.
Also, how fault tolerant is the system if they accidently push the wrong button? Mabye because the screen was off or they were viewing from an angle? The less fault-tolerant it is, the bigger your buttons need to be. Mistakes happen. Smaller buttons means more mistakes.
That's going to depend a lot on the device itself as well as the UI that you're putting on it.
Many touchscreens (excluding multitouch) average the area touched, so chances are you don't want to put UI items any closer than fingertip area to cut down on mis-touches.
Touch screens need to be calibrated post installation, and even then there might be some parallax depending on the screen type or the natural angle from which the screen is being viewed.
You might also consider visual feedback on touch down and only let the event through on touch release. When you get a touch, display an x larger than a fingertip centered on the point of contact and let it track until the touch is released. That point is the click point.
Above all, user test, user test, user test.
If you're really worried about size - make it fluid so you can change it easily and test it on real users under real circumstances. Did I mention user testing?
Depends on so many factors...
All touchscreens degrade over time, and give less accurate, more noisy, and less linear results over time. Resistive touchscreens have vastly improved over time, but you'll still have issues, especially with such a large touchscreen.
Further, people have different sized fingers, and different levels of hand/eye coordination.
Lastly, the hardware and software that actually processes the touches before it even gets into your application needs to be calibrated and characterized.
So it's really much more difficult than merely asking how big the buttons need to be.
First, I'd talk to the manufacturer of the touchscreen itself, and the manufacturer of the hardware/software interface and find out their recommendations.
Second, I'd do some tests - make a few targets onscreen, and then record all the points that the touchscreen hardware sends you when you press them. Do a bunch of tests for quick jabbing presses, hard long presses, light presses, etc. See how much the input jumps around (you might be surprised...) and how fast it actually responds (heavy filtering might make the presses come late, which could reduce usability without speedy feedback).
Thirdly, I'd design the user interface for GREAT user feedback. Make the buttons wider than the finger so that when the user presses it, they still see a little of the button, and it appears to depress when the press it.
Fourthly, I'd consider adding adaptive learning. You'll have to have calibration run and rerun occasionally, but in-between you can adjust to the user slightly to decrease the likelihood of errors. It's not for the faint-hearted, though, and is easy to do wrong so take care if you want to consider it.
-Adam
I would agree somewhat with James that a US Quarter is a better target, but often you can change that so it is about a US Quarter in one dimension, and a US Dime in the other. Of course, you want to keep the center of active UI elements separated from each other by at least the distance of a US Dime, depending on how "solvable" clicking on the wrong element is. (Clicking on the wrong element in a list is easily solvable if all that is being done is selecting it; clicking on the exit button of a dialog isn't so much.)
Be sure to make your most common cases really easy to do. This usually means making a really big button; or, sometimes, making a whole UI area "clickable" (but if you do that, it's often nicer to the user to also see some sort of button in the area to imply they can click on it.)
Depending on the quality of the touchscreen, you can often "cheat" around the edges. Not only are the edges and corners easiest to hit on a traditional mouse-based interface, but they can be for touchscreen-based interfaces as well, since the user can press their finger right up against the framing element and not worry about triggering something else. Make sure your UI elements accept clicks all the way to the edge of the screen if they are near the edge, as well. Using this, you could have a US dime-sized button in each corner that would still be very repeatably clickable (although possibly lacking feedback if your users have large fingers).
Bigger is better, as we know size matters.
It is important for users of touchscreen interface to get feedback when click somewhere on screen and because this cannot be mechanical as on normal keyboard or mouse button we use sound and/or changing color.
Playing sound only when control is clicked instead of each touch anywhere in screen to achieves good usability.
If working environment is noisy you must give color feedback too, and in this case button should be twice or triple bigger than finger. It is important that user can see feedback when his hand is on screen, and you know that hands are not from glass.
Ordering on screen is important too. For mouse driven interface using of drop downs combobxes, menus and etc is good, but for touch screen you will kill usability with them. So instead of placing controls in upper left part of screen put them in bottom right side. This will give your users free of hands information area on screen when they works.
Think about left/right hand layout, and day/night color scheme too.
Currently i am working to create set of .net UI components for touch screen and you can take a look for demos soon on my web site.
Atanas
I m, on a daily basis creating web pages. My preferred development screen resolution is: 1600x1200 but what is yours?
And do you use any other plug-ins?
I use window re sizer 1.0 for Firefox. But are there better options?
In my opinion, if you're using a window resizer, you're already on top of the game. I try to aim for pages that work well on a 1024x768 screen, accounting for scrollbars and toolbars and whatnot. It may be worth resizing your screen to 1024x768 (or whatever the minimum is that you support) every once in a while just to fully understand that user experience, but in general the window resizer keeps you aware enough.
I disagree - fixed size layouts are just fine. In fact, Stackoverflow.com uses a fixed size layout, as do a great many professional sites out there. The reason? Predictability.
A few things:
Never have horizontal scroll bars
Try to avoid vertical scroll bars when it's reasonable to do so
Remember, AJAX and other newer technologies can help you save space on your page with popups and other niceties.
My 2 cents,
-Doug
It shouldn't matter - design your web pages to be flexible and fluid such that they degrade gracefully on any reasonable screen resolution. Cater for mobile devices with very minimal screen space and massive displays.
I develop with a 2x1440x900 setup, but I leave Firefox as a window at 1024x768 using Web Developer Toolbar.
The dual monitor setup is really useful when you have the code on one screen and Firefox on the other.
I wouldn't go over 800x600. However, ideally your layout is not fixed to a screen size, and can resize and still look right.
I stick with 1024x768. It's usually big enough for what you need to display, and not everyone is quite to 1600x1200 yet. Maybe in a few years. I'd stick with a smaller display...that way it may force you to be more design conscience.
Two screens are invaluable regardless of screen size. One screen to run your editor, and one screen to run your browser. It's amazing how much smoother development becomes.
With my stats showing 1024x768 as my users' dominant resolution, I certainly wouldn't go below that. Beyond that, I agree with, apparently, everyone else here that fixed size layouts are just a bad idea, and your design should adapt to render context.
For the love of Pete don't use pixel sized fonts. Use em or pt sizing instead.
It all really depends on what kind of page you are designing. I would try to design with the ability for the page to scale in mind. There is nothing I hate more than having to zoom in a page that was designed for 800x600 on a 1920x1200 display.
I think the best advice given here is just to try it at different resolutions instead of your native one, and try to make it look good at a variety of sizes.