I think Steam just haven't noticed this problem.
Here are some reasons to put the logout button at the bottom of the dropdown:
Avoid Accidental logouts - as you pointed out putting the logout at the top of the list could create accidental logouts for users that are used to double clicking on elements.
Follow standards - when browsing the internet users ...
Note: This answer is a frame challenge.
The checkbox should not be there at all.
According to your screenshot, your users use your search engine to find a solution to their billing problem.
You write that your users "weren't compelled enough to select [the checkbox]". And why should they be?
They have a billing problem, and so, their number one ...
Make it harder to find destructive buttons
If you do need to include destructive buttons, you should definitely
find a way to make them harder to find than the primary action button
Best practices for buttons
It's very important for businesses today to keep the users engaged with their products, and no one wants to give them an easy access to the ...
I don't like tree views, but sometimes they really are the most appropriate widget.
Before you write the tree view off, it's worth thinking about whether it can be redesigned better for tablets.
1. Issues with tree views
The drop-down icons are usually too small. They're hard to click even on desktops, let alone on tablets (see Fitt's law).
Idea Can we ...
Think about each menu item as a task. You can perform tasks sequentially, like task1, task2, task3.... taskN . Which would be the very last task you can perform? Answer is easy: logout.
By adding the logout link at the bottom of the menu, you make it harder to accidentally click that element. See graphic below:
Once you open the ...
Try using actions that represent a clear choice between two outcomes. Phrase in the form of a question or a command to address them directly.
Your question is about graphic emphasis, but I'm suggesting rethinking the checkbox and the writing you have.
A checkbox is associated with a setting or configuration. Here, you're asking the viewer to leave an ...
Consider panels that come out from underneath each other to reflect the hierarchy in dimensions. The top is some major classification that you can still trace back. As you go deeper into the hierarchy previous panels slip off to the left. You can go back up the tree by swiping them back to the right.
When you finally hit on an option that has no more ...
I have not seen this pattern employed exactly as you describe. My relevant experience in information-rich webapps stems from enterprise health-monitoring and deployment software, which has a deep navigation hierarchy.
In my opinion, the left-navigation and the main content should not both employ accordions.
Left hand navigation is typically vertical, and as ...
When designing for presentation of information, it is important to try and fit the interface as closely to the underlying data structure and the relationships between the different sets of data as possible. In general the aim is to make the relationships as simple as possible, and it might mean also using a combination of data structures if it makes sense to ...
Yes tags can be hierarchical and there is actually a lot of (not yet widely recognised) potential in it.
Although some people (probably like the question asker) have been curious and/or after hierarchical tagging for years, the reason it is not present on the CMS market now is more because of technical obstacles rather than not seeing point in it. With pure ...
Another option is to use Miller columns, which is essentially a treeview flipped around and structured in rows.
This is a rather common approach in file organizers, but you may find it a little bit tricky when there are too many levels of hierarchy.
You could also look at an organisational chart or graph that is commonly used to represent hierarchy within ...
To my understanding, the log out button is the button in the dropdown that has a different action than the rest.
The rest of your menu account details, preferences, view profile etc are navigation elements for the user, but the log out button is an action that would make the user log out from the system.
What is sure is that the Log out and the ...
Some improvements are:
Remove agressive black border as it takes too much attention
Use single grid, it creates simple visual structure
Align numbers to the right for easy scanning and reading
Remove repetitive 'Score'. It breaks the numbers reading
Don't use too long empty lines
Be careful with zebra-coloring the lines, as printed version could be hard ...
I have a similar set up for a test environment and a production environment.
I found myself accidentally adding test data to the live database. So I wanted to make sure that it was easy to identify which server I was on. I could glance at the address bar, but it was too easy to forget. I wanted the differences to be minimal but obvious.
I chose to add a ...
As shown here:
In my opinion, I do not think it's too complicated for the user if they can see the selection highlighted when the mouse over (assuming it's not a touch based device).
Also, I noticed it's much easier for me to view the hierarchical multiple selection if it's top down approach.
This a common case in a complex workflow or process, which can be solved with progressive disclosure, like:-
Initially show all parent tasks with their progress indicated and also childs status with notation like 2 off 5 childs is comleleted (indicated by showing 2/5).
For more detail user can always expand a parent task to get sub-task details which in ...
Personally, I think your main issue is to use a table, which complicates things and provides an affordance that collides with what you want to achieve. Think about this: I see your categories list, and see there are 10 per page. Great. Now, I expand your category... and now I see subcategories but some of the categories I was seeing disappeared! This is a ...
It sounds like you're offering an affordance that the users would benefit from, but you're explaining it in the terms that make sense to you. Rather than using the concepts of propagation and hierarchy, I'd set it up to use the more familiar "apply to everything like this" pattern, which commonly shows up in applications and OS functions.
Your presentation ...
This is a common pattern for users.
If a subset of child items are selected, the parent item indicates partial selection.
If the parent item is clicked while in the "partial" state, all child items will also be selected.
If the parent is deselected, all child items will be deselected.
I think the problem here is you shouldn't use a table, but something different. The first easy choice is a Tree View. Tree view is a system that allows you to organize hierarchical data in an easy to understand manner, and most users (if not all) know how to use it and its affordances.
From an implementation side and user experience, it also allows you to ...
Showing multiple prices should not be an option.
You can think a lot of reasons for that, like misunderstanding of users, perception of users, possible longer lists for countries which will be added in the future etc...
So, you should show just one price, which leads us to another question: which price?
You can find many answers for this another question ...
"The Problem: On one hand deeply nested code is hard to read. On the other hand, visualising nesting levels are necessary to understand code. De-nesting code/html requires a lot of effort, which only improves readability, not actual code effectiveness, accuracy etc."
Do you know that 'de-nesting' improves readability for sure i.e. you or others ...
Since space in full screen applications is often an issue, choice A seems to work fine. A dialog is temporal, and won't add clutter to the UI.
'Custom' implies more UI/interaction
You can also use a UI hint that custom... will bring up an additional dialog if you have concerns about surprise.
In addition, we offer other preset date ranges like - Any time, ...
Everyone apt enough to use a computer understands what a parent-child relationship is.
Experientially, I would consider the usage of the term "parent-child" in abstracted contexts to be fairly technical. If your audience is non-technical, I believe this usage will be confusing (at least initially so).
As a general principle, it's often advisable ...
In my opinion tag hierarchy is not always a bad idea, but I think hierarchy is a bad word here, I would consider this being subsets.
Let's say we are on Stack Overflow and because you work often with Microsoft Excel, you are interested in all questions regarding it. So you add as favorite the "excel" tag and ignore all the others.
But there are other tags ...
The tree model is more visual and easier to use than the "folder hierarchy model" (but certainly harder to code)
You can grab inspiration in the genealogy website like myheritage but also on some hierarchy builder like Writemaps.
Here is a quick mockup, I hope it will help.