Tag Info

Hot answers tagged

26

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


23

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 ...


17

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 ...


10

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?


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 ...


4

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 ...


4

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.


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 ...


4

The 1990's called! Please return its cascading message boxes! Alerting system are extremely complex and difficult to get right. They require subtlety in one case, while demanding you slap the user in the face the next. If you fail to get it right you either cry wolf every time (your current design is doing this) or hide them in the corner. You should ...


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

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

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

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 ...


3

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

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 ...


2

On developers.android.com you can find very useful information about "Navigation with Back and Up" button in Android Apps. The standard behavior of the "Back" button is to navigate in reverse chronological order: The system Back button is used to navigate, in reverse chronological order, through the history of screens the user has recently worked ...


2

I would recommend going with a simple approach like this download bmml source – Wireframes created with Balsamiq Mockups I would recommend putting the archiving or withdrawing option as the primary call to action as you want that to be the primary interaction and not have the user be accidentally deleted. Since there is some confusion about ...


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 ...



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