27

Maybe try having the scoring information appear as a sub-heading under the student's row when you expand it? Something like this. You'll want to be careful to stylistically de-empasize the sub-headings so that they are obviously part of the expanded row rather looking like the start of a new table.


21

Tweaking Jim's answer... ...adding a bit more distinction. Boxing in the child table, vertical lines separating columns, instead of horizontal as in the parent table. . Inspired by Tonny's comment, here's some indented examples, for your consideration:


9

A little bit cleaner and following @Bergi and @CoDEmanX suggestions. Original: When you expand a row, what you have is: As the ID, First Name and Last Name is common to all the subjects the info is repeated in each row. One way to prevent repeating those common fields, and not change the table layout is to use a single field which represents several ...


8

Amazing how I've never thought about this 'conundrum' before, but it's intriguing. Here are the possible solutions I could come up with: Two menu buttons My first thought was to put the sub nav off-canvas to the left. Leaving you with a menu button on the right for a dropdown menu of the main nav and a menu button on the left for the off-canvas sub nav. But ...


7

It's a splitter and pane… The draggable control itself is a splitter, of one kind or another. The separate space that is created by dragging the splitter usually called a pane or sometimes a panel. To confirm that this is the kind of interaction you meant to describe, have a look at these samples: Telerik example or DevExpress example. There are other ...


5

I always go by the rule Chapter is to Tab. Paragraph is to Collapsible Panel. When you have 2 hierarchies, the broader of the two levels are tabs and the other ought to be for collapsible panels. For complex applications, there are more than 3 levels. Whatever you do, don't implement the same UI division to the next immediate generation. This means that if ...


5

When designing an interface, you should focus on making it as easy to use as you can, not on doing something new for the sake of it. And as your question stands you haven't really shown what the problem with checkboxes is that you are going to solve with icons and colours. So breaking it down with specific reasons: Checkboxes clearly indicate their state ...


5

While I understand your read on why the header would go under the panel; the opposite visualisation can follow the same animation "principle" and make the same amount, if not more, visual sense. Think of an actual accordion being held sideways by someone. The "header at the bottom" logic would have the bottom half of it being pulled down ...


4

Three typical options: You can teach the user a command key that displays all the panels, overlaying everything else, and then disappearing when the command is pressed again. Adobe suite does this. You can also consider giving access to these assortment of panels through a Pie menu. This is what is used by Alias for their Maya product. It requires a ...


4

You can give a color to the background of content inside the accordion panel, such as #f4f4f4 or light grey which will improve the depth and more noticeable.


4

An alternative is doing as Material design deals with expansion panels: As you can see when a panel is expanded, it separates from the others to deal with this problem.


4

It might be a collapsible panel then.


4

An accordion by conventional definition is a self-contained panel made up of a 'stack of drawers'. Each 'drawer' can be expanded individually - an action that customarily closes any other drawer open at the time - to reveal its content. An accordion following this description can be a collapsible panel at the same time. So while you can open one drawer at a ...


3

Usually this comes down to space. If you have the space, two buttons makes more sense and is easier to implement. A single button is bit more confusing because you don't know which action will happen first.


3

I would call it a "Drawer" (such as the app drawer on Android), but there are many possible terms for this kind of thing (tray, slide-up overlay, popup, etc.).


3

Both tabs and collapsible panels are ways of grouping controls. Both have advantages and disadvantages. Advantages of tabs Easy to understand, easily discoverable, widespread and thus likely to be recognized by users of other products Less cluttering because only the contents of one tab is visible at any point in time, separating each group of controls ...


3

One solution would be to collapse the Primary Nav, as you currently have planned and to simply stack the secondary nav items. The reason for this approach is given that there will be numerous actions involved in most of those items such as text input, dropdowns, saving, etc., you'll want to make use of the little real estate you have available, but yet ...


3

Having so many tabs that the user must scroll horizontally is never a good idea. It's very fiddly and breaks the tab analogy. I would only use tabs if the number of tabs was predictable and limited. If your user can create a large number or theoretically infinite number of items, I think a vertical list (scrolling if necessary) would be more appropriate.


3

Data visualization uses color (and shape) to differentiate status, magnitude and categorical differences between data. They are often the go-to for understanding a dataset. Your question regards UI capabilities, in this case the ability to expand an element to view the child elements. You can look for indicators that emphasize a function, not to be confused ...


3

I am currently facing a similar challenge regarding pages with "too many" filters. Showing all of them and asking the user to scroll through all of them, while reading each and every one, seems to be a no-go. The benchmark upon which we chose to work is the component used at mixpanel.com: No filters are shown, just a "+ Add" button All ...


2

I think there are a few things you can do to improve this within the activity stream itself (examples loosely based on sharing amongst users, but the principles are the same): Group notifications together by type and time then output one item to the activity stream. So a user adds 20 pictures, that would be one notification 'X added 20 pictures'. This saves ...


2

Providing too much information with matrix view, as in your panel, makes it hard to process it. The reason is there is conflict of view patterns: per-row or per-column. So there could be a risk of loosing eye-view path, see the image. You could see how Amazon organizes information for its hudge number of servers: Source . Source So, per-row view with ...


2

Many elements, such as light-boxes, will close if you detect a click outside of your box. One simple way to do that: toggle a bool on mouseenter and mouseleave and then on click do if(!InPanel) closePane(); This is my primary suggestion. I think depending on the purpose of the panel, the user will sometimes want to scroll down the page to view something ...


2

In terms of a cleaner, more modern UI this seems like a good idea, but the problem is most users are not used to modern UI's as much as we want them to be. This type of interaction is not obvious to the user and without guidance they will, Not notice the button at all. Users who notice will not know what it does. If you're keen on removing the label, ...


2

Collapsible panels are more valuable when combinations of settings from various panels are important. If settings are totally orthogonal or independent - that is, the settings from one group don't affect the settings from another group - then tabs are fine (and so are any other ways of showing/hiding groups of settings). If the settings from various groups ...


2

Based on the screenshots, I assume when you say collapsible panels you mean drop-downs or drop-lists. Here's a research article about tabs by NNGroup: http://www.nngroup.com/articles/tabs-used-right/ Summary: 13 design guidelines for tab controls are all followed by Yahoo Finance, but usability suffers from AJAX overkill and difficult customization. ...


2

The way I would approach this is to slightly rethink everything. For instance, if I were designing it, before a node has been selected I would have the node selector fill the entire working area. Then, when a node has been selected, the node selector would collapse into narrowness and fade into the background like in the Spotify web app. In this example, I ...


2

I would decide based on the chance of the user wanting to use the same filter as he did before. Now let's assume the user wants to filter the same way on different moments (if not, there is no need for a save function). You could also think of a third option. Why not remember the last filter (preferably with a cookie or something that doesn't need an account)...


2

I don't see anything wrong with placing them above the accordion. As long as it is clear that the controls belong to the accordion component that should be fine.


2

I'd say either full left, or full right. Not zigzaggy in the middle. Consistency is super important. However, have you considered making the whole row act as a button? This would make it a much larger touchtarget. It has the minor drawback of making the label text slightly harder to select but not impossible; try selecting one of the 'related questions' ...


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