New answers tagged

0

How about something like this? comma will end sequence and convert it to a UI with background. Inside the sequence, the individual items (which are seperated by a [space]) are converted into UI items with background. Moving a cursor onto a sequence will remove the BG from the sequence, indicating the sequence is currently being edited. Moving the Cursor ...


1

onchange is too slow, onkeyup is too fast -- fortunately there is a middle ground, which doesn't require pestering the user with a notification: debounce the input events. Essentially what this means is that you set the event to trigger on both keyup and blur, but limit the speed at which repeated triggers are taken into account: on receiving a new event, ...


0

Try using events like 'OnKeyPress' in JavaScript. I believe you are calling JS functions to send the input data to the Graph values.


4

Go with the flow Seems to me your users are telling you the solution: make right motion increase the annuity proportion. You see the slider as some kind of horizontal stacked bar chart, but your users don't. They see it like a car's AC/heat control. So don't fight it. Make a stacked bar chart more like a stacked bar chart If you really must have the ...


1

The Android developer portal has a couple of widgets - since it is on the dev portal, it's quite understandable that it must be in use. https://android-arsenal.com/tag/227 This youtube video is showing a practical use of it. https://www.youtube.com/watch?v=NdWZq8vdKhs


2

Could you have a url that populates the database? Something like domain.com/autopopulator.php?itemid=thecode If so I would use a qr code. Most users have them, they dont have to input anything and you can send them directly to some congratulations page without the middle step. Btw, very interesting question. :)


5

The best? Only testing will tell. Going to both your examples, the second one is way better from an user point of view. See both dropdowns: one has a list of TLD and nothing else. The other, a list of TLD PLUS the price. And in the domain business, this is a huge difference since the newer TLD use to be way more expensive than the classic original TLD. ...


2

Dropdowns have: PRO: no needless waste of screen real estate with long lists CON: a user action is required before the user can see what the options are Dropdowns only really help if the list is long. 3 options is not a long list, and a radio button would make more sense in this case. Something like this: download bmml source – Wireframes ...


0

Your select only has three options which are mutually exclusive, so why not consider using radio buttons? The default radio button should be set to None. If you select another radio button, the UI should display the appropriate fields for that option (progressive disclosure).


2

You can combine options 2 and 3, to link the scroll position and which tab appears selected. As in the Change active tab depending on scroll position answer. Or you can use Miller columns as in Finder on Mac.


0

Perhaps one (slightly left-field) way to look at this would be to investigate accessibility research for people with motor impairments - people who find it difficult/impossible to use mouse/keyboard/touch inputs. Some useful resources: How people with disabilities use the web To use the Web, people with physical disabilities often use specialized ...


1

I'm sure there are other concerns, but the first one that comes to my mind is that the app should be designed to minimize the input of number and letters, as it is usually very cumbersome on this type of device... When it is absolutely necessary to let users input letters/numbers, I would use smart defaults (popular choices for instance), autocompletion or ...


1

I can't see any problem. You have a wheel that can be turn front/back. And push button. You can easily prototype such interface by simulating scrolling by tab/shift+tab and push like enter button. The main thing is to put all elements in proper order (like tab index) and clearly highlight which button is selected currently.


0

Your best bet is Option 1. Let me address your concerns: -Separate page/form for each plugin seems pretty heavy Unless you can know for sure how many settings each plugin will have, giving an entire page seems to be the most flexible option. Furthermore, it creates a separation in the user's brain that seems useful: There is no interaction between each ...


0

It all depends on the number of things you might need to account for (scalability). Another way to score this is based on efficiency: Option 1 users can access everything with just one mouse-click. Nothing is hidden. Option 2 users need to make 1 mouse-click and scroll the page to view everything. Some things are hidden until you scroll. Option 3 users ...


0

I think collapsible section on the right may be better. It makes it easier to read and see the different sections. Tabs are also limited in size and width. With a collapsible section you have more space for the title and purpose of each plugin. It can grow vertically dynamically.


0

A fourth option would be an extra settings dialog for every plugin. But this would certainly be the worst option because it will separate the options. Basically you have to take three numbers into account: number of NPCs number of MODs number of options per NPC/MOD Depending on what number is more likely to grow you will have to decide between your ...


0

In my opinion, wizards are only good for on boarding process, account creation or making changes to settings. They are not so suitable for scenarios where the form has to be access frequently such as task related features (product creation, appointment scheduling). Thereore I favor the 3rd option you have presented. Based on what was described, it sounds ...


2

Here are some options to reduce cognitive load and make the task easier: Shorten your descriptions. 200 symbols * 19 options = 3800 symbols, which is roughly A4 sheet, full of text. Looks crazy. Substitute long description with short labels. For repetitive users this is OK, for the new ones provide some help/guide. E.g. "Home", "Professional", ...


3

Considering your design layout, I really think the best option is to use either checkboxes or radio buttons (depending on whether the user can select more than one option or not). Below is a quick mockup of what I mean: However, if you have a large number of options, this could prove to be problematic. In that case, I would consider having your Section C ...


1

In most (if not all) modern browsers and Operating Systems the menu of a dropdown is a separate (but not independent) object from the trigger. download bmml source – Wireframes created with Balsamiq Mockups This means that the text on the trigger can be safely truncated while the contents of the menu remain full length - Effectively showing the ...



Top 50 recent answers are included