search

TiddlyWiki / TiddlyWiki5

A self-contained JavaScript wiki for the browser, Node.js, AWS Lambda etc.
https://tiddlywiki.com/
Other
7.98k stars 1.18k forks source link

Proposal: Add wiki loading bar during boot / page load #2254

Closed felixhayashi closed 5 years ago

felixhayashi commented 8 years ago

Currently, a big wiki leaves a blank screen for a few seconds at startup. The boot process should trigger a simple loading animation (edit: just animation, no js or progress bar) that informs the user that the page is loaded. This boot display is killed once the wiki is loaded. An option would be to work with CSS pseudo elements for this task.

edit An implementational design suggestion is stated here: https://github.com/Jermolene/TiddlyWiki5/issues/2254#issuecomment-176123061

twMat commented 8 years ago

https://css-tricks.com/html5-progress-element/

felixhayashi commented 8 years ago

Hi @twMat

I agree, the "progress" element would serve well here.

Only css animation for reasons mentioned below

pmario commented 8 years ago

There are some CSS only spinners: IMO they would be simple to implement and modify: http://blog.pexels.com/css-only-loaders/

pmario commented 8 years ago

SVGCircus has some nice animations, but it uses script tags inside SVG, which won't work with TW. So some more work would be needed. ... But imo the animations are very nice. see: http://svgcircus.com/

felixhayashi commented 8 years ago

@pmario I am much in favour or css-only solutions. @twMat the problem with the progress element would be that it needs to be updated and what to use as "max" value? An endless spinner is better.

sukima commented 8 years ago

:+1: for css-only solutions

tobibeer commented 8 years ago

:+1: css only

I like this one... http://codepen.io/brunjo/pen/vELmaP hinting at how TiddlyWiki also does some zooming when opening tiddlers.

Jermolene commented 8 years ago

Hopefully it's fairly obvious that figuring out how the display progress bar is the trivial part of the problem. The hard part is figuring out how to interrupt the loading process so that our JavaScript can run and update the progress bar. For plenty of the delay that the user perceives the browser is doing stuff that doesn't give us an opportunity to run any JavaScript.

I think to tackle this we need to instrument the startup process sufficiently so that we know where the majority of the time is spent, and to the degree that any of them are JS tasks done by TW, we need to figure out which of them could be made asynchronous.

Jermolene commented 8 years ago

A simple loading indicator is a different matter, of course, it's just an actual progress bar that's difficult.

felixhayashi commented 8 years ago

A simple loading indicator is a different matter, of course, it's just an actual progress bar that's difficult.

Hi @Jermolene, yes, its not about updating a loading bar, it is about a css spinner that signals the user that something is happening (in contrast to a white screen).

felixhayashi commented 8 years ago

I updated the OP

sukima commented 8 years ago

We do this trick on one of our EmberJS apps:

It look s like this:

spinner

tobibeer commented 8 years ago

I guess one question to answer is: do we really need an algorhithm to assess the loading progress and what would be the actual benefit? I don't think we do. For me it's really more of a simple visual bridge to fill the gap.

twMat commented 8 years ago

Looks simple enough: http://www.gradient-animator.com/ More impressive: http://webdesign.tutsplus.com/articles/15-inspiring-examples-of-css-animation-on-codepen--cms-23937 (...is that second thing a Subtiddler? )

felixhayashi commented 8 years ago

I guess one question to answer is: do we really need an algorhithm to assess the loading progress and what would be the actual benefit. I don't think we do. For me it's really more of a simple visual bridge to fill the gap.

@tobibeer Yes, I think we all agree on that.

@sukima, you don't need to go that far to add elements. Just make use of css pseudo elements and once the core has booted, add a flag (e.g. a class) that disables the css style (as in your example).

sukima commented 8 years ago

@felixhayashi correct, In our case though we needed elements for our boot loading messages. In the simpler case a pseudo element would be better.

twMat commented 8 years ago

[OP]

Currently, a big wiki leaves a blank screen for a few seconds at startup

Come to think of it, this is really an opportunity that we shouldn't miss! - How can we make those, presumably unavoidable, screen seconds of animation be of value? - of value for the TW project or the users site.

Three approaches come to mind. Use those seconds of animation for either of

It should be an overwritable tiddler so people can modify it to their own needs.

Color marketing

tobibeer commented 8 years ago

Actually, I think this should be implemented via some $:/SplashScreen tiddler (or named differently) that is rendered on startup... assuming that's possible. Then users can define / override the default loading message any way they'd like.

felixhayashi commented 8 years ago

Here is what I suggest:

  1. In the control panel, the user can specify an image and a text, moreover, for technical reasons, he/she has to click on a button "create splash screen" to make changes effective (converting image into css; generating styles and markup).
  2. Once the user clicks on a "create splash screen" button, a tiddler tagged with $:/core/wiki/rawmarkup is created that contains a style tag with css instructions.
    • These instructions contain the image base64 encoded and a text that is placed in the css content attribute. So we have an all-css solution.
    • Hardcore users that want to design their own splashscreen may override default styles completely by using the tag $:/tags/RawMarkup (which is placed below markup generade by $:/core/wiki/rawmarkup)
  3. Once the wiki boots, the image is positioned in the very center of the window with the text below.
  4. Once the last startup module has loaded (or when would you suggest @Jermolene?), a class tc-wiki-ready is added to the <body> element which makes the css style rule invalid and removes the animation.

As @twMat suggested, we could do a little advertisement for tw here. However The boot process varies between 1 and 3 seconds. If you place a text message for the user to read, it will certainly often not be enough time to read it, which is frustrating/irritating ("wait I couldn't read that, was it important? it looked like an error?"). Moreover, I am certain, nobody wants to have a big picture in the core just to show a splash screen.

Therefore I suggest the following default: A small movotun jack svg (which is included in any wiki per default) displayed e.g. in changing colors (css) or pulsating (css) and a very short text below as default: "TiddlyWiki is loading"

Feedback?

felixhayashi commented 8 years ago

@tobibeer Ha! For some reason we thought the same thing ;)

tobibeer commented 8 years ago

;-)

I think I remember that in TW2 some SplashScreenPlugin actually inserted html into the wiki html, so you possibly even needed to save and reload twice for changes to take effect.

tobibeer commented 8 years ago

Therefore I suggest the following default: A small movotun jack svg (which is included in any wiki per default) displayed e.g. in changing colors (css) or pulsating (css) and a very short text below as default: "TiddlyWiki is loading"

Now that sounds quite neat indeed... and possibly not all that hard to achieve.

twMat commented 8 years ago

As @twMat suggested, we could do a little advertisement for tw here. However The boot process varies between 1 and 3 seconds. If you place a text message for the user to read, it will certainly often not be enough time to read it, which is frustrating/irritating ("wait I couldn't read that, was it important? it looked like an error?").

You're probably right... Maybe the color aspect for subtly communicating a "feeling" is the only thing that can be used... but probably not the default background gray...

A small movotun jack svg...

Sure. Would .svg be better than converting it to css?

BTW, how is this content fetched before the TW is loaded? Does it add to the loading time?

felixhayashi commented 8 years ago

Hi @twMat

sorry for my unprecise language in my previous post: First, there is no such thing as a css format. What I meant is that a bitmap image needs to be converted into base64 to be embedded into css.

That said, movutun jack is svg ($:/core/icon) and svg doesn't need to be converted into base64. Anyway, tw's utils methods do the job here automatically as far as I remember.

BTW, how is this content fetched before the TW is loaded? Does it add to the loading time?

The content is not fetched, it is statically persisted as html. Because $:/core/icon is super small it should be loaded in an instant.

sukima commented 8 years ago

I'm confused. I thought the problem was that there was a delay in rendering as the boot system loads. If that is the case how can a $:/SplashScreen or what ever work. Tiddlers are in divs that don't render till the boot system loads. The point of this is before any JavaScript runs.

The only option I could see is when a $:/SplashScreen changes modify the raw HTML. This obviously would lead to syncing problems.

tobibeer commented 8 years ago

The only option I could see is when a $:/SplashScreen changes modify the raw HTML. This obviously would lead to syncing problems.

That's what I was trying to hint at how it was done in TW2.

On tbGTD all the code that is needed is actually in my zzConfig plugin:

//shortened splashscreen code
var tbRestart=window.restart;
window.restart = function(){
    var splash=document.getElementById('SplashScreen');
    if (splash) splash.style.display = "none";
    document.getElementById('contentWrapper').style.display = "block";
    tbRestart();
}

The SplashScreen in that TW2 being defined in MarkupPreHead.

PS: Yes I know the above looks hacky. ;-)

felixhayashi commented 8 years ago

Hi @sukima

I'm confused. I thought the problem was that there was a delay in rendering as the boot system loads. If that is the case how can a $:/SplashScreen or what ever work. Tiddlers are in divs that don't render till the boot system loads. The point of this is before any JavaScript runs.

I am not talking about tiddlers, but about raw static markup here. TiddlyWiki offers us a clean way to inject markup into the html header using the tags I described above. This markup will not be virtual but truly stored in the html header. It all happens when the html wiki is build on the basis of $:/core/templates/tiddlywiki5.html. That's similar to how the page's title element makes it into the wiki src file. So this is completely independent of the boot or any tw rendering. Hope it's clearer now.

tobibeer commented 8 years ago

TW2 used the tiddler MarkupPreHead to inject content in the appropriate spot, before doing any major booting. So there only is some minimal kernel loading (boot) which injects the splash screen before most everything else.

A standalone wiki must be able to define its splash screen. For it to do that needs to be a tiddler that could actually be baked into the wiki's html upon saving ...or upon serving / building it via node ...as opposed to dynamically loaded first on startup.

felixhayashi commented 8 years ago

A standalone wiki must be able to define its splash screen. For it to do that needs to be a tiddler that could actually be baked into the wiki's html upon saving ...or upon serving / building it via node ...as opposed to dynamically loaded first on startup.

You are right, this is the only way it works + this is what is possible with TW5 + what I am proposing.

felixhayashi commented 8 years ago

TW2 used the tiddler MarkupPreHead to inject content in the appropriate spot, before doing any major booting. So there only is some minimal kernel loading (boot) which injects the splash screen before most everything else.

This was not optimal then, because if a crawler doesn't execute the wiki with javascript, then the markup won't be available. TW5 does a better job here.

tobibeer commented 8 years ago

This was not optimal then, because if a crawler doesn't execute the wiki with javascript, then the markup won't be available. TW5 does a better job here.

Possibly, TW2 actually did write those tiddlers to the actual HTML upon saving. Not sure.

tobibeer commented 8 years ago

Possibly, TW2 actually did write those tiddlers to the actual HTML upon saving. Not sure.

That would explain why at some point (I believe) it took two saves / refreshes for changes two apply.

  1. First time: Modify, save & reload the plugin.
  2. Second time: The plugin does its thing and replaces underlying html... which only showed up after another reload.
felixhayashi commented 8 years ago

That would explain why at some point (I believe) it took two saves / refreshes for changes two apply.

Ahh, I get it. I was wondering why you mentioned that at some point in the discussion.

felixhayashi commented 8 years ago

By the way, it just happened: 1700 stars ;)

telmiger commented 8 years ago

Hmm, I had some thoughts about this topic too, but in a different direction: How about using a kind of preload.html page for big wikis, which shows the animation, preloads the wiki page and redirects to wiki.html when finished? I am not sure, how this could be done, but found this in a discussion here at the end:

Prerender is the most powerful option. It tells the browser to request the url and download all the assets. <link rel="prerender" href="http://example.com/page">. You should be pretty sure that the person will open the page, otherwise you will just waste his bandwidt

This trick could be used for heavy wikis without increasing the weight of TW for the rest of the users. Just my 5 cents

danielo515 commented 8 years ago

This is closely related with this commit:

https://github.com/buggyj/TiddlyWiki5/commit/91a2afd2495122a534f9e6066e7e7272e83ca119

And this issue #2159

Jermolene commented 8 years ago

Hi @danielo515 this topic is quite long and embraces a number of distinct suggestions, which one are you thinking of?

danielo515 commented 8 years ago

Hello @Jermolene

I'm referring to what @tobibeer said:

I think I remember that in TW2 some SplashScreenPlugin actually inserted html into the wiki html, so you possibly even needed to save and reload twice for changes to take effect.

This happens on TW5 too as it is exposed on issue #2159

telmiger commented 5 years ago

After #3417 is resolved, I would suggest to close this issue too. Users can find a spinner anywhere and display it on their splash screen.

Jermolene commented 5 years ago

Thanks @telmiger