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 :)
Related
I am setting up a database for some coworkers and they asked for something a little different involving forms and split forms. There are three separate people who put info into the database based on location. Due to certain reasons, the forms they use are different by a couple of factors. Those forms are being built to add data to the same table. There is a fourth person who overseas this data from the three forms and assigns priority levels to each row within the table.
The goal was to create a split form so that the fourth person can see all of the data that is being added from the three forms. Click on one of the incidents and add a priority level to each. I have that mostly done the problem is I want to add all of the data fields to the bottom half of the split form without adding more to the top half (the form). As of now I have the boxes I don't need hidden but it doesn't auto-size the form so it just looks long and takes up a ton of space.
By setting the boxes as hidden and resizing them to be smaller it kind of works but not every cell is re-sizable and it won't let me resize the form because of the extra hidden boxes.
This is an image to help visualize what I am asking
As I have understood, you want to hide/show fields corresponding to what type of records fourth person oversees.
I have solved this in form part using Tabs Control, placing different classes of fields on separate tabs. After user selects a definite record, all tabs are set to hidden, except needed.
If you want to hide this in table form appearance... This could be difficult IMHO. Better to split other way, grouping data, adding some more forms and so on.
I am creating a rating component , and wanted to add accessibility feature to it. What all aria-attributes has to be added? What are the tab navigation required?
i.e how it should behave on right/left arrow click or click on other keys?
There is probably no unique definitive answer to this question. You may design your component rather differently, depending on the exact desired behavior.
Is your rating component read only ? Can the user rate only once for all or change his mind at any time ?
When the user sets or changes a rating, is it taken into account immediately or does he have to click an OK/save button ?
Are three of the few questions that may change things.
For example, probably the simplest:
you may view your component as a serie of radio buttons labelled 1, 2, 3, ... 10.
If you use true radio buttons <input type="radio"/> with accompagning labels, you have very little to do to make your component accessible.
A bit harder, you may see your component as being a slider. IN this case it's going to be more difficult because you will probably need to use some ARIA.
Refer to W3C authoring practice for implementing it correctly.
This was for a component allowing input. Now if your component is read only or become read only once the user has given a rating, remember that, after all, a rating is just a ratio between two numbers, the rate obtained and the maximum possible rate.
How fancy you present the result to the normal user has finally little importance as long as you give the two numbers in text somewhere, e.g. "4/5" or "4 starts out of 5" in a place and in a form where it can be read as is. The rest is pure optional decoration.
However, if you really don't want to give the numbers in clear somewhere, you are going to fail. For example, color blind won't see if it's green or red, screen readers users won't figure out the size or number of bars, etc.
I can well understand the willing to hide exact numbers for many reasons, but it's a bad idea for accessibility.
I need to create a dropdown, which can contain 100s of options.
I need a scrollbar to appear and be consistent across all browsers.
Google came up empty: Is there a good URL that describes if this is consistent or not?
I would strongly recommend against having a scrollable select with 100s of options for usability reasons.
With exception of one corner case, navigating (both searching in, and selecting from) that list is a really really hard and very annoying to the user.
The UI design reasoning is that it requires:
Wide mouse gesture (tiring), followed by immediate precise stop (hard to do because of inertia)
Very difficult to use interface of a scrollbar (extra crap points for scrollbar being in the middle of the page instead of on the right side) - see Jacob Nielsen's and others' usual ranting about difficulties of using scrollbars and general evil of anything too long that requires much scrolling.
Eyes need to scan whole page worth of menu up and down and back, all the time. very tiring.
Here is a set of bad examples
[ the corner case is when all the option names are uniformly distributed across the alphabet (as far as the first letter), which allows somewhat-possible keyboard-only navigation in the drop-down via pressing the first letter of an option ].
A proper UI solution is to have a select whose contents are dynamically populated based on a search field - either typed text (think Google's new search box, or browser's address bar) or sometimes checkboxes/radio buttons.
BTW, sub-menu solutions also suck for mouse navigation - minor twitch of the wrist and you lost all of the pointing work.
I apologize that this answer is not an answer to "how do you solve my technical problem", but I am of a very strong opinin that you're solving the wrong problem in the first place.
HTH.
The short answer is no, for the standard HTML select element and the requirements you describe.
However, do you know you can set the size attribute for how many rows are visible at one time? AFAIK this will force scrolling in all browsers, but it isn't a drop down. Like this:
<select size="10">
<option>etc</option>
...
</select>
There is also the possiblity of optgroup to split the options into categories.
If you have many categories you could do what I did on one site and use this jQuery click menu, using the click function to set a hidden field. So now I have a dropdown with sub-categories and it's quite easy to find the right option.
I have an Access form displaying a tiny amount of data for a certain type of record. Basically it just prints the name on the left and on the right has a bunch of Rectangle controls whose background color I change in the form's OnLoad() function, according to results from a query performed using that record's ID as parameter.
This all worked fine, got my ID/name on the left and 31 boxes on the right, colored if that day of the month is reserved :) But needless to say that function can be completely arbitrary since it's code.
Then I decided to switch to 'continuous form' as to display as many records/items as possible. But alas, it was not to be -- all boxes were colored according to the query/function performed for the first record only. I figured that might be because it's the OnLoad() but changing it to OnCurrent() did not do much either. As it turns out, or that's what I read, the Rectangle intances are shared over the entire form and if I change the BackColor for one of them it changes for that box for each record.
I want to be able to change this according to a query performed on a per-record basis. Is there any way? Up until now I've only been able to find conditional formatting (the feature that's nor available for rectangles nor seems to cater my exact needs?) and kludgy Access 97 text-box hacks.
Thanks in advance :)
You may be coming from an HTML background, where rectangles would be a natural solution. They aren't in Access. I don't think they'll work for you (in fact, "kludgy" could describe the attempt in my humble opinion).
You can however display an image. You'll keep an image for each status ready to call up. I've made visual displays this way. A little later I may be able to post some code, but I think you'll find this plays out pretty simply even if I don't.
ADDED NOTE: I'm glad this looks like it will work for you. You are concerned about "instanced only once" in your comment below. Yes, that's true for rectangles which are unbound controls (because they are designed for mere ornamentation). But you'll be using an image control which is a bound control (see Remou).
Change each rectangle to a text box, Control Source:
=Iif(myConditionIsMet,"ÛÛÛÛÛ","")
The "Û" is the Full Block character in Arial (asc 219).
All unbound controls in a continuous form will be the same; bound controls can be varied using conditional formatting.
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.