Hot answers tagged

22

I think the only way to warn users that a confirmation will follow, is to use a conventional symbol. Because a standard symbol for this purpose does not exist, you have to establish one in your application. You have to use the symbol consistently in all screens of your applications, so that users will create an implicit connection between the symbol and the ...


18

You can add Step Number to let them know that there are other steps ahead. I have attached a snapshot just for reference.


5

First, ensure that any data entered by the user is being temporarily saved. It's horrible to go to effort of filling out a long form only to have everything erased because a session timed out or you accidentally left the page. Consider using inline validation and perhaps encouraging statements. They shouldn't be patronizing or too chummy. But showing a ...


3

If the address fields are dynamic based on what country you select then I would lead with the personal details fields (name, company, email, phone), and then the country, then the other address fields. It makes sense to lead with country if that determines which address fields show/hide. When the country is changed the address fields below would reload ...


3

At first, I do not recommend the PDF issue. It will add more confusion if added to the data collecting form. It should be moved to another form if necessary, like "my profile" for example. Secondly, the concept of "write the data, go back, edit it, resend , and duplication allowed" reflects a bad system design. If the data needs validation, then this ...


3

Delete is a destructive feature, so if you have not implemented an undo or trashcan feature in your solution, the extra "Are you sure" step is to ensure they really mean to do this, because it will be lost for ever. I recommend you enhance this extra step to explain why you are making sure they really want to do this. You might even want to consider a ...


3

Some recomendations on getting the higher conversion rate with the long forms: Make the labels clear for users. Dont't make them think (a lot), work on the language and tone Group the fields in a logical way. So the users a) focus on some aspect (Address, Contacts, etc.), b) have a rest after filling some set of fields, c) enjoy when some part of ...


3

I think you can get close with just a couple of changes from where you are now. Have a different and informative CTA for the requirements Currently you have 'Save' (local) and 'Save all changes' (global). This seems potentially confusing. If you changed the CTA to something like the following, the user would be made aware that this change is local, not ...


3

For First Layout : If it is a responsive layout, where the Change Language will shift. According to me the second layout will work good. Beause its all in center, User will concentrate only in center he do not have to search for things here and there. Even Google, Facebook have launguage change, at the bottom of the website.


2

The solution can be catered in a slightly different way to solve such issues. A simple layout like this would solve quite some issues. Mobile designs require careful usage of space. Illustrative approach for such can help simplify and beautify app designs. Description about the layout: The social login buttons can be arranged horizontally instead of ...


2

I would consider the type of data you're collecting. If several fields relate (e.g. city, state, country), then horizontally is appropriate (and, in my opinion, preferred as it tips me off that they are grouped for a reason). This would help condense the form a bit and allow a user to keep their hands on the keyboard longer before needing to scroll, thereby ...


2

My understanding is that people visually have a preference towards reading columns or shorter text. But apparently, people actually read better with a little wider text. (I dont know if this is completely true when dealing with forms). (See point 18): http://www.graphics.com/article-old/how-people-read Susan Weinschenk PhD. - Behavioral Psychologist I ...


2

Header If you have a lot of records then probably good pattern is to keep the always header on the top of the screen and records to be scrolled "under" it. Action bar as a footer Then good place for actions and well as save/cancel button is bottom of the screen not a bottom of table. When you select item and scroll pane action bar remains. Multiple ...


2

When do those buttons (Save and Cancel) appear? If they should appear when the user edits the table directly, then I think it would be a good idea to put buttons in the action menu. Save and Cancel are actions too, and the user already knows where actions appear. Maybe you can display buttons always in an action menu, but if a particular action isn't ...


2

Regarding input: do your users really need to type thousand separators manually? If no (which is the most likely case), I would treat both . and , typed into the field as a decimal point and allow only one symbol of that kind for that value. Regarding output of the values: IMHO, it is better to rely on OS formats by default, but to provide possibility to ...


1

For the specific case of item deletion there's a widely implemented that works as a doublecheck, but in a more intuitive way. Windows has a recycle bin, gmail has a trash folder. When you throw things in a trashbin you can still pick them out and dust them off again. Although some systems have an automatic/periodic clean up moment. So for a non-final ...


1

According to me, the order for the country should always be: Country State City Because state and city selection is dependent upon the country. The state field should become visible only if the selected country has states, like USA. If user selects UK, only the field for city should be available.


1

I think modal could be an overkill, as it will take the focus away from the page - and moreover its not justified for something like an edit function in the context of the application. Take a look at the below suggested flow: 1) Initially, the user is visually shown which are the editable vs non editable categories. As seen, Reqs are shown to be editable, ...


1

"The earlier system just had all fields editable at all time, which avoided this problem - is that still the best way to go?" Yes. What is the difference between the fields of a requirement to the fields of its evaluation? - None. The evaluation fields are also "saved" locally and you do not have 'Save' and 'Discard' buttons for them, and that's because ...


1

What is the ultimate goal for the user? Evaluate the Law? Edit the Requirement? Edit and Evaluate? I suspect the ultimate goal is to just Evaluate, and if so this should be the primary Call to Action trigger. I also suspect that Editing the Requirement is an occasional supplementary activity so it's trigger needs to be very different to the primary ...


1

C#and javascript both have a few good tools for converting number formats... if you can get the country/language iso code from the user or site (eg "de-DE" for Germans), this is easy to do... C#, for instance, has the CultureInfo class for this purpose... User goes to your site (eg. with "/de-DE/" somewhere in the URL) User enters his value in his format ...


1

One way to resolve this is to not make people enter decimal periods. Reject any non numeric input and let people choose the unit (meter, centimeter, etc). For dates, use a date picker rather than a textbox. The risk of using user's locale setting is that if people are sharing information (e.g. in support forum/wiki) about how to enter fractional inputs, ...


1

It depends on the visualisation of the data. Will it be shown in a readonly form or in a card or list view? I use it like this for a form: In a cards view the empty fields are just not shown:


1

I think the way you've displayed it will work properly and people will understand it. However, I would suggest to remove the save button, because there won't be anything to save in the first image. Make this button the "change information" button, and once a person clicks this button, you change it to "save changes". Not every user might notice the fact ...


1

Okay, this answer may be edited in future depending on what answers if any I get to my questions in the comments. But I see a few possible solutions if the worst case scenario is that end users can move things around as they please. These are as follows: 1. Do nothing (well, sort of) You could just design the form with the fields exactly where you want ...


1

Well, tag is used to group related elements in a form - so yes. You can also take usage of legend and label inside your fieldset, i.e.: <fieldset> <legend>Date</legend> <label><select><option value=".....</select> Day</label> <label><select><option value=".....</select> ...


1

Obviously, with registration, there would be a bit more fields to fill in, and the user would have to scroll down to register using social media, even though we would prefer it if they would register using social media, so that we would be able to retrieve more data about them On mobile apps, user should be able to perform all operations quickly be it ...


1

It all goes with your business needs. If you want your user's information, then it would be better to include your own login first, and social login as last resource. If you want less friction, user's information is no problem for you and want just some kind of simple user identification, then give preference to social media login. Additionally, I see ...


1

If you prefer users to register using social media, then you should definitely put those choises on top. It will gently push them to use it. To me, it is confusing that you call the manual account creation "Mobile, Username or Email". I would just let the user fill in email (or username if that suits your system better).


1

Whether you have a typeahead control or not is purely anecdotal for your question. You don't need to (and furthermore, shouldn't) clear all. Instead, you should UPDATE form info based on the new client's variable. Since as you say, this field controls the price fields, then a simple update of the price fields should suffice. Like so: if $client --> ...



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