In January, Cloudinary released a free tool for generating responsive image breakpoints that was based on some of the ideas I had for picking breakpoints based on performance budgets. Today they’ve updated with some amazing new features that I’m incredibly excited about.
The big new feature is that Cloudinary (and by extension, the free breakpoints tool) can now do art direction and output the
<picture> element automatically!
This works because Cloudinary now has an algorithm that identifies the area of interest in each image. Then the tool allows you to define art-direction for each screen size by selecting the aspect ratio and viewport ratio, then it will do all the remaining work.
You can see this in action by using the Responsive Breakpoints tool and turning on all of the art direction options.
Simply handling the aspect ratio options is pretty cool by itself.
There are a bunch of other improvement to the Cloudinary service including:
- Analyzing every image to find the best quality compression level and optimal encoding settings
- Automatically converting images to the whatever format the user’s browser supports that will compress best
- Support for browser client hints which automates even more the responsive images work
For the full details on the improvement, check out Nadav Soferman’s announcement on the Cloudinary blog.
Spending the last few days in New York City for Smashing Conference reminded me of an analogy for Mobile First Design that seems to resonate with people.
If you’ve made your life fit in a tiny New York apartment, you’ll have no trouble when you move to a house in the suburbs.
But going the other way, from a house full of stuff to a tiny apartment, is much more difficult.
Designing for small screens works the same way.
Google’s announcement of Android Instant Apps caused me to fear for the future of the web for the first time.
I’ve participated in many native versus web debates over the years. We even contemplated becoming an iOS-only shop after working on the Obama ’08 iPhone App.
But we chose to bet on the future of the web, and I had never doubted that decision in the years since until seeing Android Instant Apps.
Why Android Instant Apps Unnerved Me
When we placed that bet on the web years ago, we didn’t bet on the web “winning”. I didn’t think there was a contest to win. I expected apps and web to live side-by-side, and thus far, it has played out that way.
Plus, there were three factors that made me believe the web was the correct long term bet:
- PhoneGap/Cordova showed how most apps could be built using web technology once the web got access to device capabilities and features like push notifications.
- Scott Jenson’s Mobile Apps Must Die and the Triumph of the Mundane made compelling arguments that the app store model wouldn’t scale into an Internet of Things future. This belief is the foundation of the Physical Web project.
- Worst-case scenario, it seemed like a good future could be made simply building websites to promote apps.
We’ve finally reached a point where the promise of PhoneGap is becoming reality due to browser advances and Progressive Web Apps. And yet just as that promise is about to bear fruit, Android Instant Apps come along.
Stephanie Rieger once observed that we often install apps; give them space on our devices; and use our bandwidth to update them all “just in case” we need them. What we really need is “just in time” apps instead of “just in case” apps.
We need to use apps and throw them away. These sorts of transient experiences are something the web is excellent and that apps are poor at providing.
That is until Android Instant Apps which, in theory, make just-in-time apps possible.
And it is notable that one of the examples Google is showing off not only uses a common Physical Web example—a parking meter, but also uses the Physical Web beacon to launch the Android Instant App without ever opening the browser.
And if search results can open apps without needing to install apps, well, there goes my future career building websites for those apps.
Android Instant Apps may be vaporware
This year’s I/O keynote was full of promises and short on shipping code. Android Instant Apps was a prime example.
The scuttlebutt at the event is that Android Instant Apps have a long ways to go before they are ready for prime time. There are big questions about security, privacy, performance, and user experience that remain to be solved. And converting existing apps to Android Instant Apps in a single day is…optimistic.
But even if there are challenges, Android Instant Apps are a shot across the bow of the web. If there was ever any doubt that the owners of native platforms would eliminate the web if they could, there should be no doubt now.
Progressive Web Apps
At I/O, Google also heavily promoted the best alternative that we’ve had yet to native apps: Progressive Web Apps. The fact they were both promoted by the same company at the same event still blows my mind.
Over the last few days, there has been a lot of debate about progressive web apps between people who appear to be in violent agreement with each other. There’s been a lot more discussion than I can cover here so I am going to try (and probably fail) to summarize the debate thusly:
- Early progressive web apps are not responsive, not progressive, and only work on one platform and thus Google shouldn’t be promoting them.
- Chrome’s criteria for the app install prompt doesn’t support URLs as well as it should.
- Progressive web apps are a Google thing that they’re pushing that only works on Android to the determent of the broader web.
- People spend far too much time talking about apps and trying to make things that compete with native.
On the first two points, there is mostly broad consensus. The folks on the Chrome team dislike that the best examples they have thus far all have shortcomings, but they are the best ones have so far. They want to encourage developers to make them better instead of chastising them for not doing everything right out of the gate.
I sympathize with both perspectives. I agree with Michael Scharnagl when he cautions us to not repeat the errors from the beginning of responsive web design when it comes to progressive web apps.
And yet, if a client came to us and said they wanted to move to responsive web design, but they felt it was risky, I might very well suggest they start by using device detection to route mobile traffic to a m-dot site where they could test the design before rolling it out further.
That is what the BBC did with their beta responsive web design and they were praised for their work. How is that substantially different than Flipkart’s Progressive Web App for which they are getting grief? Yes, it started on Android Chrome only, but they promised to make it work elsewhere and are about to deliver on those promises.
I think the only major difference is that by the time the BBC did their mobile-only beta, we already had the Boston Globe to look at. Plus, we didn’t have a large company like Google using the BBC site as an example.
Keep in mind, Flipkart had actually shutdown its mobile website earlier so this is a welcome return to the web for them.
As far as URLs are concerned, the Chrome team agrees. Both Chrome and Opera are working on ways to fix it.
I find the third point fruitless to discuss as it seems to emanate from distrust of Google. I understand why people distrust Google, but distrust often makes for circular conversations because you can never address the core issue.
Which bring us to the final point and the question of whether or not we’re spending too much time worrying about native.
The web that cried wolf
In response to some of the progressive web apps criticism, Alex Russell went on a bit of a Twitter rant about the challenges facing the web. Peter Gaston collected the tweets and added some thoughts. Bruce Lawson from Opera chimed in saying that Alex “is not being alarmist; it's true.”
And yet, the day after Alex issued a clarion call to save the web, Recode’s big headline is that The App Boom is Over:
Last month, the top 15 app publishers saw downloads drop an average of 20 percent in the U.S., according to research from Nomura.
Because this isn’t the first time that someone has sounded the web’s death knell, people were rightly skeptical.
I’ve been in the skeptical camp in the past. And I’ve previously ascribed a lot of the concern about the web from Chrome Googlers to their internal battles with the Android team.
It can’t be fun to be part of the Google’s Web Developer Relations team—recently renamed from Chrome Developer Relations to emphasize that their role is to promote the web, not one browser—and have the company you work for releasing Android Instant Apps. Worse, announcing it at a conference where you have to spend the next three days answering multiple questions about it from people like me. (Sorry!)
But the Google Web DevRel team also has more opportunity to talk to people working in companies around the world. Same with Opera. It would be foolish to completely dismiss what they say.
Plus, in addition to my fears of Android Instant Apps, I’ve recently been spending some time in Google Trends and the graphs for web-related searches are a bit depressing.
Lately, I vacillate on whether the web is endangered or poised for a massive growth due to the web’s new capabilities. Frankly, I think there are indicators both ways.
A few years ago, I watched a video on climate change that applied a decision matrix to the question of whether or not climate change is real. The matrix looked something like this for worst case scenarios:
||Spend money unnecessarily, possible global recession
||Save the world
||Destroy the world
That’s simplified, but it gets at the heart of the matter. If climate change deniers are right, the worst case scenario is a recession which sucks, but is something we’ve recovered from. If climate change deniers are wrong, the consequences for inaction are something that puts our existence as a species at risk.
I’ve been thinking about a similar matrix for this question of whether or not the web is imperiled by native and if we should do the things that Google advocates. That decision matrix might look like this:
|Web is threatened
||Don’t Build PWAs
||Users get a faster, better web experience
||Current slow web
||Users get a faster, better web experience, plus we save the web
||Web loses to native
I need to provide a few caveats on this table. First, I’m not equating people who say the web is fine with climate change deniers. The scientific evidence and consensus on climate change is overwhelming. Whereas I already mentioned that support for whether or not the web is endangered seems to change daily.
Second, I used progressive web apps here, but I’m using them as a placeholder for doing the work necessary to create faster and better experiences on the web. Basically, whatever we need to do to have less of this:
And more experiences that are so snappy—particularly on mobile devices—that people aren’t driven to native apps.
Build better experiences
When I think about the problem this way, the question of whether or not the web is imperiled doesn’t matter. The collection of web tools under the umbrella of Progressive Web Apps provide a better experience for people using our sites. This should be a no brainer.
Yes, none of the current examples of Progressive Web Apps are perfect. We have yet to see the Boston Globe or ESPN of Progressive Web Apps.
I see that as opportunity. An opportunity to build Progressive Web Apps that show how these tools can provide a better experience for everyone regardless of the device or browser they are using.
And I’ll say it again, I really want to work on the Boston Globe of Progressive Web Apps, so if you want to be that site, we should talk.
Whether you see the web as threatened or see Chicken Little in people’s fears and whether you like progressive web apps or feel it is a stupid Google marketing thing, we can all agree that putting energy into improving the experience for the people using our sites is always a good thing.
Last fall after the Umpqua Community College shooting in Southern Oregon, I decided that my donations and support for Everytown weren’t enough. I wanted to do more. And I wanted to do something local.
I did some research and discovered a wonderful advocacy group called Ceasefire Oregon. They seemed to be both passionate about sensible gun legislation and also wonky which appealed to me.
Ceasefire Oregon is the best resource on local legislation. Unfortunately, the website was difficult to read and navigate.
So we offered to help redesign Ceasefire Oregon on a pro-bono basis. And I’m pleased to announce that the new Ceasefire Oregon site has launched.
In addition to the opportunity to contribute to a great cause, we found several pieces of the project interesting from a technical and design perspective.
Rebranding Ceasefire Oregon
The first challenge was finding a way to convey what Ceasefire Oregon does in a logo. The old logo was a riff on a shooting range target which seemed less than ideal for a gun violence prevention group.
We talked to Ceasefire Oregon about their goals and what they wanted to convey:
- Change is possible
- Moving ahead
- New future
We collaborated with Ceasefire Oregon on mood boards to get closer to the brand. And then we began working on logo ideas.
Aileen designed an origami-like dove that captured everyone’s imagination. It became the centerpiece of the new design.
Once the dove was approved, Aileen began work on variations of the logo. We wanted to support both horizontal and vertical logos as well as different versions for the three different Ceasefire Oregon organizations.
After we had the high-level brand details sorted out, we moved immediately into building a pattern library.
I want to highlight a couple of things in the pattern library.
First, because of the three different sites and their color schemes, there is a pull down menu in the upper left that allows you to switch which colors are being used. This is most noticeable when looking at buttons, blocks, and navigation.
Second, during development, our pattern libraries rarely follow a completely linear progression from smallest components to larger ones. You can see evidence of this in the sandbox where we experimented with designs.
Local WordPress Development
For many of our recent projects, our clients had well-established content management or ecommerce systems. This has meant that we were able to keep all of our development front-end and exclusively used local development tools.
Ceasefire Oregon needed a new content management system. The old site was running on Drupal 6 which has been discontinued. We decided to move them to WordPress.
We wanted to find a way to continue to work on our own local machines while doing work on a content management system. We ended up running vagrant installs of WordPress.
I also want to give a hearty endorsement to WordPress Migrate DB Pro. We lost a lot of time trying to get open source database syncing solutions to work. I wish we’d bought the plugin earlier.
Pattern Library to WordPress Theme
One of the thornier challenges we ran into was figuring out how to tie the output of the Ceasefire Oregon Pattern Library to the WordPress theme that we were developing.
We ended up with a solution that worked pretty well. The gulp process for the pattern library also created a compressed CSS file that was aliased into the Vagrant environment in the theme directory. Whenever we made changes to the pattern library, they were automatically reflected in our theme.
The biggest downside to this approach was that the repository was a mixture of pattern library and theme code. But this combination sped up our design and development so much that it was worth it.
Content Strategy and Modeling
We spent time working with Ceasefire Oregon on their content strategy. We’ve done a little bit of this in the past, but this was the first time we’ve run workshops with clients discussing content. It is clear that the new site benefits from this work.
I’m particularly proud of how Sara and Gerardo mapped the content into WordPress content types. The new legislation section makes it easy for Ceasefire Oregon to keep track of new and old bills. I expect it to become the canonical source of gun safety legislation relevant to Oregon.
And much, much more
This article is inadequate for describing all of the hard work that went into this project by everyone on the Cloud Four team. I’m incredibly proud and grateful for everyone’s contributions. It means a great deal to me.
And I hope we get a chance to write in more detail about the way the site was built in the future.
Making Oregon Safer
We’re tremendously grateful and humbled by the work that Penny Okamoto, Joanne Skirving and the rest of the volunteers at Ceasefire Oregon do. If you feel strongly about sensible gun legislation, they deserve your support.
We’re honored to have had the opportunity to work with them and to contribute our small part towards helping make our community safer.