New answers tagged

0

Speaking from the user perspective, I think it makes the most sense to complete the first booking before starting to provide all the info needed for the second booking - unless I wanted to set up a "regular" appointment, like every 5 weeks please set up an appointment with me with Barber Joe Smith for 11:30am on Saturday. In that case an option to repeat ...


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, ...


0

This is a more common problem than the number of questions that have been asked about it, so I think it is a good place to summarize a couple of key points that may help you to determine what the best combination of strategies might be: Labelling of the call-to-action: the wording that you use can play a small part to address this issue. I know that people ...


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

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 ...


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.


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 ...


0

The solution I would use here is fairly simple- pull out the nested edit unto a modal window. I've also made some modifications to try and address some of the slight UX issues in the original mockups. download bmml source – Wireframes created with Balsamiq Mockups (Pretend that the above mockup is presented beneath the grey overlay) ...


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.


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 ...


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 ...


0

What you could do is summarize the filled forms on the right side of the screen, in a window which scrolls along as you scroll down the form. See this form on a dutch website to get a visual of what I mean. It shows things you've selected or filled in, and you can also press "change info" in the windows once you've filled it in and have scrolled down. What ...


0

Having literally designed 100s of forms I have to agree with DrWael's answer - forget the downloaded PDF option. I also agree that the data shouldn't be written until it is ready to be written. What I have found works very well in most cases is once the form is complete and ready for submitting, it should present the user with a confirmation screen. I ...


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

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 ...


1

There are serious usability flaws in the placement of your buttons that none of these answers address. Your Next and Previous buttons are too close together. Users can click one when they mean the other on accident. You should use directional mapping and place the next button to the right. This is what users expect and are used to when they paginate and it ...


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 ...


0

On the input side I would leave the thousand separator, and allow only numbers and decimal separator based on the language settings of the current user, but store the values in a unified way eg: allow 1000.0 (as 1000) and store as 1000.0 allow 1000,0 (as 1000) and store as 1000.0 On the output side you can again rely on the language settings. And can ...


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, ...


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 ...


0

As a user i would feel more comfortable if it the form autosaves the things that i am typing in every field and the publish button stays always there and after i have finished by pressing it, my changes get published. Or you can change the button save to say draft and stays static, when pressed it saves the draft.


0

The idea of using hidden fields is actually nothing new. I have used this approach many times over the past decade. I've used them for the same purpose as you're doing, but also for doing what they are most commonly used for (passing data without the user being aware of it - not for any sinister purpose, but usually to avoid confusion or to provide a cleaner ...


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:


0

I'd add one or more of these changes to make it more clear: make the three new textfields and the button appear in the rightmost part of the screen, just where the button "Change Password" disappeared; add a "Save New Password" button, just above "Cancel"; deactivate the "Save" button after the user clicked on "Change Password". Reactivate it again once ...


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 ...


0

One reason that I've had to implement restrictions on spaces and dashes is that to get a mobile device to pop up the numeric keyboard instead of the full keyboard, it's useful to have a pattern="[0-9]*" property for greater browser support. For the moment, this is part of the only cross browser solution.


-1

I would suggest to display the dropdown at the bottom of the page because: - changing language is not the primary user task for this page - the login form has a super low learning curve, most of the user knows how to fill-in such form even if is not written in his own language - as a secondary task is not overloading the user with extra information In my ...


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.


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 ...


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 ...


0

The possibilities that I can think of : You can place all your actions on the fly that is, as and when you select a row or a cell have the actions dialogue box appear on top of the selection. If you have a fixed height for the table then it makes sense to keep all the actions at one place.


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 ...


0

As a user, I dislike multi-page forms. When you fill in a form you are usually giving someone else information about yourself. If a question you would rather not answer is on the last page of the form, you have already unnecessarily submitted a great deal of information by clicking at the end of each page. If a whole form cannot be viewed without having ...


0

It seems as though the main objectives you have are to get users into the system with the hope that when the product will support them, they will actually use it. So, my advice would be to: gather the absolute minimum amount of information required to create a user (perhaps username/email/mobile number and password) begin with most restrictive questions ...


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 ...


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 ...


0

Although it may seem useful that inline validation for pre filled form fields is ok, it depends on the kind of field that you are addressing. If the address fields are not critical to further information from the user, then you can use the green validation. Else it might be better to let the user validate the information.


0

Tabs are good Having persistently available tabs supports the idea of recognition over recall. It's theoretically harder for a user to forget language n when it's sitting right there in the UI. But not here Tabs should be relatively few in number (I like 3-7). Any control in too great a number can become noise and users will inadvertently block it from ...


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 ...


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> ...


0

Yes fieldset is better option as it allows you to group set of fields and also allows you to mark up your data.


0

It's better to have submit button at the bottom. There is no point having two buttons on same form. The bottom button will help user to fill out all the necessary details present on the form as it is scrollable.


0

You'll find that most questions on UXSE regarding implementation of design concepts are difficult to answer without the context, but the principles used to come up with the design decisions shouldn't vary too much. So here's some things for you to think about to guide the thinking process: What is the main purpose of the preview? Is it to verify that ...


0

Yes <fieldset> should be used for grouping inputs for text, radio-dials, checkboxes and other related content that should be grouped together so this would include both input and select elements.


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 ...


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 ...


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).



Top 50 recent answers are included