15 events
when toggle format what by license comment
Dec 15 '14 at 14:14 comment added Gusdor "put the least effort into any addition editing" - Bravo. This is the root of the issue. Ease vs Accuracy.
Dec 15 '14 at 9:47 comment added Makyen @hvd, That the user may edit the textbox without specifically clicking on the radio button is a good point. Depending on the UI framework it may be necessary to have an event handler select the radio button for the textbox upon a focus or input event in the textbox. It would probably also be a good idea to indicate the selected option in a way that is more obvious than just the radio button being selected. Perhaps use a darker/different colored background for the selected option (similar to what StackExchange does).
Dec 15 '14 at 9:39 comment added Makyen @snotwaffle, I disagree that a tooltip is more appropriate. If this was a system where the user is entering their own personal information, then I would agree that something less would be better. In this system, where the information is being entered by a professional about their client(s), I think it more appropriate to present to the user how the information is going to be used and what it will look like to their client. That way they can make an informed choice as to how it looks to their client. The default, if they just click OK, is to keep it exactly the way they originally entered it.
Dec 15 '14 at 9:33 comment added Makyen @fredsbend Keep in mind that it is, explicitly, not the personal information of the person entering the data. This is "used by solicitors and will-writers to submit client information". Explaining to the user how the information they are entering is going to be presented to their client allows the user to make an informed choice of how they want it to be seen by their client. Offering the user the opportunity to modify the input they have provided based on that information is reasonable.
Dec 15 '14 at 9:18 comment added Agi Hammerthief As others have suggested, a tooltip that warns about all caps (rather than explicitly asking a user what form of input is most correct) is a better solution.
Dec 15 '14 at 8:21 comment added 51426 @snotwaffle That's worse than annoying. I'd be like "really?! It's my personal info. Take it the way I gave it to you or don't take it at all. I don't care if you want it caps'd 'correctly'."
Dec 14 '14 at 14:32 comment added David Z It might make sense to have the system choose the most likely capitalization based on some heuristics and have the corresponding option be preselected. This leads to the lowest number of errors in cases where users just click OK without really thinking about what they're reading.
Dec 14 '14 at 0:54 comment added hvd Don't forget that users don't always pay attention. This approach will likely lead to a significant number of users editing the text in the input box, and clicking "OK", without checking the radio button in front of the text box, unless that radio button is checked automatically when the text box is focused and/or text is entered.
Dec 13 '14 at 13:23 comment added Makyen @HagenvonEitzen, I could go multiple ways on it. Normally I would use an editable menu-list (a drop-down-list; user can select the closest and edit that one), although editable menu-lists are not as well understood by users. In this instance, a primary goal is to encourage the user to input something that is in proper case. Thus, pre-filling that field with what is guessed to result in the least user editing effort looked good. All Upper case hand edit to lower case is PITA->low user compliance. Could record initial/final inputs. Then analyze so end up presenting one with least editing effort.
Dec 13 '14 at 12:16 comment added Hagen von Eitzen This is a nice idea. However, I guess I'd expect that the editable fourth alternative maybe should be the original input (in this case: all-caps) of the user.
Dec 13 '14 at 9:09 history edited Makyen CC BY-SA 3.0
clarify text. Add paragraph making it clear that the user needs to ultimately be in control.
Dec 13 '14 at 8:59 history edited Makyen CC BY-SA 3.0
add a first pass at a popup
Dec 13 '14 at 8:54 history edited Makyen CC BY-SA 3.0
add a first pass at a popup
Dec 13 '14 at 1:56 review First posts
Dec 13 '14 at 9:12
Dec 13 '14 at 1:52 history answered Makyen CC BY-SA 3.0