Tag Archives: HTML

Three ways to load lazily

Lazy loading is a method for optimizing a website by loading images (or iframes) on demand.  If properly implemented, the browser should load the images that are at the top of the page first and wait to load the rest until the user starts to scroll down the page.  This is something that is relatively easy to implement but more difficult to test.  While writing the examples for this post, I opened the browser console, switched to the network tab, and watched the images load.  If you want the effect to be more pronounced, you can throttle the speed of your network connection but it didn’t help to much in my case. Continue reading Three ways to load lazily

Data URLs

Last week, we talked about CSS sprites and a large benefit of it was that the user didn’t need to retrieve as many image files from the server.  This week, we are going to look at how to not need to retrieve ANY image files from the server.  The method is something called data URLs.  I used this concept five years ago with my TNO encryption demo.  Let’s take a look at a quick demo.

See the Pen
Data URLs – Part 1
by Joe Steinbring (@steinbring)
on CodePen.

In the simple demo above, I base64 encoded a JPEG file and just included the full content of the file (using the data:[<mime type>][;charset=<charset>][;base64],<encoded data> syntax).  Let’s looks at one more example.

See the Pen
Data URLs – Part 2
by Joe Steinbring (@steinbring)
on CodePen.

This one works the same basic way but instead of using a JPEG file, I’m using a PNG file.

So, why use this method?  The big reason is to have one fewer asset to load into the page.  You are still requiring the client to download the same amount of stuff but it is via one HTTP request instead of two.  I have also seen people use this method to more easily include graphics in HTML email messages.

Easy enough, right? 🙂  Have a question, comment, etc?  Feel free to leave a comment.

 

[ Cover photo by Joshua Sortino on Unsplash ]

Fixing JWS.app: The “Superfeed” (Part 1)

One of the goals for JWS.app was for it to pull in activity from a bunch of sources and update itself.  That is the reason why I created the “superfeed”.  Let’s start by looking at its current state.

See the Pen
JWS.app – Superfeed (Before)
by Joe Steinbring (@steinbring)
on CodePen.

Getting the content from the photo blog, the blog, dev, github, and the two tumblr blogs and interleaving the content was tricky enough.  When it came to displaying the updates, I just used an unordered list in version 1.  I couldn’t immediately think of an alternative.  In previous weeks, we have leveraged Bulma.  I figured that we could use it again.

See the Pen
JWS.app – Superfeed (After – Option 1)
by Joe Steinbring (@steinbring)
on CodePen.

The above example uses Bulma‘s Media Objects.  This look is similar to what you see with things like twitter.  It feels like a lot of waste, so let’s try another option.

See the Pen
JWS.app – Superfeed (After – Option 2)
by Joe Steinbring (@steinbring)
on CodePen.

This might be my favorite option, so far.  This example uses Bulma‘s Cards.  My goals were for long-form posts (like this) to be more prominent and to do something mildly similar to Microsoft’s Metro design language.

I am not completely sure if the Bulma Card solution is best option or not but I do think that there is a next step to this.  Previously, we looked at the Notifications API and that got me thinking about incorporating push notifications.  I might need to add some sort of Modal (to have something to link to), though.

 

[ Cover photo by AbsolutVision on Unsplash ]

Fixing JWS.app: Turning our attention to the footer

I have never been fond of the footer on JWS.app but I’ve been unsure what to use, there.

After addressing the elements at the top of the page, it makes sense to turn our attention to the very bottom of the page.  Considering how much we have leveraged Bulma so far, it also makes sense to do it the Bulma way.  Let’s see how that would look.

See the Pen
JWS.app – The Footer
by Joe Steinbring (@steinbring)
on CodePen.

It works but let’s try it another way.

See the Pen
JWS.app – The Footer (Option 2)
by Joe Steinbring (@steinbring)
on CodePen.

I’m not sure if I prefer option 1, option 2, or future option 3 but I am guessing that there might be a part 2 to this post.

 

[ Cover photo by Cristian Newman on Unsplash ]

Fixing JWS.app: Styling the content on the page

Previously, we have looked at the navigation bar, the hero image, and the combination of the two.  I figured that next natural step is to look at how to style the content on the page.  I want to add some sort of visually pleasing container and Bulma‘s box class seems to be a good option.

See the Pen
JWS.app – Adding Section Boxes
by Joe Steinbring (@steinbring)
on CodePen.

You will notice that I also added an “upwardbump” class to create a slight overlap of the content over the hero image.  It is a visual element that is present on the current style of this blog that I kind of liked.

 

[ Cover photo by Kelli McClintock on Unsplash ]

Fixing JWS.app: What if we merged the nav bar with the hero image?

Previously, we looked at using Bulma to improve the nav bar and we looked at ways we could improve the hero image.  I figured that this week, we would combine the two.

See the Pen
JWS.app – Hero with Nav
by Joe Steinbring (@steinbring)
on CodePen.

I kind of like this look but the nav bar might not have enough contrast.  Let’s try one more variant.

See the Pen
JWS.app – Hero with Nav (Option 2)
by Joe Steinbring (@steinbring)
on CodePen.

 

What do you think?  Have any questions, comment, etc?  Feel free to drop a comment, below.

 

[ Cover photo by TK Hammonds on Unsplash ]

Fixing JWS.app: The Hero Image

Last week, we looked at more ways to tweak the nav bar on JWS.app.  This week, I figured that we would move down to the hero image.  The current hero image is dynamically generated based upon a subset of images on photos.jws.app.  It doesn’t look great, though.

See the Pen
JWS.app – Hero (Before)
by Joe Steinbring (@steinbring)
on CodePen.

I think that we can improve it with a gradient and making the image a background.

See the Pen
JWS.app – Hero (After – Option 1)
by Joe Steinbring (@steinbring)
on CodePen.

The next big question is if the navbar should be visually overlapping the hero image and if the website name should be a little more prominent.  That might need to wait for a future post, though.

Have a comment or suggestion?  Feel free to drop a comment, below.

 

[ Cover photo by Steve Halama on Unsplash ]

Fixing JWS.app: The Nav Bar (Part 2)

Last week, we looked at two ways to fix the nav on JWS.app.  For the first option, we simply added an additional header that displays when the screen width gets narrow enough.  For the second option, we introduced a hamburger menu.  This week, let’s look at two new options.

The first of this week’s options uses Bulma.  We have looked at Bulma‘s responsive navigation bar once before.  Let’s see how it works to implement our JWS.app navbar with it.

See the Pen
JWS.app – Header (After – Option 3)
by Joe Steinbring (@steinbring)
on CodePen.

The above example has no custom CSS in it.  It simply uses Bulma and it’s CSS classes for styling.  This example is pretty close to the original look and feel but it implements a hamburger menu when the screen width calls for it.  It is worth noticing that I did add an “onclick” in order to get the hamburger menu to work.

For second option, let’s look at how to implement the navigation using Bootstrap.

See the Pen
JWS.app – Header (After – Option 4)
by Joe Steinbring (@steinbring)
on CodePen.

The biggest difference with the above example is that it not only requires the Bootstrap CSS library but it also requires the Bootstrap javascript library and that library requires jQuery.  Without the javascript libraries, the hamburger menu doesn’t work.

Have a question, comment, suggestion, etc?  Feel free to drop a comment, below.

 

[ Cover photo by Joseph Barrientos on Unsplash ]