Bounty for Javascript Auto-Submit Counter

**Richard Cornford** · Jul 23 '05, 11:40 AM

Re: Bounty for Javascript Auto-Submit Counter

Prometheus Research wrote:
<snip>[color=blue]
> Specific requirements:
>
> 1. The component must be JavaScript, and embeddable within the tag of
> an HTML page.[/color]

"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.
[color=blue]
> The component will use a
> tag or similar place-holder for the placement of the clock.[/color]
[color=blue]
> 2. The component must work with recent Mozilla/Firefox, IE Explorer 6+
> on both Windows and MacOSX, and on MacOS Safari[/color]

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?
[color=blue]
> 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." )[/color]

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).
[color=blue]
> 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.[/color]

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?
[color=blue]
> . Increment: How frequently the clock should be updated, (2 minutes,
> 30 seconds, seconds, etc.)[/color]

There really should be a minimum and maximum specified update interval
(i.e. one second minimum one hour maximum).
[color=blue]
> . 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.[/color]

WAG guidelines don't encourage flashing screens because of epilepsy.
[color=blue]
> For
> example, one flash at close to the time limit and 2 flashes at the
> next time warning.[/color]

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.
[color=blue]
> 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.[/color]

This is meaningless as the ability to perform such a check implies that
javascript is turned on.
[color=blue]
> 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).[/color]

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.
[color=blue]
>
> Desirable features:
> . We prefer a reverse-odometer look.[/color]

You want the units digit for seconds on the left?
[color=blue]
> . It would be great to be able to configure the font and colors of the
> clock[/color]

It would be a poor script that didn't allow that. Probably using
external CSS.
[color=blue]
> . Sample css for pinning the clock to upper right-hand corner or
> different screen location[/color]

This seems to contradict the earlier "place-holder" requirment.
[color=blue]
> . any neat things you can think of![/color]
<snip>

Richard.

**Lee** · Jul 23 '05, 11:40 AM

Re: Bounty for Javascript Auto-Submit Counter

Prometheus Research said:[color=blue]
>
>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.[/color]

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** · Jul 23 '05, 11:40 AM

Re: Bounty for Javascript Auto-Submit Counter

Richard Cornford wrote:[color=blue]
> It seems superfluous to put a plus in front of IE 6.[/color]

I would assume this means 6.0 plus service packs.
[color=blue]
> 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).[/color]

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

?

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

**Richard Cornford** · Jul 23 '05, 11:40 AM

Re: Bounty for Javascript Auto-Submit Counter

Matt Kruse wrote:[color=blue]
> Richard Cornford wrote:[/color]
<snip>[color=blue][color=green]
>> 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).[/color]
>
> <noscript>
> <meta http-equiv="refresh"
> content="0;url= http://www.mysite.com/js_required.htm l">
> </noscript>
>
> ?[/color]

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** · Jul 23 '05, 11:41 AM

Re: Bounty for Javascript Auto-Submit Counter

Hello Richard. Thank you for your kind response.
[color=blue][color=green]
> > 1. The component must be JavaScript, and embeddable within the tag of
> > an HTML page.[/color]
>
> "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.[/color]

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.
[color=blue][color=green]
> > 2. The component must work with recent Mozilla/Firefox, IE Explorer 6+
> > on both Windows and MacOSX, and on MacOS Safari[/color]
>
> 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?[/color]

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.
[color=blue][color=green]
> > 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." )[/color]
>
> 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,[/color]

Clearly the time remaining would have to specify minutes (and with an
optional parameter) seconds.
[color=blue]
> 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).[/color]

This is the idea; but this graphical trick is _not_ a requirement.

[color=blue][color=green]
> > 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.[/color]
>
> Not mentioning hours implies that the maximum countdown period would be
> one hour.[/color]

Correct.
[color=blue]
> 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?[/color]

Seconds is the appropriate resolution, altough it would be nice to have
a flag so as to not show the seconds.
[color=blue][color=green]
> > . Increment: How frequently the clock should be updated, (2 minutes,
> > 30 seconds, seconds, etc.)[/color]
>
> There really should be a minimum and maximum specified update interval
> (i.e. one second minimum one hour maximum).[/color]

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.
[color=blue][color=green]
> > . 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.[/color]
>
> WAG guidelines don't encourage flashing screens because of epilepsy.
>[color=green]
> > For
> > example, one flash at close to the time limit and 2 flashes at the
> > next time warning.[/color]
>
> 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.[/color]

I think you understand the requirement; we look to the example usage
page to help guide us.
[color=blue][color=green]
> > 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.[/color]
>
> This is meaningless as the ability to perform such a check implies that
> javascript is turned on.[/color]

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).
[color=blue][color=green]
> > 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).[/color]
>
> 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.[/color]

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.
[color=blue][color=green]
> > Desirable features:
> > . We prefer a reverse-odometer look.[/color]
>
> You want the units digit for seconds on the left?[/color]

That is not a requirement.
[color=blue][color=green]
> > . It would be great to be able to configure the font and colors of the
> > clock[/color]
>
> It would be a poor script that didn't allow that. Probably using
> external CSS.[/color]

We already have one submission which doesn't; but as you said, this
is more like something to go in the example page.
[color=blue][color=green]
> > . Sample css for pinning the clock to upper right-hand corner or
> > different screen location[/color]
>
> This seems to contradict the earlier "place-holder" requirment.[/color]

*nods*
[color=blue][color=green]
> > . any neat things you can think of![/color][/color]

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

**Matt Kruse** · Jul 23 '05, 11:41 AM

Re: Bounty for Javascript Auto-Submit Counter

Prometheus Research wrote:[color=blue]
> Thank you for your thoughtful set of questions. We look forward to
> your submission. Cheers![/color]

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** · Jul 23 '05, 11:42 AM

Re: Bounty for Javascript Auto-Submit Counter

On Thu, 17 Jun 2004 20:02:48 -0500, "Matt Kruse"
<newsgroups@mat tkruse.com> wrote:
[color=blue]
><noscript>
> <meta http-equiv="refresh"
>content="0;url =http://www.mysite.com/js_required.htm l">
></noscript>[/color]

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

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

**Richard Cornford** · Jul 23 '05, 11:44 AM

Re: Bounty for Javascript Auto-Submit Counter

Prometheus Research wrote:
<snip>[color=blue][color=green]
>> "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.[/color]
>
> 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.[/color]

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>[color=blue]
> Clearly the time remaining would have to specify minutes
> (and with an optional parameter) seconds.[/color]

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>[color=blue][color=green][color=darkred]
>>> 8. A check to see if Javascript is turned on in the user's browser.[/color]
>>
>> This is meaningless as the ability to perform such a check implies
>> that javascript is turned on.[/color]
>
> 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).[/color]

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

<snip>[color=blue]
> Thank you for your thoughtful set of questions. We look
> forward to your submission. Cheers![/color]

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.

Bounty for Javascript Auto-Submit Counter

Bounty for Javascript Auto-Submit Counter

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment