Tag Info

New answers tagged

1

Not just about modal errors, but errors in general: Is it an error that prevent the user from continuing using of the application? Is it an error that resulted in loss of data? Is is an error that is not likely to be overcome by silently retrying? If all of these questions are a 'no', then there is no point in explicitly showing the error to the user. A ...


1

The other answer you mention states that modal dialogs distract the user. Therefore it is inadvisable to use them during the normal user workflow. However, if there is an event that is both (a) uncommon, and (b) important, then modal dialogs are entirely appropriate. Server errors may fall into this category depending on how infrequent and important they ...


0

The question is mostly moot because, even where dragging on empty space is an option, nobody sits there choosing a spot to drag from. That would take longer than moving the mouse straight to the one place you know will work. In terms of quickly acquiring a draggable area, I think it has more than zero value. But if it's not consistent it's not useful, and ...


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


1

I'd go with your option 2 and put the date & time on the main screen, and have a dialog to pick start & end time. I don't see any need to use multiple sequenced dialogs. Even better would be to use an inline picker that appears in the list when you tap the date, and disappears once you've selected a time. (take a look at the calendar app in iOS 7). ...


1

There's quite probably also a historical reason: defining whether the cursor is in the title bar is computationally a much simpler problem than defining whether it is in NOT(text OR button OR input box OR scrollbar OR ...). I think I remember draggable windows in GEM on a machine bought in 1987 with 512kB of RAM, and certainly in some DOS applications (text ...


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


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


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


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


0

In typography, big starting letters dropping over a few lines are called "drop caps" (see http://en.wiktionary.org/wiki/drop_cap). The idea is similar with small pictures featured at the beginning of an article. Since yours are zoomable, they could be called "zoomable drop pics".


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


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


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?


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.


24

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


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?


0

Is this for web usage or for a modal on a native app? Reason I ask is because I believe the context, "I'm looking at content on a web browser", may influence the user's thoughts as to where the X to close the modal ought to be. My gut feeling is that all modal/lightboxes plugins on the web by default have the X on the top right corner, to have a web app and ...


0

Your question can be read like so: Should I make an effort to provide my users with an interface that follows the conventions they are accustomed to? The answer to this is a resounding yes. Mac users look for close buttons on the left, Windows on the right. For most users this is a system 1 process - they don't spare a fraction of consciousness, it's ...


0

No. Your heart is in the right place, but, idealistically, one of the points of creating a web application rather than a native application is for cross-platform portability. But even if that's not a relevant factor for you, think about this: What percentage of your user base uses Macs? How much increase in effort is required for them to understand that ...


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.



Top 50 recent answers are included