There is not really a "UX" reason for this—or if there is, it is a very limited one. The actual reason why dialog backgrounds are (by default) some shade of grey is because some designers thought that looked better.
In many early operating systems, dialog and window backgrounds were stark white. Obviously they were white on the original Mac OS, since it had ...
Software development IDEs have some of the most complicated settings pages I've ever seen, and IntelliJ IDEA does a great job with discoverability. Not only do they offer a search to narrow down the left "tree" to matching pages, they also have a special highlighting effect for matching options. This is similar to your Chrome example, but even better since ...
When a user is about to take an action that may not be easily reversible, it is imperative that the interface give them enough information to:
Make the correct decision on what they want to do.
Make it very clear how to make that happen.
In Windows 7 the "Copy File" dialog gives you plenty of information to help you compare the two files using meta data ...
While Charles's Answer shows some great UIs, I wanted to add the UX that Directory Opus uses for the same action, which I find very good as well. Simple on the surface with advanced options tucked away after a click.
Clicking on the Dropdowns results in these options:
As you can see it also provides shortcuts for the advanced operations making it easy ...
An interesting question, and one that I think many of us might have pondered before without really diving too deep into the possible issues. From a purely design perspective, I can think of a number of plausible reasons:
Convention: the first person did it this way, and then everybody else followed because "that's how it's done".
Safety first: separating a ...
Too much white can cause eye strain, so tints of grey reduce this.
There is another ux.se topic which discusses white vs grey backgrounds:
Grey versus white background for ease of use and readability/legibility
If we ask UX-guru Jakob Nielsen it's 10 seconds. Longer waiting times could get the user to leave the program/page and do other stuff in the meantime. Supposing that something has gone wrong also depends on the users anticipation on how long a certain task could possibly take and the kind of task itself.
Original (1993): http://www.nngroup.com/articles/...
I'm the author of WinSCP and I've found this "question" really inspiring. Thanks. This is my (kind of) "answer".
Improvements I've done (see also the screenshot below):
Inspired by the @Vijay's answer (and Directory Opus), I have merged similar buttons into one with a drop down menu. So now there are only 4 buttons, Yes (with Newer Only and Yes to All in ...
They are distinct:
OK: Applies the changes and closes the dialog (or goes back to the previous location / one level up)
Apply: Applies the changes so the user can see / work with the results, but keeps the dialog open, ready for further modifications
Cancel: closes the dialog without applying any changes.
The "Close button" in the window title usually acts ...
The idea behind this bar can be traced back to Gestalt's law of similarity which states:
Elements within an assortment of objects are perceptually grouped together if they are similar to each other.
This is why you shall see two columns in (a) and two rows in (b). The latter also demonstrates that colour wins over shape (in this specific example at least)...
Root Cause: Implementation Driving UI
The whole idea of a single consolidated Options dialog seems to be a consequence of programs having configuration files. The Options function would read the configuration file, present it to the user in a dialog for editing, then save the changes back the configuration file. Perhaps some other programs do the same thing,...
Both Find and Find and Replace are related functionally as you mention. But both actions seem to be orthogonal in terms of what user need (mindset) they cater to. You will know in advance either you want to find something or you rather want to substitute occurrences of something. In the latter case it just happens that you need to find occurrences of the ...
That is one of the best examples of an interface designed by engineers for engineers :)
I would suggest the following improvements:
Some of the options should be moved to an advanced section, which is selectable for people that know that they want advanced features.
Related options could be grouped together to make it easier to scan.
The buttons should not ...
Because the difference between the font-color and the background-color can cause eye strain and is not optimal.
Having black or dark-grey text on a lighter grey background is the easiest for the human eye to read. See this link for a more detailed answer.
It tells you when to use brighter fonts with a dark background, and also when not to do this. ...
To personalize email or not?
Well, there is a lot of controversy around this question. Here is some list of studies:
Heerwegh et al. 2006
Studies (Heerwegh et al. 2006, Experian study, 2013 ) on the topic suggest that personalizing an email results in higher response rates ( around 5-10% ). There are ...
Users are often more interested to know How do I go about to achieve this goal that I have, rather than investigating the purpose for random actions and CTA's that they currently see in the application.
The reason it was removed was simply that it was found more efficient and helpful to focus on finding "good" solutions for letting a user search the answer ...
If you expect it to take a lot of time, instead of just a spinning circle you could add progress indicator. Progress indicators are almost perfect from the users perspective, they have just one weak side - they should reflect the TIME spent on waiting, and not DATA PROCESSED, but from programming point of view there are too many dependencies to say that a ...
If you can expect your users to be power text editor users, for example programmers, then it makes sense to combine these dialogs into one, or, even better, make it a toolbar and show real-time results as you type. This is an expected feature for development tools nowadays, as it speeds up the editing process greatly. IDEs (integrated development ...
We got a page like that in a server admin interface. You can unfortunately not download a demo of it (as it is the server admin interface) but it looks kind of like this:
download bmml source – Wireframes created with Balsamiq Mockups
One of those bars each for every day of the week. And then a set of presets like "Always", "Never", "Working hours", ...
Personally, I feel like the second one would be better. The user does not have to expand the list first in order to see all the options thus saving one extra click. For the type of the meal, I'd suggest using radiobuttons. It depends on how many options your users have there though. If there are only two or three, I'd go for radiobuttons.
I think the answer to whether the destructive "delete" should be the default action or not highly depends on the context in which the dialog occurs. If the dialog was the result of an action that expresses a clear destructive intent, like for example clicking "empty trash", the user probably knows what the consequences are, so it makes most sense to have the ...
I would keep it as a simple message along the lines of the Android writing style guidelines (even if it isn't for mobile):
Download for 1 credit?
Download | Cancel
It's short, to the point, and avoids words with negative connotations.
I think FileZilla does a good job of this. And they give you options to never ask again when overwriting - either in the current queue of transfers ('apply to current queue only'), or for the entire FTP session (just 'always use this action' selected).
If they were to add any more options though, I reckon a drop down list would be in order for the 'action' ...
I would argue no - this triggers alarm bells as to: 'what have I actually done?' and is not common practices with most software products.
However Excel is a bit of a weird fish when it comes to this - it could be dependant upon the macros within the sheet, here is an interesting thread discussing the same issue.
There are two experiences here to keep in mind: subscribing and receiving the email. If there is no need to address the subscriber with his name (eg: Thanks for your subscription Robert, Hello Robert, etc), you could get rid of the name field. I would base the decision on the tone of voice of the brand: is it personal or not.
I posted a related question recently as I have been struggling with a similar problem. From what I have mustered there is no clear and clean cut solution, as these kinds of "options" are often very contextual.
This article briefly covers and provides some well known examples.
However, I still feel that there is much to be done in terms of design solutions ...
It seems like you have a relatively simple problem in terms of what you want to ask your users, so why not ask it explicitly with four options (where I would emphasise the safest option for each).
So Import and Append and Export and Append would be the most common options I presume. The other options can either be de-emphasised text, another button.
I lot depends on what the person is waiting for.
I can't recall where I read it, but for airline flight bookings it was found that a short wait had a worse response than a longer one. If it were longer (and showed some fake activity), the customers had a better confidence in the algorithm and results. The same applies for insurance quotes and similar ...
Use specific math symbols, not para-math or pseudo-programming.
Some part of your users may not be familiar with math, so provide a description next to symbol.
Group similar symbols (less & less or equal) into pairs.
Consider using "belong/not belong to set" instead of "between".