Cloud Four Blog

Last year, John Keith, one of the founders of Cloud Four, started a side venture called Lucid Meeting. John doesn’t like Lucid Meetings to impinge on Cloud Four which is why you haven’t heard much about it on our blog. It is also the reason why I’m writing this post without his knowledge (sorry John!).

John and his co-founders at Lucid Meetings set out to make meetings that don’t suck. We’ve complained for years about rudderless meetings with no agenda, no leader and no follow up.

They decided to do something about it.

So Lucid Meetings started out focused on providing a way for people to set agendas, focus meetings, and take action items out of the meeting. Over the last year, it has grown into much more than that including:

• Meeting minutes
• Screen sharing and pdf presentations
• Time tracking to keep people on task
• Voting on motions and recording of decisions
• Integrated conference calling

It is the last one that they’ve made big improvements on today. They’ve just shipped:

• Free toll calling for every room up to 50 participants
• Volume discounts for businesses that want to switch over

Those may not seem like a big deal on the surface, but the changes are huge because the combined solution is better than current web sharing and collaboration software at a price that is significantly cheaper.

Basically, you get something better and save money. Pretty much a no brainer if you’re doing any web conferencing or running remote meetings. Check it out.

What’s even more exciting for me is that all of this has been built by a small team with hard work and passion. They’ve had no outside investment. And they’ve built something that I think will have a big impact.

I’m very excited by what they’ve done thus far and what they’ve got planned on their roadmap. Congratulations to John and the Lucid Meetings team!

Jeremy Keith has taken issue with my post about using device detection as a future friendly solution for responsive images. I think he missed the point.

The entire post was about what technique to teach in the book we’re writing. A book that has a deadline at the end of the month.

Jeremy writes:

The solution seems clear: we need to standardise on browser download behaviour …which is exactly what the HTML standard is doing (along with standardising error handling).

That would be awesome. Doesn’t help with the book. He continues:

That’s why I was surprised by Jason’s conclusion that device detection is the future-friendly img option.

Two bits of clarification:

1. The thing that makes it future friendly isn’t the device detection. It is the fact that the markup is unchanged. It buys people time until either browsers standardize download behavior, we have a replacement for the image tag or someone finds a yet undiscovered way to solve this problem. Every other technique requires changes to the markup that are specific to a particular solution and rely on browser behavior that hasn’t been standardized.
2. Again, my post was in regards to the questions I asked about which technique to teach in the book. I outlined the constraints of the book series and talked about how I entertained the idea of teaching the noscript technique before being talked out of it. Basically, I provided a lot of context for how I was evaluating the techniques for the book.

In addition to standardizing download behavior, Jeremy describes ways that he would like to see device detection improve. All of these are advances we’d welome. They are things that we might even have time to work on once the book is complete. But they aren’t the constraints I outlined in my posts and thus the rebuttal misses the mark.

So yes, device detection, as Jeremy says, is present-friendly way of keeping you from butchering your markup in a way that kinda, sorta works with today’s browsers, but may not work for tomorrow’s browsers.

However, having clean, semantic markup that so you can quickly replace device detection with a better solution in the future is the part that is attractive and arguably more future friendly than picking one of other unproven solutions and littering your markup in the hopes these solutions prove to work in the long run.

With that, I’ll conclude the same way I did my last post:

At least that’s how I see it for the book. For your project and use case, it depends.

Last week I wrote about why I was considering teaching the noscript technique in our book and asked for someone to talk me out of it before I committed what I feared would be a long-lasting crime against web development.

The post worked. I got some great feedback, and I’ve decided against using noscript in the book.

Instead, I’m going to use Sencha.io SRC (aka TinySRC) in the book. Much to my surprise, it seems like the most future friendly option.

The problem with the noscript version

Sometimes I need something explained to me multiple times before I get it. Understanding why using noscript was a problem for semantic markup was one of those times.

Fortunately, Stephen Hay got through my thick skull with this paragraph from an email he sent:

Noscript means we get an empty arbitrary container element and a noscript element in our HTML, which is meaningful only within the context of this particular solution. Other methods, take Scott Jehl’s
data-attr method as an example, at least begin with an image element. This, in contrast to the noscript technique, is meaningful in *any context in which HTML can be understood*, whether by machines or by people.

Brad Frost and Bryan Rieger also provided helpful feedback that reinforced Stephen’s point and jarred me back to my senses. And Steve Souders pointed out a bunch of performance issues I hadn’t fully considered.

Device detection as the most future friendly option

In a follow up email, Stephen laid out a line of logic that made choosing to teach TinySRC a no brainer. I will attempt to paraphrase it here.

While there are many responsive imgs techniques, they primarily fall into three main approaches:

1. Client side solutions that rely on cookies and browser parsing order. — These solutions can be done with semantic markup, but they rely on current browser behavior. Yoav Weiss has done some tests on preloaders and cookies showing that images sometimes get downloaded before the cookie is set. Because this is based on the current way browsers parse documents and not a standard, it could break at any time.
2. Noscript techniques. — Works reliably, but is an obvious hack (and a brilliant one). Not sustainable because the markup of the page no longer contains the full meaning that it once had.
3. Images being handled by device detection. — Device detection uses the user agent string to make decisions. I’ve been referring to device detection as the third-rail of web development. Like politics and religion, device detection is a topic you want to avoid if you want to have pleasant conversations. But a lot of people use TinySRC without incident.

For the book, we need to pick something that will stand the test of time. That’s what makes me nervous about option 1. Who knows when it will suddenly stop working (if it hasn’t already given Yoav’s tests).

Between options 2 and 3, we have a hack that requires us to change our markup in a solution-dependent way (noscript) and a solution that relies on the very thing most web developers have come to despise (user agent based detection). Here I must quote Stephen again because he says it so well:

When you asked about future-friendliness, I tried to think ahead to the future and imagine what the state of these documents might be. My stance is that when we no longer need device detection, we simply remove it. All of our files are intact, as they have been left alone. Our markup is still meaningful. The content is still properly structured. Not so with the noscript hack, which requires us to revert to the markup we could have had in the first place. The choice—for me at least—was clear: device detection is a pluggable solution, which can be “unplugged” once a better solution comes along.

The idea that something like TinySRC is a pluggable solution which can be unplugged is incredibly compelling. We don’t have a fantastic, client-side only solution. Or at least, we don’t have one that I feel confident enough in to include in a book and not fear that it will look foolish six months from now.

Plus, Stephen is not a fan of device detection. He isn’t simply falling back to what he is comfortable with. If anything, it is the opposite of what he would prefer to do.

I do have some concerns about teaching something that relies on a third-party like Sencha.io SRC, but I feel James Pearce will keep it running through sheer force of will if nothing else. And if it does go away, the book does teach device detection fundamentals which would give someone the basic tools they need to create their own image service.

How strange it is to think of device detection as the most future friendly of the three options? I find it hard to argue with the logic.

At least that’s how I see it for the book. For your project and use case, it depends.

I asked recently what responsive IMG technique we should teach in our book? Unsurprisingly, there wasn’t a clear winner in the comments.

After agonizing over this for a couple of weeks, I’m leaning towards using the noscript technique as the primary example in the chapter with additional information on where to find the other approaches.

I’m towards this approach despite the fact that Scott Jehl, Ethan Marcotte and Brad Frost all feel that the noscript technique isn’t future friendly. So as you can imagine, I’m terrified that I’m making a big mistake.

As I understand it, the argument against noscript as a technique is that it isn’t semantic markup. The attributes for the eventual img tag are put on the noscript tag which isn’t where they belong. Attributes for images belong on the img tag.

I’m probably butchering the arguments against noscript which is why I’m writing this post in hopes of understanding it better before it is too late for the book.

Why teach the noscript technique

Here are the reasons why I’m leaning towards using the noscript technique in the book:

• We need to use one technique to build a web page in the chapter.
  A few people suggested talking about a few different techniques and their relative merits instead of teaching one technique. That might work in a different kind of book, but won’t cut it for a Heads First book. Every chapter is structured to include a real project, exercises and working code.

  We can talk about how all of this is very new, but at some point we need to show how to the handle images on the web page that the learner is building in the chapter.

  It is easiest to think of the chapters as stories. We have a protagonist (the learner) and a journey they are on. Teaching multiple techniques would be choosing one path for the story, go down that path, and then suddenly say, “Alright, now let’s go back to where we started and go down that other path.” It wouldn’t work.

• I want to avoid server-side resizing of images.
  I know server resizing of images is probably a core part of a long term solution, but I need to teach the challenges of determining the size of the screen and picking the appropriate image. How do you tell the browser what image to download? After we’ve taught the challenges, then we can talk about server-side resizing. Otherwise, it seems like there is a magical black box taking care of things for us.

• I can’t guarantee that the other techniques will work.
  Every other client-side technique relies on assumptions about the order in which browsers will load assets. We’ve already discarded dynamic base tags because the browser behavior changed and images were getting loaded twice. Yoav Weiss has done some tests on preloaders and cookies showing that images sometimes get downloaded before the cookie is set. This will result in multiple image downloads.

• We don’t have a wide deployment of any of these techniques.
  The Boston Globe’s images haven’t been fixed yet. Our book deadline looms. Whatever we choose is going to be unproven.

• I can explain why noscript works. Yes, the noscript solution is easier to implement because it doesn’t require Apache rewrite rules and cookies, but that alone wouldn’t be enough to cause me to shy away from it. We’re teaching WURFL in the book so we’re not shying away from teaching complex things.

  When I say I can explain how noscript works, I mean I can explain clearly why images don’t get downloaded. The browser knows before the page loads whether or not javascript is available. If it is available, the img inside the noscript tag won’t get loaded. This behavior is easy to understand and reliable. It has worked this way since the noscript tag was created.

  After all of this research, I still don’t have a clear explanation of the preloading behavior of browsers. Without doing extensive testing or reviewing the loading code for every browser, I don’t think we’re ever really going to understand how it works nor be confident it won’t change in the future.

• Elegance of a wading hippo notwithstanding, noscript works.
  As far as I can tell, it works 100% of the time. I’ve been trying to think of conditions in which it wouldn’t work and haven’t come up with any.

• Tyler Sticka would teach noscript.
  In addition to being a fabulous web designer, Tyler teaches a college course on web design and development. I had the opportunity to speak to his students last year. When I think about whom we’re writing this book for, I think about people like Tyler’s students. Because of that, Tyler’s endorsement means a lot to me.

To summarize, it feels like I have to choose between semantic purity and something that works reliably. Because the focus of the book is on the practical, not the theoritical, I think we have to choose the solution that works while pointing out the problems with it. We’re absolutely going to talk about how this is the bleeding edge.

Avoiding a spacer gif mistake

Back in 1995 when David Siegel was writing Creating Killer Websites, it is unlikely that he could anticipate the impact his book had on web development. Similarly, I can’t know what impact our book will have.

While it may be illusions of grandeur to think it matters much which technique we pick in our book, I do feel a great responsibility to avoid doing harm. I don’t want to find myself in Siegel’s shoes five years from now writing a mea culpa about how The Web is Ruined and I Ruined it.

Hence this post. One last chance to hear arguments for why we shouldn’t teach the noscript tag and what we should teach instead.

And if you’re reading this five years from now and the web is in fact ruined: I’m sorry. I did my best.

Alright, I’ve written extensively on the challenges with the IMG tag for mobile first responsive web designs. What other challenges are people running into?

Here’s what I’ve seen:

• Video (especially embedding third-party video) — Looks like Fitvids.js is the solution a lot of people are using. See also Elastic Video. BTW, if you’re doing a lot of video, it is probably a good idea to look into how you can use HTTP Adaptive bitrate streaming to send different quality video based on data connection and CPU.
• Data tables — Chris Coyier’s excellent Responsive Data Tables article explains three different possibilities for solving this.
• Third-party ad networks and social widgets — This is biggest problem. It’s a problem whether you’re doing responsive design or not. Scott Jehl talks a little about how they handled ads on the Boston Globe in his presentation from the Breaking Development Conference (pg 97).

What am I missing? What other challenges do you see?