I'm making a timeline with relatively small bars representing events over time. Right now they are roughly 8px by 200px (the length is variable, but all are 8px high).
Is there a standard reference for what size is standard or minimum for what types of interaction? For example I just want a mouse-over on these bars to highlight them and provide a tooltip, where I imagine if I expected a user to click on these bars, a bit bigger might be more realistic.
Anyone have any insights on this?
It'd probably be pretty hard to find guidelines specific to what you want to do.
There are several things you could do. Wikipedia has a nice article on usability
My main advice would be to think about what your users need, and what they are capable of using/learning. What you could do is make a few different versions where you change a parameter (such as the height of the bars) and get different people to test each one.
Personally, I would be happy to use bars that were 8px high. I would not be so happy to do this if I was using a touch screen.
You should think though, is it really necessary to fit that much information on one screen? How many bars do you think would be appropriate on average to be able to fit in the vertical space of the screen? Perhaps you could have two modes - large and small, where large fits 30 rows, and small can fit many more.
But it's not really something you should be too concerned about at this stage. Just make sure that it is easy to change it later on, and you won't have to worry about it now. User testing should sort out the problems - as long as you listen to there needs (or watch them, see the mistakes they make, and try to fix the most common ones).
One thing to remember, is the "rule of 7", which basically means people are more comfortable looking at less information, as too much information can overload the brain (but it really depends on the target audience, for instance, an historian may rather see as many concurrent events at once).
Related
In Interface Builder I have a bunch of text fields that sit vertically. I want them evenly distributed in the vertical space, and all to be identically sized.
I've found the Alignment menu that lets you line up items. I can't find a menu for distribution or sizing. Does Xcode 4 include those layout commands?
The answer is, NO. And I HATE having to be "one of those people" that has to tell you so. I assume what you are looking for is something similar to OmniGraffle's quintessential feature, "Canvas, Grid, Alignment". It is THE TOOL that makes OG so damned good.
It amazes / disgusts me that a company worth $100 billion is unable to get this basic tenet of visual layout right, when a company writing software for that same idiotic company's own platform for years, has had this down for as long as I can remember. The Xcode team needs to pull it together. For example, KVO Bindings are, and have always been a joke - a not so funny one - that are impossible to implement, plug-ins are gone… And IMHO, Lion auto-layout is Unusable. They need some NEW PEOPLE or something, maybe that aren't developers, or something.. Cause Xcode is getting harder to use, not easier. It looks better, and is better organized… but its obvious that there is no "big thinker" inside that group that is willing to question their fragile and awkward paradigms.
Are they kidding with this? How about this Xcode? _Shut up, line up the buttons, distribute then evenly - like 99% of people are going to want, 99% of the time - and dont puke meaningless lines all over everything?__ And what the hell is Content Hugging Priority and Content Compression Resistance Priority? I read the docs twice and still have NO IDEA what those are or how to use them. I'm no Einstein, but If I can't "get it" after making a concerted effort… It's too hard. lol. Ok, I need to go mark futile rant off my to-do list, now.
Hope this helps: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/AutoLayoutbyExample/AutoLayoutbyExample.html
The concept is to use some spacer views and set them to be all the same size. There are some tricks with the priorities to be done so please follow the link for a definite answer.
The boring answer is to type in the coordinates manually. Not very smooth, but it gives you exact control over the placement at least (in the Size inspector).
At this point, everyone knows that there's a limit to the number of ShellIconOverlayIdentifiers (from MSDN):
The number of different icon overlay handlers that the system can support is limited by the amount of space available for icon overlays in the system image list. There are currently fifteen slots allotted for icon overlays, some of which are reserved by the system. For this reason, icon overlay handlers should be implemented only if there are no satisfactory alternatives
I can understand the 15 overlay limt in Windows 95. But in an environment where there's Gigs of RAM, numerous Cores, and GPUs, is there some technical reason for such a low number in a modern operating system?
And why isn't this value configurable?
Before giving the 'performance' answer, consider:
Windows allows for configuration such that you can kill performance... why pick on this issue specifically?
Unless someone here happens to work on the Windows Shell team, I doubt that you're going to get an answer that really addresses the technical limitations and how they affect the design choice. But I'll try...
My guess is that there isn't any technical limitation, or at least there isn't one now. The real reason is presumably that no one has ever taken the time to sit down and update the code, the design, and the spec to lift this limitation. Features aren't implemented by default, and just because the computing environment has changed in the last few years doesn't mean that someone sat down and rewrote Windows to take full advantage of all those changes.
You should also consider that is more than likely a conscious design choice, rather than an imposed limitation. Raymond Chen (who actually does work on the shell team) published a blog entry responding to the uproar about Windows 7 removing the "sharing hand" overlay. He makes a compelling argument that the icon overlay is really not a desirable way of showing information (above and beyond the fact that the system is limited to 15) [emphasis added]:
Generally speaking, overlays are not a
good way of presenting information
because there can be only one overlay
per icon, and there is a limit of 15
overlays per ImageList. If there are
two or more overlays which apply to an
item, then one will win and the others
will lose, at which point the value of
the overlay as a way of determining
what properties apply to an item
diminishes since the only way to be
sure that a property is missing is
when you see no overlay at all. (If
you see some other overlay, you can't
tell whether it's because your
property is missing or because that
other overlay is showing instead of
yours.)
It seems reasonable to me that the extra clutter added to the shell is simply not worth it in the majority of real-world cases. The Windows Shell team obviously reached the same conclusion and cut the "sharing hand" overlay. Raymond's direct explanation:
Given the changes in how people use
computers, sharing information is
becoming more and more of the default
state. When you set up a HomeGroup,
pretty much everything is going to be
shared. To remove the visual clutter,
the information was moved to the
Details pane.
And, I know you specifically asked not to mention performance, but Windows really does try to keep you from shooting yourself in the foot. Users demand responsiveness in the shell, and overlay icons can interfere with this. As further evidence that they are not the priority, another blog post by the same Raymond Chen chastises:
Another example of applications having
a selfish view of performance came
from a company developing an icon
overlay handler. The shell treats
overlay computation as a low-priority
item, since it is more important to
get icons on the screen so the user
can start doing whatever it is they
wanted to be doing. The decorations
can come later. This company wanted to
know if there was a way they could
improve their performance and get
their overlay onto the screen even
before the icon shows up,
demonstrating a phenomenally selfish
interpretation of "performance".
Excellent response on the practical issues by Cody. As to why 15 and not some other number, the limit is baked into the ImageList control itself.
This is all very well and good, as explained by Cody Gray, but frankly it is pretty unimaginative, and as reported behind the scenes, sounding a bit frustrated.
In 2015 and with Windows 10, surely there can and needs to be a better ability, as I noted about thirty overlays present and had to prioritize ones I wanted most to see, which is not what you want most people to worry about at all. Also I see aggressive vendors like Box over-competing to try to prioritize themselves, and that will never go any place good.
Here's a possibility: What if multiply overlaid icons had a generic overlay indicator; a small rectangle matrix of multiple colors like the Google Chrome Apps button? Singly overlaid would just show the overlay out of a long list.
Then when the mouse pointer meets the icon, a small flyout window collects all the icon variations to view (at small icon size or a little larger). Each overlaid icon in turn announces by tooltip what it is, when you mouse over.
Now you can have all the icon overlays you need, for state in various clouds, for repository indications as for Tortoise tools, and so forth.
I quote an extract of the definitive answer here from Why is there a limit of 15 shell icon overlays? Raymond Chen 2019 post
The value 15 came from the corresponding limit for image lists. The
ImageList_SetOverlayImage function supports up to 15 image list
overlays per image list. (Hey, it used to be worse. The limit used to
be only 3!)
Okay, but why only 15? Why not more?
The overlay image is one of the pieces of information used when
drawing an image from an image list. The options are encoded in the
fStyle parameter, and when the bits were divided up for various
purposes, four bits were available to be used to specify the overlay
image. (You get 15 overlay images instead of 16 because you lose one
of the values in order to specify “no overlay.”)
Okay, but the values in the fStyle parameter use only the bottom 16
bits. What about the upper 16 bits? There’s plenty of room there.
The 16-bit limit was carried over from the 16-bit version of the
common controls (which still needed to be supported in Windows 95). Of
course, nowadays, nobody cares about the 16-bit version of the common
controls, so why not start using the upper bits?
There’s an unsatisfying explanation: The code internally that manages
the fStyle still uses a WORD in some places, so all the code that
manages the fStyle would have to be revised. This occurs in multiple
modules across Windows, so a synchronized change would have to be made
across multiple components. This is a breaking change at the binary
level because the interfaces are no longer compatible. Breaking
changes are procedurally difficult to coordinate: The affected code
may not be visible to the shell team because they are sitting in a
far-away leaf branch that has not yet RI’d to the trunk. It might be
that expanding fStyle from a WORD to a DWORD has far-reaching
consequences for some component.
Like I said, this is unsatisfying. Basically it boils down to “It
would be a lot of work and we are lazy.”
A requirment has been given that the desktop icon change colors "to fit well" with the users chosen desktop color. Not only is that a vague requirement but it is not the standard way that applications behave. The correct solution is to provide a number of icons which the users can select from. I just think its a bad idea. We are in the requirments phase still and I feel like I am becoming antagonistic. Standard practices exist for a reason but I am about to lose my cool because fully 15% of the 300 requirements fall into this category.
defer the argument by putting this on a "nice to have" list (that will never get implemented because it adds nothing to the functionality and creates disproportionate configuration problems) and concentrating on the real features that actually do important things
suggest a transparent icon so that it blends exactly with the desktop colors (see if they realize that it would be invisible!)
give a very long list of why this feature is ridiculous, create enemies, make the customer/manager feel stupid...not really recommended
bear in mind that you may be dealing with people that mean well but don't know much technically. Say "that's an interesting idea" to validate their feeling/input/existence, and go on to more important things. ;-)
Have you ever heard about an accepted paradigm about how to design those kind of systems?
Im not talking about iphones but photo-kiosk or manufacturing systems
Rulas,
i have worked on a number of touchscreen apps. i never found a published set of standards like the ones you mention but here is a little bit of what i learned:
Create a limited "visual vocabulary" with the following rules:
Buttons should be 30 or more pixels high (and at least as wide) - simply increasing the width of a button will not make it easier to click
Try to place controls on similar points on the screen - exactly the same if feasible, so that users do not have to hunt in different parts of the screen for the same operation.
Avoid the need for scrolling - try tabs, paging, wizards etc. Using scrollbars on a touchscreen is very difficult
Consider how the screen will be used. Where will users put their hands? Will they rest their hands on the corners of the screen? Will the Power button be in the way?
As part of this rule set, create your own controls library that can be easily reused in other parts of the app
Try to omit or minimize typing on a "soft" keyboard. Make as many fields selectable as possible.
Have big buttons for "fat fingered" users.
Usability really matters.
Keep the touch screen well calibrated. This used to be a nightmare back in 1999; don't know how much better it is now.
Say for instance I'm going to do some seat of my pants coding adding a feature to an enterprise app. What are some good examples/tenants/cardinal rules a person can follow for making a fairly complex setup/config screen not look like feet.
What I'm looking for is along the lines of "Don't put one thing in a group box". But I'd also like some help with symmetry if anyone knows what layouts are most likely to achieve a relative amount of good looks that would be helpful.
Here's a cardinal rule you asked for: line up the controls vertically /horizontally and equally space the various related elements. And use correct spelling on your labels!
We've all come across screens where there are misaligned controls (even a couple pixels is noticeable) or misspelling on labels. When this happens to me I can't help but subconsciously look for other mistakes, plus it decreases my confidence in the application I'm using!
This is actually a huge topic. I frequently go to the Microsoft UX Guide for reminders on how to do this.
Some basics:
Make your app read like a book: left
to right, top to bottom
Use goal-oriented language instead of
technology oriented language
Not a cardinal rule but a great resource:
Apple UI Guidelines (good info for any OS)
EDIT: Re: achieving symmetry - things don't have to be perfectly symmetrical, but you want a feel of balance. Take a step back and get a sense of whether the page or form feels like it's leaning/falling to the left or right.
E.g., with stackoverflow, the main content is to the left, but it's nicely balanced by the extra stuff on the right.
I find that paper is my friend. I like to write out a list of objectives the form has to accomplish, and then sketch the form by hand, labeling the parts. Drawing it out lets me get away from making sure it looks perfect and that everything is aligned just right, and lets me focus on making sure that all the components I need are placed, hopefully somewhere logically. It also forces me to lay out the UI twice, so by the time I open my UI designer, I've already designed the form once and you hopefully know what I am doing
Some basic rules for you.
Try to make effective use of whitespace. Don't cram everything together in an effort to get as much stuff on screen as possible. This will make grouped controls more clear and text more legible.
Basic typography. Limit your use of fonts to 1 or 2. Don't use bold too much or it loses its emphasis.
The same goes for colours. Don't use too many, the fewer the better most of the time.
Don't just use icons to save space. Tiny icons with no explanation are useless.
Copy. Not wholesale of course, but if you are not well-versed in UI design yourself, it makes sense to take elements of interfaces you know work and apply them in your own designs.
Be clear about the purpose of the interface. How does it fit within the broader application for example? And what are the specific objectives you are trying to satisfy with it?
Get people to test it for you, early and often. I don't know what setup you are working with, or what kind of organisation you are in, but getting some kind of human feedback on your work will always be helpful, even if you lack the time and expertise to conduct proper usability evaluations.
Since you use the term, "seat of your pants," I'm assuming that you don't want to spend too much time on the UI. If you are willing to devote some time to the UI, you may want to look into custom control or UI development that will suit your situation. Like Firefox's Options UI or the .NET project properties in Visual Studio 2008.
If you are looking for something using standard controls, it is probably best to separate out different sections of related items into tabs or some other type of stacking control (i.e. Ribbon control). A good example of the tabbed version would be the Notepad++ Preferences UI. Many other programs use a similar scheme.
The best way to get a UI that makes sense is to follow Joel's advice:
Eat your own dog food.
Do it a few times to your own UI, and you'll notice some things you didnt think of intially.
I've found that a really good test is getting someone non-technical to use your GUI. Watching someone use it for 5-10mins normally gives me a very good idea about what is/isn't easier to understand.
This series by Joel Spolsky is a pretty good read and Jakob Nielsen's stuff Usability and Web Design is pretty useful.
Specific rules I try and use are:
Put items in logical groups
Line everything up
Use sensible images/icons
Spend 5-10 mins thinking through why things are the way there are
Only use words that make sense to the user not to you!
Start from the setup/config UI of an existing application that you feel is both simple and usable.
Most tenants/cardinal rules apply to UI in general and fill hundreds and hundreds of pages in UI design and HCI books, so you probably want to just work your way by example for now, while trying to capitalize on existing user experience (habits), i.e. obeying the rule of "least surprise": e.g. if your application is a Windows application, use the Installation Wizard pattern, if it's an ncurses app for a particular flavor of *nix follow the style of that particular OS's actual installation UI, etc.
You might be interested in the book "Don't Make Me Think," (author's web site) or "About Face 3.0". Both come highly recommended for reading about how to design interfaces.