On Jul 18, 7:34 am, Ganeshji Marwaha [EMAIL PROTECTED] wrote:
Hmmm, just thinking out loud here, did u try attaching a no-op function to
window.ondbclick...
That's an EXCELLENT idea! Thanks a lot!
Doh - i can't believe i didn't think of that before.
Perhaps jQ should install a no-op
On Jul 18, 7:34 am, Ganeshji Marwaha [EMAIL PROTECTED] wrote:
Did it work?
i just tried it, but it doesn't appear to have an affect - the click()
handler appears to take precedence, which actually does make sense
because you cannot have a double-click without having a single click.
i tried it
On Jul 18, 7:34 am, Ganeshji Marwaha [EMAIL PROTECTED] wrote:
Hmmm, just thinking out loud here, did u try attaching a no-op function to
window.ondbclick...
That's an EXCELLENT idea! Thanks a lot!
Doh - i can't believe i didn't think of that before.
Perhaps jQ should install a no-op
Lol, i still have friends and relatives that double click everything... Ive
seen this scenario play out a couple times.. When the X button is over an ad
or something.. :(
On 7/18/07, Michael Geary [EMAIL PROTECTED] wrote:
Now that i think about it, i'm constantly saying to my g/f, don't
There actually is a similar problem that Windows apps can run
into if they close dialogs in the wong way. But I knew we
weren't doing that, and we couldn't repro the bug at all.
Proofread, Geary, proofread. Obviously wrong, especially after that second
glass of wine. :-)
And Resig says
i guess, his windows config was set to double click when a single-click is
executed and since the dialog closes on the first click, the page
underneath gets the second click which probably opens up a popup.. Just a
theory... :-)
-GTG
On 7/17/07, Michael Geary [EMAIL PROTECTED] wrote:
When I was working at Adobe several years ago, we had a bug
report that none of us could reproduce or figure out.
The bug said that an unrelated window from another application
would pop to the front when a dialog in our app was closed.
There actually is a similar problem that
Thats funny... and it is very satisfying to know that many of us face
similar problems on a daily basis :-)
-GTG
On 7/18/07, Michael Geary [EMAIL PROTECTED] wrote:
When I was working at Adobe several years ago, we had a bug
report that none of us could reproduce or figure out.
The
Does disabling the element for 500ms sound like a reasonable solution
to you? i'm not sure that disable makes much sense for non-buttons,
but i think that buttons will make up 90%+ of use cases.
Instead of disabling the element for 500ms just ignore any other clicks on
the element for 500ms.
Very handy! Will be very useful for actions such as deleting. I'll
be trying this one out.
On 7/17/07, Stephan Beal [EMAIL PROTECTED] wrote:
Hi again, all!
Confirmer is a plugin for jQuery which implements a novel approach to
the process of confirming an action. Normally this is achieved
Very cool idea. Anything to get rid of confirmation dialogs!
I see one problem: Many people habitually double-click everything - links,
buttons, you name it. If you double-click the button, the second click ends
up confirming it.
You could avoid this by disabling the button for a second with a
On Jul 18, 12:35 am, Tane Piper [EMAIL PROTECTED]
wrote:
Very handy! Will be very useful for actions such as deleting. I'll
be trying this one out.
Deleting is EXACTLY the reason i wrote it. i have an app with a
Delete all button and a Confirm checkbox next to it (because i
didn't know that
On Jul 18, 12:40 am, Michael Geary [EMAIL PROTECTED] wrote:
Very cool idea. Anything to get rid of confirmation dialogs!
i didn't come up with the idea myself (of course). There is/was some
mail client (can't remember which) which uses/used a similar idea when
you move a mail to the trash.
Cool idea. Just add support for a class that's being added to the button
when in 'confirm' mode - otherwise there is no way to visually highlight
this new UI approach for the user ; ).
-- Felix
--
My Blog: http://www.thinkingphp.org
My Business:
On Jul 18, 12:47 am, Felix Geisendörfer [EMAIL PROTECTED] wrote:
Cool idea. Just add support for a class that's being added to the button
when in 'confirm' mode - otherwise there is no way to visually highlight
this new UI approach for the user ; ).
My initial thought was to use an onclick
Stephan,
In the demo, once i click, the action gets cancelled too quickly before i
understand that i need to click it again... Also, i guess it is pretty
difficult to explain this to the user...
There should be some other way, instead of just time before which the event
is cancelled.
Just
Just minutes after typing the email for u, i realized that i had seen a
pretty cool site from which
your plugin can gather some inspiration. This site allows you to
completely interact with any UI without any clicks at all.
Along similar lines, once a user clicks the button, an extention slides
On Jul 18, 4:51 am, Ganeshji Marwaha [EMAIL PROTECTED] wrote:
Don't you like the idea of click on the button, an extension slides out
asking to confirm. When you click the confirm extension, you can go ahead
with the action.
i do, but it breaks two of my rules for this plugin:
a) It requires
On Jul 18, 2:29 am, Stephan Beal [EMAIL PROTECTED] wrote:
Does disabling the element for 500ms sound like a reasonable solution
to you? i'm not sure that disable makes much sense for non-buttons,
but i think that buttons will make up 90%+ of use cases.
???
A bit of follow-up:
i've added
So the briefly disable behaviour is not reliable enough for
production use, IMO.
Hmmm, just thinking out loud here, did u try attaching a no-op function to
window.ondbclick...
-GTG
On 7/17/07, Stephan Beal [EMAIL PROTECTED] wrote:
On Jul 18, 2:29 am, Stephan Beal [EMAIL PROTECTED] wrote:
Now that i think about it, i'm constantly saying to my g/f, don't
DOUBLE-click those links! That causes two hits on the server! as if
she might someday magically understand what i mean by that. :/
I'll also confirm that my finding the majority of
non-hardcore users tend to double-click.
21 matches
Mail list logo
