Tag Info

Hot answers tagged

41

If I understand you correctly, you have a window that automatically saves changes for the user as they adjust items. Currently you have a button that say "Close" on this window. Your clients are requesting you to rename this to "Save and Exit". But since the save action has already happened while they're making the changes, the button really just closes the ...


25

Click button to create. Two major columns of UX design are ensuring that the interface serves the users' will, and that users are totally in control of their environment (bokardo.com says it better than I do). By automatically creating the next entity, you're making the user question what action has just happened to them and their environment. The link ...


11

Adding a Save button to your auto-saving window would be a bad idea. It would suggest to the user that closing the window without pushing Save would revert the changes — which would be wrong, and highly misleading. Then remains the fact that the users are worried that their changes could be lost. You should add a discreet message saying "Saved" when ...


8

So I did my thesis research in grad school on wayfinding and identification on mobile devices and one of the things I noticed constantly was that while people were out completing the test, there was a HUGE reliance on the blue dot for people to show them where they are in the real world. That was why most of my users didn't do well on navigation style tasks. ...


6

Double tap is not a widely acceptable navigation pattern on a touch user interface. Therefore I would discourage using it unless you indicate it to the user that if they click twice then they would get a more accurate location set. You could visualize it with e.g: a different icon during these 3 seconds change of size of the icon - bigger, standing out ...


4

This depends on a case to case basis. Based on User Research Behavior specific to your form you can select one of the two options When an Add More button is required. This button is required when you don't anticipate the user to provide more rows of information under normal circumstances. In your example you are asking the user to fill up a form for some ...


4

Your dialog actually has three buttons - cancel, assemble, load into simulator. The primary button is "load into simulator", because that's the one that lets you close the dialog and proceed. By only displaying it after the user has generated valid code you're breaking the process down into steps, basically making this a kind of wizard, but not supporting it ...


3

I agree with Mark Lakata. I believe your UX simply isn't meeting the client's desire. If you are auto saving and they are still asking for a Save button, then they don't understand that it is auto saving. There are three possible solutions. The first is continued education.. however I don't think this will be productive as they don't seem to get it as ...


3

Select then act Spreadsheets lend themselves to selecting the area to act upon then editing or choosing your action. In the case of tagging cells or ranges, as a user I would expect to select my range then apply the tag, not the other way around. There are likely some actions that blur the lines (eg cetain types of large area formatting), but those cases ...


3

BDD's excellent answer provides reasoning why you should update the location more frequently than few minutes. This is especially important when the user is moving out of the blue circle more quickly than the circle can be moved to the new location. However, if your app really does not require updates any more frequent than just a few minutes, I would ...


3

I agree somewhat with @adam.heleniak, though I do believe (and have seen many examples of good) double-tap gestures work just fine. In the case you are using it, however, that's a poor UX. Users have no reason to ever double tap on it to get their location. Furthermore, the function itself is used in a multitude of other map apps, where a single tap will ...


3

It's good to keep buttons in the same place. Here is a use case that could be pretty common. Let's say a user wants to just quickly glance at the additional information for the meeting. It's easier for the user to put the mouse in one location and click to expand (and retract), as opposed to clicking, expanding, moving the mouse to the new button location, ...


2

Alas whatever you do with those 3 buttons, it's going to be confusing for the user because they are all physically identical. 99% of the remotes I've seen in this century have rocker buttons for the volume control and a differently shaped button (usually smaller, because it's not used as often) for mute. That also allows one to figure out what he's pressing ...


2

First of all, I suggest to move your location button to the "bottom-right" corner, it will be more accessible to the user. Top-right corner is too far to reach with a thumb (when user is using the phone with one-hand). Secondly, if you are pulling the current location every few minutes already and displaying it to the user, then tapping the "location" ...


2

When I design for Android, I don't use in-app back buttons. Android users should be accustomed to the platform's built in back button, so including a back button is redundant, and, as you mention, potentially confusing. As for accidental presses of those buttons, is that documented or anecdotal? This is the first I've heard of it.


2

Let's start from the beginning: If you want to attach to the path to completion advice, you should do something like this: download bmml source – Wireframes created with Balsamiq Mockups Compare it to this: Improvements: Labels aligned with inputs => Less visual fixations, just 1 visual direction, less horizontal space, but more ...


2

Not all form actions are equal (Reset, Cancel, & Go Back are secondary actions: rarely need to be used (if at all), Save, Continue, & Submit are primary actions: directly responsible for form completion). The visual presentation of actions should match their importance. Avoid secondary actions if possible. Otherwise, ensure a clear visual ...


2

If I understand correctly, the picture below reflects what is going on? There's no problems having two primary buttons like this. Effectively, your Assemble button is an Apply role, and the Load button is an OK role. Essentially there are two primary actions, but one (load) is disabled until you successfully click the other (assemble). There's no need to ...


2

Most users feel that they should be allowed to easily change their minds If many users are asking for this then go ahead and move it up top but given what you said about how rare and permanent this action is I would leave it in a section at the bottom that clearly signifies how permanent this action is... You could also add a non-prominent link up top ...


2

No. Most people aren't sure on this, because Neilsen's statement on the subject predates the wide-spread deployment and adoption of infinite scrolling: Yes, "return to top" can be avoided, because the exact same functionality is provided by simply dragging the scrollbar to the top of the page. It's almost always better to rely on a single, generic ...


1

If the process involves a number of steps than this should be made explicit early on for example as in the mockup below: Past this point a progress bar is a good idea (Staged disclosure) as it provides the user with information about the number of steps within the process and has the advantage of making users feel they have made progress towards a a ...


1

You guys have a major UX issue, since buttons are being used interchangeably for both as buttons and as "status messages". You have already improved the situation for the better by replacing the button with icons (tick and X). Now just need to modify the text on the button clearer. You could use "Turn ON" and "Turn OFF" on the other action buttons ...


1

It's OK to have two primary buttons, or even 5 sometimes. The concept of primary/secondary/tertiary helps designers to think of what's more important by providing a 2 or 3 layer model. Nowhere does it say only one thing can be on each layer. Yet, the more elements on each layer, the less noticeable each element will be as there's less visual contrast ...


1

This is how it will be better from user's perspective. He can fill the form and tab his way to the "save" button. And instead of "Undo" a "cancel" or "cancel changes" text would be more appropriate.


1

LukeW has tested this for you: http://www.lukew.com/ff/entry.asp?571 Take into account Fitts's law Be very careful with an Undo/Erase/Delete button. What kind of a user (and how many) would take the effort of filling out a webform, and then think "you know what, let's throw everything away". Those kinds of delete buttons are mostly clicked / ticked ...


1

1. Make the buttons tactile Tactile buttons do nothing when your finger rests on top of them and require physical force to click them. All external buttons on Apple devices are tactile with the exception of the touch id fingerprint reader which has very few negative consequences from accidental touch. Some Android devices use tactile buttons as well so ...


1

I would use a Button Based UI in this case. Why? From what you've described in the use case about metadata-aware spreadsheets, I'm assuming that the most user actions would start with the question: "I need to take some action on these cells". The question you need to be answering for them is - "Which cells do you want to act on?" and then, "What do you ...


1

Using your vocabulary, I would expect a Button-based UX when using any program that looked like a spreadsheet. It sounds like you have some interesting new functionality in mind, but at the core, your product is going to appear like, and function like, a spreadsheet. Spreadsheets have become fairly standardized and users expect their existing spreadsheet ...


1

You should rename as client asks. Believe it or not the average user on the internet are not very savvy and can get confused very easily. Anything to make the message more clear is always a good step towards better user experience. The "Save and close" also serves as a peace of mind so the user is reassured that whatever changes were made is saved. It ...


1

I was thinking more or less the same as @ADTC. The problem with this UI is that it is deceiving the user, by not fully updating the location when the "update location" button is tapped. I would forget about this battery saving strategy, and try to find others, like for example not updating anything when the app doesn't have the user's full attention. Fading ...



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