Purely as a matter of approach, I think that creating a custom UX is by definition supposed to provide better UX than using spreadsheet software, precisely because your UX can be tailored to your needs and users, while spreadsheet software is spreadsheet software. Not to say that spreadsheet software is bad (I think that Excel is a wonder of creation), but it's extremely generic and meant to fit the lowest common denominator of countless different use cases. Whether you have the resources to go ahead and really design and develop the perfect UX for your use cases is another story altogether. A big caveat to the above is that analysts might be so used to Excel that initially it would be the best way for them regardless of how great your UX is, but I think that it's a matter of time and if the tailored one is indeed better, they could be won over. And as for designs, this is one potential direction you could explore (blue=selection, single-cell edit is inline)

Don't reset the partial field on blur; put the field into an error state and call attention to it. Sometimes users have partial information and they want to finish the larger task (getting through the form) before coming back to it. An example would be when the user remembers the first few digits of a credit card number but needs to get up and grab the credit card to complete the field. Destroying the data they've already entered could cause annoyance. Your engineers should prevent the user from submitting the form until all error states are cleared.

You can use a range selector like https://codepen.io/andreruffert/pen/nkbKv with a result viewer where the "no experience" is when applying the default position = 00 - 00 RangeSelector is a "double slider" control for range values.

Some general guidelines and questions that will impact what the best solution will be: Are all the inputs relevant for all the users? If no then try to only show the ones that specific users needs to see. If yes try not to hide any important fields. Hiding functionality is rarely a good idea, both from an accessibility point of view and it can also introduce stuff from a validation point of view. Are the inputs related to each other? Then one solution could be to split them into steps. But then they need to be ordered in a logical order. If it comes down to one of the aims of form is completion, having multiple steps can create a feeling of wanting to complete the form if started.

It's likely a combination of several components, because there are a few tasks here: Search for each user that is needed by entering a partial or full name Select the correct user from a list of options Collect the selected users for the next task There are two products that do this pretty well, Microsoft Office (Email) and Microsoft Teams. Here's how they do this workflow: User initiates a new task (email or chat). A "To" box appears to let the user know that names are the expected value. User types part of a name into what is essentially a Search box. The system returns a brief list of names, pictures, and other information that allows the user to make the right decision. NOTE: The system is optimized to return suggestions based on relevance to the user, often based on history with the potential recipient. User selects the correct option, which becomes a chip in the Search box. It can be removed but not edited. Repeat steps 2 - 3 until all desired recipients are selected. Finish the task that will engage the selected entities. This requires the user to know at least partial names of the records they're searching for. It doesn't cover use cases like "add all people on Mark Farrington's team" or "Add all quality assurance engineers". If your user might not know names, you might have to allow searching/filtering with other criteria.

A text field can have a round shape in the context of buttons, but making them both equally round would be a departure from tradition which is usually to differentiate text-entry components from buttons. Any time we depart from norms in UI we are taking risk and sometimes it can be rewarded. In the context of an email application users will no doubt adapt to differences in the styling of elements, and that will be okay as long as: the elements are established consistently throughout the app (learnability), provided the app is used frequently enough by users so they don't forget (recall), and provided the application is not mission-critical context (severity). In terms of screen scanability, the eye will have to stare a few ms longer to make out differences between a text entry component and a button because you have removed said shape distinctions. Taking small risks here and there is common in design and might be worthwhile if the user's wholistic impression is your app is simple and approachable (usually why we tend to make things rounded). If that's not a risk-goal you want to take up, you can save up the risk taking for areas that drive home the core value proposition of your product. In the end it's a judgement call only you as designer can make.

I'm not sure if I understood your question correctly but here is how the digital document sign app we are using looks like:

The problem I see using checkboxes is that while it allows choice selection, it does not offer a visual representation of: The type of action being performed The value increasing The start / end location of the selected values There is a https://moodle.org/plugins/block_completion_progress that allows to select steps in an intuitive and visual way within a progress bar: With an adaptation of this idea, a quantity bar can be made with the possibility of selecting / deselecting each of its steps:

My question is this: If this is not a modal, what is the difference between Reset and Discard? If this were a modal I would expect "Reset" to take back all the changes and not close the modal, and "Discard" to close the modal with no changes saved. I don't think making the user click an "Edit" button is a good idea, if you want that to be able to track any changes made, you can also track any clicks made on the inputs to the same effect. You can also make minor UI changes to highlight unsaved changes (Bold texts, highlighted input boxes/checkboxes etc. The main problem I see here is that the user may be confused with what to expect from an action / what they should do next. I would minimize the required decisions and make sure the buttons are always visible and use slight animations to guide and remind the user to save the changes when you detect any.

Structuring the two sides where the form fields are in the same positions on both sides, as you have shown, should be sufficient to allow the user to compare the unmodified to the modified data. Highlighting the modified data is good to help indicate that there has been a change to the field. Assuming that all of the form fields on the right side are editable, I'd recommend that you remove the grey backgrounds from the right form. Typically, a grey background is used to show a disabled, read-only input field. For example, if I was trying to update the Email field, I might see the grey background on both sides and think that I am not able to update that field because it appears disabled. Additionally, you can lighten the left form's font color slightly to more clearly show that they are actually read-only fields, and the editing occurs in the right-side form. In the end, you should have something like the following, where the two sides are more clearly representative of read-only and editable forms.

In Material Design, they're called https://material.io/components/chips#types . They're driven by terms entered into a text field.

So, I'm wondering... Is the time frame (eg 07:00-10:00) more important than the length of the session (3 hours)? I've prepared another concept of time tracking, in which the user's task is to report how long an action took, as opposed to when it was.

You already answered your own question. Keyboard/screen-reader users will need to step out of the search field when it was focused automatically to make use of other ways to navigate. Also on mobile, Google doesn't auto focus on the input field. The reason is simply to not directly popup a keyboard since that would be annoying. If you want to make your main search field accessible use the ARIA attribute role="search" on the form ( https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/Search_role ). This will make it a landmark and easier to find and navigate to for screen readers. Use that landmark only once.

A couple of points are worth mentioning here. Firstly, the general consensus is that disabling buttons is bad for accessibility reasons https://www.smashingmagazine.com/2021/08/frustrating-design-patterns-disabled-buttons/ it can be done, but personally, I'd aim to avoid it. Secondly, in terms of a dirty state changing from and then back to the original value should likely not result in a dirty flag being set. You say: But I don't see options that compare the original and current value of the input to check if it's actually different and needs to be saved. I'm not sure I see this in practice, most solutions will compare to the initial values (and keep those in memory/state) to establish if the form or field is dirty (e.g. Formik https://formik.org/docs/api/formik ). Additionally, if you were writing this from scratch you'd want to use this pattern.

1) Select box, with an "other" option, followed by an input field IF they selected "other". 2) Write some back-end code that merges values that are already there upon submit. 3) Alternatively, try something like the chosen jQuery plugin. It's a middle ground, that looks like a drop-down, but allows "searching". The first option won't solve it entirely but at least it'll cut down on the number of duplicates because you ask them to select something from a list, with "other" meaning "something that's not on the list". This is as opposed to what you're currently doing, asking them to "write first". Also note that most people (kids and the elderly especially) won't be able to blind-type, and thus will have their eyes fixed on the keyboard while typing, and perhaps even hit [return] (most often submitting the form) before even looking at the screen. And please, do the world a favor, and don't put the submit button underneath the dropdown. They won't be able to click it if they go to "University of the South" instead of "University of the South West".

It seams to me as though two thought pop out immediately: +/- buttons Basically I think you are asking the wrong question for this one. You have phrased it rather like you are not sure if you should allow the user to pick the fare or not; I think that is a separate - entirely business related decision to make. I do think that the +/- buttons are a bit vague, you need to explain this better; why are they able to change the fare? Most users will be used to seeing a set fare. Also below this you have "Estimated Fare - surely this is the same as what I have just changed? I am sure it is clear to you, but it is a little confusing to fresh eyes! As for the UI I think you have duplicated some information, or split it perhaps a little bit unevenly. On the first screen you have two separate addresses, try bring these together, or if they are the same address, scrap one. Map UX With regards to the map; I would scrap it. This isn't because for the purpose of the UI but rather speed, your users could be in rural areas (or indeed driving around the million roundabouts that are in Milton Keynes :]) and thus need the screen to load with the minimum data requirement for the best speed. Thus I think having the map here could cause a lag and that would be very bad. As for your actual question I would lay out the UI a bit more like this (sorry for the crude Photoshop-ing) and I know it is different that is just my experience in simplifying things giving better results. Overall it looks good though your plans seam to be fairly well thought out so best of luck in your project!

It should be a short hint (in you example "Type your username") rather than an example data (ChuckNorris). The reason for this is that Placeholders have the potential to be mistaken for pre-completed fields, especially at a glance. If you have placeholders showing sample data then that increases the possibility of people thinking the field has already been filled in. The current W3 Site gives the following advice: placeholder = string Represents a short hint (a word or short phrase) intended to aid the user with data entry. Note: It does go on to say: A hint could be a sample value or a brief description of the expected format. For a longer hint or other advisory text, the title attribute is more appropriate. However this is incorrect and is being updated in a future version of the W3 spec, partly because the attribute is no longer considered appropriate or useful for these situations. The updated advice is (from the current draft): The placeholder attribute should not be used as a replacement for a label. For a longer hint or other advisory text, place the text next to the control. Use of the placeholder attribute as a replacement for a label can reduce the accessibility and usability of the control for a range of users including older users and users with cognitive, mobility, fine motor skill or vision impairments. While the hint given by the control's label is shown at all times, the short hint given in the placeholder attribute is only shown before the user enters a value. Furthermore, placeholder text may be mistaken for a pre-filled value, and as commonly implemented the default color of the placeholder text provides insufficient contrast and the lack of a separate visible label reduces the size of the hit region available for setting focus on the control. So, if you're going to be using Placeholders (and I'd probably think carefully if you are going to) then make sure it's a hint and not an example. But make sure you surround the form with the correct markup too (correct label and descriptive text if necessary) and style the placeholder so that it is clearly a placeholder and not a piece of data (but still with enough contrast to be accessible - which overall is no mean feat!)

I have modified the Float Pattern Demo to work on a select box. First things first, I added a State wrapper, label, and box to the HTML form with all the states in there as options. I included a default item with the text State and an empty string for its value. This way I could easily tell if it was selected vs an actual state option. Next, I modified the CSS by putting in 2 styles. option { color: black; } and .watermark { color: #aaa }. The first one defaults the select options to black. The second one is used to change the option color to a gray, just like the watermarks on the other input elements, based on the default item being selected or not. The last thing I had to do was modify the jQuery to hook up the select box. So the way this originally worked was that it bound a function called checkval that would toggle the visibility of the floating label and attached listeners to the keyup, focus, and blur events for all input elements. I needed a way to hook in the select, so what I did was modify the selector to include select, so it becomes $("input, select"). The next thing I had to do was attach a specific listener for the select change event, as that's the one that gets fired when a selection has been made. Then all I had to do was write some code that would toggle off and on the watermark class I made earlier based on whether or not the currently selected item's value had a value or not. After that, it simply makes a call to the checkval function to toggle visibility on the select box's floating label. I haven't tested it in all browsers, but seems to me that it's identical to the other floating labels and keeps the user experience consistent and clean. Enjoy! See working CopePen demo HTML First Name Last Name City State CSS .field-wrapper { position: relative; margin-bottom: 20px; } label { position: absolute; top: -13px; left: 0; font-size: 11px; color: #aaa; transition: all 0.1s linear; opacity: 0; font-weight:b old; } label.on { color: #4481C4; } label.show { top: -15px; opacity: 1; } option { color: black; } .watermark { color: #aaa; } body { padding: 20px; /* the following line fixes a blink in chrome https://code.google.com/p/chromium/issues/detail?id=108025 */ -webkit-backface-visibility: hidden; } JQUERY $(function () { var onClass = "on"; var showClass = "show"; $("input, select") .bind("checkval", function () { var label = $(this).prev("label"); if (this.value !== "") label.addClass(showClass); else label.removeClass(showClass); }) .on("keyup", function () { $(this).trigger("checkval"); }) .on("focus", function () { $(this).prev("label").addClass(onClass); }) .on("blur", function () { $(this).prev("label").removeClass(onClass); }) .trigger("checkval"); $("select") .on("change", function () { var $this = $(this); if ($this.val() == "") $this.addClass("watermark"); else $this.removeClass("watermark"); $this.trigger("checkval"); }) .change(); });

Best practices are associating error messages with form fields. download bmml source – Wireframes created with Balsamiq Mockups These examples are just a few ways of displaying error messages. As long as the error is contextual and can provide feedback at first glance, there shouldn't be any problems. You don't want to have users dig to figure out what the problem is, because that creates a barrier on forms, and it wont be easy to scan. Additionally, don't confide yourself in a space that would more than likely not be the case for some users (unless you're in a controlled environment where you know everyone will have the same sized monitors, but even then, you never know what sizes the browser is going to be). After working for an agency for a while, I've realized a lot of clients/developers believe that users don't scroll their website if elements are not on the top of the fold, however, research and continuous proof points to the contrary: Users scroll. Don't be afraid of below the fold elements.

If you're using a small width then simply use the back button type functionality. Place a back button in the top left corner with a label next to it: download bmml source – Wireframes created with Balsamiq Mockups