From: David Cantrell Date: 16:48 on 20 Apr 2007 Subject: Sourceforge: an apology (and Mailman: some hate) I have ranted several times about Sourceforget's customised mailman allowing non-subscribers to post to mailing lists despite being configured not to. Cos I was *sure* I'd turned that option on. Oops, it was turned off. I hate it when I'm the PEBCAK. Mailman is still hateful though. The user interface is that to turn a feature on or off you need to clicky on a button-ish thing, and then scroll the page and clicky on another button. That's bad. While it might be OK in some situations (like, say, when you're deleting a customer from a database) it's not acceptable in this case. What I had done, obviously, was do the first clicky and thought "right, I've turned that on" then hit a link to switch to another page of options, promptly throwing my changes away. FWIW, in my own interwebnet applications, I don't use radio buttons, I have links which the user clicks to immediately submit their choice to the server. For forms with text fields, I also keep the number of options per page low so that a reasonable user won't have to scroll to find the submit button. It'll be right in front of him so it's more immediately obvious that he has to hit it.
From: Andy Armstrong Date: 16:59 on 20 Apr 2007 Subject: Re: Sourceforge: an apology (and Mailman: some hate) On 20 Apr 2007, at 16:48, David Cantrell wrote: > FWIW, in my own interwebnet applications, I don't use radio buttons, I > have links which the user clicks to immediately submit their choice to > the server. That's not very RESTful :)
From: A. Pagaltzis Date: 18:02 on 20 Apr 2007 Subject: Re: Sourceforge: an apology (and Mailman: some hate) * David Cantrell <david@xxxxxxxx.xxx.xx> [2007-04-20 17:55]: > FWIW, in my own interwebnet applications, I don't use radio > buttons, I have links which the user clicks to immediately > submit their choice to the server. GET implies that the client can't be held responsible for whatever change on the server is caused by fetching that resource. If you put things like "Delete record" behind a simple link, and the user has Google Web Accelerator installed or there are any other such intermediaries in the loop, you have just screwed over the user because your application violates the HTTP contract for GET. What you want to do is use single-submit-button forms, not links. (Eg. you have one <form> for each action rather than a link, with a submit button as UI to trigger the action.) Regards,
From: =?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= Date: 21:14 on 20 Apr 2007 Subject: Re: Sourceforge: an apology (and Mailman: some hate) On Apr 20, 2007, at 10:02 AM, A. Pagaltzis wrote: > * David Cantrell <david@xxxxxxxx.xxx.xx> [2007-04-20 17:55]: >> FWIW, in my own interwebnet applications, I don't use radio >> buttons, I have links which the user clicks to immediately >> submit their choice to the server. > > GET implies that the client can't be held responsible for > whatever change on the server is caused by fetching that > resource. [...] David said "user clicks", not "browser will send a GET request". > What you want to do is use single-submit-button forms, not links. > (Eg. you have one <form> for each action rather than a link, with > a submit button as UI to trigger the action.) Ooh, I hate those. Hello slow web-application, please force me to click on your slow slow buttons a dozen times to change a few settings. - ask
From: Adam Atlas Date: 21:22 on 20 Apr 2007 Subject: Re: Sourceforge: an apology (and Mailman: some hate) On 20 Apr 2007, at 16.14, Ask Bj=F8rn Hansen wrote: >> What you want to do is use single-submit-button forms, not links. >> (Eg. you have one <form> for each action rather than a link, with >> a submit button as UI to trigger the action.) > > Ooh, I hate those. Hello slow web-application, please force me =20 > to click on your slow slow buttons a dozen times to change a few =20 > settings. How's that any different from doing it with links, in terms of user =20 interaction? If you really want to, you can even style a button to =20 look exactly like a link.=
From: Timothy Knox Date: 21:33 on 20 Apr 2007 Subject: Re: Sourceforge: an apology (and Mailman: some hate) Somewhere on Shadow Earth, at Fri, Apr 20, 2007 at 04:22:05PM -0400, Adam Atlas wrote: > > On 20 Apr 2007, at 16.14, Ask Bjørn Hansen wrote: > >>What you want to do is use single-submit-button forms, not links. > >>(Eg. you have one <form> for each action rather than a link, with > >>a submit button as UI to trigger the action.) > > > >Ooh, I hate those. Hello slow web-application, please force me > >to click on your slow slow buttons a dozen times to change a few > >settings. > > How's that any different from doing it with links, in terms of user > interaction? If you really want to, you can even style a button to > look exactly like a link. Because some browsers (such as Firefox) and browser accelerators attempt to fetch the first few links on a page *before* the user clicks on them, so that clicking will be much faster. D'oh! Your acceleration just changed your settings. ;-)
From: Peter da Silva Date: 21:43 on 20 Apr 2007 Subject: Re: Sourceforge: an apology (and Mailman: some hate) > Because some browsers (such as Firefox) and browser accelerators > attempt to > fetch the first few links on a page *before* the user clicks on them, > so that > clicking will be much faster. D'oh! Your acceleration just changed your > settings. ;-) Jesus Wept. What happens when the first link is something really really big or on a really really slow server? Or a web-bug? Christ, that's hateful. How do you turn it off?
From: Phil Pennock Date: 02:17 on 21 Apr 2007 Subject: Re: Sourceforge: an apology (and Mailman: some hate) On 2007-04-20 at 15:43 -0500, Peter da Silva wrote: > Christ, that's hateful. How do you turn it off? If memory serves, you look at the explanation of the FasterFox plugin and then go tune everything it touches in the opposite direction. -Phil
From: Adam Atlas Date: 04:29 on 21 Apr 2007 Subject: Re: Sourceforge: an apology (and Mailman: some hate) On 20 Apr 2007, at 16.33, Timothy Knox wrote: > Somewhere on Shadow Earth, at Fri, Apr 20, 2007 at 04:22:05PM > -0400, Adam Atlas wrote: >> How's that any different from doing it with links, in terms of user >> interaction? If you really want to, you can even style a button to >> look exactly like a link. > > Because some browsers (such as Firefox) and browser accelerators > attempt to > fetch the first few links on a page *before* the user clicks on > them, so that > clicking will be much faster. D'oh! Your acceleration just changed > your > settings. ;-) Well yeah, that was my point. (I ain't fer it, I'm agin it!) I was saying that it's just as easy to use buttons to do the same thing (and make them look like hyperlinks if you must), which avoids the problems you mentioned.
From: David Cantrell Date: 22:40 on 21 Apr 2007 Subject: Re: Sourceforge: an apology (and Mailman: some hate) Timothy Knox wrote: > Because some browsers (such as Firefox) and browser accelerators attempt to > fetch the first few links on a page *before* the user clicks on them, so that > clicking will be much faster. D'oh! Your acceleration just changed your > settings. ;-) That is user error as far as I'm concerned. And quite entertaining.
From: Juerd Waalboer Date: 00:46 on 21 Apr 2007 Subject: Re: Sourceforge: an apology (and Mailman: some hate) Adam Atlas skribis 2007-04-20 16:22 (-0400): > >Ooh, I hate those. Hello slow web-application, please force me > >to click on your slow slow buttons a dozen times to change a few > >settings. > How's that any different from doing it with links, in terms of user > interaction? Yes, but that's the browser's fault. In my Firefox at least, I cannot middleclick a submit button to get a new tab. When you want to click multiple such buttons on the same page, that's hateful.
From: =?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= Date: 01:02 on 21 Apr 2007 Subject: Re: Sourceforge: an apology (and Mailman: some hate) On Apr 20, 2007, at 13:22, Adam Atlas wrote: > > On 20 Apr 2007, at 16.14, Ask Bj=F8rn Hansen wrote: >>> What you want to do is use single-submit-button forms, not links. >>> (Eg. you have one <form> for each action rather than a link, with >>> a submit button as UI to trigger the action.) >> >> Ooh, I hate those. Hello slow web-application, please force me =20 >> to click on your slow slow buttons a dozen times to change a few =20 >> settings. > > How's that any different from doing it with links, in terms of user =20= > interaction? If you really want to, you can even style a button to =20 > look exactly like a link. Ah, yes - in my hatred I mixed a few different issues. My hate for =20 the "many forms on one page" is when there are associated input =20 fields. With many forms I can't change all the input fields to do =20 one update. (One variation that works is to have one form but many submit =20 buttons, that all submit the whole form obviously). - ask --=20 http://develooper.com/ - http://askask.com/
From: David Cantrell Date: 22:37 on 21 Apr 2007 Subject: Re: Sourceforge: an apology (and Mailman: some hate) Adam Atlas wrote: > On 20 Apr 2007, at 16.14, Ask Bjørn Hansen wrote: >>> What you want to do is use single-submit-button forms, not links. >>> (Eg. you have one <form> for each action rather than a link, with >>> a submit button as UI to trigger the action.) >> Ooh, I hate those. Hello slow web-application, please force me to >> click on your slow slow buttons a dozen times to change a few settings. > How's that any different from doing it with links, in terms of user > interaction? If you really want to, you can even style a button to look > exactly like a link. A link (or a button, I suppose) doesn't have to submit a GET or POST request directly, it can go via some Javascript doodad that does it in the background. Of course, you do also need a non-Javascripty alternative.
Generated at 10:27 on 16 Apr 2008 by mariachi