[jQuery] Re: Announce: Confirmer plugin

2007-07-20 Thread Ganeshji Marwaha

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 double-click handler by default for
all form controls ;).


Did it work?

-GTG


On 7/19/07, Stephan Beal [EMAIL PROTECTED] wrote:



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 double-click handler by default for
all form controls ;).





[jQuery] Re: Announce: Confirmer plugin

2007-07-20 Thread Stephan Beal

 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 both SPAN and BUTTON elements, but the results were the
same.

:(

Perhaps the solution is to require two double-clicks for confirmation
instead of two single clicks?



[jQuery] Re: Announce: Confirmer plugin

2007-07-19 Thread Stephan Beal

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 double-click handler by default for
all form controls ;).




[jQuery] Re: Announce: Confirmer plugin

2007-07-18 Thread Matt Stith

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
 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. Heck, one of my
 previous supervisors used to double-click every thing on a web page.

 People get in such a habit of double-clicking to open icons,
 they tend to do it for everything.

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 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.

Finally we had the QA engineer who'd reported the bug demo it for us. He
clicked the OK button in the dialog, and sure enough, some other app
popped
to the front - on his machine. Something weird about his Windows
configuration?

We had him show us the bug a few times, and finally the light dawned.

Can you guess what he was doing, and what went wrong? :-)

-Mike




[jQuery] Re: Announce: Confirmer plugin

2007-07-18 Thread Michael Geary

 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 we're going to have drinks and debugging? Right...



[jQuery] Re: Announce: Confirmer plugin

2007-07-18 Thread Ganeshji Marwaha

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:



 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. Heck, one of my
 previous supervisors used to double-click every thing on a web page.

 People get in such a habit of double-clicking to open icons,
 they tend to do it for everything.

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 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.

Finally we had the QA engineer who'd reported the bug demo it for us. He
clicked the OK button in the dialog, and sure enough, some other app
popped
to the front - on his machine. Something weird about his Windows
configuration?

We had him show us the bug a few times, and finally the light dawned.

Can you guess what he was doing, and what went wrong? :-)

-Mike




[jQuery] Re: Announce: Confirmer plugin

2007-07-18 Thread Michael Geary

  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 Windows apps can run into
  if they close dialogs in the wrong way. But I knew we weren't
  doing that, and we couldn't repro the bug at all.
  
  Finally we had the QA engineer who'd reported the bug demo it
  for us. He clicked the OK button in the dialog, and sure enough,
  some other app popped to the front - on his machine. Something
  weird about his Windows configuration?
  
  We had him show us the bug a few times, and finally the light dawned.
  
  Can you guess what he was doing, and what went wrong? :-)

 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... :-)

That's a good theory, Ganeshji, but it didn't depend on his Windows 
configuration at all. (There
isn't actually any such Windows configuration option - you're probably thinking 
of the single-click
option in Windows Explorer, but that doesn't change the way clicks work 
globally in the system, it
just changes the way Explorer interprets a single click.)

This particular app had a small main window and a large options dialog. He was 
double-clicking the
OK button! The first click dismissed the dialog, and the second click landed on 
some other window,
bringing it to the top.

-Mike

(With apologies to anyone who is tired of the off-topic diversion... Back to 
jQuery now...)



[jQuery] Re: Announce: Confirmer plugin

2007-07-18 Thread Ganeshji Marwaha

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 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 Windows apps can run into
  if they close dialogs in the wrong way. But I knew we weren't
  doing that, and we couldn't repro the bug at all.
 
  Finally we had the QA engineer who'd reported the bug demo it
  for us. He clicked the OK button in the dialog, and sure enough,
  some other app popped to the front - on his machine. Something
  weird about his Windows configuration?
 
  We had him show us the bug a few times, and finally the light dawned.
 
  Can you guess what he was doing, and what went wrong? :-)

 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... :-)

That's a good theory, Ganeshji, but it didn't depend on his Windows
configuration at all. (There
isn't actually any such Windows configuration option - you're probably
thinking of the single-click
option in Windows Explorer, but that doesn't change the way clicks work
globally in the system, it
just changes the way Explorer interprets a single click.)

This particular app had a small main window and a large options dialog. He
was double-clicking the
OK button! The first click dismissed the dialog, and the second click
landed on some other window,
bringing it to the top.

-Mike

(With apologies to anyone who is tired of the off-topic diversion... Back
to jQuery now...)




[jQuery] Re: Announce: Confirmer plugin

2007-07-18 Thread Christopher Jordan



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. We often do this on elements with an onchange event.
that way if the user changes items in a select too quickly (i.e.
highlighting something in the list and then using their mousewheel) we avoid
hitting the server until the selected item has been rested on for half a
second or whatever we decide is the right timing.

I think something like that could work for protecting against double-clicks.

Another idea is to do what AVG does when it does an automatic update, (and
when FF installs an addon). Have the button show a count down and when the
count reaches zero either do the action or enable the button or both.

How about that?

Chris

--
http://cjordan.us


[jQuery] Re: Announce: Confirmer plugin

2007-07-17 Thread Tane Piper


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 via a
yes/no dialog box or a button with a confirm checkbox next to it.
The Confirmer plugin instead sets up a single button which changes to
a confirm the action state if it is clicked one time. If the button
is clicked again within a specified time then the action is confirmed,
otherwise it times out and returns to its initial state.

http://wanderinghorse.net/computing/javascript/jquery/confirmer/

Includes a live demo link.

Happy hacking!





--
Tane Piper
http://digitalspaghetti.tooum.net

This email is: [ ] blogable [ x ] ask first [ ] private


[jQuery] Re: Announce: Confirmer plugin

2007-07-17 Thread Michael Geary

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 Wait
label on it, and then re-enabling it with the confirm label. That might be a
little annoying, but probably not too bad, and it would keep the
double-clickers out of trouble.

-Mike

 From: Stephan Beal
 
 Confirmer is a plugin for jQuery which implements a novel 
 approach to the process of confirming an action. Normally 
 this is achieved via a yes/no dialog box or a button with a 
 confirm checkbox next to it.
 The Confirmer plugin instead sets up a single button which 
 changes to a confirm the action state if it is clicked one 
 time. If the button is clicked again within a specified time 
 then the action is confirmed, otherwise it times out and 
 returns to its initial state.
 
 http://wanderinghorse.net/computing/javascript/jquery/confirmer/
 
 Includes a live demo link.



[jQuery] Re: Announce: Confirmer plugin

2007-07-17 Thread Stephan Beal

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 browsers support a confirm() function!), which is a
typical solution for PHP-based apps. This allows a much cleaner
solution, though.

:D



[jQuery] Re: Announce: Confirmer plugin

2007-07-17 Thread Stephan Beal

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. After clicking the Delete button to move
a mail to the Trashcan, the button changes to Undo Delete until you
take another action, at which point it reverts back to a Delete
button. If you click Undo before doing anything else then you can undo
the delete. i never actually used the app, but read about that feature
in some UI design article a few years ago.

 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-clicked anything since i
had (was forced) to use Windows some time in 2006... thus i didn't
consider the posibility that so many people double-click out of habit.
Once you get used to single-clicking everything, double-clicking
becomes tedious and seems downright barbaric.

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. :/

 You could avoid this by disabling the button for a second with a Wait
 label on it, and then re-enabling it with the confirm label. That might be a
 little annoying, but probably not too bad, and it would keep the
 double-clickers out of trouble.

That's a very good idea. A 500ms wait shouldn't be a big deal. i'll
take a look at how that might be made configurable. The only potential
problem i can think of with that is that it might require, as a
target, an element for which a disabled state is possible (e.g. a
button), whereas the current implementation can be applied to other
elements (in theory, any elements for which click() and html() are
valid).



[jQuery] Re: Announce: Confirmer plugin

2007-07-17 Thread Felix Geisendörfer
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


Stephan Beal 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 via a
 yes/no dialog box or a button with a confirm checkbox next to it.
 The Confirmer plugin instead sets up a single button which changes to
 a confirm the action state if it is clicked one time. If the button
 is clicked again within a specified time then the action is confirmed,
 otherwise it times out and returns to its initial state.

 http://wanderinghorse.net/computing/javascript/jquery/confirmer/

 Includes a live demo link.

 Happy hacking!


   


[jQuery] Re: Announce: Confirmer plugin

2007-07-17 Thread Stephan Beal

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 callback so the user could
modify the element using an arbitrary animation, but you're right -
adding a class is a good generic solution without the usage overhead
of a callback.

i've added this to the TODO list. Thanks :).



[jQuery] Re: Announce: Confirmer plugin

2007-07-17 Thread Ganeshji Marwaha

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 thinking out loud, maybe something like clicking outside the button
cancels it... i dont know

I know, we can increase the timing there, but still, i am not sure if the
timing approach is the best for confirm kinda dialog. For undo style
dialogs that probably is a better idea...

Just something to ponder...

-GTG

On 7/17/07, Stephan Beal [EMAIL PROTECTED] wrote:



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 callback so the user could
modify the element using an arbitrary animation, but you're right -
adding a class is a good generic solution without the usage overhead
of a callback.

i've added this to the TODO list. Thanks :).




[jQuery] Re: Announce: Confirmer plugin

2007-07-17 Thread Ganeshji Marwaha

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 out,
asking to confirm, and if you click that extention, you got your
confirmation.

Oops, i almost forgot the link - http://www.dontclick.it/

-GTG

On 7/17/07, Stephan Beal [EMAIL PROTECTED] wrote:



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 set very low because when
testing it it gets really annoying to wait a full 3 seconds (the
default timeout period). i've re-set it to 3000ms.

 There should be some other way, instead of just time before which the
event
 is cancelled.

That would involve adding another UI element, which is part of what i
was trying to avoid. Any ideas which don't involve an extra UI element
or dialog?


 Just thinking out loud, maybe something like clicking outside the button
 cancels it... i dont know

That could have weird semantics in some use cases:
Let's say i have a Delete Object button which performs the delete
UNLESS i confirm the action (that is, it's usage is backwards - i'm
going to delete unless you cancel the deletion by clicking the confirm
button).

Granted, that would be an unusual use case, but users often come up
with weird things to do.

Stealing a click like that could lead to other confusion, as the
widget the user actually clicked on (a hyperlink, form control, or
other button) doesn't get the click. We might be able to pass on the
click by figuring out what the coordinates are, but that gets very
ugly very quickly.

Also, i'm not 100% sure that i could get the click-anywhere event
handling working cross-browser. i only have Linux machines, so i can't
test on the most popular (MSIE) and most esoteric (Safari) browsers. A
quick look at the subject lines of the last 100 posts in this forum
suggest that about 20-30% of the users have some sort of problem which
applies on to MSIE, and i don't want to do anything in jQuery which is
so tricky that the world's most popular browser cannot handle it.

 I know, we can increase the timing there, but still, i am not sure if
the
 timing approach is the best for confirm kinda dialog. For undo
style
 dialogs that probably is a better idea...

 Just something to ponder...

In principal i agree with what you're saying, but i don't think the
click-anywhere-else is the proper solution, and i don't have any ideas
which don't involve an extra UI element or dialog box.

i'm open to suggestions. Keep in mind that this particular plugin is
intended to be light-weight and free of dependencies on other plugins
(e.g. Dimensions would be useful for the click-anywhere support, i
think).





[jQuery] Re: Announce: Confirmer plugin

2007-07-17 Thread Stephan Beal

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 an additional UI element.

b) Any animation beyond the most basic requires additional plugins.

 This solves the problem of timeouts and it is more
 intuitive to a click interface than to non-click interface like the site i
 mentioned.

i do agree that it's more intuitive, but timeouts are necessary when
you have a use case which says click within 3 seconds to abort, or
else i will confirm the action you requested. That use case sounds
very realistic to me: move to trash with option to cancel, means you
can click Trash and then go do something else because when the timer
expires the action will be automatically confirmed (via timeout).


 Also, why do you think setTimeout can't take a function reference... As far
 as i know, it can... Correct me if i am wrong.

Oh my god... you're right.

Aaarrr

The (several) docs i've looked at only said that it takes a string,
but (at least in FF 2.x) it CAN take a function. Okay, that changes my
implementation significantly because some of that code is there to
work around having to use a string. When passing a string to
setTimeout(), the string is executed in another scope, so you cannot
access local vars/funcs that way, e.g.:

function xyz() {
  var self = this;
  self.foo = abc;
  setTimeout( alert(self.foo), 1000 ); // won't work: self is
undefined
}

Damn, and i wasted so much time writing a workaround for that.



[jQuery] Re: Announce: Confirmer plugin

2007-07-17 Thread Stephan Beal

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 code to implement a disabling delay, but:

a) disabled=true only works for some elements (e.g. BUTTONS), so this
isn't usable when the click-zone is a different element. This could be
made to work by shuffling the click() handlers around and changing the
element's class (for visual disable effect), but i haven't gotten that
far along yet, and probably won't because...

b) i'm getting weird behaviours vis-a-vis cancellation/confirmation
when i quickly double-click. When quickly double-clicking, sometimes a
confirmation takes and sometimes it doesn't. i believe this has to do
with a second click getting through (or queued) before the
disabled=true has a chance to happen (classic race condition).

So the briefly disable behaviour is not reliable enough for
production use, IMO.

Bummer.

i think i'll just punt on this perceived problem for the moment and
say, if you're stupid enough to double-click a form element, and
thereby risk POSTing data twice, then you deserve any bugs you get. :-
P

But i will keep the problem in mind and search for a graceful
solution. i just won't spend too much time hacking on it until a good
idea comes around.

Thanks once again to all of you for your feedback so far.

:D

Happy hacking!



[jQuery] Re: Announce: Confirmer plugin

2007-07-17 Thread Ganeshji Marwaha

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:
 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 code to implement a disabling delay, but:

a) disabled=true only works for some elements (e.g. BUTTONS), so this
isn't usable when the click-zone is a different element. This could be
made to work by shuffling the click() handlers around and changing the
element's class (for visual disable effect), but i haven't gotten that
far along yet, and probably won't because...

b) i'm getting weird behaviours vis-a-vis cancellation/confirmation
when i quickly double-click. When quickly double-clicking, sometimes a
confirmation takes and sometimes it doesn't. i believe this has to do
with a second click getting through (or queued) before the
disabled=true has a chance to happen (classic race condition).

So the briefly disable behaviour is not reliable enough for
production use, IMO.

Bummer.

i think i'll just punt on this perceived problem for the moment and
say, if you're stupid enough to double-click a form element, and
thereby risk POSTing data twice, then you deserve any bugs you get. :-
P

But i will keep the problem in mind and search for a graceful
solution. i just won't spend too much time hacking on it until a good
idea comes around.

Thanks once again to all of you for your feedback so far.

:D

Happy hacking!




[jQuery] Re: Announce: Confirmer plugin

2007-07-17 Thread Michael Geary

 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. Heck, one of my 
 previous supervisors used to double-click every thing on a web page. 
 
 People get in such a habit of double-clicking to open icons, 
 they tend to do it for everything.

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 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.

Finally we had the QA engineer who'd reported the bug demo it for us. He
clicked the OK button in the dialog, and sure enough, some other app popped
to the front - on his machine. Something weird about his Windows
configuration?

We had him show us the bug a few times, and finally the light dawned.

Can you guess what he was doing, and what went wrong? :-)

-Mike