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 ...
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
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,...
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).
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 ...
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 ...
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 ...
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.
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 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.
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 ...
Not a guideline, but the result of long experience.
You should remember the size setting, but not the location.
If you need to resize the dialog to see something, you will need to resize it again when you next perform the same task.
I have worked with applications with the following:
No resize, no scroll. Content the developer didn't forsee gets cut off.
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".
In general, when something goes wrong, software should—in decreasing order of preference:
Recover automatically with the most commonly acceptable fix, without bothering the user. Undo can hekp the user back out of a fix they don't want.
Offer to fix the problem, with the most commonly accepted fix as the default choice.
Inform the user of the problem and ...
The overall usefulness here all depends on what files you want to upload, how your workflow is and how you organize them.
Scenario 1 : You know where your stuff is
You know exactly which files you want to upload, how they are named and in what folder they are located.
Navigating to them in an explorer window and drag/dropping them will need ...
Well, I tried to get the answer from the design team (UENO. Created the interface, the renaming part is as it is since then), They simply can't answer it.
I believe that renaming in a modal doesn't have any specific advantage over inline renaming (they must have a better word for that, which I don't know) renaming inside a modal provide clear context and ...
Just require the minimum information you need from the user.
Any extra interaction the user needs to do will probably make some users go away.
The more private information you request the more users might go away.
Also, in some countries there are certain regulations for personal information you might retrieve from users such as names. Be sure to check if ...
You already have the reason: to raise distinction.
Make distinction with non-caps text
Raise importance visually on the UI
Raise importance when the user taps
These are the options:
All of them are understood. However, in the all caps example the order of importance goes
(or even the actions before the title), while in the ...
Meal type (breakfast, lunch, etc.) seems to be the header of the form rather than a setting.
In the first solution all meals are displayed in a dropdown under one form, and the rest of the form varies depending on what meal the user selects. When choosing a meal the layout configuration changes. This could confuse users, some might even want to keep ...
As a checkbox, tied to your action button.
Remember the checkbox is a choice based on the action (hence, tied to the button). The system should always offer to remember preferences on common actions in order to avoid repetition. However, "remember" is not an user interaction, but a system feature. Therefore, adding a button for a non-existent interaction ...
Yes, remove the dialog box altogether. Users are conditioned to not read them.
Take them directly to the results page with proper pagination (loading a few results per page). If they need finer control over results shown, provide the dropdown option to choose how many results per page to load.
I agree confirmation/discard dialog should not be overused. A good practise which I follow is to use such dialog in case of any loss of data. In your case I would suggest any action that closes the page with uncommitted changes should show the dialog box and discard should clear any changes made.
I would not recommend having uncommitted changed state since ...
I'm going to be the wet blanket and suggest that there may not be a big benefit.
The fact that these are being used more often is more about changes in technology. We can do it this way now, so let's do it this way.
Yes, drag-and-drop is not a new concept. It's been part of our systems GUIs for 4 decades. But note that the process of uploading a file via ...
The only time I can think of when no close button should be there is when "Cancel" action is not acceptable, e.g. the user must make a choice.
This is often connected to popups that isn't caused by user action. For example, the system must be restarted and asks the user when the system should reboot. "Now", "In an hour" etc. Letting the user close that ...
Grouping can be improved by drawing a line between "Configuration" and "Preferences". Everything that the user has to configure to get your app running should go to "Configuration". Everything optional, which can actually be a matter of preference, should go to "Preferences". For example, I hardly have a "preference" for the default printer (it has to be the ...
This is a great question and its opens up a question back to you. Why are you using a modal?
I really like how Atlassian considers this UI pattern.
Use modal dialogs when you need a user response, to reveal critical
information, or to show info without losing the overall context of a
page. No other interactions on the main page can be accessed while ...
Use spin boxes when the value being entered is a numerical value within a range, and don't use them when the number instead represents an identity (e.g. port number).
Especially consider using spin boxes if the value is a numerical value where you want to encourage particular increments (e.g. thousands)