aws iam errors
Share on facebook
Share on twitter
Share on linkedin

Serverless User Interfaces: Stealing the best of mobile for the web

Sam Kroonenburg
Sam Kroonenburg

Introductory Note: This is the first of a comprehensive series of blog posts in 2016 that the A Cloud Guru team will be writing on Serverless Architectures in AWS. We’re busy building our learning platform with a unique serverless architecture on AWS, using AngularJS, AWS Lambda, AWS API Gateway & a raft of other technologies. We really hope you enjoy this series.


Enhancing serverless web app experiences with content placeholders.

I was going to title this post “Death to the AJAX spinner”, but I resisted the urge to be inflammatory (thank you, thank you). However, as you read, please know that this article is aimed squarely at destroying the god-awful AJAX spinners from all corners of the web.

OK — so we know that moving to a serverless architecture has a lot of advantages. You can very quickly build rich and responsive web applications, that can perform very complex tasks.

But going serverless means exactly that: no servers… which leads to some interesting challenges. When your site first loads, it is like a child — it doesn’t know anything about the world. It doesn’t have your data or content pre-loaded — it has to go and fetch it all from cloud services (such as your API, or cloud data-stores like Firebase or DynamoDB)

Umm, why’s that?

Well, in traditional systems, web servers serve up the site HTML and JavaScript each time a user’s browser requests it. These servers sit in the middle and dynamically inject up-to-date content and data into the HTML and JavaScript — so that this content is available to display as soon as the browser loads the site.

Without a server, your front-end code is static. It’s a robust and powerful single-page app that, once loaded in the browser, talks to an array of services in the cloud to fetch data. It can be deployed via any CDN — there aren’t any active servers generating your HTML & JS based on user requests. Every user gets exactly the same copy of the HTML, JS & CSS at all times. This means that you don’t have to manage any servers and it’s blazingly fast to load the initial app, but that app doesn’t have any of your data/content embedded in it.

The serverless model is a little different: There’s no web server to inject content into the HTML data.

DEATH TO THE AJAX SPINNER!

(there, I said it)

The result of this architecture is a period of up to 3 seconds or so where your web application has loaded, but the app is still fetching your content. Which leaves us with the problem of what to show the user during this window…

In the past, we used a couple of different approaches:

The whole-page ajax spinner

The entire page is covered by a single spinner, and the user doesn’t see anything until the entire page is loaded.

Hundreds of tiny ajax spinners

Where the UI is made entirely of sections that need to be loaded and there’s a spinner for EVERY. SINGLE. ONE.

These approaches are really painful to watch. They don’t give the user any indication of what is coming & where to look. When the content does load, all of the sections of the page jump around and move as the data is filled in. It’s hard to know where to look as the page reflows itself before your very eyes.

Our first site design used AJAX spinners everywhere, and I was never proud of it. Our recent redesign gave us the opportunity to change things up.

So, where can we look for inspiration?

If you think about it, mobile apps are a great parallel to rich single-page web apps. In mobile, the application code is stored on the mobile device and therefore loads instantly. The apps then need to fetch data from the web to fill in the UI with content. And mobile is a great ecosystem to draw inspiration from because of it’s generally high standard of user experience.

These days, there’s a trend in great mobile apps towards placeholders. Placeholders are essentially little great boxes that fit in exactly where the content will go,once loaded. You’ve probably seen placeholders in apps like Facebook and LinkedIn.

Left: The Facebook for iOS app. Right: The LinkedIn for iOS app.

Placeholders match the size and shape of the data you know you are going to load. They allow the users to “take in” the user interface, and understand where things are going. When your content loads, a user’s is already looking at the right place on the screen and ready to read. There’s no time needed to adjust to the layout of the page, because the user has already taken this in. It serves for a much less jarring user experience.

So we decided to incorporate placeholders into the A Cloud Guru web application. If the data is being loaded, the placeholders show. If the data is ready immediately when the user navigates to a page then the placeholders don’t show, the content just loads immediately… so you get the best of both worlds.

Featured Courses on the A Cloud Guru Site
Featured Discussions on the A Cloud Guru Site
The Course Listing Page With Fade-In Effect

A reusable CSS framework for placeholders

We knew that we wanted to build placeholder support throughout our site — anywhere that data is loaded from the cloud. So we built a re-usable CSS framework for our placeholders, complete with an animated shimmer effect to indicate that the content is yet to be loaded. Here’s how it works…

By simply addling a ‘placeholder’ CSS class to an element that will show content, it will be initially covered with a grey placeholder shape that is animated with a shimmer effect. The framework uses the CSS :before pseudo-class to add this additional element to the DOM, positioned using z-index and relative positioning, over the top of the content element.

There’s a few different shapes you can choose from:

Block elements

Where you expect to load a rectangular block of content, we overlay a rectangular placeholder

<p class=”placeholder”>Some text</p>

Circular elements

Some elements are circular nature, such as user profile images. In these cases you want to show a circular overlay.

<a class=”placeholder placeholder-circle”><img src=”images/myimage.jpg”/></a>

Hidden elements

Some elements will vary wildly in appearance (size / shape) when the data loads, or may not even show at all. In these cases you actually don’t want to show a placeholder because it can make the experience quite jarring to have a placeholder that is then replaced by content that doesn’t match it.

In this case, we created the placeholder-hidden class. While the content is loading, the original element is simply hidden with zero opacity. When the content loads, the element is faded in, if it exists.

<span class=”placeholder placeholder-hidden”>{{scores.highScore}}</span>

Half block elements

Where you expect to load a rectangular block of conten that consumes approximately half of the element’s width. This is useful for short pieces of text, that may expand beyond 50% width when loaded, but most of the time won’t.

<span class=”placeholder placeholder-half”>Some brief text</span>

Quarter block elements

The same as above, but a quarter of the element’s width rather than a half.

<span class=”placeholder placeholder-quarter”>Some tiny text</span>

The Code

As soon as the content loads, we have our AngularJS code add the ‘loaded’ class to a parent element, and the placeholders are then automatically faded out by our CSS framework.

The placeholder elements take the size of the original content element that you add the ‘placeholder’ class to — so it’s important that you set min-width and min-height (or line-height) values to each content element.

But it’s 2016. We have electric cars and can land rockets back on earth. Surely I can have my cake and eat it too?

Placeholders are a really nice effect for dynamically loaded data. But there’s some content so important that your users really shouldn’t have to wait for it. If you are running an e-commerce store then your lead promotions should show at the top of the page as soon as it shows. Showing placeholders instead of sales information while the page loads is a sure-fire way to lose business.

There is a way to do this in the serverless, single-page-app model — made possible by good DevOps practices and continuous integration/deployment strategies.

You can actually insert a step into your build system to fetch the most recent data (such as recent promotional content), and pre-cache this into your JavaScript code. This way, your site can show it immediately as soon as the web app is loaded, whilst then contacting the cloud to look for any recent changes.

If you have a good CI system setup, like Travis CI, then you can simply use a web hook to kick off and deploy a new version of the static web application code each time this data is modified. So, when one of your product managers updates a promotion’s content, the system can automatically trigger a new build of your static web site code with this data cached inside it, and automatically deploy this new build to your host CDN.

We’re currently working towards this model with A Cloud Guru, for our course listings, prices and promotional information.


Serverless architectures bring new user experience challenges that can be overcome by looking to other eco-systems that have faced similar problems, like mobile. Placeholders are a great way to keep users engaged with your site in that brief period of time before your content loads.

Sam Kroonenburg

A Cloud Guru

The mission of A Cloud Guru is to engage individuals in a journey to level-up their cloud computing skills by delivering the world’s leading educational content designed to evolve both mindsets and careers.

“Let no man in the world live in delusion. Without a Guru, none can cross over to the other shore.“ — Guru Nanak

Our courses are delivered by industry experts with a shared passion for cloud computing. We strive to serve our growing community of cloud gurus, who generously contribute their insights in our forums, workshops, meet-ups, and conferences.

Keep up with the A Cloud Guru crew @acloudguru.

Recommended

Get more insights, news, and assorted awesomeness around all things cloud learning.

Get Started
Who’s going to be learning?
Sign In
Welcome Back!
Thanks for reaching out!

You’ll hear from us shortly. In the meantime, why not check out what our customers have to say about ACG?

How many seats do you need?

  • $499 USD per seat per year
  • Billed Annually
  • Renews in 12 months

Ready to accelerate learning?

For over 25 licenses, a member of our sales team will walk you through a custom tailored solution for your business.


$2,495.00

Checkout