Last modified: 2014-01-29 18:12:21 UTC
For consistency, when editing, the 'Cancel' link should really be a button along with the other buttons on the line, since it is an action like the rest of them even if it isn't directly tied to the form itself. The help link should also probably be removed entirely from at least the default installation, as no help pages actually come with said installation and thus the link doesn't go anywhere. Expecting wikis at this point to write their own editing help pages is also pretty silly, as there tend to already be much more thorough such pages on other wikis such as enwp, meta, and similar, and new projects can merely refer to those instead if needed. For any projects using the WikiEditor extension, though, having a link at all is redundant anyway as the toolbar the extension provides includes a navigable help menu directly in it. Ignore the other stuff, but the line of buttons would look something like on this: http://commons.wikimedia.org/wiki/File:Enwp_edit_20120917_with_even_less_stuff.png
You're conflating issues here. This bug should _only_ be about the "Cancel" link. Anything else (such as the "Editing help" link and its interaction with the WikiEditor toolbar) should be filed as separate bugs. I'm changing this bug's summary from "'Cancel' link when editing should be a button, and 'Editing help' link is silly" to ""Cancel" link when editing a page should be a button".
Okay.
The following html should work for this: <a href="/wiki/pagename" title="Pagename" id="mw-editform-cancel"><input type="button" name="Cancel" value="Cancel"/></a>
I disagree that the "cancel" link *must* be a button. If there were different visual treatments to the various buttons, then it could work as a button with an alternate treatment. However, since all buttons have the same visual treatment, then the "destroy" action must have different treatment. Ergo, it shouldn't be a button. This should be closed unless the buttons get different visual treatments.
(In reply to comment #4) > I disagree that the "cancel" link *must* be a button. If there were different > visual treatments to the various buttons, then it could work as a button with > an alternate treatment. > > However, since all buttons have the same visual treatment, then the "destroy" > action must have different treatment. Why does it need to be different? The meaning of 'cancel' is pretty unambiguous.
If there were only two actions ("save" and "cancel"), even then. The positioning of the actions is important: (in LtR languages) left actions are "backwards" and right side actions are "forwards". We are not talking about the "word as written" but rather the "word as perceived". There have been about 4234523452345234532 studies done where human beings ignore the text "cancel" and simply click the button because they think it means something totally different.
On the contrary, the save is the one that needs to be distinct, not the cancel, or that will really confuse people. Yes, different systems use different orientations, but it generally still works just fine - partly just because people are used to it at this point, but also because one button is consistently distinct: the one people care about. The save. The english wikipedia was right to bold that one. It should be bolded on all of them. And the cancel link should really be a button if it is going to be there at all.
The other consideration that should be made here is that MediaWiki core may end up using different styling/button positions than VisualEditor (which currently has one large, green "Save page" button _above_ the textarea).
(In reply to comment #8) > The other consideration that should be made here is that MediaWiki core may end > up using different styling/button positions than VisualEditor (which currently > has one large, green "Save page" button _above_ the textarea). Having a button above the text area is not unprecedented - there was a labs feature that added a 'Publish' and a 'Cancel' button at the top right above the textarea. I've used it to cancel before, since it's in a convenient and expected place; dunno that I've ever used the link by the usual buttons. It really stands out with the VE sandbox, but that's the model both VE and the current editor should be following, regardless of positioning - a cancel button is intuitive. Having to click on the 'page' tab is not, and yet that is still more so than a text link that gets lost amidst the other text.
Minor update!
Can I work on it?
Having Cancel be a link instead of a button is not unprecedented in designs, and in fact would be preferred for a couple of reasons: 1. Making them both buttons would put extra emphasis on the Cancel action, making it more likely that users will accidentally click it and wipe their edit. 2. If a user does not wish to actually edit, and the Cancel link is removed entirely, they may not know that they can also cancel the edit by clicking another link elsewhere (does anybody have info on how many times the cancel link is clicked vs how many edits are cancelled via other means?) If we need to be messing with the buttons, I'd say we need to be putting additional emphasis on the "Save page" button rather than further emphasizing "Cancel". Interesting further reading on the topic: http://www.lukew.com/ff/entry.asp?571=
(In reply to comment #12) > If we need to be messing with the buttons, I'd say we need to be putting > additional emphasis on the "Save page" button rather than further emphasizing > "Cancel". There are some bold plans about doing just that, Steven and Jon (CC'd) know more about them than me. I think you can play with a reasonably current demo at http://ee-flow-extra.instance-proxy.wmflabs.org/wiki/Main_Page (use the "Agora styling" menu on the left).
Okay, so I'm inclined to say this ain't worth doing. Closing.
