The Responsive Image Challenge – Part 1

ej

Images on the web used to be pretty simple. Upload your image to a server, throw the URL into an HTML <img> tag, and then it would appear on your page. No big deal.

However, a lot has changed in the last two years.

In 2007, Apple released the first-generation iPhone. The iPhone was the first smartphone that appealed to the average person. And, as we all know, it was a huge success and now all the major smartphone manufacturers are taking the same approach.

Overall, smartphones are great. You have instant access to the Internet, GPS navigation, calling, and texting all from a little device that you carry with you. For website maintainers, however, smartphones and the many devices they’ve spawned present some serious problems.

Problem #1 – Mobile connections are slow

While mobile speeds are a ton faster than they used to be, they’re still pretty slow compared to a traditional connection, especially outside of a big city.

So why is this a problem?

Well, compared to text and HTML code, images are really big. In fact, the text, html, CSS, and Javascript from www.bethel.edu is about 10% of the total page size. The other 90% is mostly images.

All that to say, text loads really fast, images load really slow. You can have an entire essay that’s smaller than a single image. On a desktop connection, not the biggest deal. However, this can make a huge difference on a slow mobile connection.

The simple solution: Make images as small as possible. Easy, right?

Not so fast.

Problem #2 – Retina

In 2010, Apple coined the term “Retina display.” In reality, this is just a screen with a ton more pixels than normal and an operating system that can still make everything look good. This is amazing for text and icons. Everything is smoother and overall better to view. So what is the downside? Well, images of course.

If anybody happens to be reading this on a Retina laptop, you might have noticed images look really bad on some websites. Why is this? Well, if you double the pixels of your display, but don’t double your image size, the images will have to expand to fill in the extra area. This causes blurry images all over your websites.

On a desktop, you can just serve an image twice as big. Not a huge deal. But what about mobile?

Retina screens are actually more popular on mobile than laptops because you actually hold those devices close enough to notice the difference. The catch-22 is that if we make our images look good, they are twice as big, and therefore take twice as long to load. If you compress them too much, the image quality will deteriorate. So we are dealing with the worst of both worlds—slower load speed with larger images. And even if connection speed wasn’t an issue, there is one more thing to consider…

Problem #3 – “Just make a bigger copy”

Pretty easy to say, but extremely hard to do.

If your source image is 300×300 but needs to be 600×600 for your Retina device, you can’t exactly just expand the 300×300 copy to be twice as big. It will look just as bad as if you served the 300×300 copy to begin with.

This relates to our first rule of images: “Always upload the largest copy possible.” Technically, we could serve this image all the time, and the let the phone or computer shrink it to the correct size. But these images are huge. At 3-5 megabytes a pieces, using this method would make our homepage close to 20 MB’s—a 2000% increase of our current page size.

So we need to resize it. But now the problem is that resizing and compressing images takes time. And time is very valuable when serving to a mobile connection. This creates a second rule:  ”Have your resized images ready to go before they’re needed.” Okay…so we need to have a different image size ready for every single width and height we’ll need to serve.

Great. And since we’re trying to speed things up, we’re going to need to make sure we only serve the exact size needed for the page. This ensures we’re loading as little data as possible. That is, if an image is only going to take up 100 pixels on the page, we don’t want to make someone load a 600-width version of the image. This is in line with our final rule, “don’t serve a bigger image than you need.”

Putting all those rules together shows how big of a problem this can be.

Before, we had one single image in an HTML tag. Now we have 10-20+ versions of the exact same image needed for a single webpage. After all, there are so many different phones, phablets, tablets, laptops, desktops, etc., that all need something different. That’s a lot of overhead.

We’ve spent a long time trying to create a solution that is fast, responsive, and extremely easy to use. And we think we’ve come up with something that, for our web authors, will be as easy as it was pre-2007 when we all we had was one image inside some HTML. Just put your image on the page, and leave the rest to us.

So how do we solve this? Check back next week for The Responsive Image Challenge – Part 2.

High-Stakes LEGOs

ej

Last week we mentioned that there are tons of parts that go into a single page in Cascade. It’s actually a little insane just how many different pieces there are. When we logged into our fresh Cascade install for the first time, it was overwhelming how empty it was. Up until that point, our demos and sandboxes had been somewhat functional. Now we had to start from a completely blank slate. We’ve had many meetings where all we do is draw diagrams trying to wrap our heads around how all the pieces fit together, and which blocks to work on first.

 

It might seem like all the different pieces would make it too complicated to use. But in reality, it’s almost the opposite. You can almost think of Cascade as a CMS to build a CMS. We start with a blank slate and work until we have Bethel-flavored Cascade ready to go.  This is where it’s advantageous to have all the different pieces and possibilities. We can put them together so they fit our needs perfectly in an easy-to-use package.

Right now we’re essentially playing with high-stakes digital LEGOs. Even our most basic page has dozens of parts. But this is actually a good thing. When we’re done, you won’t see individual LEGO blocks. Instead it will be finished LEGO sets, glued together so they won’t fall apart—ready to play with.

 

 

Fitting a Square Peg into a Round Hole

ej

Throughout the past year, Bethel’s been making plans to replace Silva with a new content management system (CMS). We’ve been working with our new system, Cascade, for about a month, and after countless hours of training, reading documentation, and experimenting, I think it might be safe to say we’re starting to feel confident.

You might might be thinking both Silva and Cascade just put words onto the internet, so how different can they be?

Great question.

It’s almost like trying to fit a square peg into a round hole. On the inside, they couldn’t be more different. Silva is a square cartridge and Cascade is a round hole. It’s our task to move over parts of Silva until they are square and work “The Cascade Way”.

So far I’d say we are off to a good start. In the last month alone we have:

  • installed a fresh copy of Cascade
  • integrated it with Bethel Single Sign On
  • integrated basic pages, forms, and videos

To make things more complicated, each piece in Cascade is built using a ton of different parts (more on that in another post…). This means we’ve have to read, plan, experiment, and then read some more, all before we could even try and set up the most basic page we could imagine.

The good news is that if we set it up right, it will be simple to use. All the burden is on us to do things well so we make creating and editing pages as easy as possible. We’re excited for the task. And we’ll keep you posted on our progress.