|
Design Decision No.2
Okay, my user form is full of textboxes, checkboxes and radio buttons (all displayed in a very userfriendly way).
The form also has a preview box.
As the user types and clicks, the preview box updates itself automatically.
As a nice touch I have added an Edit button, that way if the preview is not exactly what the user wants, they can click edit, the preview box turns into a rich text box and becomes editable.
The problem with this is that if the users makes an update to any of the aforementioned textboxes, checkboxes, and radio buttons, the preview will auto update, losing any of the users changes.
My question is how best to handle this?
I am loathe to put any other buttons on the form, so would prefer (and think we can) avoid this.
1. Don't allow auto changes once the preview has been edited. Changes are over until the form is restarted.
2. Don't allow changes while the preview box is in 'preview' mode. If the user types/clicks the other controls while in Edit mode, perhaps a box pops up
"The automatic preview feature is turned off while in Edit mode (with a 'do not display this message again' checkbox)".
The user will learn quick enough that if they turn Edit mode off, then the autoupdate will work, and they will lose any changes. I wouldn't put this in a msg box, as I think msg boxes should be one line only. Too much info = 'dont bother reading, just press okay'
3. Once the Edit has been used, whether turned on or off, if the user types/clicks the other controls, then a message will pop up warning them that all changes will be lost (okay or cancel).
I don't like this idea too much as it would require too much writing in the msg box.
4. Whether the box is in edit mode or not, the auto update still works, no msg at all to the user, he will figure it out quick enough.
5. The autoupdate works only when not in edit mode, but still no msg to the users, he will figure it out.
I am prefering option 2.
It allows a single advisory message, but does not go further, and does not see the user faced with msg boxes all the time.
Aussie Chick
Monday, January 5, 2004
There was a thread a while ago that discussed whether to disable controls or not. In this case, I think you should disable them. Consider this design:
1. The rich-edit text box is always active.
2. Delete the "Edit" button, and put a "Revert" button instead. It starts out disabled.
3. The moment the user modifies the text box manually, disable all the other controls and enable the "Revert" button.
4. (Optional) Draw a text label below the edit box, something like "Edit this text only after you finish using the automatic tools."
5. If the user presses "Revert" then restore the text to the state it was before the user started editing it, and re-enable the other controls.
This way you don't need to use any message boxes, and the modality is made more explicit.
For extra credit, use "Undo"/"Redo" buttons instead of just "Revert".
Oren
Monday, January 5, 2004
interesting.
my response:
1. The main reason I like the preview (richTextbox) disabled is it stops the form from being overhwelming.
However perhaps the button could change from 'Edit' to 'Revert' once activated.
2./3./5. This is actually quite interesting, the term 'revert' may be a little confusing at first, but this still makes an interesting method.
Lets call the above 4 points option 6. (as in I had already pasted 5 options, this is a sixth option). This option could forgo the need for any msgboxes popping up.
4. I am glad you said optional because I am sorry but I would never do this. It is clutter, it is unnessecary writing, which the user may read once and completely understand, and yet the label will always stay there, looking messy and yets it functionality is over.
Aussie Chick
Monday, January 5, 2004
As I haven't seen the form you may have done some of this already.
Have two controls, the preview control and the editable control. Have them at the same location and hide and disable whichever is appropriate. At the end of editing refresh the preview control as you enable it and make it visible.
Disable the other controls as appropriate.
For signage, rather than 'Edit' use 'Change' and whilst the editable control is visible rename the button to 'Preview'. You could have a comment line beneath the control (above won't be read), saying 'To use your changes return to Preview' or similar. If you have an overall Save button then obviously that commits the current changes regardless of how they've been done.
Simon Lucy
Monday, January 5, 2004
Update the model when the (edited) preview looses focus. That way all the editable views (the ones ascociated with your other control parts) will always be synchronised.
If you can't reverse parse the freetext edits to the proper model parts, you should make it clear that this is an output only post-creation operation, that will not be reflected in any persistent state change.
I prefer putting such a thing in a separate environment, by placing it on a separate form with an appropriate warning ("edits will not be saved"?), which you navigate to by appropriate means (e.g. a "render" or "preview" button or a separate "output" tab).
Just me (Sir to you)
Monday, January 5, 2004
>Have two controls, the preview control and the editable control. Have them at the same location and hide and disable whichever is appropriate. At the end of editing refresh the preview control as you enable it and make it visible.
Not sure what you are getting at with this, but I have used the one control, and just change the backcolor, and disabled it to give it the impressions of a 'preview only' box.
I don't see why maintaining both edited and unedited views would be any good.
If I were a user and was viewing a control, then chose 'edit' I would not wish to see the control that I had edited 2 minutes ago appear, I would wish to see the control I was looking at become editable.
>For signage, rather than 'Edit' use 'Change' and whilst the editable control is visible rename the button to 'Preview'. You could have a comment line beneath the control (above won't be read), saying 'To use your changes return to Preview' or similar.
I prefer Edit to change (anyone else think otherwise), and as both modes (edit and not-edit) are a 'preview', I don't think I would do that.
>If you can't reverse parse the freetext edits to the proper model parts, you should make it clear that this is an output only post-creation operation, that will not be reflected in any persistent state change.
Yes, it cannot be reverse parsed (as you say), and yes, but the question is 'how to make it clear"? This is kind of why I like option 2 & 6 of the suggested methods, both make it clear in a subtle nice way.
>I prefer putting such a thing in a separate environment, by placing it on a separate form with an appropriate warning ("edits will not be saved"?), which you navigate to by appropriate means (e.g. a "render" or "preview" button or a separate "output" tab).
Do you mean pressing the edit button pops up another form to allow editing?
This is also a subtle way of doing it I suppose. Worth considering at least.
Aussie Chick
Monday, January 5, 2004
I don't think any of the options you've presented are really ideal.
As a user, if I have to enter data a second time, then I'm annoyed at the poor design of the form (normal users are just annoyed and frustrated ;).
I'd prefer one of the following since they don't result in lost data:
1) I've made changes to the radio buttons etc. I click to edit the preview box. All my previous changes should be saved. While I'm editing, the radio buttons etc should be disabled to prevent me from changing them and losing my changes.
2) I've made changes to the radio buttons etc. I click to edit the preview box. All my previous changes should be saved. If I change the radio buttons while I'm editing, the program should remember the values I've entered or automatically update the form. Once I'm done editing, I should be able to save the new changes.
Also, if the preview box updates automatically, why don't the rest of the fields? Conversely, if you have to save the form anyway, why don't you have to save the preview box? We find that this kind of inconsistency in behaviour can cause user confusion.
Phibian
Monday, January 5, 2004
The user wouldn't notice any difference, other than it became editable, but changes would not affect the preview and so the user could change their mind about editing.
Simon Lucy
Monday, January 5, 2004
I think I'd need to play with the app to have a good suggetsion, but perhaps this will help:
Make the dialog have two tabs, and put the editing stuff on a second tab that doesn't have the buttons and options...
Harvey Motulsky
Monday, January 5, 2004
It seems to me that the process has two steps: do automated editing, then fine-tune with the edit control. Perhaps you could make this more explicit.
Don't show the edit box, just a button: 'edit'. When the user clicks it, hide all the other controls and show only the edit box. Change 'edit' to 'back' and provide a warning dialog (with a 'don't show me this again' checkbox) if 'back' is clicked.
This solution has the added benefit that the manual editing takes place in a decent-sized edit control; you're not wasting space with a slew of disabled controls.
This is all barring the possibility of reverse-parsing the custom edit, which is the ideal solution.
First Timer
Monday, January 5, 2004
Yes, though it has been mentioned, reverse parsing is not an option at all.
The idea is that using the edit box, the user can make any changes they want. This could include adding an extra line to the end, which does not relate back to any of the input controls.
I had thought that in a future addition I may implement some sort of “reverse parsing”, but it would be a large job and have many design issues of its own, so whether it is possible or not, I will leave this possibilty to another release.
I would rather not have the user be taken to another screen for editing. If it came to that, then (as the ‘insert’ button inserts the preview straight into the word document) I would let the user do editing in the word document, which would be far more functional then my editable preview box.
Perhaps the answer is to not allow editing at all? And yet, I think that the minute amount of additional functionality that being able to edit the preview allows, is nice.
Aussie Chick
Monday, January 5, 2004
Not knowing what the dialog is for or how it's used, it's hard to say whether the edit box is required or not. If editing can be deferred to Word, do so -- that's what it's there for. What's your argument for having your own edit box? A "minute amount of additional functionality" doesn't sound like it's worth the potential confusion and frustration of lost editing.
First Timer
Tuesday, January 6, 2004
> doesn't sound like it's worth the potential confusion and frustration of lost editing.
I am beginning to think the exact same way.
Aussie Chick
Tuesday, January 6, 2004
 Recent Topics
Fog Creek Home
|
