Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

June 14 2011

Four short links: 14 June 2011

  1. ASCII Flow -- create ASCII diagrams. Awesome. (via Hacker News)
  2. Principles of Uncertainty -- probability and statistics textbook, for maths students to build up to understanding Bayesian reasoning.
  3. Playable Archaeology: An Interview with the Telehacks Anonymous Creator (Andy Baio) -- The inspiration was my son. I had shown him the old movies Hackers, Wargames, and Colossus: The Forbin Project and he really liked them. After seeing Hackers and Wargames, he really wanted to start hacking stuff on his own. I'd taught him some programming, but I didn't want him doing any actual hacking, so I decided to make a simulation so he could telnet to hosts, hack them, and get the feel of it, but safely. (Andy was the interviewer, not the creator)
  4. Responsive Data Tables -- CSS ways to reformat data tables if the screen width is inadequate for the default table layout. (via Keith Bolland)

June 10 2011

Four short links: 10 June 2011

  1. Advanced Computer Science Courses -- collection of online course notes/lectures for classes in advanced CS topics. (via Hacker News)
  2. UK SoundMap -- very cool crowdsourced audio landscape of the UK. (via British Library)
  3. CSS Panic -- game with no HTML, no Javascript, it's all CSS. Only works in Safari and Chrome. (via Dale Harvey)
  4. Sharing Intentions Talk -- interesting talk by Jyri Engestrom on building social mobile apps to share intentions as social objects. Gotta love these folks who can read and use Bruno Latour instead of merely reaching for the Advil as I do.

June 07 2011

Four short links: 7 June 2011

  1. OMG Text -- a plugin for CSS framework Compass for directional text shadows. (via David Kaneda)
  2. Build a Cheap Bitcoin Mine -- some day it will be revealed that the act of generating a bitcoin token is helping the Russian mafia to crack nuclear missile launch codes and Afghan druglords built the Bitcoin system to destabilize the US dollar.
  3. Polycode -- a free, open-source, cross-platform framework for creative code. You can use it as a C++ API or as a standalone scripting language to get easy and simple access to accelerated 2D and 3D graphics, hardware shaders, sound and network programming, physics engines and more. The core Polycode API is written in C++ and can be used to create portable native applications. Lua interfaces. (via Joshua Schachter)
  4. Flickr Date Design -- interesting thoughts on Flickr's date design. The date your photos was taken is stored in a MySQL datetime technically giving you the ability to label your photo as being taken solidly 800+ years before anything most of us would describe as the invention of photography. Which is a little silly.[...]Fundamentally this split between system activity time, and human editable creation date models a world where the people who use your software do something other then use your software. You have to decide how you feel about admitting that possibility. (via Nelson Minar)

June 01 2011

The state of speed and the quirks of mobile optimization

Google's performance evangelist and Velocity co-chair Steve Souders (@souders) recently talked with me about speed, browser wars, and desktop performance vs mobile performance. He also discussed a new project he's working on called the HTTP Archive, which documents how web content is constructed, how it changes over time, and how those changes play out.

Our interview follows.

What are the major factors slowing down site performance?

SteveSouders.jpgSteve Souders: For years when developers started focusing on the performance of their websites, they would start on the back end, optimizing C++ code or database queries. Then we discovered that about 10% or 20% of the overall page load time was spent on the back end. So if you cut that in half, you only improve things 5%, maybe 10%. In many cases, you can reduce the back end time to zero and most users won't notice.

So really, improvement comes from the time spent on the front end, on the network transferring resources and in the browser pulling in those resources. In the case of JavaScript and CSS, it's in parsing them and executing JavaScript. Without any changes in user network connection speeds, websites are able to cut their page load times in half. And that's because even with fast connection speeds or slow connection speeds, there are ways that the browser downloads these resources that developers can control. For example, more parallel downloads or less network overhead in managing connections.

We can work around some of the network problems, but inside the browser there's very little that developers can do in how JavaScript and CSS are handled. And of those two, JavaScript is a much bigger problem. Websites have a lot more JavaScript on them than CSS, and what they do with that JavaScript takes a lot more time. I always tell website owners: "If you care about how fast your website is, the first place to look is JavaScript. And if you can adopt some of the performance best practices we have around JavaScript, you can easily make gains in having your website load faster."

Why do load times vary by browser?

Steve Souders: Even if you're on the same machine, loading a page in one browser vs another can lead to very different timing. Some of the factors that affect this difference are things like the JavaScript engine, caching, network behavior, and rendering.

I don't think it's likely that we ever will see standardization in all of those areas — which I think is a good thing. If we look at the competition in the last few years in JavaScript engines, I think we would all agree that that competition has resulted in tremendous technological growth in that space. We can see that same growth in other areas as the focus on performance continues to grow.

Velocity 2011, being held June 14-16 in Santa Clara, Calif., offers the skills and tools you need to master web performance and operations.

Save 20% on registration with the code VEL11RAD

Are we in the middle of a "speed arms race" between browser developers?

Steve Souders: We're certainly in a phase where there's a lot of competition across the browser teams, and speed is one of the major competitive differentiators. That's music to my ears. I don't know if we're in the middle of it, because it's been going on for two or three years now. Going forward, I think speed is always going to be a critical factor for a browser to be successful. So perhaps we're just at the very beginning of that race.

Starting around 2005 and 2006, we started to see web apps far outpacing the capabilities of the browsers that they ran in, mostly in terms of JavaScript and CSS but also in resource downloads and the size of resources. I'll be honest, I was nervous about the adoption of AJAX and Web 2.0, given the current state of the browsers, but after that explosion, the browsers took notice, and I think that's when this focus on performance really took off. We've seen huge improvements in network behavior, parallel downloads, and JavaScript performance. JavaScript engines have become much faster, and improvements in CSS and layout — and some of the awareness around these performance best practices — has helped as well.

We're just reaching the point where the browsers are catching up with the rich interactive web apps that they're hosting. And all of a sudden, HTML5 came on the scene — the audio tag, video tag, canvas, SVG, web workers, custom font files — and I think as we see these HTML5 features get wider adoption, browsers are going to have to put even more focus on performance. Certainly mobile is another area where browser performance is going to have a lot of growth and is going to have a critical impact on the adoption and success of the web.

What new optimization quirks or obstacles does mobile browsing create?

Steve Souders: As large and multi-dimensional as the browser matrix currently is, it's nothing compared to the size of that matrix for mobile, where we have even more browsers, hardware profiles, connection speeds, types of connections, and proxies.

One of the biggest challenges developers are going to face on the mobile side is getting a handle on the performance of what we're building across the devices we care about. I talked earlier about how on the desktop, without any change in connection speed, developers could work around some of the network obstacles and get significant improvement in their page load times. On mobile, that's going to be more difficult.

The connections on mobile are slower, but they're also constrained in other ways. For example, the number of connections per server and the maximum number of connections across all servers are typically lower on mobile devices than they are on the desktop. And the path that HTTP requests have to take from a mobile device to their origin server can be much more convoluted and slower than they are on the desktop.

So, network performance is going to be a major obstacle, but we can't forget about JavaScript and CSS. Mobile devices have less power than desktops. The same amount of JavaScript and CSS — or even half the amount of JavaScript and CSS — that we have in the desktop could take significantly longer when executed on a mobile platform.

What should companies be doing to optimize mobile browsing?

Steve Souders: Developers are in a great place when it comes to building desktop websites because there's a significant number of performance best practices out there with a lot of research behind them and a lot of tooling and automation. The problem is, we don't have any of that for mobile. That's the goal, but right now, it doesn't exist.

When I started talking a year or so ago about switching the focus to mobile performance, most people would respond with, "Don't the best practices we have for desktop also apply to mobile?" And I always said the same thing, "I don't know, but I'm going to find out." My guess is that half of them are important, a quarter of them don't really matter, and a quarter of them actually hurt mobile performance. Then there's a whole set of performance best practices that are really important for mobile but don't matter so much for the desktop, so no one's really focused on them.

In the first few months that I've been able to focus on mobile, that's played out pretty well. There are some things, like domain sharding, that are really great for desktop performance but actually hurt mobile performance. And there are other things — like "data: URIs" for embedding images, and relying on localStorage for long-term caching — that are great for mobile and don't exist in any of the popular lists of performance best practices. Unfortunately, companies that want to invest in mobile performance don't have a large body of best practices to refer to. And that's where we are now, at least that's where I am now — trying to identify those best practices. Once we have them, we can evangelize, codify, and automate them.

What is the HTTP Archive and how can developers use it to improve site speed?

HTTP Archive logoSteve Souders: Over the last five years, we've seen a lot of interest in website optimization — and websites have changed over that time. Unfortunately, we don't have any record of what those changes have been, how significant they've been, or what areas we've seen change and what areas we haven't seen change. The purpose of the HTTP Archive is to give us that history.

It's similar to the Internet Archive started by Brewster Kahle in 1996 — the Internet Archive collects the web's content and the HTTP Archive archives how that content was built and served. Both are important: The Internet Archive provides society with a record of the evolution of digital media on the web, and the HTTP Archive provides a record of how that digital content has been served to users and how it's changing, specifically for people interested in website performance.

This project will highlight areas where we've seen good traction of performance best practices and where we haven't. Another insight that will come from this is that it's important, for example, for browser vendors and JavaScript framework developers to develop tools and features that can be adopted by developers to improve performance. It's also important to provide support for development patterns that are currently popular on the Internet. We can't ignore the way the web is currently built and just author new features and wait for developers to adopt them. The HTTP Archive will provide some perspective on current development practices and patterns so browser developers can focus on performance optimizations that fit with those patterns.

Image transfer size and image request chart
Click to enlarge and see more trends data from the HTTP Archive.

Right now, there aren't that many slices of the data, but the ones that are there are pretty powerful. I think the most impactful ones are the trending charts because we can see how the web is changing over time. For example, we noticed that the size of images has grown about 12% over the last five months. That's pretty significant. And there are new technologies that address performance issues like image size — Google has recently released the WebP proposal for a new image format that reduces image size. So, the adoption of that new format by developers and other browsers might be accelerated when they see that image size is growing and will consume even more bandwidth going forward.

Associated photo on index pages: Speedy Gonzales by blmurch, on Flickr


May 24 2011

To the end of bloated code and broken websites

In a recent discussion, Nicole Sullivan (@stubbornella), architect at Stubbornella Consulting Group and a speaker at Velocity 2011, talked about the state of CSS — how it's adapting to mobile, how it's improving performance, and how some CSS best practices have led to "bloated code and broken websites."

Our interview follows.

How are CSS best practices evolving?

NicoleSullivan.jpgNicole Sullivan: New tools are being added to browsers, and the Chrome team is really pushing the limits of what we can do with CSS, but there is still an uphill battle. Some of the best practices are actually bad for the domain.

I recently wrote an article about the best practices and what's wrong with them. I figured out this year that it wasn't just that the best practices weren't ideal — it's that they were absolutely, every single time, leading to bloated code and broken websites. It was a revelation for me to realize the best practices were often causing issues.

How are architect-level CSS tools improving?

Nicole Sullivan: The preprocessors have gotten much better. They were partially created because people didn't like the syntax of CSS and wanted a new one, but the preprocessors changed a bunch of things that weren't necessarily useful to change. In the last year or so, the preprocessors have embraced CSS and have become a testing ground for what can go into browsers. At the same time, the Chrome team is pushing forward on WebKit — it's a pretty exciting time to be working on this stuff.

Are you encountering browser support issues when building with CSS and HTML5?

Nicole Sullivan: Particularly with CSS3, there's a ton of variation and levels of support. But what CSS3 gives us are ways of doing visual decorations without actually needing images. Stoyan Stefanov and I wrote a few years ago to crush and optimize images because we realized that image weight was one of the big problems on the web. Overall, CSS was sort of the source of the problem because it was bringing in all of this extra media via images.

The cool thing with CSS3 is that now we can eliminate a lot of those images by using the more advanced properties — "border-radius" can give us rounded corners without images; you can get gradients now without images; you can get drop shadows and things like that. The thing is to be flexible enough with design that it's still going to work if, say, it doesn't have that gradient. And to realize that for users on an older browser, it's not worth the weight you'd add to the page to get them that gradient or the rounded corners — they're much more interested in having a snappy, usable experience than they are in having every visual flourish possible.

Velocity 2011, being held June 14-16 in Santa Clara, Calif., offers the skills and tools you need to master web performance and operations.

Save 20% on registration with the code VEL11RAD

How about at the mobile level — what are the major issues you're facing in that space?

Nicole Sullivan: Media queries are the biggest issue for mobile right now. Designers and developers are excited to be able to query, for example, the size of the screen and to offer different layouts for the iPhone or the iPad. But that means you're sending your entire layout for a desktop view and a mobile view down to a mobile phone or down to an iPad, which is way more than you want to be sending over the wire. Designers need to put mobile first and then maybe layer on a desktop experience — but then only sending that code to a desktop user. All of this requires more of a server-side solution.

Do developers need to build two different sites to accomplish that?

Nicole Sullivan: It depends. On my little iPhone, there's not a lot of screen real estate. If I go to a travel website, I don't want every feature they've got cluttering up my iPhone. I want to know what flight I'm on, what my confirmation number is — that kind of thing. It makes sense on the design side to think about why your users are coming to the mobile site and then designing for those needs.

What happens to desktop design is there's sort of a land grab. Each team tries to grab a little bit of space and add stuff so they'll get traffic to their part of the site. It creates a disjointed user experience. The great thing about mobile is that people aren't doing that — there isn't enough screen real estate to have a land grab yet.

This interview was edited and condensed.


March 29 2011

Four short links: 29 March 2011

  1. Serve -- American Express mobile payments play. Money on mobiles is a huge potential, look for others to bang around here before the right answer is found. (via Mike Olson)
  2. Move Mayonnaise and Ketchup (YouTube) -- I don't know why you'd want to move mayonnaise and ketchup intact, but this is the machine for it. (via Russell Brown)
  3. Duplicates Detection with ElasticSearch (Andre Zmievski) -- duplicate detection (or de-duping) is one of the most unappreciated problems that the developers of certain types of applications face sooner or later. The applications I’m talking about share two main characteristics: item collection and some sort of social aspect.
  4. Ceaser -- tool for making CSS easing animations. (via Josh Clark)

January 12 2011

Four short links: 12 January 2011

  1. Zork and Tic-Tac-Toe on a LiveScribe Pen (YouTube) -- this guy totally ported the Z-Machine so he can play Zork on his pen. My favourite bit is the comment from Infocom founder Scott Cutler: As the implementer who wrote the first Z-machine for the TRS-80 some 30 years ago and one of the founders of Infocom, I was thrilled and impressed to see what you did. I can guarantee you that we never imagined it would be played with a pen! (via Joe Johnston and Jason Scott)
  2. Ben the Bodyguard -- brilliant web site design. (via Aza Raskin)
  3. three20 -- open source iPhone library based on the Facebook app, providing things like photo viewer, message composer, etc. (via The Mission Lab)
  4. Scale and Rhythm -- beautiful web site that lets you experiment with the variables in text layout.

December 28 2010

Four short links: 28 December 2010

  1. Amazon Sold 158 Items/Second on Cyber Monday (TechCrunch) -- I remember when 20 hits/s on a Sun web server was considered pretty friggin' amazing. Just pause a moment and ponder the infrastructure Amazon has marshaled to be able to do this: data centers, replication, load balancers, payment processing, fulfillment, elastic cloud computing, storage servers, cheap power, bandwidth beyond comprehension.
  2. Quick Thoughts on Pinboard (Matt Haughey) -- thoughtful comments, and an immediate and just as thoughtful response. (I am a happy pinboard user who is also looking forward to the social networking features to come)
  3. Female Founders -- impressively long list of female startup founders. (via Hacker News)
  4. Less Framework -- cross-device css grid system based on using inline media queries. (via Pinboard)

March 30 2010

Is the "e" in ebooks the new blink tag?

Do you remember the blink tag? My gosh, I do. This was back when we were indiscriminately mixing our content and presentation, our HTML and our CSS, our data and its display. Usually you'd be graced with this tag in some horrible sort of "40% off!" fashion.


We'd all grimace at this abuse of the web (and even the most common sense of design). Why? Well, besides the tag itself being obnoxious, this was a classic case of taking your content and manually controlling how that content would look. That little bit of data -- "40% off" -- was inexorably and permanently linked with a bit of formatting -- the <blink> tag.

And you all know about this, whether your knowledge is localized to the blink tag, or just produced in a growing separation-of-content model for web design and development. Hardly anyone intentionally and consistently mixes content and presentation in web pages these days. CSS (and SASS, in some circles) simply makes it too easy to keep your style separate from your content.

So here we are in 2010, all design-sophisticates, separating our content from our style. Well, on the web we are. The more I listen and watch and involve myself in ebooks, though, the more I find myself thinking about the blink tag again. And while I think the term "ebook" is useful and possibly necessary for intelligent conversation, I just wonder if that little "e" in front of "ebook" might be on its way toward becoming the new blink tag.

I won't draw this out. I'll make it simple. Right now, I'm typing into Movable Type's editor. I'm typing words, and sentences, and paragraphs. And MT will take those words, sentences, and paragraphs--my content--and display it on the Radar blog, formatted, styled, easily consumable by web browsers and RSS readers.


At no point has it even occurred to me, until right now, that I'm in fact typing e-words or e-sentences. I've not thought about adding an e-carriage return to separate this e-paragraph from the next e-paragraph.

How absurd would that be? Come on. I'm just typing. I'm creating content. Plain old raw content. And it just so happens that my content will be delivered in a particular format (a blog). I suppose if O'Reilly wanted, they could assemble this content with a bunch of other content, and print the sum of all that content into a book. It wouldn't be an e-book because its content started out digital. That's just as silly as saying that because content first lived in printed form, and then was released digitally, we have a digital print book.

Web 2.0 Expo San FranciscoSo why the "e" in ebook? Yes, I know there are some naming issues. We have to use language, and we need some means of distinguishing a book bound with glue, printed on paper, from a book that lives purely in the digital realm. I get that with every bit of my editor-laden, grammarian being. Communication requires a distinction.

But I'm increasingly seeing the ebook treated as more than just a language distinction. I see people creating content with a specific display paradigm in mind. The content assumes a certain width of screen; a certain font size. Images are being inserted not because they belong, but "because iPhone and iPad users will expect more imagery."


So just because your image is easier to look upon than a blink tag, are we not returning to a very bad time in the history of the Internet?

So let's be clear: I'm saying something that isn't overly original, but bears saying (again). The first group/publisher/company/person who moves away from the ebook and to content--content that can be delivered to a variety of media, digital and non-digital, with display and style applied separate from and after content creation--wins. They'll have lower costs involved with taking content and making it available on multiple platforms. They'll have content that can adapt to new formats quickly, because there's no "un-presenting" content before it can be repurposed for another platform.


Sure, we'll always have ebooks. But can we all hope that this becomes a term based on a distinction in display format and medium, rather than a fundamental distinction between one type of content and another? I'm really not up for another blink tag.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!