I think that in this case graying out the unselected data is good. You don't need more space, so hiding them is not needed. Additionally as you said if you gray them out, the other columns won't change their location.
Tables usually adjust and show only the columns that user have selected it is helpful in most cases. As I said it's makes space for the ...
Do not recall if I have seen this type of design around or not, but I would implement something like this.
The user clicks "New Field" and chooses the desired predefined data type from a drop down (this also adds a new color coded selection to the sample text).
Couple of notes:
If the data types have a fixed character length then the adjustment handles ...
I don't think there's the One True Way to solve this, so you can choose either behavior for your application. That said, the behavior should not depend on what kind of object user would click, because consistency is key!
(There is a reason why "Strive for Consistency" is the very first of Ben Shneiderman's Eight Golden Rules of Interface Design.)
It seems you may have two issues: which segment is selected, and what can the user search on, especially if the user comes with an immediate intention to search.
In your mock, you have two different data sets, but you're using a control placement way to the right of the data, so to see at a glance which is selected, my eyes have to look right.
The search ...
It's definitely a challenge with toggle buttons. We had to use them in one of our projects and we assumed that indicating the active state by changing the background to the primary colour would be enough.
However, user interviews showed us that we were wrong. Whenever we had a collection of three toggle buttons, the user did not seem to be confused. When it ...
Maybe you could use a little gamification.
First, you have the user sign up only with the essential info, so that they don't leave the platform before having finished to sign up.
Then, you can encourage them to complete the missing info after they created the account.
Option A: give the user points for completing sections. This however makes sense only if ...
You can try removing the background color of the button to indicate inactive state. Having color on both the states is confusing because they both stand out equally. To further improve, use bold typeface for the active state.
The less friction you can put in front a user who wants to register with your site, the better. If your onboarding process is too complex, you will lose users.
I would get the user signed up with the absolute minimum of information necessary, then maybe on subsequent visits give them reminders to fill in the rest of the data. For example, "If you are not ...
I suspect the answer, as is usually the case, will depend partly on your users themselves and their preferences for keyboard input vs. mouse input.
Atlassian suite (e.g., Jira) has a process sort of like your Example 1 flow, but with some important enhancements. First, when you start typing a name, a suggestion box will appear below the field to help you ...
The most important thing is the user knows the state of the system "Can I perform an action and does the system tell me something is happened"
With the save state disabled you're actually telling the user the save state is up to date and everything is saved. This is a good thing. As long as the user knows that.
With the second option as long as you ...
It depends on how frequent your user will be made some changes to it. But you can enable the button at all times and once the user applied some changes on it, make sure to inform the user that it is saved successfully.
Save changes - Primary name of the button
Saved - Button name will change after triggering the save changes button and after a few ...
Yes, the save button should be disabled if there have been no changes made.
It's best if the button's name emphasises the fact that it saves changes, e.g.: Save Chages and it's accompanied with a Cancel (or close) button, so the choice is obvious for the user.
Unless the changes always applied successfully (e.g. not as separate HTTP calls that can fail) ...
I don't like option two if it's running on many types of hardware that you don't completely control; sometimes applications run slow on overloaded hardware / bogged down OS/trojans - if it does, and you miss the brief time the save is active, you don't know whether you have saved or not. You need another small message that says: last saved (timestamp) / not ...
It looks like it should be a single drop-down multi-select list that contains only organisations with the related countries, e.g.:
Organisation and its Branch:
Two drop-downs seems excessive in this case.
If the user starts to type the name of the country, the suiting options should ...
One approach is to have the default filter set to the most common search, and have users be explicit about the starting dimension.
In the sketch below, I'm suggesting some friction up front aiming for more clarity about the dependent relationships. You could make them explicitly select the starting search:
By country (which then shows only the Orgs)
IMHO, choice 1 is bad. I work in IDE which does not reinstall the executable on remote server if it knows it's already there. If that file is deleted, any attempt to run/debug the executable fails even right after explicit "installing". Please don't do this.
Edit: I mean that if your saved data is somehow deleted or changed outside your program. If I don't ...
Instead of giving the character for ‘two’ as part of the question, could you include it next to (or as part of) each answer?
That would take a little more screen space, but seems far clearer than the other alternatives, with less opportunity for confusion or misinterpretation, even for people not giving it their full attention.
You may need to add any signal (icon or graphic) showing where the beginning of the area to be completed is, in this way you will avoid leaving orphan the incomplete areas at the beginning of the paragraph.
You could suggest a shape that matches the choices below, and use a color to suggest interactivity.
Then, to match that, make a hover state that matches the area above:
Another slight option is to treat it like a drop area, and just have the space, but no ellipses:
Yes, this type of test would be a "between-measures, within-group experiment". You are testing two conditions (old design and new design) within the same group of participants.
Aside from getting user ratings, you should set easily measurable tasks such as time-taken for a task, accuracy and success rates, so that you'll be able to reach a conclusion.
Yes, test both ideas.
When testing different versions of the same flow, you'll find the sequence of exposure to designs might play a role in results. To mitigate this, I would suggest splitting the testers into two groups. Take the first group through the old version, followed by the new one and the second group through the new version, followed by the old ...
This isn't so dissimilar from A-B Testing, where you test two valid or "workable" options to see which works best for users. It'd probably be a fun thing to test, but there's a very big caveat here.
Long-time users will be used to the old design, and while some will invite change, others may think the old one is better or easier for them, no matter how ...
If there's a concept of default product, have that selected (and moved to the top). Or, just have the first product selected. I don't see any viable reason for not having anything selected.
Clicking on the product shouldn't enable/disable as it isn't clear what the checkbox does. I would refrain from using the exact same pattern as the browser because ...
My guess is it would have to do with usability.
In the case of the apps using top navigation bar (which, by the way, is also a recommended navigation pattern for Android Apps), usability may be better off by having the "lesser used" actions far away from the user's thumb. By doing this, they free up the space for users to swipe or choose any of the more ...
With SUS, you have some room to play around with the words without effecting the results too much.
For example, you could change it to:
I think that I would like to use this service frequently.
I think that I would like to use this product frequently.
Whatever works in your context.
This is backed up by this article.
Small changes are less ...
Did you get any feedback on that question? In my experience people take questions like this usually abstractly and answer them without thinking that they won't use it frequently.
You are not asking about the task, you are asking about how they went through with the task and the walk-through might be pleasant enough to answer that as "Strongly agree". I ...
You shouldn't use tabs for a step-by-step user flow. Use a progress indicator and label each step as step 1/2/3 or with arrows.
In addition to the main user flow, if you need to let the user browse info while they maintain the current state in the flow, this should be activated by a corner button or bottom tab. So basically, the step-by-step flow belongs to ...
As a former student, I would much prefer that the homework assignment details would open in a new page.
The benefits of opening in its own page are numerous:
It helps the student focus on one homework assignment at a time.
The student doesn't need to be concerned with other assignments while working on one. It is likely that the student will complete one ...
Using an iframe to load critical information or action buttons would lead to such issues, whether it is a third-party screen or not. But, that is an implementation issue (and so is the solution) so, I will focus on what could be done to improve the user experience.
1. Capture data from the iframe and load it inside the app
This is the best option, in my ...
TL;DR: Functionally, there should be little-or-no difference between top-level containers1 ("groups") and lower-level ones. However, it may be useful to allow users to give semantic labels2 to different containers, and – ultimately – to use those labels to affect how the UI displays containers and their contents.
I think part of the problem is that notebook ...
From what I understand, only the selected date range is editable. In this case, I would remove the date picker / calendar icon from the other rows.
In the current design, it's not immediately visible which date range the dependent fields are associated with: you could highlight the background of the selected date range and the dependent fields in the same ...
Would like to propose below option only if 1. You have some space (possibly towards right side of screen) and 2. Its useful for users to review their existing selected items with different filters and choose items from various filtered results.
Solution: As soon as user checks an item, move its small view (icon or fewer details than whats there in search ...
I would personally reselect the necessary items. Say, A, B and C are selected. Then the filter is applied which means now only A and B are visible. If so, I will say, display A and B as selected. If the filter is reset after that, keep only A and B as selected. C lost selection once the filter was applied, so after resetting filter, C must be selected again.
It seems like selecting rows is a relatively easy task here, and that automatically deselecting them has a pretty low risk in regards to frustrating the user. So, I think you’re right to deselect rows when a new filter is applied. It’s simple for the user and easier for you to maintain moving forward.
If you retain their selection, you’ll need to show the ...
It looks like a responsiveness failure to me.
The result appears like a technical glitch - which it is, on the device surface - but the first step toward a fix may lie in more explicit UI spec instructions on dev implementation, which I'll get to.
An iframe is essentially a window to some other content embedded within a window.
A good and frequently ...
Make a left hand side list menu for each of your tab items. And clicking on list menu item will open respective tab content. Its just a vertical arrangement of tab, but to ensure tab titles (now list menus) are not written vertically.
You could include a tab bar with arrows to scroll left/right, and a dropdown list to provide quick, scrollable access with many items, as well as any functions like 'close all'. This is used by Firefox:
It's possibility to add UI controlers, which changing the view of displaying product:
In the case of single product page - it's not a clear and universal solution.
It depends on a lot of variables (like industry, customer type, amount of information needed)
Suggestions and ideas:
highlight and raise a section with warehouse information / availability