Buttons for Post, Links For Get
Still with buttons. How many of you have added an "Edit Document" button to a form, which has an @Command([EditDocument]) call behind it, which translates to a _doClick() call on the web? That's right, we all have!
Well, from now on, I plan to never use another button with an @Function behind it. So, how would I go about adding an edit document button?
Remember I talked about a codeless edit button before? That, I suppose, was a bit of a hack. Well, using yesterday's trick will can simplify the form a little, so it becomes:
<form action="/db.nsf/0/ComputedDocIDHere" method="get"> <input type="submit" name="EditDocument" value="Edit" /> </form>
Which simply results in a request to GET the URL /db.nsf/0/DocID?EditDocument=Edit
Still an odd way of doing things though, don't you think? It takes me back to a discussion we had last year about the difference between links and buttons. Back then my notion was that buttons were for actions and links were for, ahem, links. Buttons send data. Links fetch pages. Is it as simple as that though? Is "Edit" an action or a link? Technically speaking, it's simply a GET request for a URL that ends in ?EditDocument. So, it could just as well be a link.
I've found myself rethinking the approach and have decided on a new paradigm - buttons for POST, links for GET ("BPLG"). Consider the following table:
| Action | Method | Element Used |
|---|---|---|
| Create Document | GET | Link |
| Save Document | POST | |
| Edit Document | GET | Link |
| Delete Document | GET | Link |
| Approve Workflow | POST |
I can't help thinking it's a little too broad-ranging though. Deleting documents might technically be a GET for us as developers, but it's an action to the user. What then about Close/Cancel buttons? If they do indeed have a place on any form, should they be a button, when, in fact, they are GET requests. My head hurts.
Is there not an accepted standard that defines when to use a link and when to use a button? I've been using BaseCamp more and more recently and I know that follows the BPLG idea. They have links for create, edit, delete and cancel. Buttons are reserved merely for saving documents.
Skip to the 
You can subscribe to an individual
Personally I go for links for all form actions rather than buttons (just marked up in a different way).
Though I understand your need to keep things simple and accessible, for Web Applications JavaScript is a normal requirement and therefore these links typically set a hidden input field and then submit the form.
Of course if the form is in Read mode then there is nothing more accessible then a link. So an edit action should be no more than a href with ?editdocument.
Normally critical actions should not be performed via GETs (like delete document) but with Notes Security this shouldn't be such an issue.
It's not just about what is accessible though. There's also the *usability* factor, which is something completely different. Don't go against what the user expects. A link to submit the form? That goes against the grain IMO.
Depends what the link looks like ;-)
I should clarify that I am talking about a full blown Web Application rather than a simple form (like this comments form).
From a usability point of view I believe as long as your consistent in placement and look and feel (i.e. your actions should be styled different to your links) then this works well.
For a simple form with only 1 action then the submit button is fine.
It's a tricky one.
I've used both options to do various things in my time. There is no hard and fast rule, because you can always find options which violate one or other of the the options.
You could even have a link for WorkFlow approves if it's done as an Agent. /ApproveAgent?OpenAgent&Parameter=docid or some such. Admitidly it's probably not a good idea to expose such information, but it's what I used back in 2000 when I re-wrote my Anime website. It's quick and dirty and does the job. And as only admins can get to see these actual links, then there is no real harm done.
(I did it this way, because not only does it approve or reject the submitted document, but it also updates the user's stats and refreshes a whole series of other documents.)
So it's horses for courses. If it works, use it. If it doesn't, use something else. As Mark says, if you're consistant...
I'm not sure usability is simply a case of being consistent in *your* design. More important is to be consistent with the design of others. It all comes back to the "Don't Make Me Think" school of thought.
I see your point but looking at some applications e.g. hotmail, Amazon which use images + links (at least I am not that bad), Flickr which uses flash and then GMail which uses buttons I do not see major applications being consistent across the board.
Whereas the simple submit button is normally a grey button.
I think the "Don't Make Me Think" school of thought is good (love the book) so my links are styled very clearly as actions with the appropriate CSS based roll over images and have a very descriptive text label so even if the style is removed its very clear what the link(action) will do.
They are also contained in an Actions panel which is placed (normally) top and bottom of the form.
As Mark said in the first comment: don't use GET for deleting docs. For example, Google Web Accelerator 'clicks' GET links on the page and stores it cache for faster retrieval. So GWA can delete a doc even if a user didnt want to. Houston, we have a problem! Do a search on the web for GWA problems with GET and POST. It broke BaseCamp, too.
{Link}
{Link}
{Link}
The best bet for deleting is to have a link that opens a confirm page. This page then has a confirm *button* on it. Seems perverse but that, I think, it what most users expect.
The way I see it, a form would have 3 buttons really. One each for save, delete and cancel. These are actions affecting the data user entered. It doesn't matter if cancel is a get request, user won't care. Button states that user needs to be careful about clicking them. ( ofcourse not all buttons are needed on all places. for example, a Search module, needs one field and one "search" button )
Links could be to open different pages, show popups etc. Users can click on them without thinking much, if they made mistakes, it shouldn't affect anything.
Jake-- curious what your laws are for accessibility in the UK. In the US, I've always undestood the accessibility laws are to accommodate sight impaired (screen readers) and alternate input (kb only, for example).
Is no-JavaScript part of the laws you're talking about? I support simple apps, and flexible designs that work for screen readers, mobile phones, print, etc. But I also support feature-rich applications and fast design time. So I'm very pro-javascript if it makes the app easier for users and doesn't break the app's basic (typically read-only) functionality. If we're trying to expand the utility of web apps, we need to embrace the tools available.
As for gets/posts-- in my exerience, users have no expectation of a button vs. a link. Images that serve as buttons/links also complicate the distinction. Users *definitely* don't know the difference between GET/POST (nor should they need to).
-Seth
N. Bethesda, MD USA
In a previous project we did usability testing on a suite of intranet applications, and users could not connect links with application actions. Users are used to using links as ways to open a new page, link out of the current application, and/or cross-reference with other pages. Computer users have been clicking buttons to perform application actions for way too long to easily override the behavior.
IMHO, anything that relates as an application action is going to be a button. Opening a folder, document, page, etc, will end up in a link. I would look for a strong business case to override these.
Although I am stating the obvious, it should not be forgotten: Webpage buttons mimics real buttons. The technology behind buttons is usually completely irrelevant to the user (post/get).
Webpage buttons is a way to highlight important actions. I think it's very difficult to make rules for what is important in every context. However, Jakes question is interesting. - It had been nice if someone could give a link "for further reading".
@Seth,
No laws as such. Just suggested guidelines. Although if you're developing for Government or local councils then the suggestions, are actual requirements.
On the whole, I find that placement impacts usability far more than appearance.
Consider the behavior of this comments form: because the "Post It!" button immediately follows the last field, its purpose is obvious regardless of its appearance (excluding the label, of course... if it said "Purchase This Kitten", for example, I'd likely be quite confused).
Compare that to the positioning of the Notes client action bar; although I found and experimented with code allowing Domino apps to lock the action bar in place, that ironically confused some of my long-time Notes users... in Notes they're used to the bar staying put, on the web they're used to having to scroll.
Button or link, if the placement makes sense, the user will - more often than not - know intuitively what to do.
BPLG is right and proper, but it assumes that GET has no side-effects. "?DeleteDocument" has a bit of a noticeable side effect. So _can_ "?OpenAgent" (even if the QS is only implied) -- one agent may simply display joined data from a couple of sources, another may cycle through a couple of dozen databases changing field values. The side effects issue should probably be the guiding principal. If the GET is doing more than getting, then it's probably not safe to treat as a simple link.
For something like that, I'd play it by ear. If the client is used to a certain way of doing things, it's easier all round to stay doing something similar.
Every application would have different requirements, and each requirement would need a different approach.
I say, let nature decide what you use - use whatever suits the application itself, rather than trying to force a convention.
I guess get - <a-Tag> and post - button are not linked 100%.
For my feeling post should be used when there is a state change of a document on a server (save but not toggling edit/read mode).
Might be that button should be used for state changes on the client and <a-tag> for surving stuff. Toggling edit/read mode qualifies as state change on the client. close the same.
only speculating
I'm with Jeff here. I'll go a bit further and say that if it has to be a bit more secure (e.g., no caching of any input value pairs) then Posting via buttons is the clear choice for the action in question.
In my recent work, this has come up a lot and I too argued passionately that "actions" should appear as a button no matter the programming details behind it. If it "does something" as opposed to "takes you somewhere", use a button. Document Reads, in this case make sense as links, since that is their historical context. They stem from Ancient Druidic™ hypertext linking, meaning you see more text somewhere else (ala wiki) when you click a link. All of the examples you cite above, Jake, do something, and should be buttons.
In my case, I guess I stand on precedent as the most reliable measure of what is "standard". Static links were in use long before CGI enabled forms with buttons were prolific, and when buttons did appear, most of them were (as someone before me has said) submit buttons.
This is what the HTTP spec says on GET vs POST (or DELETE) and it's recommended implications on UI design:
" In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested."
Read the full text here: {Link}