Hot answers tagged

28

From my experience, the answer is... It depends! I work for a recipe site and we launched a new site last year which had a whole redesign. We used to have a smaller search box and users interacted with it completely differently to a larger one. Looking at the data that was captured on peoples searching terms, the big change was that when they had a smaller ...


5

Primary factors 1. Average length of expected search terms The visible character capacity of the input will influence behavior. In my tests, users will instinctively limit their entry to the available length. This is true even though the input will support typing beyond the field boundary. I've tested slight variations in width where a known norm was ...


3

If you want to avoid confusion, you could display an error message below the entry box (or someplace else) that they tried to add an illegal character. This is preferable to letting them enter illegal characters, which would lead to more problems and them wasting effort on having to reenter.


3

You could indicate lines separately. Also, you could try showing a visual marker for lines to indicate there are only 10 lines of space. Here is a quick sketch -


3

About 4-5 years ago, I was working on the redesign of AOL Canada's homepage which, at the time, featured a gigantic Google-powered search bar in the header. The search bar was approximately 800 pixels wide, running almost the entire width of the page and it had "Type your search here" written inside the box. This seemed like an overkill to me so I proposed ...


3

Is there a standard size for search boxes? - NO But should we keep a minimum size ? YES Search boxes can be of any size , as long as user can enter the query and perform a search without much hassle. Most commonly used sizes Having said the above , although not a standard Internet giants such as google , Quora , Youtube etc use search box size greater ...


2

Straying away from the UI design question for a second, I would suggest making sure that it's clear to your users what the relationship is between the size names and the numbers. If the sizes are supposed to map to numbers, this mapping should probably be explicit, otherwise users (especially inexperienced ones) might be confused by the fact that you're ...


2

I'm not sure when this section was added, but currently, the specs do have a short section about required fields: To indicate that a field is required, display an asterisk (*) next to the field. At the bottom of the form, include a note explaining that an asterisk indicates a required field.


2

Some unknowledgable guy have done this, as a UX designer you will see a lot of silly mistakes like this one. If you look it from a cognitive science point of view, the user will waste a lot of time visually searching which input is active and which is disabled. In your case the developers have violated Norman's usability heuristic of "Recognition rather ...


2

Here's a quick sketch of something you can try: You can add multiple websites and hierarchies and make the location field specific to that combination of website and hierarchy. You can also individually close each field. I think it's important let users toggle between multiple combinations that you have, which could also be done easily in this ...


1

There are a lot of different considerations involved when you are talking about the 'best way' for a user to enter a value, especially when you have many fields and many line items to enter. So rather than to provide an answer, here are some factors that you should take into consideration: Are you aiming for accuracy or speed because what you gain in ...


1

In order to allow data to be entered quickly, I would recommend allowing keyboard input, much like an Excel spreadsheet. Pressing enter or tab should advance to the next box to reduce the need for the user to switch between keyboard and mouse. I would however recommended including up/down buttons in the "goals" and "assists" boxes, to make it easy to ...


1

Like JDanniel Pacheco, i think the best solution would be to group the possible options. But I would go for something like this: Additionally, you can let the user maybe enter the filter themselves like:


1

I think you're on the right track but what's missing and what would make this really useful is for the design to empahise key metrics I've attached a comp This is a pattern I've seen elsewhere and addresses the use case "I have a loan amount in mind and I want to see over how many months I would need to pay it back at a rate I can afford" and brings the ...


1

The search box should be a size that reflects how important it is on the site in question, or how much you think it should be used. If that is too small of a size, let it expand into a usable size when focused. Apple.com has a very small search field, because they probably want users to look around, rather than go directly to the product they were looking ...


1

Your idea is a good one: in situations where you have a hard requirement on an input, make it impossible for the user to make a mistake. I've used a combination approach to good effect. If the user presses a key for a disallowed character: Prevent the character from being added Display a message, clearly tied to the field ("Oops, please enter numbers ...


1

I believe that your search input can't be too large, as long as it looks like what users are accustomed to, for example Google search input is 60 characters long. If your search box looks like search box and it is not to narrow everything should work as usual. Anyway it is always a good practice to test it out.


1

It's important that each pairing of selects has a parent label to bind them. A side benefit of this is it provides you a full line width – it could actually wrap to multiple lines and still work property – in which to explain the purpose of each grouping.


1

It's helpful that you grouped optional information together and avoided the annoying red asterisks. However, why repeat "(optional)" for each select? Group them as optional under a single headline after required fields, thus reducing cognitive load and length for the long labels.


1

Option 2 is the clear choice. The field labels need to read as labels and not data right from the start. In options 1 and 3, before a selection is made, the labels are indistinguishable from data. Additionally, it is important that the labels remain persistent in style and location to avoid confusion, unnecessary learning, and a sense of instability. Once ...



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