Kill the Page Action button — As a user interface fiddler one of the first things I noticed here was that the Page Action mechanism has two problems. First, you can't see the choices until you click on the little triangle, so they are usually hidden. Secondly, choosing any but the default choice takes extra seconds of my time, needlessly.
Why not institute a button for each choice?
They would all be visible and choosing one would be easier and quicker.
Expand "Changes to v-1" — Make this choice clearer by rewording to "See latest changes to this page" or even just "See changes".
Yes, one always needs to review and rethink design. Yet Ward's overall design stategy of "inertia" to change has served well. A simple design needs long thinks to get better. Unfortunately, the changing Web environment has required the introduction of impediments instead – as annoying yet evidently as necessary in the public space as speed-bumps in residential districts.
Originally, page actions were just links, but it became clear over time that bots followed these and edit forms were appearing on the search engines. Overloading the server was not an issue, except for when bots triggered searches. A more serious issue was that following edit/save links from outside wiki contexts could automatically trash page content.
Nevertheless, I still use the link format in some authenticated contexts for one-click selections – mainly my own personal wiki instances when I mostly just search and edit. (It's a configurable option in the current codebase to use either mode.) I agree that the two-step selection easily turns annoying, but so do the other measures required today to block browse-by spamming.
Separate link/button entities for each desired function is unfortunately space consuming and easily becomes visually confusing. The separate-button strategy is also more easily hacked by spam scripts than the pulldown. With pulldown and current default, script hacking at worst results in a browse to a random page. (So far.)
Should perhaps point out that the form button as such has really only a single function: to Submit the form to the server. It does not lend itself easily to multibutton layouts triggering several functions. Multifunction actions generally require radiobuttons, checkboxes, selections fileds or dropdowns in the same form to convey a desired action on submit.
The stock browser provides a very primitive UI framework and makes good UI design difficult. I am already divided about presenting "as many" user options up front as is the case... in particular on the edit form – yet I do know many wiki implementations have a score more.
I have resisted the temptation to provide an icon-tab toolbar across the top or down the left edge, as these designs do not scale well into different resolutions. There's a world of difference using the same wiki in 800x600, 1024x768, or 1920x1400. Icon-tabbed pages as found on some web pages, and most project management tools, are generally awful IMHO.
I ultimately chose the pulldown as a "safe" compromise that allows for on-the-fly redefining of available functions without messing with templates or affecting layout. The pulldown is dynamically generated from context, by the way.
Possibly, one could make another default action a user cookie preference... Yes, why not...?
– Bo Leuf
—
(correlates: Spam Patrol, SiMonumentumRequiris, LineariZation, ...)