Full service digital agency.

We create awesome digital experiences that make people smile

Get to know us

EN slash NL

(W)APPSITE

We all have an idea of what a Website is and what an App is. We all know what they are and what they do, 9 out of 10 times there’s not a whole lot of difference. So why not just combine the two, since they’re already so alike?

The past years everyone became familiar with websites and of course they did improve massively, technically and design wise. Together with the way websites are used — Business cards used to be filled with information that was not really relevant, nowadays we choose the message, information and tone of voice with care. All together the experience as a whole got a bit smoother and better thought through.

But how can we smoothen this even further? Right now in too many cases we have to stare at a loader, waiting for the page to load. Not the most elegant view we can safely say. So a nice opportunity to fight mediocrity and make the Internets a bit nicer. No more waiting and weird looking loading pages!

What if you visit a page, and every time you click a link, you’re still able to continue browsing that page until the new page is done loading? Then, with a elegant transition you get redirected to the new page. Wouldn’t that be nice? Actually this is exactly what an App does. A little more App-feel to our Website experience will surely be appreciated on your side too right?

<!— Nerd glasses on —!>

How are we able to mange this, and how do we implement this without using a large library like AngularJS when this is the only reason for using AngularJS? Routing a website like this shouldn’t be too hard. There are a few steps we have to take, and an other few things we have to think about when we implement this.

Backend wise there is not going to be much of a difference. Pages will still be rendered the same way as they always have been. However, on the frontend there is going to be a slight difference.

/* But, how do I know which link should trigger a transition? */

First we would have to add a class, data attribute or some kind of indication that we want to trigger a page-transition (Since we only want internal links to trigger a transition). This could be done backend wise although there will be WYSIWYG editors where the client will add links themselves which is harder for them to check. Plus, if a browser is not compatible with some elements, we also don’t want the script to run. Therefore we will add the indication for a page-transition with jQuery/JavaScript. This could be done in several ways. For example checking all links on page-load with startsWith(‘/‘), since external links will never start with a ‘/‘. Checking on startsWith(window.location.origin) as addition is also necessary since some url’s will also include the location.origin.

// Great, additional data on my links 🙁 What now?

After that we know which links should trigger a page-transition. Structure wise some modifications are also needed. Of course there are several ways this could be achieved, for the sake of this article ill pick one that includes two different wrappers.

One for the current page, the page we actually already see when we open the page. The other for the new page to render in while we can still browse through the current page which will be empty when we visit, for example; the homepage. With some styling one wrapper is shown, the other one is hidden so the new page will be able to render without showing.

Then, it’s actually pretty simple. When someone clicks a link an ajax call will fetch the new page and place the contents of the new page in the second wrapper that was empty.

Of course we want to wait for the new page to be fully rendered before we show the new page. When we injected the new page content in that “invisible” wrapper, images and other page components already started rendering. The only thing we will really have to wait for are images. I’ve chosen a small plugin to get a callback whenever these are ready to be shown. It’s called “waitForImages” and is publicly available for anyone :).

https://github.com/alexanderdickson/waitForImages

(* So the loading is done, splendid. What’s next? *)

There’s only one thing left in order to show the new page. With some styling we’ve managed to show one wrapper and hide the other. Now a class could be added to the hidden wrapper or to the body in order to trigger a transition. With just styling we can switch the visibility of the two wrappers with a fancy transition.

After all this the page should be set to a state just like we’ve engaged the page in the first place, with that same empty wrapper so we can repeat the process.

With jQuery/JavaScript we can just simply change the classes of the wrappers, set the new wrapper to the current wrapper and delete the old-current wrapper. Then, after all that creates a new empty wrapper so we can repeat the process.

# My SEO friends are not going to be happy!

Indeed, that’s why we have some last steps to satisfy the SEO guys :). In this process of switching pages we also have to set some data to the data of the new page:

  • Change all meta tags
  • Trigger a virtual page view (since Google Analytics and GTM do not register a actual page visit)
  • Change the url
  • Change the page title

Besides that any other page unique information.

Changing meta tags can be done with filtering all meta tags when you do the ajax call. Do the same with the current meta tags and set the new tags while removing the others. A virtual page view should be triggered so Google Analytics or GTM actual register page views. The url can be simply changed with a JavaScript pushState (history.pushState({}, “”,  newPageUrl);). The page title can be simply changed with document.title.

One more thing…! Do not forget the window.onpopstate function, so people are actually able to use the back and forth buttons from their browsers.

PS: Be careful with some JavaScript variables that you probably will have to set again after the page-transition.

Generation (w)Appsite


,

Connect