Tag Info

Hot answers tagged

24

Not according to Microsoft. Use title-style capitalization, without ending punctuation. Source: Microsoft Guidelines for Windows, section about error messages.


21

I would say that this often leads to an unwanted drag and drop action. What if this window for example has a small scrollbar, you want to scroll to the bottom of the page and you accidentally miss the scrollbar? You would drag the window down and you might need to reverse this action. Why is it uncommon that windows can be moved by clicking anyway in the ...


15

My answer would be to synopsis the question of the modal form, so with the question being: You are leaving the question with unsaved changes The title would be: "Unsaved Changes" It's a pattern I've seen and used regularly, it's brief and informative.


13

This is actually not always true. In some cases the default behavior of most apps would be to allow to drag windows by empty space. An example is KDE. See the screenshot: KDE's default Oxygen widget style has window decoration visually merged with window contents. Thus, to make feel match look, the theme also by default allows to drag windows from all ...


13

The title bar isn't always the only spot to that can be used to drag the window, (these days some windows can be dragged by parts of their background, but it's rare) but it's the oldest and most established and common convention. It originated in the early WIMP UIs, the Smalltalk systems from the 70s and 80s. If you study the way the above windows were ...


9

The Windows OS provides the (optional) title bar and control box, as well as a mechanism for OS users to organize their application windows (re-positioning, minimizing, maximizing, closing). From the perspective of the Windows OS, the title bar is the user's API for these operations. Everything else in the window is "content" that is under the control of ...


8

This area is normally giving you information on the type of question being asked (at least in my experience), so the question mark feels like the dialog is questioning itself. I'm a "Save Changes" dialog... or am I?


4

You'll find that nearly without exception, question form in modals is little appropriate. On content vs interaction Probably to core duality in all interfaces is the that of content and interaction. Respectively, what you can see and what you can do. Cognitively, these are mapped to (so to speak) two cognitive processes - interpretation and action, which ...


3

The placement of the OK button really depends on the content of the modal. If you tend to use them for forms, a left justified button may be best. As forms are usually left justified it is easiest for users to go down in a straight line. A user's eyes are likely not to leave the left side of the modal often. However for shorter modals that may not have ...


3

I have previously designed an interface which had the exact same header links. A basic wireframe of what I finalized upon is shown below download bmml source – Wireframes created with Balsamiq Mockups The reason for the design of the login/signup link were: A button indicates an action as opposed to link divs which are for navigation A bright ...


3

Microsoft doesn't always have the correct answer, but they do set the standard. In this case, I think the question is lost if it's in the title bar. I would probably phrase the text like this: Title: Save Progress Text: You have unsaved changes on this page. Would you like to save them now?


3

In my experience, modal windows are best used to present clear interactions that the user either: needs to do (e.g. resolve an alert) has chosen to do (e.g. open a photo gallery). Resolving that interaction should close the modal, and there should already be a control in place that does that. This is because modal windows interrupt the user flow and ...


3

In general, I use the following guidelines for using modals: Is it focused? Every time you throw a modal in front of a user, you're disrupting their workflow. Disruption isn't always bad. Sometimes that's what you want. But you have to realize you're doing that and use it for your benefit. Items within a modal should self-contained. A good rule of thumb is ...


3

Take a look at this UX/Design guideline from Google about Confirming and Acknowledging: https://developer.android.com/design/patterns/confirming-acknowledging.html Although the guideline is for mobile applications, the principle and flowchart highlighted in the guideline can help you and your team decide when and when not to use alerts and confirm dialog.


2

No never. Adding a second modal dialog over the first one is the equivalent of using pop-up window over pop-up window (and there's a good reason they where blocked in the browser and soon deprecated in web design). Instead try to guide your users through a modal dialog wizard with clear interface of what to expect next. User feel comfortable and trust the ...


2

I would not make search another tab because it creates disconnect between search and the categories search is for. Instead, I would put the search field above the tabs (a global search) so user understands that search is for all the categories. When user performance a search, you could display a search results tab to show the results.


2

Generally you should look at the use of confirmation dialogs as a last resort. They break the flow of the task for users that understand the system. The dialogs are often confused by users or not read at all. First decide if something significant will happen. If so, determine if undo function can be developed.


2

I think the problem is you are looking at the technological implementation instead of the user experience. The user generally doesn't care where they are saved, or how they are saved, only that they are saved. So instead of asking the user to deal with files, assume the user expects you to save them. It's then your choice of where to save them. Use a ...


2

Modal windows are quite common nowadays so the user might not but surprised to see something like that appear. The content of the modal window is more important than the pattern itself. If the content is an action, it is a common pattern to use ellipsis (aka suspension points). If the content is just information and long, you should just use a simple ...


2

I don't know about the general convention but I had the same problem and used the following solution. The link is displayed as a bootstrap button and I added the fullscreen glyphicon. Here is the result: First icon is edit and second icon is fullscreen, I hope the user will understand that by clicking on the link he will be able to edit the entity in ...


2

Inline not Modal Inline edit is to be preferred at all times. The user keeps context, have the ability to use information related and narrow to the edit and the user don’t have to focus on a new UI. It is the same, simple, easy and straightforward process where the flow of work can be kept. Modal dialogue breaks the users’ context and it takes time for the ...


2

Arguments of the appropriateness of modal windows aside (because I don't think we have enough context for that from your question), I think your reasoning for why this is a good idea is sound. Some users rely very heavily on the back button: The Back button is the lifeline of the Web user and the second-most used navigation feature (after following ...


2

Dragging is limited to the title bar for consistency and perhaps usability. If you could both drag a window by clicking in the content area, as well as interact with buttons, text, etc. in the content area, there would be a much higher margin for error (and presumed difficulty in programming). Clicks within the window are reserved for interacting with ...


1

YES! It is but it has to fit the "design language". We don't usually see punctuation in titles, that's a big graphical difference. Titles are also rarely full sentences. So for a window I would say it's probably better not to do it. The thing is that modals don't need titlebars. They are not windows. If you are able to make it work out graphically, in a ...


1

Although it means writing a lot more code, you should try to prevent the user from making those errors. The most popular example is the password field: as long as the password is too short, ther will be hint on it and the "save" button is greyed out. If the user can't add new items, tell him before he tries to add a new one. Also always tell the user what ...


1

I would recommend a page error message, not included in the layout but as an overlay, that is strongly visible and disappears after a while.


1

It's easy to overthink these types of questions but in my experience we ux professionals are often the only people for whom this might jar. I would suggests that your users would expect "something" to happen when they clicked LOGIN, and whatever that was, as long as it provided a clear, simple and recognisable login prompt, I doubt they'd have a problem ...


1

Yes there are. They are described in detail in About Face 3 (by Alan Cooper) and maybe earlier versions as well (I can't check since I only have version 3). The main guielines are: Make your click/touch targets large enough: 20 mm should be enough. Use soft-keyboard input sparingly: awkward for user and creates lots of fingerprints (which make the screen ...


1

Within my specific constraints, I found a way to avoid the confusion. Some of the other answers suggest to use 'add' button in the list, or to pin it below the list . I cannot pin a fixed 'add' button at the end of my list because if the user scroll out of the list, another section has to be displayed below. So my only real option to show the button ...


1

I'll answer this question in two parts. Are modal windows Accessible The answer to what I can find seems to be Generally no. I recommend looking at this study which was done to check how screen readers react to modal windows. To quote the study Being a screen-reader user I tested several modal dialogs, including the jQuery modal dialog, with several ...



Only top voted, non community-wiki answers of a minimum length are eligible