currently I have a requirement to display related items in a multi level grid.
that is great grandparent -> grandparent-> parent-> child
For example:
Country-> state->City->Street is the order of display.
The proposed solution is to display all these in a multi level grid (4 levels maximum).
Country
-> state
->City
->Street
Since I am not comfortable with this solution with respect to usability aspect, I am looking for a UI design pattern that will break up the display into logical units.
thanks
When you have data objects from two different levels of the same hierarchy, you can:
Put each level in a different window (or page, lightbox) and allow navigation between them. I call this drill-down.
Put each level in a different pane of the same window (or page), where placing focus on an object in the superordinate pane populates the subordinate pane. I call this master-detail (this includes cascading lists and is not to be confused with drill-down above).
Put both levels in the same pane, indenting the subordinate objects under each superordinate object, and usually providing controls to hide and show the subordinate objects for each superordinate object. I call this a tree.
With a hierarchy of multiple levels, you can use any combinations of these. Here are some guidelines for deciding how to relate any adjacent levels in the hierarchy.
Put the levels in a tree if
The number of levels in the hierarchy varies arbitrarily with each data object (like folders).
The user will be regularly comparing the subordinate objects of two or more superordinate objects that are near each other in the sort order (the user can then expand the tree for both superordinate objects to see the suboridinate objects all at once).
Put the levels in a master-detail relationship if:
You’re showing more than one or two attributes per object (e.g., more than just the name), and each level has different attributes.
There is more than one class of subordinate objects for the superordinate objects.
There are many-to-many relations that you’ll be displaying.
For details see Hierarchy Visual Design
Put the levels in a drill-down relationship if:
The amount of information to show for each level is simply too large to fit in a single reasonably sized window.
The task dictates that the user may transition from one level to the other but the user doesn’t use both levels at the same time (in general, you want to avoid making the user navigate back and forth between windows).
You’re going to need separate windows for different high-level tasks anyway. This implies you’re going to provide a means to directly navigate to the subordinate window without “drilling down” through the superordinate window
Generally drill-down only makes sense if both windows are primary windows (or pages). The subordinate window should not be a dialog box, property window, or lightbox. If you don’t have enough to show in the subordinate window to justify a full-size primary window, then use a master-detail. Compared to master-detail, a drill-down dialog:
Introduces inconsistency in saving changes.
Creates modes or ambiguity in the z-order (or, in the case of lightboxes, ambiguity on the function of the Back button).
Lacks a pulldown menu with its basic controls for editing and undoing (in Linux and Windows).
Does not support window resizing (in Mac and Windows) to provide more flexible viewing of the contents.
For more on all the above see http://www.zuschlogin.com/?p=31.
A common way to break this down might be to do it in 2 or more steps with navigation between them (i.e. navigation to another page or opening a modal dialog etc.)
So you could display the first grid/table with 1 or 2 or 3 levels of your hierarchy, and a navigation link to display the remaining levels in a second or subequent lists/tables.
If you're looking for confirmation of some established patterns you could choose from (or combine) these:
Master/Detail
Tree Table
or
Cascading Lists
Tree? Like a Windows Explorer view of a file system?
Related
If I select some items of the model using-
viewer.select(dbids, viewer.model, Autodesk.Viewing.SelectionType.OVERLAYED)
and then try to zoom in/out or rotate the model, the viewer gets slower. But if I select some items using mouse click it doesn't affect the viewer at all.
If I select items using-
viewer.select(dbids, viewer.model, Autodesk.Viewing.SelectionType.REGULAR)
the viewer first hides everything except the selected items and a moment later shows up. It also hide some parts of the selected item(s). The navigation is smooth now.
This is before selection-
This is after selection-
Is there any way to overcome this slowness and the hidden parts issue.
Let me first explain the difference between the overlaid and regular selection highlighting:
Overlaid highlighting means that the selected objects are rendered twice. Once with their standard material, and once with the overlay material (so that they can be seen through obstacles as well). Of course, this doubled rendering may have significant impact on performance, especially if you select many objects (for example, by selecting a group of a large number of objects in the model browser).
Regular highlighting was introduced to mitigate the performance problems. In this case, instead of rendering the selected objects twice, they're simply rendered once, with a specific color tint applied to their regular materials. The drawback of this approach is that the selected objects are not visible through obstacles.
Now, to your problem: "regular" selection highlight is definitely the right way to go if the "overlay" highlighting is slow, but the fact that parts of your model disappear is strange. I'm thinking there might be a problem with the model itself. Perhaps it's too granular or tessellated (has too many parts or triangles), so applying the "selection tint" to all the selected parts takes unusually long time. Could you please try both the "overlay" and the "regular" selection with another type of 3D model? If it works well, you may need to look at the settings of the application that's creating this problematic model, and see if you can decrease the tessellation levels.
Introduction
An HTML form contains a checkboxes element listing various indicators. The user may choose exactly three items from that list (see image 1). Upon submitting the form, a bubble chart is created, with one indicator each on the x and y axis and the third indicator defining the size of the bubble (see image 2).
Image 1
Image 2
Problem
By choosing the indicators, the user is not able to define the order of the selected indicators. Thus, the user is not able to define, which indicator is on which axis or which indicator is responsible for the bubble size respectively.
Available solutions
Of course, instead on having a single multi-select checkboxes field in the web form, (1) one could create three single-select radio elements named x, y, and z. Or, if the form is ajax-powered, (2) additional form elements could be shown to let the user choose the respective options.
However, with option (1), the indicators would be repeated thrice in the form and with option (2) the additional form elements would not be inside the list of indicators. Further, I would like to keep the indicators in one element due to the fact that there are other chart options using a very similar form (they are all generated from the same toolbox) and the processing functions are relying on specific element names (not types though).
Questions
I've read about multi-state checkboxes, however, the (only) additional state (indeterminate) is just a visual representation, the checkbox must technically still be either checked or unchecked.
Q1: Is there another (similar) form element which could be used?
From what I read, I would assume, that such an element doesn't exist since what I am practically trying to do, is to send two values (indicator id and chart representation).
Q2: Could someone point me to UI/UX best practices for similar cases?
Due to the lack of correct (search) terms, I haven't quite found good examples of solving this or similar situations. "multi-state checkboxes" bring up the before-mentioned indeterminate state, "ordered checkboxes" mostly refer to some MS Excel problems.
What if I want to have the Biomass for x and z?
UX is a very difficult topic, and denying choices from a user doesn't make them happy at all.
So my solution, not to the technical question, but the UX one, would be to convert all check boxes to radio items and add an additional selection (either as a dropdown or again as radio items) with which you select either x,y or z.
This can easily be achieved via js and solve the problem at hand easily. Another advantage is that you only use controls with which users are already familiar with, which might be an additional plus :)
I'm currently experimenting with HTML5 Drag and Drop API. Now I've got several questions:
1.
Am I right, that it's not possible to connect draggable elements with drop-areas?
Example: You have 2 different kinds of elements you want to be able to drag and drop: Files and Text-Labels. Now if I give some div an DragOver-Handler and a Drop-Handler it will respond to both, files and text-labels. I'm looking for a simple possibility to only respond to a specific type of draggable items.
A connected problem is the dropEffect cursor-style: At the moment I enable all possible drop-targets in the DragStart-Handler and disable all of them in the DragEnd-Handler (with "disable" I mean, that I remove all DragOver- and Drop-Handlers). If I wouldn't do so, it'll look like if you could drop a file on an element that should only react to text-labels.
2.
The dropEffect cursor-style is a mess. In Firefox I don't get them at all, in Chrome it will give me a big "plus"-icon (even if I have removed the DragOver- and Drop-Handlers from an element)
3.
Last feature I am looking for is multi-select: Select multiple Text-Labels and then drag all of them at a time. Is this possible? My first idea was to create a new div and move all selected elements inside this div and then drag the newly created div. Seems pretty hackish and looks quite ugly ;-)
I hope you guys have some answers for me. Thanks!
I don't think that HTML5 drag and drop (and friends) are supposed to be replacements for commonly used "drag and drop" Javascript libraries (although it COULD be used instead of them in some cases). The name is misleading.
Modern operating systems include APIs that allow cross-application communication: clipboard and drag-and-drop. Both APIs are quite similar and need to be quite low-level because of specific challenges:
the data must be sent across processes, so it must be somehow serialized,
the sender must have a way way of offering the data in many formats (eg. text/plain and text/html) and the receiver the ability to pick one that it likes best,
the sender and receiver may live in different processes, so they can never find out about each other (they might even be entities coming from different platforms, GUI frameworks, programming languages etc.), the only channel of communication is the data itself,
Current HTML5 APIS, as opposed to - say - JQueryUI draggables - are not meant to give programmer strict control of the look and feel of the dragging process, but rather enable tight integration with the native, system-wide mechanisms. Which may or may not be what the programmer needs.
So to answer the questions:
you cannot "connect draggable elements with drop-areas", because your draggable elements can even come from outside the browser. But you can make an area that rejects certain types of data (which is what user expects from native drag and drop).
"div" and "multiselect" are not things that operating system understands (we don't have native multi-cliboards or multiple-text-selections). You CAN implement such functionality if you make a with inner divs that can be toggled (eg. by clicking while holding shift). When someone tries to drag the outer dive, make a transfer object that says which inner divs were selected (you could even create an image that shows them).
If the above solutions sound a bit low-level, well - that's because they are. When you develop a desktop game or tool, you do not rely on native drag and drop for moving pieces across the chessboard or moving sliders in the GUI. I think it will be the same with JavaScript. JQueryUI Draggables are not going anywhere.
In Sql Management studio MDX query designer, there's the metadata pane from which you can drag elements of the cube into your query.
Is there a key for the icons anyway?
There's six dots in a pyramid, another has six dots in two vertical rows of three. Not sure what the folder icon represents under a dimension, etc. That's not the only ones, so I'd really like a key. Any ideas? Couldn't find it in the help.
Thanks
The meaning of the icons become obvious once you've had experience creating a number of dimensions. Many of them are obvious by the label that's next to them. Here's a list of a few of the others:
Measure
Calculated Measure
Dimension
Attribute Hierarchy
User-Defined Hierarchy
Level 1 of User-Defined Hierarchy
Level 2 of User-Defined Hierarchy
Member Property
The folder icon underneath the dimension that you're talking about is most likely to hold the member properties.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I always have trouble designing the user interface when it come to manage a list of object.
For example, I need to manage a list of employees. At my work, we always switched between two method of managing the employees:
Use a single split screen with the left part being the list of employee, and the right part being the place where you edit the employee. There is usually a toolbar (or ribbon bar) at the top to allow Add/Modify/Remove.
Use a two windows approach: the first one is a full size list with the same toolbar at the top. When someone press a button (or double click an employee), it open a dialog that let you add or modify that employee.
While I prefer the 2nd approach, I don't have any UI expert reference to back my choice or to dismiss it.
Does anybody have any suggestion or references that would help me design a good UI for mananing a list of object?
I don't believe you're going to find any actual studies on this particular issue, since it's so specific to the application at hand. What it comes down to is how the individual objects are used/accessed/modified/etc.
That said, I've gone back and forth over the years on this, and have come to settle on #2. Here's a snag from one of our internal apps.
Power users can get into middle-clicking to open in a new window, and you get sorting, filtering, etc, as the list grows.
Option 1 allows the user to see more list items at a time, so it is preferred when the user is likely to need to jump around a lot in the list (e.g., to find the next record to edit). More items means less scrolling, among other things.
Option 2 can usually get the user to editing the field faster, since there is no waiting for a new browser window to open and no cognitive re-orientation needed by the user, so it is better for heavy data entry (e.g., making a change to every record, one after another).
Both options are substantially inferior to edit-in-place in the table by using an editable grid or replacing your table with an array of appropriate controls (text boxes, combo boxes, checkboxes, etc.) that are populated with the field values for the appropriate set of records. Users change fields directly in the table and select a Save button or menu item to update all changed records at once. Or you can save automatically whenever a field loses focus, if your bandwidth can handle it.
Compared to Options 1 and 2, edit-in-place has the following advantages:
No need to click an Edit button to change a record, an additional navigation step that takes time and learning (e.g., the user has to learn the “edit” icon).
No need to visually re-acquire the fields in another location in order to edit them, making editing faster and easier.
No second window or form layout to learn and understand, and to consume screen real estate that the user may want to use for something else.
No modes –the users can fluidly switch between editing and viewing, and save whenever its convenient.
If you have too many fields for the Employees to show in the table even with horizontal scrolling, then you need to choose between (1) having a split-screen master-detail layout in a single window, and (2) having two windows and allowing drill-down. However, optimizing the display of “extra” fields is a separate issue from how to edit records. The general rule for usability is that if a field can be edited by the user, always make it editable for the user wherever that field appears, whether it be in a table, a detail overflow area of the screen, or a separate drill-down detail window.
Dialogs are modal, and user-experience specialists generally frown on that. A split screen allows not only editing, but also very natural "perusal with all details" of one given employee [or other kind of object] (there may be more info about each than the bare list can usefully show); a button to "make this detailed-info editable" seems a very smooth, natural and seamless approach, without the unpleasantnesses connected with dialogs, popups, "tooltips" appearing on hover, and the like.
For a reference summary of UX criticism of modal operation, you might start at wikipedia and follow their links.
I've used the "email client" layout with some success. The left hand side of the screen contains navigation elements (analogous to folders in an email client); the right hand side is divided into top and bottom in a split window, with the top containing a list (e.g. of employees - analogous to a list of emails) and the bottom containing a form (consisting of tabbed pages) to edit selected items in the list (analogous to a single email which you are composing or viewing). The email client layout has the major benefit of familiarity - almost everyone uses email! And the major email clients all follow the same layout, reinforcing the familiarity benefit.
The right answer depends on whether your list primary objective revolves around editing objects or viewing the list.
If editing is infrequent operation, you can settle for it being in a separate window and use the screen space on the main view to show as much details as needed.
However, if editing is going to be a frequent operation, you want it in place with the list, as opening a new window creates too much of a friction.