Tag Info

New answers tagged

0

I think the way you have it now is great. Why clutter it by trying to do too much at once. I would suggest changing Quick to a more expressive saying though. Like Set time increments or something shorter. If you did want to get it all on one page you could just put Camera one and Camera two as two small tabs at the top and not give them all that screen real ...


0

It seems to me that changing the function of your interface at the click of a button would make for a confusing experience. The user has built a mental model of how it works, and expects the app to act a certain way, so it should consistently act that way. At least if you are operating on the "Principle of Least Astonishment": ...


1

Looking at Nielson's top 10 (despite being written in 1995), and based on some user testing, I actually think there's a case to be made for option 1. Consider the situation where a user believes the file they have prepared for the program is located at a place on the disk. The file is not of the required type, but most users don't always (often) read ...


2

Why does your boss need to compare the two forms? Think about what your user is doing, not what your user is saying. In other words, try to look for the deeper "story" your boss is telling you about how she wants to use the software, and try to provide that, even if it doesn't look like what she describes. Is it because the Annex is mostly identical to the ...


1

Option 2 is much closer to the mark than option 1, but having no "option to change [the] file type", especially when the user would normally expect to be given that option, is still wrong. Ideally, you should not be deciding whether the file in question is valid based on the filename extension, but rather by checking some type of tag at the beginning of the ...


2

In your case i would split up the whole input form in a wizard-like step by step input area. When looking at your layout it appears that you already started grouping the input fields with boxes. Consider that names of countries, persons and so on could be much longer than the input fields, so give them the space they need to properly display their entered ...


3

I have a personal rule that no single form should contain more than ~20 visible form fields because after that threshold the screen just becomes unusable. The solution to this problem will change depending on your client's actual needs. e.g. If there is a workflow where a user can create a contract (by itself first) I would have that as a simple form. ...


2

I would like to give you one explanation that comes from my field of activity. It has to do with the design of human-computer-interaction or better: human-automation-interaction. Very often tasks are too complicated to be fully automated. At certain points of the solution process the user has to be incorporated. Researchers found that a "mixed initiative ...


7

Alan Cooper makes the point IIRC specifically in The Inmates are Running the Asylum (coincidentally also using an ATM example) that a source of poor UX is that computers do not interact i.e. "converse" like real people. e.g. You: "Withdraw $200" Computer: "Insufficient funds" You: "Check balance" Computer: "$187.34" with a human You: "Withdraw $200" ...


1

Your immediate issue is a branding/PR problem. Your customers come in two flavors, but the ones you're looking to communicate with are "cloud admin" users (whether these are concurrently "system admin" users is irrelevant at the moment). First things, you need two discrete schemas to associate accounts with. The cloud admin needs to internalize these ...


1

Four things need to happen for users to migrate to cloud user management User needs to see and understand the overall system User must believe in benefits in cloud user management (notably this includes (a) belief that it is secure, and that (b) working off line won't be impacted Painless and clear migration path "Nudge" to both remind, educate and ...


0

Why we chose to do something similar was the result of internal studies. Something we try to keep in mind is that we (designers|programmers|analysts) are not representative of our audience. Not to be snobbish, we just remember that half of our users are "below average" and we have to keep systems accessible to all. We aim for about a 5th grade reading level, ...


1

I agree with the other answers, radio buttons are the best choice for an input with 3 choices. According to GNOME developer, they are preferable for your problem because: Radio buttons are used in groups to select from a mutually exclusive set of options. https://developer.gnome.org/hig/stable/radio-buttons.html.en Radio buttons or a list will ...


0

Errors cause frustration and confusion. Forcing a constraint to avoid an error is the better option. Forcing functions are a form of physical constraint: situations in which the actions are constrained so that failure at one stage prevents the next step from happening. In addition to preventing the user error, afford the user a clue about acceptable file ...


4

The answer is in the 10 Heuristics for User Interface Design by Norman Nielsen, which are a must read if you listen to me. Error prevention: «Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation ...


2

Instead of sticking to a 2-column layout, I would suggest going for a list based layout as shown in the mock-up below: In this layout, the Medicine name can be the title and the condition it treats can be shown as tags under the medicine name. Furthermore, if the user wishes to search all medicines for a particular condition, he can just click on the tag ...


1

I would suggest making it an accordion style interface. Keep the panels but have them expand horizontally (while shrinking the width of the others others) slightly when a user hovers over. Instead of the "flip" effect. You can add easing to the animation to make the motion feel more fluid. This would result in more horizontal space within each panel. I do ...


1

One option would be to give the user the ability to hide one or more of the lines, and the ability to display hidden lines again. Postscript: Based on what dayluloli stated: The lines are often close together and overlap. The legend should follow the end-of-line. Thus, the lines and legend should be presented in the graph. With the four lines in the ...


0

I'd prefer the navigation tabs approach, but if there are just two possible modes you could simplify it by just giving the option to select the mode in which you are not positioned.


6

A few different ideas come to mind. 1 - make the label color match the associated line color, so even if they overlap it's clear which label belongs to which line. 2 - Put each label in a containing div, possibly giving that containing div a border the same color as its associated line, with an opaque white background ... and possibly when a user ...


2

I generally favor radio buttons but -- as an option to experiment and test with -- you can use a slider. EXAMPLE: YES _ : : ▲ NO OPINION ▼ : : _ NO Be careful to factor in up/down and left/right prejudices/tendencies in your testing. Up tends to be "good" and down "bad". And left-right is inextricably ...


4

Generally, there are just two natural ways to set up a 1-out-of-many choice in HTML: a set of radio buttons, and a select element. The latter can be used with a size attribute specifying the number of options visible in the initial size, or with size defaulted to 1. For usabaility, it is best to have all options visible initially, so that the user can just ...


23

To select one option of a limited number of choices, Radio Button Inputs would be the way to go.


3

I think it depends a lot on whether this is a very common form or a rare form. If it is rare form, where the user might have little or no idea of what is valid input, I'd emphasize "explaining" a lot more. Since having the field just "beep" or "flash" on invalid entry will frustrate the user who doesn't know what they are doing anyway. If it is a common ...


3

Your second and third bullets (numeric only, maximum length) can be "preventing," because it's more or less clear from the context why the input box is not accepting the characters they are typing. Everything else is almost always "explaining." The ideal, of course, is to both prevent and explain. If your user is running up against a character limit, it's ...


3

Leave the value in there as an invalid state You should allow users to change the type and still keep what they wrote in value field. They might have clicked the wrong type, or want to copy what they had written. You need to communicate that the value is invalid though so I suggest you indicate this by making the value red: When the user leaves this ...


3

There are no absolutes in UI design, so it's impossible to say which is better in all cases. It depends on the data being input, the importance of it being correct, the difficulty in entering the data, the size of the form, the type of user, etc. That being said, Preventing invalid input is generally the best place to start, but you need a ...


1

To a certain degree, the system can handle the problem itself - if an integer is changed to a string, the number can be converted into a string automatically (in the image above to the string "123"). In this case no user intervention is required. If a conversion is not possible, there should be a warning message. You say, the user "can change data types ...


1

Aside your questions you should take a look at accessibility, as ipavl already stated in his comment. To get started you could take a look at the anySurfer website, if I'm not mistaken the label is only valid in Belgium but they offer a complete and normative checklist with code examples and solutions for common problems. Personally I think the majority of ...


0

I think it depends on if this is the primary purpose of the app or not (or at least the page). If it is, then in my opinion it SHOULD be obtrusive and I vote for option #2. Regarding #3, I don't see allowing user to enter text as a "pro". You're allowing a user to think they're doing something only to present them with an error afterwards. It's wasting ...


2

Of your three options, I prefer the second because it adds an upgrade option, empowering the user to solve the search availability issue. Alternatively... Create a button for each concurrent search that your user's current account can perform and replace each one with a confidence animation when its search is running. Something like...


0

Another argument for using the dotted underline is that the HTML5 element <abbr> is rendered this way in some browsers.


2

You can mimic the approach LogMeIn has taken in their various clients. As you can see in their featured screenshots, they use an icon of a computer monitor to symbolize a PC. Computers in the online state are displayed in full color while computers in the offline state are displayed in gray scale. Font Awesome has an appropriate desktop icon. You can ...


0

If a site is dominated by broadcasting-style text, then subsequent language selection is pointless. This might be the reason for the sites you referring to to put the language selection into the footer: here the contents itself has barely text, or its texts address a limited audience (or are even translated automatically).


2

Is there any big difference when it comes to designing for people aged 60 + and people aged 50? Technological know-how, perhaps. For example, people who are 60+ might have never used a computer aside from simple tasks, but those who are 40-50 might have some experience with a bit more. This would depend on your user-base, of course. You should also ...


0

Several existing answers on this site offer advice related to this question. One of the problems is that dropdown menus and dropdown selectors just get called "dropdowns", which can make it tricky to find stuff. I've mixed these answers in with a couple of my own suggestions. Links throughout and at the bottom. Make Sure This is Really a Problem As with ...


0

One solution could be creating an asynchronous transfer. Implementation would vary greatly depending on your platform, (.net, php, ruby, ...) and it's all kinds of coding voodoo to get it done. Another level of difference could be the transfer method (cURL, fopen, file_get_contents) The outcome would be similar by allowing you to create hooks into the ...


0

How real are the distinctions between your workflows? How relevant are the boundaries between them TO YOUR USERS? Do they come to your interface saying "Today, I want to do an 'B'!", and then consider which of the 'B' options they are interested in. Or do they come to your interface knowing exactly which choice they want without your having to divide that ...


0

I've done this before by having a sidebar (cf. Word Task Panes, etc) with a list of available "tasks", each having an icon and some text (actually title and subtitle) to describe what the action will be. In the old days a toolbar would also be an option, but these are considered déclassé. It may not be the most elegant solution, but I've found that users ...


1

Just an idea... could you use a different font treatment? For example a slight difference in color and italics? i.e. "Saved.txt" vs. "Edited.txt" - hope that helps.


1

Because nobody else has mentioned it: SublimeText's use of the • character in its title conforms to the way it changes the close tab icon (x) to a circle when edits have been made:


0

I am not a UXer, but a developer so I am not able to help with how the data is presented. But I have an answer for obtaining progress of uploads. A relatively common practice for uploading files while getting feedback is to break the file(s) into chunks, and updating the progress bar/indicator based on the chunks uploaded/ total data to upload. This can ...


2

How about combining Total and Sum as a single field? Like this download bmml source – Wireframes created with Balsamiq Mockups The input field for the selected item gets enabled. The other option is disabled. You'll probably need to come up with a better label than "totalling method" though.


0

Button should say what they do. UXMovement has an article: Why Your Form Buttons Should Never Say ‘Submit’, which describes why providing generic terms... gives users the impression that the form isn’t focused on a specific task. It also gives off the impression that your website isn’t user-friendly because you’re speaking in a technical way that most ...


0

I had the same issue with X for delete line or X for error line. But now with apps, tablet, smartphone and flat icon we have now the possibility to use simple trash for delete action.


1

Why not embed the prerequisites into the modules themselves? That way you can see all prerequisites at one place. No lines to other places, no other place to look up associations. I added one possible draft using a drop-down box for addding prereqs and an X button which will remove it again. Depending on further factors (size of list, knowledge about ...


0

I have also participated in a project involving large amount of data input on multiple types of devices. And our solution is using Responsive Web Design, so users can choose to input data on mobile, tablet or desktop, through accessing the same URL. Also one thing we found is that although mobile devices are relatively small, users under certain ...


1

Design for people not device. You might prototype a few scenarios that involve mobile + desktop pairing. Wearable UXD is a good example of this paradigm. Generally desktops are better for data entry. While mobile has the benefit of being always on the user. Take something like Fitbit for example. The device is optimized for collecting data in an ...



Top 50 recent answers are included