Bounty for Javascript Auto-Submit Counter

[Prometheus Research]

http://newyork.craigslist.org/eng/34043771.html

We need a JavaScript component which will auto-submit a form after a
set period has elapsed. The component must display a counter that
dynamically shows the minutes and seconds remaining before submission.
We have a fairly tight deadline (by 5PM EST, Friday, June 25); we are
using a "bounty" in the hope of getting a few good responses in a
hurry.

BOUNTY: $200 for first place, plus a $50 bonus for the winner if
submission is there by 5 PM EST, Wed 23rd. $50 for second and third
place. (Payment to the winner will be sent after 30 days of bug-free
operation.)

Specific requirements:

1. The component must be JavaScript, and embeddable within the tag of
an HTML page. The component will use a
tag or similar place-holder for the placement of the clock.

2. The component must work with recent Mozilla/Firefox, IE Explorer 6+
on both Windows and MacOSX, and on MacOS Safari

3. The component must show a clock/counter counting down the minutes
and seconds to when the form will be auto-submitted. (A superior
submission might display the clock as a continuously changing
"odometer.")

4. The component will have several configurable items:
• Time period: The total length of time from when the page is loaded
until when it must be automatically submitted (16 minutes, 4 minutes
and 40 seconds, etc.) It should have minutes and seconds, with the
ability to set the display so that seconds are hidden.
• Increment: How frequently the clock should be updated, (2 minutes,
30 seconds, seconds, etc.)
• Warning: A time left when the user is given an indication that the
form will shortly be submitted (3 minutes, 1 minute, 10 seconds, etc.)
It should be a visual warning, preferably a flashing screen. For
example, one flash at close to the time limit and 2 flashes at the
next time warning. Two warning interval setting are sufficient.

5. Auto-submit the form when the clock reaches zero

6. The license for the clock will be BSD, and you can maintain
ownership.

7. An example HTML page that shows how to use the autosubmit
component.

8. A check to see if Javascript is turned on in the user's browser. If
Javascript is off, the user should be redirected to an instruction
page that will tell them to turn Javascript on (an sample instruction
page would be useful to us).
Desirable features:
• We prefer a reverse-odometer look.
• It would be great to be able to configure the font and colors of the
clock
• Sample css for pinning the clock to upper right-hand corner or
different screen location
• any neat things you can think of!

Good luck! Looking forward to seeing your scripts!
http://www.prometheusresearch.com
You are welcome to copy this request to anyone who may be interested.
Job location is New Haven, CT
it's NOT ok to contact this poster with services or other commercial
interests
Compensation: $200 for first place, $50 early bonus, 2x$50 for
runner-up submissions
Telecommuting is ok.
This is a contract job.
Principals only. Recruiters, please don't contact this job poster.
Please, no phone calls about this job!
Please do not contact job poster about other services, products or
commercial interests.
Reposting this message elsewhere is OK.

[Richard Cornford]

Prometheus Research wrote:
<snip>

Specific requirements:

1. The component must be JavaScript, and embeddable within the tag of
an HTML page.
"embeddable within the tag of an HTML page" is a strange use of
terminology that sounds like it is intended to mean something specific,
but doesn't actually express the requirement.
The component will use a
tag or similar place-holder for the placement of the clock. 2. The component must work with recent Mozilla/Firefox, IE Explorer 6+
on both Windows and MacOSX, and on MacOS Safari
It seems superfluous to put a plus in front of IE 6. Is there a reason
why Opera 7 or IceBrowser, for example, shouldn't support this?
3. The component must show a clock/counter counting down the minutes
and seconds to when the form will be auto-submitted. (A superior
submission might display the clock as a continuously changing
"odometer.")
An odometer displays, for example, the miles (or kilometres) travelled
by a car. Usually as a row of decimal digits, which is not at all
difficult to do, or significantly different form what would be expected,
Which makes me wonder if this "odometer" suggestion is asking for an
animated graphical presentation such as sliding the last number out as
the next slides in to replace it (as would happen with the revolving
cylinders of a car's odometer).
4. The component will have several configurable items:
. Time period: The total length of time from when the page is loaded
until when it must be automatically submitted (16 minutes, 4 minutes
and 40 seconds, etc.) It should have minutes and seconds, with the
ability to set the display so that seconds are hidden.
Not mentioning hours implies that the maximum countdown period would be
one hour.

It wouldn't hurt to know something about the style of specifying periods
of time. Would providing figures in milliseconds be appropriate, or
would the minimum total period and interval be one second and so
specifying periods as total numbers of seconds be acceptable, or as two
parameters in minutes and seconds?
. Increment: How frequently the clock should be updated, (2 minutes,
30 seconds, seconds, etc.)
There really should be a minimum and maximum specified update interval
(i.e. one second minimum one hour maximum).
. Warning: A time left when the user is given an indication that the
form will shortly be submitted (3 minutes, 1 minute, 10 seconds, etc.)
It should be a visual warning, preferably a flashing screen.
WAG guidelines don't encourage flashing screens because of epilepsy.
For
example, one flash at close to the time limit and 2 flashes at the
next time warning.
Only doing it twice might be safe.

This could probably do with more information about the context of use
because an action like toggling the background color of the BODY element
would represent a reasonable way of giving such an indication, but only
if the background color of the body was being inherited by a reasonable
proportion of the elements on the page. Otherwise a different strategy
might be called for.
Two warning interval setting are sufficient.

5. Auto-submit the form when the clock reaches zero

6. The license for the clock will be BSD, and you can maintain
ownership.

7. An example HTML page that shows how to use the autosubmit
component.

8. A check to see if Javascript is turned on in the user's browser.
This is meaningless as the ability to perform such a check implies that
javascript is turned on.
If Javascript is off, the user should be redirected
to an instruction page that will tell them to turn
Javascript on (an sample instruction page would
be useful to us).
And this is impossible, as when javascript is turned off there is no way
it can do anything (and no reliable alternative given the specified
browser list). Under the circumstances it would make more sense to have
an alternative page employ javascript to re-direct to this one.

Desirable features:
. We prefer a reverse-odometer look.
You want the units digit for seconds on the left?
. It would be great to be able to configure the font and colors of the
clock
It would be a poor script that didn't allow that. Probably using
external CSS.
. Sample css for pinning the clock to upper right-hand corner or
different screen location
This seems to contradict the earlier "place-holder" requirment.
. any neat things you can think of!

<snip>

Richard.

[Lee]

Prometheus Research said:

We need a JavaScript component which will auto-submit a form after a
set period has elapsed. The component must display a counter that
dynamically shows the minutes and seconds remaining before submission.

I assume that you don't mind that, since it will be client-side
Javascript, it will be trivial for your visitors to disable the
count-down, or to set it for whatever time period they prefer.

[Matt Kruse]

Richard Cornford wrote:

It seems superfluous to put a plus in front of IE 6.
I would assume this means 6.0 plus service packs.
And this is impossible, as when javascript is turned off there is no
way it can do anything (and no reliable alternative given the
specified browser list).

<noscript>
<meta http-equiv="refresh"
content="0;url=http://www.mysite.com/js_required.html">
</noscript>
?

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/

[Richard Cornford]

Matt Kruse wrote:

Richard Cornford wrote:

<snip>

And this is impossible, as when javascript is turned off there is
no way it can do anything (and no reliable alternative given the
specified browser list).

<noscript>
<meta http-equiv="refresh"
content="0;url=http://www.mysite.com/js_required.html">
</noscript>

?

META is a %head.misc element and so only allowed to be the child of a
HEAD element. NOSCRIPT is a %block elements and so only allowed to be a
descendent of a BODY element. Most of the specified browsers allow META
refresh to be disabled under user configuration/preferences. Even if the
browser swallows the dubious mark-up without side-effects, the results
will not be reliable.

Richard.

[Prometheus Research]

Hello Richard. Thank you for your kind response.

1. The component must be JavaScript, and embeddable within the tag of
an HTML page.
"embeddable within the tag of an HTML page" is a strange use of
terminology that sounds like it is intended to mean something specific,
but doesn't actually express the requirement.

Yes, it appears as if the posting stripped content; although on a second
read, we think it is best to leave howto use the Javascript up to the
designer as the example page would show its operation.

2. The component must work with recent Mozilla/Firefox, IE Explorer 6+
on both Windows and MacOSX, and on MacOS Safari

It seems superfluous to put a plus in front of IE 6. Is there a reason
why Opera 7 or IceBrowser, for example, shouldn't support this?

We only require support for Mozilla/Firefox, IE 6 and Safari; of course,
if it worked with Lynx that'd be great. *winks* I believe 6+ was used
since an associate had mentioned bugs were introduced in some versions of
IE 6, I'm not sure what those bugs are, but this script is probably simple
enough that one would not have to grapple with various patchlevels; we hope.

3. The component must show a clock/counter counting down the minutes
and seconds to when the form will be auto-submitted. (A superior
submission might display the clock as a continuously changing
"odometer.")

An odometer displays, for example, the miles (or kilometres) travelled
by a car. Usually as a row of decimal digits, which is not at all
difficult to do, or significantly different form what would be expected,

Clearly the time remaining would have to specify minutes (and with an
optional parameter) seconds.
Which makes me wonder if this "odometer" suggestion is asking for an
animated graphical presentation such as sliding the last number out as
the next slides in to replace it (as would happen with the revolving
cylinders of a car's odometer).
This is the idea; but this graphical trick is _not_ a requirement.

4. The component will have several configurable items:
. Time period: The total length of time from when the page is loaded
until when it must be automatically submitted (16 minutes, 4 minutes
and 40 seconds, etc.) It should have minutes and seconds, with the
ability to set the display so that seconds are hidden.

Not mentioning hours implies that the maximum countdown period would be
one hour.

Correct.
It wouldn't hurt to know something about the style of specifying periods
of time. Would providing figures in milliseconds be appropriate, or
would the minimum total period and interval be one second and so
specifying periods as total numbers of seconds be acceptable, or as two
parameters in minutes and seconds?

Seconds is the appropriate resolution, altough it would be nice to have
a flag so as to not show the seconds.

. Increment: How frequently the clock should be updated, (2 minutes,
30 seconds, seconds, etc.)

There really should be a minimum and maximum specified update interval
(i.e. one second minimum one hour maximum).

The increment would specify how many seconds pass before the screen
is updated; in many cases we don't want it updated every second as
this would be distracting to the user of the form.

. Warning: A time left when the user is given an indication that the
form will shortly be submitted (3 minutes, 1 minute, 10 seconds, etc.)
It should be a visual warning, preferably a flashing screen.

WAG guidelines don't encourage flashing screens because of epilepsy.

For
example, one flash at close to the time limit and 2 flashes at the
next time warning.

Only doing it twice might be safe.

This could probably do with more information about the context of use
because an action like toggling the background color of the BODY element
would represent a reasonable way of giving such an indication, but only
if the background color of the body was being inherited by a reasonable
proportion of the elements on the page. Otherwise a different strategy
might be called for.

I think you understand the requirement; we look to the example usage
page to help guide us.

Two warning interval setting are sufficient.

5. Auto-submit the form when the clock reaches zero

6. The license for the clock will be BSD, and you can maintain
ownership.

7. An example HTML page that shows how to use the autosubmit
component.

8. A check to see if Javascript is turned on in the user's browser.

This is meaningless as the ability to perform such a check implies that
javascript is turned on.

We are aware of that, ideally, your set of example pages would
demonstrate this; for example, a clever example page would
put in "5 minutes" when Javascript is not available (via noscript).

If Javascript is off, the user should be redirected
to an instruction page that will tell them to turn
Javascript on (an sample instruction page would
be useful to us).

And this is impossible, as when javascript is turned off there is no way
it can do anything (and no reliable alternative given the specified
browser list). Under the circumstances it would make more sense to have
an alternative page employ javascript to re-direct to this one.

Sounds good; the submission should show how we can meet the requirement,
it is unfortunate that we had specified an implementation which won't work.

Desirable features:
. We prefer a reverse-odometer look.

You want the units digit for seconds on the left?

That is not a requirement.

. It would be great to be able to configure the font and colors of the
clock

It would be a poor script that didn't allow that. Probably using
external CSS.

We already have one submission which doesn't; but as you said, this
is more like something to go in the example page.

. Sample css for pinning the clock to upper right-hand corner or
different screen location

This seems to contradict the earlier "place-holder" requirment.

*nods*

. any neat things you can think of!

Thank you for your thoughtful set of questions. We look forward to
your submission. Cheers!

[Matt Kruse]

Prometheus Research wrote:

Thank you for your thoughtful set of questions. We look forward to
your submission. Cheers!

I would expect low-quality solutions, if I were you.

$250 for such a project seems pretty low for experienced developers, so
you're probably not going to get submissions from the best possible
developers. Especially when payment is not guaranteed.

Good luck, though ;)

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/

[Jim Ley]

On Thu, 17 Jun 2004 20:02:48 -0500, "Matt Kruse"
<ne********@mattkruse.com> wrote:

<noscript>
<meta http-equiv="refresh"
content="0;url=http://www.mysite.com/js_required.html">
</noscript>

Even IE can disable meta refresh let alone more advanced UA's

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Richard Cornford]

Prometheus Research wrote:
<snip>

"embeddable within the tag of an HTML page" is a strange use of
terminology that sounds like it is intended to mean something
specific, but doesn't actually express the requirement.
Yes, it appears as if the posting stripped content; although on a
second read, we think it is best to leave howto use the Javascript
up to the designer as the example page would show its operation.

That probably wasn't a wise decision as no matter how garbled by chinese
whispers in being relayed to broadcast I have a feeling that the idea
originated with someone familiar with the (technical) context in which
the code will be being used, and it is often advisable to listen to what
such people have to say as they will be trying to reduce their
associated workload. Which initially sounds like laziness but actually
means they will be able to get more done for the money they will be
being paid anyway.

Leaving the implementation decisions up to the script designer is not
necessarily a bad idea, but it really necessitates the designer being
fully informed of the purpose of the script. So far you have provided
details of what you want the script to do, but not said anything about
what you intend doing with it, and why, once you have it. It is those
details that a designer needs if they are going to attempt to fill in
the blanks in a vague or incomplete specification.

<snip> Clearly the time remaining would have to specify minutes
(and with an optional parameter) seconds.
Clearly if you say that is what you want, not so clearly otherwise. The
'natural' unit for specifying an interval in javascript is the
millisecond, but it isn't a problem to be using anything less precise
(just need appropriate multiplication).

<snip>

8. A check to see if Javascript is turned on in the user's browser.

This is meaningless as the ability to perform such a check implies
that javascript is turned on.

We are aware of that, ideally, your set of example pages would
demonstrate this; for example, a clever example page would
put in "5 minutes" when Javascript is not available (via noscript).

The functionality described does not have an inverse relationship with
NOSCRIPT (very little browser scripting does).

<snip> Thank you for your thoughtful set of questions. We look
forward to your submission. Cheers!

It is unlikely that you will see anything from me. The money is an
irrelevance as a one in N chance of getting such a small amount of money
(assuming you intend paying out at all) for such a script, without even
getting a clear idea of what criteria the results will be judged by, is
not appealing in itself. My interest is only in whether the problem was
interesting in its own right, and you have not really contributed to
answering that question as your specification is hardly any more
specific than its original vague form and the supplementary information
required to compensate for a vague specification remains absent.

Richard.