[drupal-devel] New themeable function for buttons?
The theme_confirm() function contains the following code: <?php $output .= '<div class="container-inline">'; $output .= form_submit($yes ? $yes : t('Confirm')); $output .= l($no ? $no : t('Cancel'), $path); $output .= "</div>\n"; ?> The use of HTML links, such as 'Cancel,' along side form_submit() will be more common in the future. I am planning on changing all the Delete buttons, which should go to a confirmation page, to links. I don't think that this has been fully documented, but I think it is an accepted de facto standard now. The main rule of thumb is that links should never change anything. I think a themeable button wrapper function is needed. The above code could be: <?php $buttons = array(); $buttons[] = form_submit($yes ? $yes : t('Confirm')); $buttons[] = l($no ? $no : t('Cancel'), $path); $output .= theme('buttons', $buttons); ?> <?php theme_buttons($buttons = array()) { return '<div class="container-inline">'. implode('', $buttons) .'</div>'; } ?> I have two specific questions for the list: 1. Does this look like a good idea? Does anything need to be changed for better themeability? 2. Does this interfere with any other possible changes to form output? -Neil
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 How about a form_buttons, like we have a form_radios ? On 07 Jul 2005, at 1:08 AM, neil@civicspacelabs.org wrote:
The theme_confirm() function contains the following code:
<?php $output .= '<div class="container-inline">'; $output .= form_submit($yes ? $yes : t('Confirm')); $output .= l($no ? $no : t('Cancel'), $path); $output .= "</div>\n"; ?>
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCzHgxgegMqdGlkasRAtp3AJ0alDyg18cmXAPQ5NXq8h587lalLACgjBh/ jsmuH58QcGFHLeJRMiPDAwE= =CPf6 -----END PGP SIGNATURE-----
The Cancel link next to the button is wrong, imo. I don't like it. Cancel is an action even if it doesn't cause something in the database to be updated. In fact, it does update the db - as does every click on every link. Therefore we need to look at it from the user's perspective. Cancel is an action. It should be a button. Cancelling a process is most definitely different than navigating to the homepage. "Home" should be a link, Cancel, Submit, Delete, Confirm, Contact, Reply, Vote etc are all actions and should be buttons. I think the confirm link next to the button is ugly too and I think making the delete button a link would be a big step backwards in user friendliness. Making the cancel button into a link was a mistake and I'd like to see it undone. Cancel is an action. It is a verb. Don't expect the user to understand that the Delete button only called up a form which enables them to delete if they press delete again. From their point of view, they took an action by saying Delete in the first place. The confirmation screen should have Confirm and Cancel (both buttons). After all, the user already took the action of initiating a Delete - why should the Delete button appear twice? That's another issue, though. -Robert neil@civicspacelabs.org wrote:
The theme_confirm() function contains the following code:
<?php $output .= '<div class="container-inline">'; $output .= form_submit($yes ? $yes : t('Confirm')); $output .= l($no ? $no : t('Cancel'), $path); $output .= "</div>\n"; ?>
The use of HTML links, such as 'Cancel,' along side form_submit() will be more common in the future. I am planning on changing all the Delete buttons, which should go to a confirmation page, to links. I don't think that this has been fully documented, but I think it is an accepted de facto standard now. The main rule of thumb is that links should never change anything.
I think a themeable button wrapper function is needed. The above code could be:
<?php $buttons = array(); $buttons[] = form_submit($yes ? $yes : t('Confirm')); $buttons[] = l($no ? $no : t('Cancel'), $path); $output .= theme('buttons', $buttons); ?>
<?php theme_buttons($buttons = array()) { return '<div class="container-inline">'. implode('', $buttons) .'</div>'; } ?>
I have two specific questions for the list:
1. Does this look like a good idea? Does anything need to be changed for better themeability?
2. Does this interfere with any other possible changes to form output?
-Neil
+1 Robert Douglass wrote:
The Cancel link next to the button is wrong, imo. I don't like it.
Cancel is an action even if it doesn't cause something in the database to be updated. In fact, it does update the db - as does every click on every link. Therefore we need to look at it from the user's perspective.
Cancel is an action. It should be a button. Cancelling a process is most definitely different than navigating to the homepage. "Home" should be a link, Cancel, Submit, Delete, Confirm, Contact, Reply, Vote etc are all actions and should be buttons.
I think the confirm link next to the button is ugly too and I think making the delete button a link would be a big step backwards in user friendliness.
Making the cancel button into a link was a mistake and I'd like to see it undone. Cancel is an action. It is a verb. Don't expect the user to understand that the Delete button only called up a form which enables them to delete if they press delete again. From their point of view, they took an action by saying Delete in the first place. The confirmation screen should have Confirm and Cancel (both buttons). After all, the user already took the action of initiating a Delete - why should the Delete button appear twice? That's another issue, though.
-Robert
On Thu, 07 Jul 2005 06:59:37 +0200, Robert Douglass <rob@robshouse.net> wrote:
The Cancel link next to the button is wrong, imo. I don't like it.
Cancel is an action even if it doesn't cause something in the database to be updated. In fact, it does update the db - as does every click on every link. Therefore we need to look at it from the user's perspective.
Cancel is an action. It should be a button. Cancelling a process is most definitely different than navigating to the homepage. "Home" should be a link, Cancel, Submit, Delete, Confirm, Contact, Reply, Vote etc are all actions and should be buttons.
I think the confirm link next to the button is ugly too and I think making the delete button a link would be a big step backwards in user friendliness.
I'm with Robert. Everytime I see the Cancel button as a link, it just seems wrong. Both Confirm and Cancel should be buttons (and Delete should remain a button). -- Tim Altman
On Wed, Jul 06, 2005 at 04:08:09PM -0700, neil@civicspacelabs.org wrote:
The use of HTML links, such as 'Cancel,' along side form_submit() will be more common in the future. I am planning on changing all the Delete buttons, which should go to a confirmation page, to links. I don't think that this has been fully documented, but I think it is an accepted de facto standard now. The main rule of thumb is that links should never change anything.
I was expecting (and hoping to avoid) some debate of the basic issue. I certainly didn't expect this reaction. I was sceptical of the links next to buttons idea at first. The reasons that convinced me to approve of this approach are: - Helped visually distinguish the actions. You probably want to click 'Delete' rather than 'Cancel.' - Buttons do POST and links do GET, which fits with what the respective actions actually did. In my recent work trying to standardize on links for 'Delete' which go to a confirmation page I found it was actually significantly easier to do all the destination handling if I was doing links. I did find one supporting weblog at http://www.lukew.com/resources/articles/web_forms.html. You should probably review his logic as well; it is near the bottom. I wanted to do something really simple, but I think I need to bake the concept of primary and secondary actions into a heavier API closer to what Adrian suggested earlier in this thread. I'm don't think theme control of something being a link or button is realistic, that is just asking for problems to arise since the two have rather different properties. For the button vs. link debate for non-consequential secondary actions- this seems like a holy war and the *only way* to resolve this issue once and for all would be doing some user testing. Any volunteers for helping design a test to get valid results and anyone willing to find and provide incentive for test participants? -Neil
participants (5)
-
Adrian Rossouw -
David Norman -
neil＠civicspacelabs.org -
Robert Douglass -
Tim Altman