1980k 7/9/13 1980k 7/9/13

State of Social Media Sites

Good quote I pulled from an article I was reading:

MySpace was where you went in the past, WordPress and Movable Type were where people went if they had the patience and writing output to maintain a traditional blog, Facebook was where you went to define yourself by schools and checkboxes, and Tumblr was where you went to make your own identity and express your creativity.

Source

1980k 7/9/13 1980k 7/9/13

Why We Need Responsive Images

The topic of responsive images has been one of the most hotly debated topics amongst web developers for what feels like forever. I think Jason Grigsby was perhaps the first to publicly point out that simply setting a percentage width on images was not enough, you needed to resize these images as well. He showed that if you served appropriately sized images on the original responsive demo site, you could shave 78% off the weight of those images (about 162kB) on small screens.

The discussion has evolved since then with debates over what sort of solution we need (server-side, client-side), new markup (srcset vs picture) and even, in some cases, wondering whether we really needed to worry about it at all.

It’s a messy issue for sure. The current solutions for responsive images do come with some complexity and overhead. If you’re using a client-side solution and don’t want to make more than one request per image, then you end up breaking the preloader. As Steve Souders explained rather well, this can have a very negative impact on the time it takes for those images to actually start appearing to your visitors.

No doubt there are trade-offs. Complexity of solutions, preloader versus file size—these each have to be considered when making the determination of what solution to use. Eventually we’ll have a native solution which will take care of the preloader issue, but browsers sure seem to be dragging their feet on that.

In the meantime, I was curious just how much page weight could be saved with a responsive image solution in place. I know that on the projects I’ve worked on, the savings has often been huge, but I wanted to see how consistent my experience is with the web as a whole.

Experiment time!

Yoav Weiss created a bash script called Sizer-Soze that, with the help of ImageMagick and PhantomJS, determines just how much you could save in file size by serving optimized and resized images. The script is built for one url at a time, so I modified it slightly to let me loop through a list of 471 URLs (the same list used by Guy Podjarny for his analysis of responsive performance). My bash scripting skills are minimal (read: nearly non-existent), but thankfully Yoav is far more skilled there than I and was happy to help out and make the whole thing run much more efficiently.

The script looped through the 471 urls, spitting out the results into a CSV. Each site was tested at widths of 360px, 760px and 1260px. Numbers were collected for total original image size, size of images if they weren’t resized but were optimized, and size of images if they were both optimized and resized to match the size they actually displayed at (so if a 1200px image was displayed at 280px wide, the script resized the image to 280px and compared the two file sizes).

If Sizer-Soze came across an image set to “display:none” it would re-check the dimensions every 500 milliseconds (for a maximum wait of 25 seconds) to see if things had changed. This was done to account for image-based carousels where images may have been hidden initially but then later revealed. If the image became visible during that time, then the dimensions were used to process the file savings normally. If the image was never displayed, the entire weight of the image was counted as wasted.

Even with that tweak, there are few caveats about Sizer-Soze:

It does not make a distinction between 3rd party images and images served by the site itself. So some of the weight can be attributed to things like ads.
It does not analyze background images. That’s fine because that’s not what we want here anyway, but its worth noting that potentially even more bytes could be saved.
It won’t be able to pickup some clever lazy-loading techniques, so again, its possible that some sites would actually be able to save even more than the reported numbers.
It doesn’t include data-uri images in the totals as the file name exceeds the length limit for the script.

After looping through, the list shortened to 402 different responsive sites. Some of the original 471 moved to new URLs or apparently went AWOL so Sizer-Soze couldn’t follow along. Others had no images in the source code—either as a result of some sort of lazy-loading mechanism or by design. Still, 402 sites is a pretty good base to look at.

Results: Total Savings

On to the results! First up, the totals.

Viewport SizeSum of Original SizesSum of Optimized SavingsSum of Resized Savings360237.66MB12.86MB171.62MB760244.39MB13.30MB129.34MB1260250.08MB13.70MB104.31MB

It’s not too surprising to see that the original size (what’s being served now) is pretty consistent from screen size to screen size. Guy’s research, and many others, have already demonstrated this pretty well.

What is staggering is just how massive the savings could be if these sites served appropriately sized images. At 360px wide, these 402 sites combine to serve 171.62MB of unnecessary weight to their visitors . That’s a whopping 72.2% of image weight that could be ditched by using a responsive image technique.

It’s not just small screens that would benefit. For 760px and 1260px sized screens, 52.9% and 41.7% of image weight is unnecessary.

Results: Average Savings

Let’s look at the savings in terms of per-site averages.

Viewport SizeAvg. Original SizeAvg. Optimized SavingsAvg. Resized Savings360603.89kB32.68kB436.08kB760622.53kB33.88kB329.47kB1260635.43kB34.81kB265.06kB

Looking at it from the perspective of an individual site, the numbers feel even more impactful. For each screen size, sites on average would shed about 5% of the weight of their images (from 32-34kb) by simply doing some lossless optimization. Considering that this could be automated easily into a build process, or manually done with tools like ImageOptim with little effort—that’s an easy 5% improvement.

Unsurprisingly, the gains are much more significant if those images get resized to an appropriate size as well. At 360px, the average site would drop 436.08kb. Consider that for a second. One optimization (resizing images) dropping that large of a chunk of weight. That takes image weight for a page from 603.89kB to a mere 167.81kB. That’s a huge difference that shouldn’t be dismissed.

While the improvements are slightly smaller for larger screen sizes (as you would expect), using some sort of responsive image technique would still save 320kB for sites displayed at 760px and 265kB for sites displayed at 1260px.

Conclusion

We spend a lot of time talking about responsive images online—debating the approaches, trying out new solutions. Sometimes it can be a little discouraging that we still haven’t gotten it ironed out (I know I feel that way frequently).

But the web needs us to be diligent. It needs us to not settle for seemingly simple solutions that sacrifice performance. It is extremely rare where one optimization lets us knock off such a significant amount of page weight, but here we are staring one such technique right in the face.

72% less image weight.

That’s why we need a responsive image solution.

Source

1980k 7/9/13 1980k 7/9/13

5 Reasons Vine Will Still Be Successful

Immediately after Facebook announced that Instagram would be launching short-form video uploads last week, the hashtag #RIPVine started trending. I’m not ready to send my condolences yet though, and brands shouldn’t be either.

Vine offers a platform with more unique and compelling content that both brands and users will want to continue to create and consume. Here is why:

The Science of 6 Seconds: Twitter knew what they were doing when they instituted the 140-character limit, and they applied the same science to the 6-second length of Vine videos. This length is more conducive to creativity as it forces brands and users to think outside the box in order to tell a story.

In-Stream Video on Twitter: Facebook and Twitter are both key channels for brands so the decision is not whether to use one over the other. It’s all about taking advantage of the right video-sharing platform on the right channel. Brands posting video on Twitter should use Vine, while those posting video to Facebook should use Instagram.

User Experience: Users on Vine expect to see video, while Instagram users are accustomed to seeing static imagery. Going from viewing photos to 15-second long video is a big jump and users are bound to feel like the new videos are an intrusion—particularly when they are from brands. You know what else is 15 seconds long? Pre-roll.

The Audience: Instagram created a video-sharing platform that has mass appeal, while Vine is more of a niche community of video-sharing addicts. The Vine audience appreciates the platform specifically because it is not for everyone, so while they will all probably make a few Instagram videos, they will remain loyal to Vine in the long-term.

Looping: The GIF-like feature makes Vine videos more fun to consume because, lets face it, everyone loves a GIF. Looping also poses a creative challenge to users and brands to take advantage of the feature in a unique way, which has produced some really amazing video content on the platform.

Instagram is about capturing moments. We have been trained to Instagram our food, pets and trips to the beach. Adding video will not change the type of content because the user remains the same. Vine is completely different in that it trained users to create incredibly creative videos that feel like a story or a work of art. There’s a place for both. Just like on all social media channels, brands that put the right content in the right place with the right people will thrive.

— Casey Savio is a social strategist at iCrossing.

Source

1980k 7/9/13 1980k 7/9/13

Germans (DFKI) Developing Robot Ape. The video shows the walking pattern of the developed ape-like robotic system. Besides different walking directions (forward, backward, sideways, and diagonally) a smooth transition between the respective directions is realized. Source

1980k 7/9/13 1980k 7/9/13

Germans (DFKI) Developing Robot Ape. The robot shifts its center of mass in realtime, based on the slope it is walking on. Source

1980k 7/9/13 1980k 7/9/13

SpaceX’s Grasshopper flew 325 m (1066 feet)—higher than Manhattan’s Chrysler Building—before smoothly landing back on the pad. For the first time in this test, Grasshopper made use of its full navigation sensor suite with the F9-R closed loop control flight algorithms to accomplish a precision landing. Most rockets are equipped with sensors to determine position, but these sensors are generally not accurate enough to accomplish the type of precision landing necessary with Grasshopper. Source

1980k 6/25/13 1980k 6/25/13

“The creative process is just that: a process. Recognizing value that others have missed doesn’t require preternatural clairvoyance. A well-honed creative process enables us to intuitively recognize patterns and use those insights to make inductive predictions about divergent ideas, both vertically within categories, and horizontally across categories. By understanding the genealogy of innovation within a given category, we can imagine what might come next.”

—

Source

1980k 6/25/13 1980k 6/25/13

Tesla Model S Dashboard Display

The Tesla Model S is the first premium all-electric car built in the US. It won car of the year honors from both Motor Trend and Automobile magazines, and Consumer Reports called it the best car they have ever tested. But the main reason I’d like to get behind the wheel of this vehicle is the massive, 17-inch touchscreen display.

Automobile in-dash displays are traditionally the poster children of poor UX design. Tesla’s is the antidote — thoughtfully laid out with intuitive controls inspired by the best iPad apps. And most notably, clean typography. Gotham is not the most exciting typeface, but I can think of few better options for this display. It’s very clear, legible at a variety of sizes and weights, and just like the car: American made. I commend the company for looking beyond Helvetica and Eurostile, dashboard choices that are standard in the auto industry and certainly not stars of legibility. This is also a major improvement over the Arial Italic display oflast year’s Model S.

Personally, when it comes to car controls, I’m a fan of big knobs. And maybe a touchscreen can never successfully replace the immediate accessibility of a tactile device. But this is the best attempt I’ve seen so far.

Now that Tesla has produced a dashboard this lovely, maybe they can rethink their uglylogo, conceived with the goofy “hi-tech” aesthetic typical of contemporary car brands.