[Patternfly] Pattern for form actions

Emily Dirsh edirsh at redhat.com
Thu Apr 10 16:21:23 UTC 2014



----- Original Message -----
> From: "Matt Carrano" <mcarrano at redhat.com>
> To: "Gabriel Cardoso" <gcardoso at redhat.com>
> Cc: patternfly at redhat.com
> Sent: Thursday, April 10, 2014 12:11:53 PM
> Subject: Re: [Patternfly] Pattern for form actions
> 
> Agree with you that having the three buttons side by side does not feel
> right.  But I think the problem I have with the Delete button as you've
> placed it is the following.  I expect that the buttons placed in the lower
> right of the form are going to take action on the changes I made to the form
> itself, e.g., Save, Cancel, Clear.  When you place the Delete button there
> it confuses matters in my opinion.  Delete what?
> 
> Deleting the artifact is really a higher level decision.  In other words, the
> first thing the user needs to define here is what they want to do relative
> to the item in question.  Am I here to edit it?  Am I here to delete it?  I
> think what I would do is to introduce a set of separate actions in the
> header of the object to either delete or edit.  So by default the form is
> read-only.  Clicking edit puts the form in edit mode and then the cancel and
> save buttons appear.  I don't think you necessarily need the Clear in this
> case, but you could include it.  I recognize that this forces the user to
> make one additional click to edit the form, but I think it will be
> absolutely clear what they are doing.
> 
> What do you think?
> 
> Matt

+1 to everything Matt said, but I'd also like to add to his point that you really probably don't need the 'Clear Changes' button. It's the same as the infamous HTML 'reset' button which has been pretty universally considered a bad idea because people don't use it (except by accident), and it's destructive. Instead, users are much more likely to either edit the data in the fields if they want to change it, or use the back button (or a cancel button) to abandon the form if they decide not to complete it.

> 
> ----- Original Message -----
> From: "Gabriel Cardoso" <gcardoso at redhat.com>
> To: patternfly at redhat.com
> Sent: Thursday, April 10, 2014 11:39:47 AM
> Subject: Re: [Patternfly] Pattern for form actions
> 
> 
> 
> I assume that you want to keep the number of visible buttons to a minimum
> otherwise there is no point of hiding 'delete' button if the form is dirty.
> I.e., if you want to delete the record, you don't care about the unsaved
> changes you already made.
> Yes, Petr, I want to reduce the information load. The Delete button calls a
> lot of attention (more than the save button actually) and I don’t want to
> make him think (see image below). We are assuming that after the user start
> to edit, he is more likely to save or clear his changes than deleting the
> artefact. That’s why we hide the button.
> 
> 
> 
> 
> We have similar buttons in FreeIPA just with different names:
> - 'Refresh' reload from server - always enabled
> - 'Reset' undo changes - enabled if form is dirty
> - 'Update' save changes - enabled if form is dirty
> 
> We also have 'undo' next to each form control. It's visible only when the
> item is dirty.
> Thanks for sharing!
> 
> 
> 
> These are good questions that you raise. Not sure about Scenario 02 either.
> In other places I have seen a "Revert" button that I think does the same
> thing you are proposing for "Clear Changes". Not Sure what "Delete" is doing
> in this context. I'm generally not a big fan of buttons appearing and
> disappearing or changing names.
> Matt, we need somehow to allow the user to delete the artefact. I’ll take the
> Push page as example. We don’t have a list of Push resources, so the only
> place where the user can delete a push is inside the Push page. This page
> illustrates the scenario 02:
> 
> - Initial state (not modified)
> 
> 
> - After making changes
> 
> 
> I’m not a big fan of dancing buttons as well, but I think this is better than
> the three buttons side by side (like above). What do you think?
> 
> And finally, that will be the initial state for the scenario 01:
> 
> 
> Thanks,
> 
> Gabriel
> 
> ---
> Gabriel Cardoso
> User Experience Designer @ Red Hat
> 
> 
> _______________________________________________
> Patternfly mailing list
> Patternfly at redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly
> 
> _______________________________________________
> Patternfly mailing list
> Patternfly at redhat.com
> https://www.redhat.com/mailman/listinfo/patternfly
> 




More information about the PatternFly mailing list