Tag Info

New answers tagged

0

If you have some common motives to why a user would flag content, you could use the flag button as a popover/drop-down where the user can select one of the common motives or explain it him self. This dribbble shot is a good illustration of what I mean. Regarding how the user explains the flagging him self - I don't see why you couldn't use a pop-up both on ...


1

To make long form simpler and faster: Get rid of every single filed that is not crucial for the process (and ask stakeholders also to validate if each field is a must-have, because usually they put all they think is a nice-to-have to the form) Separate it into steps, give progress bar with steps Use autocomplete as much as possible - there is finite number ...


2

Separate the UX from the implementation concerns This will help simplify the problem by clarifying priorities and through decomposition. Usually, the first priority with a complex form is to design the optimal user experience. UX makes a huge difference with long forms, so that's why it helps to separate the concern and focus on creating a clear user ...


0

I would make the flag explanation field optional. And the flow would be like this. Flag click/tap > Want to explain why? [Just flag] [Explain] [Undo flag] If the users decide to explain why they are flagging a course, then you take them to the new page where they can fill up the flag explanation.


0

Firstly, Always categorize form fields in groups, group similar type of fields first, because categorization reduces cognitive load of user who is filling form. Secondly provide the wizards and break the process into smaller steps. Third, always provide 'Save as draft' feature for such a big forms because if a user is not able to fill form in one sitting ...


0

What I use for this kind of scenarios is a simple multi-steps form, where I ask for some specific data, do a quick validation, if correct, enable the continue button and so on until getting to the last screen with the SUBMIT button. Using AJAX, this is a pretty simple task. As for when to send info to database, it depends. For example, since I work with ...


0

Your best bet is to use a control similar to the AJAX Accordion instead of the tabs. That way all the fields will be validated within a single page although they will not be all visible (unless all headers are expanded). In the past, I worked on a web application with a similar number of fields, we didn't find any other way to display and validate all the ...


0

In my opinion, When user submits form by clicking 'Submit button' instead of making that button disabled, show the 'progress bar' in that button. This will not break user's focus and attention.


0

I'd go with the second one. With the first choice, it is not very obvious that the user can manually input time. Assuming precise time is important to the application, you want to make it immediately clear that they should be precise, which the longer picker does. If you want to go with the shorter option, make sure it looks like a control that the user can ...


0

This would take a more work, but I think it would be pretty slick if you could mimic the behavior in Mac Mail when searching through emails. You could just have one big search box and allow users to just type in keywords. For example, in Mac Mail you can type "from:John" and it will search for emails from John. In your example: "Show me all users ...


0

I had similar issue. Saveing was usualy 0.2s but in some cases it was takeing aprox 4-6s. What was done: - click green "save" button - button goes gray with spinner and text "saving" - when done buttons goes green with "done" Progress bar is nice solution... but only when you are able to determine the end of process. Your loading is overwhelming. But ...


1

If it's a matter of milliseconds then your approach works just fine. You're refreshing the entire main body after the form submits, so your users will most likely not even notice the progress bar because they will be reorienting their vision around the new panel.... Your progress bar appears at the edge of the screen so it is in peripheral vision. Some ...


0

I don't think you can answer this question unless you look at the entire form and also the individual form fields themselves. The reason for this is that there are at least two different types of scanning patterns that the users will adopt during the process of completing a form. The first of these is the scanning of the entire form, which requires them to ...


1

How about this: User Mouse overs the image and gets a border with 2 action options(button / icon maybe) to edit and upload. (on click) Upload will open the natural operating system process and can be default to Pictures(windows). User selects the new image from his local machine. You can resize and push it on your interface. I liked the idea that you ...


1

I would not use pointer-events:none; on a disabled button. It's better to manually set the cursor and hover effect to the default/disabled state. In some cases it's useful to add a tooltip to a disabled button; pointer-events none would disable this. I've added a use case for pointer-events:none; below if your interested.. Pointer Event Use Example ...


2

From a UX perspective, there are things that could be done to help the user experience by not setting pointer-events to none. Showing disabled fields to a person is sometimes cruel. If the rules for why the field is disabled are complex and not obvious from the screen layout, it is like holding a carrot just out of reach of the person trying to use the ...


0

Based on what you've told us, it seems like there are three primary routes to the add/edit workflow for customers: Global Nav → Add/Edit Customer Customer List → Add/Edit Customer Customer List → Individual Customer → Edit Customer Regardless of route or status, I think the window should use one pattern that's used globally. If you're creating a new ...


0

Not providing specific error messages can come to bite you in the end, when some bug in your JavaScript code causes an invalid submit and the only diagnostic you have is an e-mail from a user saying it said ‘Generic error.’


0

Don not worry about users who disable javascript in the browsers. It depends on the back-end framework and API you follow. Will anyone else use your API? If yes : Answer will be Yes you need to make the error message more specific. If NO : Answer will be NO since your UI is the sole user of the back-end and your your UI has got all the validations done ...


2

Yes, you should give specific error messages! In a perfect world, errors would never happen. Unfortunately, we do not live in a perfect world. Errors can happen, and let me tell you that by far, the most irritating thing to come out of an error is a generic message such as "An error has occurred!" The one product that I've seen this happen the most in is ...


1

No (but...) The critical points are that the app requires JavaScript to function and you're not intending to support a non-JS fallback mode of operation. Having said that, you may need to consider accessability issues for users using screen-readers, etc, and may need to revisit the decision regarding non-JS support, in which case you'll need to supply a ...


1

A common solution for things like multilingual customs or banking forms is either to stack translations vertically, or to write them horizontally but separated with a slash "/" : Not exactly pretty, but functional and makes good use of rather restricted space. Depending on the required languages and their use within the target audience, you could also ...


1

In my experience of multi-language applications, they bring their own complications. As you don't know the exact size of the prompt that is brought forth from the localisation item, you will need to design your form to be flexible. If you have a set of defined languages and the resources have already been translated you can get a feel for common terms (form ...


5

From comment and reply above: If a user must go out of his way so as to pass client-side validation but fails server-side validation as a result of putting javascript in a field then we're truly talking about an edge case. – Mayo @Mayo We are. And that's why I'm asking if it's really necessary to provide detailed errors in such a scenario. – ...


26

This is a very common situation with client-side validation In a world with no budget or time constraints, yes...of course users would be better off with more information. In the real world, you probably have far better priorities. The only time when users would see a server-generated form error is: (a) if your client-side JS is broken (in which case, ...


12

Yes, you should provide server-side validation along with client-side validation Client-side validation allows you to provide feedback as quickly as possible. Immediate feedback allows users to identify and fix common errors without having to submit the form to see the errors. Server-side validation messages provide a backup communication tool. There are a ...


2

Simply, yes. Why wouldn't you provide the user with as much information to rectify the problem, that they need?


2

Use HTML type="tel". Read about it here The Idea is to have something like this setup _ : _ So the amount of keypress/touches will be 4, ex. 12:45. I would try to make them go with always using 24-hours, to save space and bring some kind of consistency into it. Presets as mentioned @tohster is a good idea, like :15, :30 and :45 on buttons to save a press. ...


3

You are describing a use case for an expert interface Expert interfaces are specialized to accomplish a particular task effectively. The UX trades off intuitiveness in favor of productivity/accuracy/speed. Here's an example of an expert interface, a stock trading keyboard: Unfortunately, expert interfaces are so specialized that they aren't very well ...


0

I would first look at the workflows and possibly see if you can eliminate them entering the time so often. For example if a bunch of tasks come in at around the same time is it possible to group them all together under the same time? Other things you can do to possibly make entering the time less troublesome. Try to predict the time range they are going ...


0

In your situation, i would design this very simple solution by Showing Status at all times A control to easily switch to default and customize settings with single click any time No need of repeating and showing advanced/custom settings toggle bars inside user creation/main task area Use one line to show status if user is using customized settings ...


5

It's best not to reload during a signup process, but sometimes it can't be avoided. There are many signup processes for even very mature sites (e.g. gmail, ebay, etc) which involve page reloads. What issues need to be addressed? Page loads create cognitive disruption to users. While you're filling in a form, the page becomes your universe so a reload ...


0

I might not fully understand your reference to primary/secondary actions but it seems like the users were comfortable with the original color scheme so stick with it. In case you don't already do this I would suggest having a common layout for your action buttons. For instance... With Accept, Refuse, and Correct, a horizontal layout of Refuse, Correct, ...


0

The scrollable “flipper” for one important reason. When in that format, it shows relationship to other data points (the years before and after) and this helps to focus the user’s mind in a time-based thought process, which is the desired cognitive state for recalling and asserting this type of information. Users lose focus or forget what they’re doing; ...


3

In the process of developing a new app (releasing next week), we ran into this exact problem. We originally included a date picker, but went back to the drawing board because we realized we didn't ask the right question. For us, it was straight text inputs, no pickers or options. So, apologies, but you're not asking the right question either. What is the ...


0

I prefer the scroll-able in iOS. A key UX principle is to be consistent with industry standards. Jakob Nielsen had this on his famous 10 usability heuristics for UI design (see "follow platform conventions" Furthermore Most of the time for current dates and birth dates the user wont do much scrolling. You can also put multiple wheels if your date ranges are ...


0

Scrolling from 2015 to some older years can be a pain, I suggest a two digit (not four) entry field. It is the fastest way, and the first two digits in a birth year are unneeded.


1

Indeterminate checkboxes are not a good idea ...but if you must use them, the two common styles are shaded (windows approach) or dashed (mac approach): A key issue with the mixed/indeterminate state is that once the user makes a selection (checked or unchecked), you have to either: Provide a way for them to get back to the indeterminate state (e.g. ...


1

The most common way to represent a multiple state selection with a checkbox is to give it a dash. In the example below: all students have "Lorem" selected, some students have "Ipsum" and some don't, nobody has "Dolar". download bmml source – Wireframes created with Balsamiq Mockups In the case of radio buttons your best bet is to just leave ...


1

I opted to implement a mix between the provided answers. There are now three states: 0 images have been added: 1 image has been added: 2 images have been added: Now there is always a placeholder. The placeholder is the same size as the other grid items and is always at the end of the list so the interface will not change drastically after ...


1

Regarding designing a longer form The problem with two columns forms is users would be confused by the two column layout and interact differently needing them to more time to get the task done. To quote this article One of the problems with form fields in multiple columns is that your users are likely to interpret the fields inconsistently. ...


1

Having inputs on the right side of the tablet that are easy to hit with the thumbs is almost irrelevant, or a at least a pretty low level concern. Users will typically rush through forms to get them over with, and having inputs scattered around the page will take away from the discoverability of inputs and their labels. Left aligned inputs and a scrollable ...


0

i wont use any site or app the forces me to do anything not needed to use it. if i were making this app (and i've stopped using two like this, btw. I'm an iphoneographer, mother of a dev with apps in the appstore, and i create literally 2 to 4k images a month), one would be sufficient. let busy people do one if they want. if the like how it goes they might ...


7

Twitter FTW I've always thought Twitter has the best solution to this. It allows you to hammer out whatever you like, then edit it down to something that fits. It's extremely clear to the user.


1

Don't let user type anything longer than 55 characters, and give feedback on how much characters are left when each character entered . download bmml source – Wireframes created with Balsamiq Mockups Edit: Of course a tooltip informing that user reached the limit would be a nice to have.


3

Instead of showing an empty list, show one with two placeholders that need to be filled before continuing - this shows the user that you're expecting at least two images. As real images are added, remove the placeholders.


1

From your diagram, we can add a simple message next to the 'add bikes' button, stating "x images to go." or "1 of x images added." after an image is added. Additionally, to ensure that the user uploads the correct amount of images, we can disable the save button until the correct amount of images is reached.


4

A simple resolution would be to show a simple descriptive text which tells them what to do i.e. they need to atleast upload two images to continue. Here is a quick wire frame for that. Until the user doesn't add the required number of images keep the continue\save button disabled.


2

The trust is not built at the logi form but before! It takes into account the presentation of content, footer of your site and some associations verifying the authenticity. Depends on business you are operating, one of the biggest trust building factor can be simple login form with links to your public domain content. Like contact details with real address. ...


0

You should ask if the brand name and product name create any untrustworth-ness to user perception. If you clarify brand or product name has not any trustworthy issue, you can try to give "reasoning" or "promises" at the context of login form. "We won't post something to your facebook wall, we promise" - can be nice for facebook social login. "We don't ...



Top 50 recent answers are included