> 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 trie
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 dou
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 dou
On Jul 18, 5:51 pm, "Christopher Jordan" <[EMAIL PROTECTED]>
wrote:
> Instead of disabling the element for 500ms just ignore any other clicks on
> the element for 500ms. We often do this on elements with an onchange event.
> that way if the user changes items in a select too quickly (i.e.
> highli
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.
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.
> >
>
> > 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 pr
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:
>
> 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
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
> >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 doubl
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]>
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 ad
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) I
i'm not a big fan of setTimeout(), partly due to its limitations
(must take a string argument, instead of a function reference)
Not true. setTimeout takes either a string or an fn ref.
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. This solves the problem of timeouts and it is more
intuitive to a click interface than to non-click interface like the site i
menti
On Jul 18, 3:56 am, "Dan G. Switzer, II" <[EMAIL PROTECTED]>
wrote:
> The trickiest part would be showing the user progress of the timer before
> they can click to perform the action.
>
> The problem is I'm still not sure how intuitive this behavior would be. I
> guess a clue/tool tip that explai
>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 sl
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 o
On Jul 18, 1:58 am, "Dan G. Switzer, II" <[EMAIL PROTECTED]>
wrote:
> I'll also confirm that my finding the majority of non-hardcore users tend to
> double-click. Heck, one of my previous supervisors used to double-click
> every thing on a web page.
My girlfriend does the same (and it drives me u
>> 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.
>
>That's an interesting point. i've been using KDE in single-click mode
>for many years, so i haven't actually double
On Jul 18, 1:43 am, "Ganeshji Marwaha" <[EMAIL PROTECTED]> wrote:
> 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...
You're right - i had the timeout delay
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 think
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 onclic
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: http://www.fg-webdesign.de
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.
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 k
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 "
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
29 matches
Mail list logo
