timeline

[Andrew Poulos]

I'm working on an elearning course which displays one "page" of content
at a time to the user. Each page includes the same sort of items:.
image, text, more text, audio...

The items get displayed in sequence with various transition effects eg.
an image fades in, text slides in from the right...

What I'm finding is that some content is heavier than other content and
so an item may display earlier/later than it should. To workaround that
I've started putting in calls to trigger the next display eg. display
the image when the fade in has completed display the text... rather than
to rely on timeouts.

This is ok but it's become tedious tracking stuff from within the code
that does the transition.

What I'm thinking might be a better approach is to have a "timeline"
where there's a series of functions that get triggered by some "control"
code. So I would have a timeline that looks like

var timeline = ["a", "b", "c",...];

where "a" "b" are the names of the functions to call and control code
that looks like

var position = 0;

function runTimeline() {
position = (position == timeline.length ? position : 0);
window.timeline[position]();
position++;
}

function a() {
// do stuff and then when done
runTimeline();
}
function b() {
// do stuff and then when done
runTimeline();
}

Is that a workable approach or is there a better/smarter way?

Andrew Poulos

[Evertjan.]

Andrew Poulos <ap_...@hotmail.com> wrote on 20 Jul 2017 in
comp.lang.javascript:

The smart way is to have real or virtual distinct html-pages,
and do the job with serverside code, methinks.

You can include the common part of the code with serverside includes,
or make virtual pages using a 404-page server.transfer and more.

You can still use javascript, using a windows server,
if only to stay on topic here with such serverside code.


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Wally W.]

On Thu, 20 Jul 2017 18:17:46 +1000, Andrew Poulos wrote:

>I'm working on an elearning course which displays one "page" of content
>at a time to the user. Each page includes the same sort of items:.
>image, text, more text, audio...
>
>The items get displayed in sequence with various transition effects eg.
>an image fades in, text slides in from the right...

Needless for the purpose. The opinion of one who has been frustrated
by elearning crapware: users don't care how much you impress yourself
with eye candy.

What are wanted: content, rapid response, and navigation that doesn't
wander into lala land (possibly with no return) because it was poorly
presented and implemented.

Maybe eye candy wows the people who write the checks to have the
course electronified, but it is a PITA for people who are forced to
use elearning crapware by the same people who expect it to reduce
*their* workload. If they have any clue how much time they cause
others to waste via the crapware they commissioned and approved, then
they are simply lazy/evil for not holding the creators of the crapware
to a higher standard.

[Michael Haufe (TNO)]

Are your users using new enough browsers that you could rely on CSS?

<https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Transitions/Using_CSS_transitions>
<http://caniuse.com/#feat=css-transitions>

<https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animations/Using_CSS_animations>
<http://caniuse.com/#feat=css-animation>

[Julio Di Egidio]

On Thursday, July 20, 2017 at 10:18:00 AM UTC+2, Andrew Poulos wrote:
> I'm working on an elearning course which displays one "page" of content
> at a time to the user. Each page includes the same sort of items:.
> image, text, more text, audio...
>
> The items get displayed in sequence with various transition effects eg.
> an image fades in, text slides in from the right...
>
> What I'm finding is that some content is heavier than other content and
> so an item may display earlier/later than it should. To workaround that
> I've started putting in calls to trigger the next display eg. display
> the image when the fade in has completed display the text... rather than
> to rely on timeouts.
>
> This is ok but it's become tedious tracking stuff from within the code
> that does the transition.

Tedious is not really a sufficient reason, it's more about
manageable/understandable. Anyway, I think you are on the right track:
this is a controller, i.e. a state machine, which eventually is best
coded by tabling the states and corresponding actions/transitions.

> What I'm thinking might be a better approach is to have a "timeline"
> where there's a series of functions that get triggered by some "control"
> code. So I would have a timeline that looks like
>
> var timeline = ["a", "b", "c",...];

Rather store function references directly.

> where "a" "b" are the names of the functions to call and control code
> that looks like
>
> var position = 0;

Usually, you'd have named states, but your case might be simpler so
this might even be OK. The point really is do not get "anal" on the
patterns, what counts really is the readability/manageability of the
code, and getting there progressively.

> function runTimeline() {
> position = (position == timeline.length ? position : 0);
> window.timeline[position]();
> position++;
> }
>
> function a() {
> // do stuff and then when done
> runTimeline();
> }
> function b() {
> // do stuff and then when done
> runTimeline();
> }

Better have some driving function that calls the single actions passing a
callback... Then some would suggest promises instead of plain callbacks,
but I think that's really only appropriate for libraries/API's.

> Is that a workable approach or is there a better/smarter way?

There is always better: aim for "saves the day" to begin with.

HTH,

Julio

[Andrew Poulos]

On 20/07/2017 10:37 PM, Wally W. wrote:
> On Thu, 20 Jul 2017 18:17:46 +1000, Andrew Poulos wrote:
>
>> I'm working on an elearning course which displays one "page" of content
>> at a time to the user. Each page includes the same sort of items:.
>> image, text, more text, audio...
>>
>> The items get displayed in sequence with various transition effects eg.
>> an image fades in, text slides in from the right...
>
> Needless for the purpose. The opinion of one who has been frustrated

Said like the sort of person that claims they'd learn better from a
paper handout yet waxes lyrically about the shadow on an icon

Andrew Poulos

[Wally W.]

Said like a typical IT geek who doesn't give a rat's ass about what
end-users need.

[Andrew Poulos]

Quite the contrary. We have adopted a user-centric approach to all our
work and almost everything goes through rigorous user testing and
acceptance. We do care a lot about our user's needs, wants, and desires.

Andrew Poulos

[Evertjan.]

Andrew Poulos <ap_...@hotmail.com> wrote on 21 Jul 2017 in
comp.lang.javascript:

> Quite the contrary. We have adopted a user-centric approach to all our
> work and almost everything goes through rigorous user testing and
> acceptance. We do care a lot about our user's needs, wants, and desires.

What is the difference between wants and desires, btw?
Does the user have the knowledge to know what (s)he needs?
You should have the professional quality and courage to weigh those needs
and desires against the robust quality and servicability of the product.

User and programmer should learn eachother's language and possibilities and
requirements. This process should be lead by the professionality of the
programmer, as for her or him this process should be innate.

And using simple, understandable, cross-browser reliable code not only is
good for the user's budget, but also makes your work better and easier.

So methinks the clientside code approach for things that could be better or
just as good done on the server is a bad thing, and emulating different
pages by clientside code should be avoided, even when giving it fancy names
like a 'timeline'.

[Julio Di Egidio]

On Friday, July 21, 2017 at 11:36:27 AM UTC+2, Evertjan. wrote:

> So methinks the clientside code approach for things that could be better or
> just as good done on the server is a bad thing, and emulating different
> pages by clientside code should be avoided, even when giving it fancy names
> like a 'timeline'.

Or single-page apps, or simply some gadgets, or the fact that the 90's have
been over for a while now, or that one of the recurrent mistakes indeed is
doing server-side what should be done on the client, and so on. You are
speaking utter nonsense.

Julio

[Evertjan.]

Julio Di Egidio <ju...@diegidio.name> wrote on 21 Jul 2017 in
comp.lang.javascript:

Please elaborate.

[Andrew Poulos]

On 21/07/2017 7:36 PM, Evertjan. wrote:

> What is the difference between wants and desires, btw?

The tautological use is to emphasis my position on the matter.

Andrew Poulos

[Evertjan.]

Andrew Poulos <ap_...@hotmail.com> wrote on 22 Jul 2017 in
comp.lang.javascript:

> On 21/07/2017 7:36 PM, Evertjan. wrote:
>
>> What is the difference between wants and desires, btw?
>
> The tautological use is to emphasis my position on the matter.

Well, what is your position?

[Andrew Poulos]

On 22/07/2017 6:19 PM, Evertjan. wrote:
> Andrew Poulos <ap_...@hotmail.com> wrote on 22 Jul 2017 in
> comp.lang.javascript:
>
>> On 21/07/2017 7:36 PM, Evertjan. wrote:
>>
>>> What is the difference between wants and desires, btw?
>>
>> The tautological use is to emphasis my position on the matter.
>
> Well, what is your position?

Currently I'm seated upright.

Andrew Poulos

[Evertjan.]

Andrew Poulos <ap_...@hotmail.com> wrote on 23 Jul 2017 in

comp.lang.javascript:

> On 22/07/2017 6:19 PM, Evertjan. wrote:
>> Andrew Poulos <ap_...@hotmail.com> wrote on 22 Jul 2017 in
>> comp.lang.javascript:
>>
>>> On 21/07/2017 7:36 PM, Evertjan. wrote:
>>>
>>>> What is the difference between wants and desires, btw?
>>>
>>> The tautological use is to emphasis my position on the matter.
>>
>> Well, what is your position?
>
> Currently I'm seated upright.

Ata boy!

> Andrew Poulos

[Thomas 'PointedEars' Lahn]

Andrew Poulos wrote:

> var timeline = ["a", "b", "c",...];
>
> where "a" "b" are the names of the functions to call and control code
> that looks like
>
> var position = 0;
>
> function runTimeline() {
> position = (position == timeline.length ? position : 0);
> window.timeline[position]();

Never use “window” to refer to the global object; pass a reference to it
instead:

var timeline = ["a", "b", "c",...];

function runTimeline (global)
{
// …
global.timeline[position]();
}

runTimeline(this);

That said, avoid global variables and functions, and referring to the global
object, in the first place.

> position++;
> }
>
> function a() {
> // do stuff and then when done
> runTimeline();
> }
> function b() {
> // do stuff and then when done
> runTimeline();
> }
>
> Is that a workable approach

I do not think so. All of this still runs in a single thread, so you would
be blocking the browser/tab. Also, consider stack overflow:

runTimeline()
a()
runTimeline()
b()
runTimeline()
…

And I do not see how you would prevent items from being displayed earlier,
before they are fully loaded, this way.

> or is there a better/smarter way?

As should be obvious now, *anything* is better/smarter than this.

ISTM that ultimately you will want to use the Promise pattern, triggering
the next step only when the previous step has been completed *and* the
required resources have been loaded (i.e. the Promise has been fulfilled).
Built-in Promise support was just added in ECMAScript 2016, so you will
probably have to use a framework (pre-existing or your own implementation)
to make it work in all of your target environments.

--
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[Thomas 'PointedEars' Lahn]

Michael Haufe (TNO) wrote:

> <https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Transitions/Using_CSS_transitions>
> <http://caniuse.com/#feat=css-transitions>
>
> <https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animations/Using_CSS_animations>
> <http://caniuse.com/#feat=css-animation>

Neither CSS Transitions nor Animations *alone* will solve the stated problem
because without scripting they are triggered *regardless* whether the
content in question has been loaded.

They can alleviate the need for scripting CSS properties (which was not the
question). The difficulty lies in detecting support for them at runtime,
and due to bad implementations there can actually be a performance loss in
using them instead of scripting CSS properties directly. Also, not all CSS
properties can be animated this way (for example, you still need workarounds
for a simple blend-in/out effect of an element that, if not displayed,
should not be rendered at all: “display: none” still *disables* all
transitions on an element).

[Julio Di Egidio]

On Sunday, July 23, 2017 at 6:57:32 PM UTC+2, Thomas 'PointedEars' Lahn wrote:
> Andrew Poulos wrote:
<snip>

> > Is that a workable approach
>
> I do not think so. All of this still runs in a single thread, so you
> would be blocking the browser/tab.

No, it isn't: indeed, promises are just syntactic sugar on top of the usual
callback-based continuations.

> As should be obvious now, *anything* is better/smarter than this.

Obvious or not, you are talking complete bullshit.

Julio