In the programming of a table-based application module (i.e. the user mostly enters tabular data in an already laid-out table), how would you reject user input for a given cell?
The scenario is: the user edits the cell, enters something (text, picture, ...) and you want them to notice when they finish editing (hitting enter, for example) that their entry is not valid for your given "format" (in the wider meaning: it can be that they entered a string instead of a number, that their entry is too long, too short, they include a picture while it's not acceptable, ...).
I can see two different things happening:
You can rather easily fit their entry into your format, and you do so, but you want them to notice it so they can change if your guess is not good enough (example: they entered "15.47" in a field that needs to be an integer, so your program makes it "15")
You cannot guess what to do with their entry, and want to inform them that it's not valid.
My question specifically is: what visual display can you offer to inform the user that his input is invalid? Is it preferable to refuse to leave the editing mode, or not?
The two things I can imagine are:
using colors (red background if invalid, yellow background for my case 1 above)
when you reject an input, do something like Apple does for password entry of user accounts: you make the cell "shaking" (i.e. oscillating left and right) for one second, and keep the focus/editing in their so they don't loose what they've typed.
Let's hear your suggestions.
PS: This question is, at least in my thought process, somehow a continuation and a specialization of my previous question on getting users to read error messages.
PPS: Made this community wiki, was that the right thing to do on this kind of question or not?
Be careful using autocorrection such as forcing user input to fit your format. See:
Is it acceptable to normalize text box content when it loses focus?.
It’s generally better to prevent invalid entries in the first place than to autocorrect them later. For example, if only integers are allowed, then you ignore any keying of the decimal point (along with all letters and most special characters). In some environments, you may want to provide a quiet audible signal that input is ignored (e.g., a dull thud).
As for when you need to alert the user to an error, how about a callout? Draw a bright line from the control or point in question (field, status annunciator, button, menu, location of a drag and drop) to the margin of the window and put a brief message (two or three words, like "Unrecognized date") in a balloon. Placing the message on the margin should keep it from occluding anything of interest in a crowded table.
The sudden appearance of the call-out should be sufficient to catch user attention, so it's okay to let the user move on to other cells in case they want to fix the error later. For efficiency, you may want to hold the user in the error-related field when the error originally occurs (since often the user wants to correct it right away), but then allow the next tab or mouse click to navigate the user away.
On mouseover or when focus is on the control associated with the error, the line is highlighted (to distinguish it from other callout lines that may be present) and the balloon expands to a full error message, providing more details on how to fix the problem (up to two sentences). Allow the user to drag and drop the balloon to a new location in case this occludes something of interest.
Include a Help button in the expanded balloon for further details. You can also include a button to fix the error (e.g., Retry, Reconnect, or set to default value).
The balloon disappears automatically when the error is fixed. Undo reverts whatever caused the error (e.g., reverts the field to its original value), which should clear the error.
If the user scrolls away from the place associated with the error, the balloon shrinks to an icon that remains in view so that the user is less likely to forget about it. Maybe an exclamation point in a triangle is a good icon. Place the icon beside or in the scrollbar track to indicate its relative location in the table, so the user can quickly scroll to find it later. Mouseover expands the icon to its full message. Perhaps clicking the icon can scroll to the right place in the table and put focus in the relevant control.
Balloons could also shrink to icons if they start visually interfering with each other. You may even want to include a control in a balloon to allow the user to force it to assume an icon.
For consistency, use for all errors, not just those associated with fields in tables.
The last time I did such a form (on a web page) I put a red box around the offending input.
I thought it was really neat... until a user asked me "Why's there a red box around this cell?"
What'd be nice is also displaying why the input's incorrect: "This field accepts only numbers", say.
You could display an icon in the cell, or a tooltip. The tooltip could open automatically or when mouse pointer hovers over the icon. It could disappear automatically when user edits another cell or when some timeout expires.
You can go with arrow tooltips like Adobe Flex's error tooltips. It focuses the attention to the error and supplies a brief description.
Related
I am working with an edit control in a dialog--all MFC. The only style specified in the resource is ES_AUTOHSCROLL. The dialog comes up and displays correctly. The edit control also works and edits text correctly--up until a point. At that point, it stops displaying text completely. The edit control is just blank.
My first thought was to try and adjust the limits of the edit control by sending calling SetLimitText() on the edit control which just sends EM_SETLIMITTEXT. I set a big number which was 10x the previous limit, and verified by EM_GETLIMITTEXT that the number retrieved is equal to the number set. After that, I still have the problem and nothing is changed.
Next I tried trapping EN_MAXTEXT and EN_ERRSPACE. Neither one of those notifications was sent.
Lastly, I started trying a little different input, and if I entered a space or a period then I could get a few more characters displayed than if I entered a W. The font in the dialog is MS Shell Dlg which on my system maps to Microsoft Sans Serif. It's a proportional font, do different characters have different widths, so I was beginning to thing that maybe it was GDI related.
Next, I trapped EN_CHANGE, and when it is fired off, I went and created an IC for the display, selected the font into the IC from the edit control, and then called GetTextExtent() on the text in the edit control. The problems occur in display right around 32760 which is darn near the 16-bit signed integer limit.
So, I am thinking that my problem is GDI related in that the EDIT control cannot draw past that limit. I tried substituting a RICHEDIT2 control, but it displayed fewer characters before going blank.
The other weird thing is that if I keep on entering characters and call GetWindowText() on the edit control, all the characters will be returned. It is just that the edit control is blank.
Yeah, maybe I shouldn't be displaying that many characters, but it is what it is.
Does anybody have a better explanation, solution, or workaround?
When using icon images without text captions, should the icon represent the current state or the next state? For example I have a block of text that I want to minimize / maximize or I want to toggle showing All User Records or just My Records. I'm sure there are compelling arguments for either side and know that consistency is key, but what are the arguments related to good intuitive user design?
There is neither standardization nor general human tendency on this. For example, MS Windows UX Interaction Guidelines specifies four basic kinds of toggling progressive disclosure control. Three out of four show the state-when-activated, while one shows the current state.
I believe if you test a particular approach on your users, you'll get different results depending on what you ask. If you show them a control and ask them what state the app is in, they'll tend to read the icon as if it were indicating the state. If you show them a control and ask them to change the state (where in some cases the state is already changed), they'll read the icon as if it were the state to achieve. It's precisely because of this they invented toggling buttons.
If you're lucky, users use the icon primarily for either reading the state or setting the state, and not both. Then let the icon indicate whatever the users use it for.
If they indeed use it for both reading the state and setting the state, you're basically hosed, but there are a few things you can try to minimize hosehood:
Use text in addition to or instead of an icon. When labeled with a verb (e.g., "Connect"), the control indicates the state the user gets. When labeled with an adjective or noun (e.g., "On Line"), it implies the current state.
If your lib doesn't support toggling icons, then consider using a checkbox control, if that's allowed.
If your lib doesn't support checkboxes, then consider two controls, one to set each state, where the current state is disabled. Not too good for reading the current state, but there's some precedence for this in pulldown menus.
Fiddle with graphic design or placement to make it consistent with the meaning you've chosen. For example:
Command buttons are always labeled with the action they commit, so if your icon indicates the state the user gets, then give the icon a raised appearance like a command button. If the icon indicates the current state, then give it a flat appearance.
Toolbar controls usually show the state they bring about, so put the icon at the top of the window if indicates the state the user gets. In contrast, icons in the "work area" of the window indicate objects or attributes, so icons there should show the current state. Icons at the bottom of the window (in the status bar) should also show the current state.
This has not been truly standardized. Folder icons, for example, show open folders when they are open and closed folders when they are closed. Same for disclosure triangles, etc.
However, in other contexts, this is not always true. In a movie player, the "Play" arrow shows when the movie is not playing, and it shows the pause icon when it is playing. Probably the thing to do is use your best judgment, then poll your users. If a preponderance of the people you test are confused by your icon choices, switch them around. Then test them again and see if your initial test holds up. :)
If you are just going to have one button to toggle between two states, then the button should represent the next state, because that is the action that the button will take when clicked.
You gave the example of text that is minimized/maximized. Think of any expandable tree interface you ever see in Windows. A minimized tree has a [+] next to it, because clicking the button will expand the tree. And a maximized tree has a [-] next to it for the same reason.
You could also try to make a toggle that is highlighted or "pressed down" like mihi says, but that might be more confusing.
I prefer the "next state" approach (click plus to expand, click minus to collapse).
One reason is that this is the most widely used approach, so doing anything else would confuse users (and me as well).
Another reason is that the "next state" approach looks more inviting for the user to click.
May I present Zoom's mute button:
It shows the current state, as an icon, and the action that will occur when you push the button, as text. In other words, the icon on the button is the current state and the label on the button is the new state. The current state and the new state are opposites, so the button appears to contradict itself unless you read it very carefully.
(I hate that button.)
Working on an application that controls a remote robot where there is the potential for significant delay between pressing a button and that action actually happening. Furthermore, there is the potential that the command did not successfully reach the intended recipient after all (due to network unreliability, etc.). Additionally, there are variables in play whose changes are not instantaneous. For instance, there is a variable both for commanded speed as well as current speed; changing the commanded speed will not immediately make the current speed match that value.
The question is, how do I make the application reflect both the current states the remote robot is reporting, as well as acknowledging to the user that his command was understood by the application, but the system has not yet received notification from the robot that it has been acknowledged? (Popups are an absolute no-go.)
Some ideas that have been discussed:
Disable Buttons
When a command button is pressed, start a timer for some reasonable number of seconds and disable the button during that time. Don't update corresponding label directly, but instead wait for a response from the robot. (e.g. if you press a Speed + button, and to the right is a text label showing current speed, don't immediately change the label but instead wait for a response from the robot). Once this response occurs, or when the timer expires, re-enable the button.
Pros: No additional control widgets needed on page. Labels always reflect current state of the robot.
Cons: If you wanted to send two speed updates in a row, would have to wait until first had been received and acknowledged. Would feel sluggish and unresponsive.
Logging Info
Have a log that users can view that shows a textual representations of all the actions the user has taken, timestamped, and with a history clearly visible. Could be color coded based on user preferences.
Pros: User has immediate feedback that his command was understood, as it appears in the log
Cons: Does not resolve problem of what to do with button (especially radio button) behavior.
Does anyone have experience with building UIs for environments in which there is significant latency between action and response? I would appreciate any and all input.
I would not go for a Log: your main focus is with the Widgets. There are several techniques for reporting status for different components, I will discuss a simple one here:
A button has an status-icon next to it show it's status. Use different colors to denote the latency. Green means "ready", when the user clicks the button, the icon changes to "orange" and that indicates busy. When the user clicks again, the color changes to "red", which means queued. When the queue is empty, the color changes back to orange. If the action was executed, the color is changed to green.
A slider can be used for floating values: use two "sliders". The first is better visible, and can be dragged. The second, and a layer below the first, is the "actual reported value", which shows the latency.
Textual input can also use the green/orange status-icons. While editing, the color changes to orange. If your queue/networking protocol supports canceling editing actions, you can resend the new string every time the user presses a key. If not: change the icon to orange upon a change, send the string, and wait for a status report. The status report should contain the actual value, and if this actual value is equal to the value in the component then change the icon to green. If the the actual is not equal to the value in the component then resend the value in the component.
Radiobuttons/Checkboxes should have a double-display. One editable, one uneditable. The first is for user-input and the second is for actual reported status. Same behavior as the slider component.
These require custom components, or widgets, to be made. You can extend original components or recreate them from scratch.
If your robot can also be "steered":
Create a rectangle which can be dragged upon. The rectangle has a small cross painted on, of the current value. While you drag, you see the latency of the cross. You can use interpolation and time values to smooth out robot control. A user will notice the lag because the cross "follows" his mouse-pointer. (Often used in space shooter simulation games when controlling virtual ships, Allegiance for instance)
It sounds like you have the following information that needs to be communicated to the user:
Current state or value of an attribute of the robot.
Target (i.e., received) value the robot is seeking.
Commanded value sent by the user to the robot.
Status of each command (pending, received, achieved, timed-out).
There also a couple other considerations:
Continuous or discrete feedback. Do you have continuous real-time feedback of the current value from robot? Or is it discrete feedback, where the robot sends the current value only after achieving a target? Obviously continuous is better for the user, since it allows the user to distinguish between the robot being slow and being stuck, but if you don’t have it, you have find a way to live without it.
Synchronous or asynchronous command-sending. If the commands are sent synchronously (i.e., no new one is sent out until the last one is known to be received), then the user may need a means to (a) force out the next command without waiting for a reply from the previous (in case the reply was lost), and (b) cancel a queued command in case conditions change between when a command was created and sent.
Robot with or without conflict resolution. Does the robot have the logic to look ahead in the list of commands it has received and resolved conflicting commands? For example, if it’s at a stop and its received-commands queue includes a command to go 5 m/s followed by a command to go 2 m/s, is it smart enough to delete the 5 m/s command? Or will it first attempt to accelerate to 5 m/s then 2 m/s, possibly resulting in an overshoot? Will it wait until it achieves 5 m/s before it even “looks at” the 2 m/s command? A lack of conflict resolution complicates your UI because the users may have to track all commands sent to understand why the robot is behaving like it is.
Integrated Information with Position-coding Controls
Let’s assume that the robot has conflict resolution and asynchronous command-sending. Rather than have separate controls for commanded, targeted and current values, I recommend you integrate them all in a single control to make it easy for the user to compare current, target, and commanded values, and see discrepancies. Perhaps the best way to do this is by representing values by positions in the window. Such position-coding of values is unmatched in showing the relations among things. There are two standard GUI controls, radio buttons and sliders, that accomplish such position coding. However, you’ll have to augment them to fulfill for your purposes. The best usability could require custom-made position-coding controls where you schematically represent the robot and maybe the environment, and allow the user to control it through direct manipulation. However, I'm assuming you need a simple-to-develop implementation, and a well-laid-out combination of sliders and radio buttons may get you pretty close to this ideal.
Use radio buttons for setting a categorical value and a slider for setting a numeric value. The slider may include a text box to allow the user to fine-tune the value. You augment each of these controls so that they show the commanded, target, and current values at the same time. The “usual” indicator (the dot for the radio button and the handle for the slider) represents the commanded value while separate graphic pointers indicates the current and target values. Discriminate the current from the target by making the current more prominent. I’d design them such that they merge into a single pointer when they are at the same value in order to minimize clutter for the usual state of things. If your users are untrained on the system you may want to include text labels on the pointers (“current,” and “target” when target is different than current).
Using these position-coding controls makes it easy for the user to compare current, target, and commanded values and see discrepancies. The status is implicit in the relative positions of the indicators. When the target pointer moves to the commanded position, the user knows the command was received. When current pointer is at the target, the robot has achieved the commanded value. This is especially good for continuous feedback of numeric values because the users can not only see the difference between the current and target value on a slider, they can estimate how long it will take for it achieve the target by seeing how fast the pointer is closing on the target. For the radio buttons, you can include “X% Done” text by the Target pointer to indicate when the target will be achieved (if this information is available).
For the most responsive UI, changing a value of a slider or radio buttons should send an immediate command. There is no “Apply” button. Users can re-send a commanded value at any time by re-clicking on the appropriate slider position or radio button. I think you'll find this is a natural human tendency anyway when confronted with an apparently unresponsive control (consider elevator buttons).
The descrepency between the target pointer and commanded indicator may be too subtle to signal a lack of reception of a commmand if responses are commonly slow (over a few seconds, such that user attention has likely shifted elsewhere). If that is the case, you may want to include a modeless alert after a time-out period that almost certainly indicates the command was lost in transmission. A modeless alert may include a text annunciator beside the control and/or graphically highlighting the commanded-target descrepancy. Depending on criticality, you may want to use a audible alert like a beep or animation to speed capturing user attention. The modeless alert disappears automatically when the target value matches the commanded value for whatever reason.
Separate Controls for Commanded and Current
If sliders and radio buttons take too much space for your purposes (or have other issues), you can go with separate non-position-coding controls for commanded and current values, as implied by your Disable Buttons design. However, overall, this is a more challenging design with more issues to resolve.
I would favor field controls like text boxes, check boxes, and dropdown menus, rather than command buttons so that the commanded value is clearly shown. Continuous numeric attributes may include spinner buttons with the text box if it doesn’t end up clogging the queue with incremental commands. As with the above option, changing a value sends an immediate command.
You’re right to be concerned about the using a timer and disabling. In addition to the problem of making the system sluggish, it means you gray out the commanded state. That can make it hard to read, and also requires some mental gymnastics by the user to interpret (“it’s unavailable, so that means I already selected it”). The interpretation can also be ambiguous because often disabled means Not Applicable (e.g., the Speed control is disabled because the robot has lowered stabilizers for fixed-base operation).
The solution is to use some other graphic feedback than disabling. I’d stay away from color coding. Color coding tends to be arbitrary and thus confusing (e.g., does red mean queued or timed-out?). This may be one of the (rare) good places to use animation since animation is intuitive for representing an on-going process. A flashing or throbbing border (or other feature) for the commanded-value control can indicate a sent command is awaiting reply. A flashing/throbbing border for the current-value control indicates the command is received and the robot is seeking the target value. If animation would be distracting in this situation (like it is for most other situations), then consider a dashed border (versus solid) to indicate awaiting reply or seeking target; dashed suggests a tentative or transitory state.
The target value and status are implied by what is animated. If the commanded-value border is animated, the value inside is a pending –the reply is yet to be received. If the current border alone is animated, the value inside the commanded control is the target value. If both borders are animated, then the robot is seeking one (unspecified) target value, while another is pending. If you think it’s problematic to leave the target unspecified in such circumstances, then you may need three controls to discriminate commanded, target, and current. However, if this is an edge case, it may be better to display the target value on mouse-over of current value control or with a drop-down button.
If feedback is continuous, you can also update the current value of numeric attributes at regular increments (about every 200 to 500 ms) so this animation provides an additional feedback of the robot seeking the target. For any attribute, if it takes 10-15 seconds or more for the robot to reach common targets and the robot has conflict resolution, you may want to also display a progress bar within or beside the current attribute control so the user can judge when the robot will achieve the target value.
To re-send the command, users can always re-select a value, or hit Enter while focus is on the commanded control. That’s a little odd and awkward for some controls (e.g., checkboxes), so I’d also consider a modeless notification (not a popup) that appear near the control if the command times out for a reply. The notification includes a button to resend the command.
If your users are untrained on the system you may want to include redundant text under the animation (e.g., “Sending” when waiting for a reply and “Seeking” when moving towards the target value).
Log Table
The logging approach is probably best if commands are sent synchronously and/or the robot lacks conflict resolution. This way the user can track the command queue for either sending commands or the commands received by the robot in order to predict robot behavior. However, I wouldn’t make it a read-only text box, but rather a table that can be manipulated. While the table is sorted by default by timestamp, there will be separate sortable fields for the attribute, the commanded value, the status (pending, seeking, achieved, timeout). If feedback is continuous, then the status should indicate progress towards achieving the target value (e.g., percent, or a progress bar).
If there is synchronous command-sending, then users can edit the commanded values of pending commands or force forward, move, or delete pending commands. In any case, commands can be copied and re-inserted in order to resend any command from any time. Maybe even provide a means to save selected commands and retrieve and insert them later –now you have macro facility.
If the robot tends to be is especially cranky (frequent loss of communications, slow responses), then you may want to have this log table beside the controls for creating commands and viewing the current values. The controls should be set up to make the creation of a discrete command clear to the user. With a cranky computer-to-robot interface, spurious commands are costly, so each command should be well-planned and deliberate. Likely this means a set of field controls like text boxes and drop-down lists to set values of various attributes and a button that generates the command(s) for those values. Awkward, yes, but that’s an accurate representation of the communication link with the robot.
Alternatively, if typically the queues are nearly empty, then you may want to make this table available in a separate window for experts to troubleshoot problems with robot behavior. Normally then the users use one of the other two options I gave above.
Maybe you can use a variation of the command pattern. Each action by the user generates a command, which goes into a queue. The queue is visible to the user in a printout on the screen. So you do not disable the button, but allow the user to press the button multiple times but show the user that the command is queued. At the same time you do not update the labels showing current state of robot until you receive the state from the robot.
In the queue the command could show its status somehow, maybe text and colour. And maybe you should allow the user to delete a command before it is processed by the robot(if that is possible).
So the queue might look like this:
Command Status Result of Action
speed+5 pending speed will increase to 200 (Delete This)
speed+5 pending speed will increase to 205 (Delete This)
speed-5 pending speed will decrease to 200 (Delete This)
and so on.
I have a table column where each row has one of three states, and the purpose of the row is to offer manipulation AND display of this property with three states.
My current development view is to have three tightly packed radio buttons with labels at the head of the columns (and every 50 rows or so) and onClick they send an AJAX request and thar she blows.
This is fugly.
Is there a standard idiom for a control like this? I'm currently mocking up something similar to the iPhone on/off toggle, but with a "middle" state.
Any input would be welcome.
EDIT
A bit more clarification: I have a tool for confirming events. Each event is either "proposed", "cancelled", or "confirmed". They all default to "proposed" until someone explicitly confirms or cancels them. This is a thin front-end for a SQL table.
I've seen this handled with image buttons that remain "depressed" when you click while popping the other two out. They act like radio buttons except that the label and the state are merged. If your names are too lengthy to fit in a button, you can abbreviate them and provide a key. I'd also give each one a distinct color. For implementation just pop the value in a hidden form field on click.
These are called "Toggle Buttons" in some other UI's:
http://java.sun.com/products/jlf/ed2/book/HIG.Controls2.html
http://msdn.microsoft.com/en-us/library/dd940509%28VS.85%29.aspx
http://developer.gnome.org/projects/gup/hig/2.0/controls-toggle-buttons.html
The standard mechanization for things like this in military avionics, where screen space is always at a premium,and so are buttons, is a "rotary". Each time you click it, it steps to the next value in sequence, wrapping around.
As an example, a device with a cryogenic cooler might have three states: OFF, WARM, and COOL. Initially, the device is OFF: no power applied. Click it, and it switches to WARM, meaning power is applied, but no cooling. Click it again, and it starts the cooler. (Since cooling in this kind of thing is usually supplied by a gas bottle with a strictly limited capacity, you don't want to cool the device until you are getting ready to party.) Click it again, and it shuts the device OFF.
You could also do this with buttons or hyperlinks. In a big table, hyperlinks will probably look best.
In the Proposed state, your cell could look something like this (with underlined links, but the editor won't let me):
Proposed Confirm Cancel
In the Confirmed state:
Confirmed Undo
In the Cancelled state:
Cancelled Undo
This will take two clicks to get from Confirmed to Cancelled and vice versa, but I assume that this operation is rarer than switching between Proposed and one of the other two.
Perhaps display arrows on either side to change the state:
(Cancelled) <| Proposed |> (Confirmed)
These may or may not 'wrap' depending on how well that suits the values and how important it is to saving a click when transitioning from value 1 to value 3 (or vice-versa).
As an alternative to you radio buttons, you could consider a drop-down list with three options. The disadvantage is, of course, that two clicks are needed to change the value.
Maybe use a slider with three states? (It really depends on the exact situation!)
Consider a fixed-position slider with three positions, such as offered by jQueryUI: http://jqueryui.com/demos/slider/#steps
I am reminded of the permissions button in SQL - it has multiple states; green check, red x, no setting, and clicking on them cycles through the three states. Its ok but annoying if you want to change a bunch to the state reached second, and if you click too many times you have to go through it all again. Left click - cycle forward; right click - cycle backward might work but certainly has no basis in UI expectations.
Idiomatically, I would say a Stop Light (red/yellow/green). They could behave like radio buttons; darker toned for 'off' and lighter tones for 'on', and since the color gives a cue you can move the description to a mouseover label. Of course, it isn't RG Colorblind kosher, so depending on your application that may be a deal breaker. (also, it may be confusing on Mac where the minimize/close etc buttons are the same color scheme).
Why not use three boxes that look like the "Questions", "Tags", "Users", ... boxes on this page (could be implemented as links, buttons or whatever)?
I am designing the (G)UI of a program, and have stumbled across a problem; The program will convert a number into different units, and the layout of a unit been converted to is:
[Unit name (when clicked gives information)]
[Special status, if any]
[Output in textfield that can also be used for input (to convert to other units)]
I want the user to be able to copy an outputnumber onto the clipboard, without having to mess around with highlighting and finding the right buttons to press. So, I thought I'd make a button after the text-output field, saying something like "C" or "Copy".
But I was reading on joelonsoftware.com yesterday, and discovered that users seem to be cursorclumsy. So what should I do?
I've thought about a number of different options:
Click on textfield to copy to clipboard - BUT: I want to use it for input as well
Pressing a numeral on the keyboard to copy the respective one - BUT: There will probably be more than 10, and I need them for new input
Bigger Copy button, like on that actually says "Copy" - Hmm, would this work? I know that I like to use the keyboard when I can, so a solution involving it would be nice.
Each unit will have its own space, where everything (name, textfield etc.) fits in. What if it would copy to clipboard when clicked anywhere in that space except for on the name or textfield. - BUT: What if you miss, meaning to click below one textfield, and clicking above another?
But what about highlighting the unit's space as I went along? - Could still mean trouble...
What do you think? I think I just might opt for #3 - Bigger copy-button..
There's nothing wrong with a Copy button after every field if you feel that it's going to be a very common operation.
Two suggestions, however:
In terms of look and feel, make sure that the button is clearly associated with the field. For a text field, the best way to do this is to put the Copy button inside the text field (on the right side - but be prepared to handle RTL languages by switching its position as needed!).
To avoid making it overly big, don't use any text, but rather use the stock Windows icon for Copy (like this one: ), and put the text into its tooltip. If you do that, you may also get rid of button border entirely, further reducing its size, though you'd still want some visual hover indicator to make it clear that it's an active UI element. In fact, you might want to specifically copy Vista/Win7 Explorer (also seen in IE7/8) UI for location field and the Reload icon in it.
I think the solution #3 is the best in your list, but I would like to see a sketch of your GUI.
What ever you do, it is important to use the OS standard keyboard and mouse event bindings and preferable look-and-feel too otherwise users get confused.
For sheer speed, the keyboard is the way to go. How about letters A-Z to copy the text boxes instead? Skip “E” to allow scientific notation to be inputted. Potential speed is high, but learnability is low. I’d expect users will have a hard time figuring out this UI even with explanatory text on the page/window, and if users have to read explanatory text, then the time that takes will likely negate the time savings of the UI, unless the user is using the app all the time (Joel also writes correctly that users hate to read).
For an app that will be used only occasionally, the big button is a better choice, the bigger the better, as predicted by Fitts’s Law. And absolutely label it “Copy,” not “C” and not an icon, to maximize learnability. Your other ideas have learnability and tolerance issues without the speed of the keyboard.
That said, I think you’re taking what Joel says too far. Certainly you want to eliminate unnecessary clicks, but the typical design for this type of app would require one click on the text box (which should by default highlight the whole value) followed by one click on a Copy menu item –or better, Alt-C or Ctrl-C from the keyboard. It’s hard for me to imagine a task where saving one click or a couple keyboard presses would be worth the clutter of a bank of Copy buttons beside your text boxes. Are you also going to have buttons for Paste and Clear? At some point the clutter will slow your users down more than the extra click.
How often are users going to be copying? If it’s really dozens of times per session, then you should re-think the whole design approach because any copying and pasting of one number at a time is going to get tedious. Maybe you should support batch processing, taking multiple numbers at once and outputting results in a form already suitable for the expected use. Maybe have it work within other apps like the way Enso does: user highlights a number in any document or text field of any app, commands Convert - Feet - Meters and it’s changed in the document or field.
If you accidentally click on the wrong area, you could just click on the right area after that. If your issue lies in the user not knowing when they click on the wrong area, just highlight the last-clicked area.
Is there a problem with copying whatever is in the textfield when they click on it? So what if it's being used for input? They're just going to copy the value they need after they type values in.
You could also have a ctrl-click or shift-click in the text box be a copy.
Most people know how to copy text on their own computer. Perhaps the best solution is to just auto-highlight all the text in a textbox when it gets focus so they can just ctrl-c to copy or start typing to begin input.