Earlier quoted context omitted.
OK I'm wrong. I use a Mac every day and thought they didn't do double click. Apparently it's a somewhat subconscious action.
Wasn't that the whole point of the article? How many times did he point that out? More than two: >Everywhere in the Operating System, whether it's Windows or Mac OSX, the default behaviour to navigate between directories is by double-clicking them. We're trained to double-click anything. >Want to open an application? Double-click the icon. Want to open an e-mail in your mail client? Double-click the subject. Double-c…
Double-clicking on the Web
91–100 of 109 posts
Re: Double-clicking on the Web
#92Earlier quoted context omitted.
Subsequent requests to the same token don't have to fail - they just have to silently pass.
That doesn't make the situation any better. Request 1 takes the 'token' Request 2 sees the token gone, returns 'silent success' Request 2 response reaches client, client assumes success. Request 1 fails somewhere internally Request 1 returns failure to client, which has already acted on the success of request 2 User thinks the action was successful, when it wasn't. Now, you can build yourself a lovely two phase commi…
Request 1 submits token
Request 2 submits token
Response 2 returns first with a 409 conflict
Response 1 returns with a 200 OK
It's a question of handling the error codes properly. 409 means resubmit with a new If-Match. Other 400-series errors indicate some other problem with the client's submission.
Actually, if I were reviewing the original author's proposal, I'd say that double-click should be disabled only on
Re: Double-clicking on the Web
#93Earlier quoted context omitted.
That doesn't make the situation any better. Request 1 takes the 'token' Request 2 sees the token gone, returns 'silent success' Request 2 response reaches client, client assumes success. Request 1 fails somewhere internally Request 1 returns failure to client, which has already acted on the success of request 2 User thinks the action was successful, when it wasn't. Now, you can build yourself a lovely two phase commi…
Why not treat this the way a REST web service would? Request 1 submits token Request 2 submits token Response 2 returns first with a 409 conflict Response 1 returns with a 200 OK It's a question of handling the error codes properly. 409 means resubmit with a new If-Match. Other 400-series errors indicate some other problem with the client's submission. Actually, if I were reviewing the original author's proposal, I'd…
Re: Double-clicking on the Web
#94HTTP already handles this just fine if you have sensitive forms: your form can include a one-time token which your server validates. If the token has already been used, you don't process the second request. What we definitely shouldn't do (as the author suggests) is disable form submissions on subsequent clicks. What if the first response fails? You'll have to enter the entire form all over again, instead of being ab…
Even before I got into web dev, I assumed something like that one-time-use token could be implemented to solve the problem. But back in the day, every online store had explicit instructions to "only hit submit once". Why didn't they just use the token solution?
Re: Double-clicking on the Web
#95Earlier quoted context omitted.
Why not treat this the way a REST web service would? Request 1 submits token Request 2 submits token Response 2 returns first with a 409 conflict Response 1 returns with a 200 OK It's a question of handling the error codes properly. 409 means resubmit with a new If-Match. Other 400-series errors indicate some other problem with the client's submission. Actually, if I were reviewing the original author's proposal, I'd…
This has nothing to do with REST, the same issues exist.
The same issues do not exist. Response 2 does not return "silent success" it returns 409 Conflict. The client can distinguish between conflict & success.
Re: Double-clicking on the Web
#96Earlier quoted context omitted.
never a good idea to camelCase html attributes :) (in case you didn't know, this won't work: $('form').attr('onlyOnce') but this will $('form').attr('onlyonce') if your attribute is written as onlyOnce
Mixed case in attribute names is perfectly valid HTML, and tag and attribute names are case insensitive. If jQuery attribute selection isn't, then maybe it should be considered a bug in jQuery. That's not to say that it isn't a bad idea, but I don't think the inconsistent behavior in jQuery should be considered in arriving at that conclusion.
Re: Double-clicking on the Web
#97Earlier quoted context omitted.
Mixed case in attribute names is perfectly valid HTML, and tag and attribute names are case insensitive. If jQuery attribute selection isn't, then maybe it should be considered a bug in jQuery. That's not to say that it isn't a bad idea, but I don't think the inconsistent behavior in jQuery should be considered in arriving at that conclusion.
no it's not valid html.. that's like saying writing gibberish is valid HTML. You can't read mixed case attribute names.. jQuery nor Javascript. It's always converted to lowercase without you knowing.
Why would you say these things without looking it up in the w3 reference (http://www.w3.org/TR/html-markup/documents.html#case-insensi...) or just trying it out (http://5ccf7f9c97075d1b.paste.se)
Re: Double-clicking on the Web
#98Browser makers like Mozilla think it's appropriate that holding down F5 should repeatedly pummel the server in accord with keyboard repeat rates. It's like the browser makers are being intentionally hostile towards web servers. E.g. https://bugzilla.mozilla.org/show_bug.cgi?id=224026 https://bugzilla.mozilla.org/show_bug.cgi?id=873045 There's no excuse, but they don't fix it.
So rather than fix your one server to be more robust, every one of the thousands of browsers that exist should change?
Re: Double-clicking on the Web
#99Earlier quoted context omitted.
That is a poor deflection of the underlying point. It's absurd to conclude that an obviously undesirable behavior -- however unlikely to pose a problem in reality -- should not even be considered let alone addressed. It could be as simple as a modest global rate limit on repeated GET requests to the same URL. We could start with 250 msec and see how that goes. Or it could be as simple as limiting F5 reloads to once p…
what's absurd is protecting the server from a vanishingly rare accident by changing the client. if you feel you need to be protected, put that protection where it belongs, on the server, where it works against more likely things as well.
Re: Double-clicking on the Web
#100Earlier quoted context omitted.
Wasn't that the whole point of the article? How many times did he point that out? More than two: >Everywhere in the Operating System, whether it's Windows or Mac OSX, the default behaviour to navigate between directories is by double-clicking them. We're trained to double-click anything. >Want to open an application? Double-click the icon. Want to open an e-mail in your mail client? Double-click the subject. Double-c…
Following a link and opening a directory are distinct enough in most people's minds to not confuse the two. That's why hyperlinks are normally underlined, colored, and give you a different mouse cursor.
Hyperlinks do not necessarily have to be triggered by single clicks. In HyperTIES, single clicking on a hyperlink (either inline text or embedded graphical menus) would display a description of the link destination at the bottom of the screen, and double clicking would follow the link. That gave users an easy way to get more information on a link without losing their context and navigating away from the page they were reading. Clicking on the background would highlight all links on the page (which was convenient for discovering embedded graphical links in pictures). [3] [4]
The most recent anecdotal evidence close at hand (in the sibling and grandparent comments to yours) that it's confusing is that nailer did indeed confuse double clicking with single clicking in his memory, not remembering that he subconsciously double clicks on Macs all the time.
I would argue that much in the same way the Windows desktop gives users an option to enable single-click navigation like web browsers, web browsers should also give users an option to enable double-click link navigation like HyperTIES, so a single click can display more information and actions related to the link without taking you away from your current context, and a double click navigates the link. (Of course in the real world, scripted pages and AJAX apps probably wouldn't seamlessly support both styles of interface, but double click navigation could be built into higher level toolkits, and dynamically applied to normal links by a browser extension.)
In order to make a sweeping statement like "Following a link and opening a directory are distinct enough in most people's minds to not confuse the two" you would have to perform user testing -- you can't just make up statements like that without any supporting evidence. Can you at least refer me to some empirical studies that support your claim, please?
[1] http://www.cs.umd.edu/hcil/hyperties/
Starting in 1982, HCIL developed an early hypertext system on the IBM PC computers. Ben Shneiderman invented the idea of having the text itself be the link marker, a concept that came to be called embedded menus or illuminated links. Earlier systems used typed-in codes, numbered menus or link icons. Embedded menus were first implemented by Dan Ostroff in 1983 and then applied and tested by Larry Koved (Koved and Shneiderman, 1986). In 1984-85 the work was supported by a contract from the US Department of Interior in connection with the U.S. Holocaust Memorial Museum and Education Center. Originally called The Interactive Encyclopedia Systems (TIES), we ran into trademark conflicts and in 1986 changed the name to HyperTIES as we moved toward commercial licensing with Cognetics Corporation. We conducted approximately 20 empirical studies of many design variables which were reported at the Hypertext 1987 conference and in array of journals and books. Issues such as the use of light blue highlighting as the default color for links, the inclusion of a history stack, easy access to a BACK button, article length, and global string search were all studied empirically. We used Hyperties in the widely circulated ACM-published disk Hypertext on Hypertext which contained the full text of the 8 papers in the July 1988 Communications of the ACM.
[...]
Today, the World Wide Web uses hypertext to link tens of millions of documents together. The basic highlighted text link can be traced back to a key innovation, developed in 1983, as part of TIES (The Interactive Encyclopedia System, the research predecessor to Hyperties). The original concept was to eliminate menus by embedding highlighted link phrases directly in the text (Koved and Shneiderman, 1986). Earlier designs required typing codes, selecting from menu lists, or clicking on visually distracting markers in the text. The embedded text link idea was adopted by others and became a user interface component of the World Wide Web (Berners-Lee, 1994).
[2] http://www.donhopkins.com/home/ties/LookBackAtHyperTIES.html
Designing to facilitate browsing: A look back at the Hyperties workstation browser
Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland
Human-Computer Interaction Laboratory, A.V. Williams Bldg., University of Maryland, College Park MD 20742, U.S.A.
[3] https://www.youtube.com/watch?v=fZi4gUjaGAM
University of Maryland Human Computer Interaction Lab HyperTIES Demo. Research performed under the direction of Ben Shneiderman. HyperTIES hypermedia browser developed by Ben Shneiderman, Bill Weiland, Catherine Plaisant and Don Hopkins. Demonstrated by Don Hopkins.
[4] https://www.youtube.com/watch?v=hhmU2B79EDU
Demo of UniPress Emacs based HyperTIES authoring tool, by Don Hopkins, at the University of Maryland Human Computer Interaction Lab.