Skip navigation
Help

Web Basics

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

Photo: tobias.munich/Flickr

Anyone who’s ever tried to optimize a website has faced the very basic question — how long does your site take to load?

The answer seems like it would be easy to discover: Load your site in a page speed crawler like WebPagetest and soon you’ll have your numbers. But that’s just it; you won’t have a number, you have numbers and figuring out which numbers to listen to is trickier than you might think.

Strangeloop’s Joshua Bixby recently tackled the performance metric question in a blog post titled a Non-Geeky Guide to Understanding Performance Measurement Terms. The whole article is well worth reading, but perhaps the best advice is to make a video of the page load. “If you want to get a ground-zero look at your site’s performance,” writes Bixby, “capturing videos and filmstrip views of your pages’ load times are one of the best ways to go.”

The filmstrip view Bixby refers to is part of the WebPagetest results and shows what the visitor sees in a progressive series of page captures. To create a filmstrip or video test of your website, head over to WebPagetest and select the “visual comparison” tab.

Some common performance mistakes Bixby cautions against include using “response time” and “load time” interchangeably and “not realizing that ‘response time’ can mean any number of completely different things.”

To help those unfamiliar with the nuances of loading metrics, Bixby then breaks down and defines all the terms, including what exactly is meant by “start render” or “time to first byte,” as well as some caveats to bear in mind when going over the numbers for your website.

While Bixby’s post can be extremely helpful, especially to those who are just starting out in the often confusing world of website optimization, bear in mind that testing sites like WebPagetest are no substitute for real-world tests. “As a matter of due course, you always need to gather large batches of data and rely on median numbers,” writes Bixby, “but you also need to periodically get under the hood and take a real-world look at how your pages behave for real users.”

0
Your rating: None

The web is buzzing, and rightly so, about Wilson Miner’s incredibly inspiring talk from the 2011 Build Conference in Belfast. You may recognize Miner’s name from his role in developing Django, as part of the team that built Apple.com or as one of the founders of Everyblock.

Miner’s talk is not your typical web developer talk; in fact, he hardly mentions the web for most of it. Rather, Miner focuses on the broader impact that technologies, and the developers and designers who create them, have on our world, and how that world in turn shapes us. Miner reminds us that we aren’t building “just websites” but shaping the world we will live in for much of the foreseeable future. And, as the Alistair Smith quote shown in the talk says, “at times of change, the learners are the ones who will inherit the world, while the knowers will be beautifully prepared for a world which no longer exists.”

So turn off your music, throw the video in fullscreen mode and give it 38 minutes. Trust us, you won’t be sorry.

After you’re done be sure to visit Miner’s website, which has links to all the material used in the talk, including books, videos, music and images for anyone who would like to learn more.

4
Your rating: None Average: 4 (1 vote)

Dutch artist Sebastien Schmieg has elevated the Google Image search from its humble intent, creating a short film that strings together a series of image searches. The result oscillates between the prosaic and profound, and feels more like a grand homage to humanity than a collection of random images.

To create the image sequence Schmieg fed a single transparent PNG into Google Images and used the “visually similar” feature to recursively loop through the results. Schmieg’s movie of the results, entitled Search by Image, Recursively, Transparent PNG, #1, is a (slightly NSFW) truly hypnotic, algorithmic tour of life as Google Images knows it.

In all there are some 2,951 images in the video. The “visually similar” option in Google Image Search tends to get stuck in loops using it the way Schmieg did so if an image had already been used in the sequence, he would skip to the next image in the results. But otherwise the sequence is entirely algorithmic. Beware pareidolia.

For more info about the movie and some other, similar efforts, be sure to check out Schmieg’s website.

0
Your rating: None

A handful of the many screens your site needs to handle. Photo: Ariel Zambelich/Wired.com

This week’s Consumer Electronics Show in Las Vegas has seen the arrival of dozens of new devices from tablets to televisions. Some of these newfangled gadgets will soon be in the hands of consumers who will use them to access your website. Will your site work? Or will it end up mangled by a subpar web browser, odd screen size or slow network connection?

No one wants to rewrite their website every time a new device or browser hits the web. That’s why approaches like responsive design, and the even broader efforts of the future-friendly group, are trying to develop tools and techniques for building adaptable websites. That way, when a dozen new tablets suddenly appear on the scene, you can relax knowing your site will look and perform as intended, no matter which devices your audience is using.

Even if you aren’t a gadget lover, CES should help drive home the fundamental truth of today’s web — devices, they are a comin’. Webmonkey has compiled helpful resources for creating responsive design in the past, but the field is new and evolving rapidly so here’s an updated list of links to help you get started responsive, future-friendly sites that serve your audience’s needs whether they’re browsing with a tiny phone, a huge television or the web-enabled toaster of tomorrow.

Basics:

  • Use @media to scale your layout for any screen, but remember that this alone isn’t really responsive design.
  • Use liquid layouts that can accommodate any screen size. Don’t simply design one look for 4-inch screens, one for 7-inch, one for 10-inch and one for desktop. Keep it liquid, otherwise what happens when the 11.4-inch screen suddenly becomes popular?
  • Roll your own grids based on the specifics of your site’s content. Canned grid systems will rarely fit the bill. The problem with canned grids is that they don’t fit your unique content. Create layouts from the content out, rather than the canvas (or grid) in.
  • Start small. Start with the smallest size screen and work your way up, adding @media rules to float elements into the larger windows of tablet and desktop browsers. Start with a narrow, single-column layout to handle mobile browsers and then scale up from there rather than the other way around. Starting with the smallest screen and working your way up means it’s the desktop browsers that need to handle @media, make sure older browsers work by using polyfills like Respond.
  • Forget Photoshop, build your comps in the browser. It’s virtually impossible to mock up liquid layouts in Photoshop, start in the browser instead.
  • Scale images using img { max-width: 100%; }. For very large images, consider using something like Responsive Images to offer the very smallest screens smaller image downloads and then use JavaScript to swap in larger images for larger screens. Similar techniques can be used to scale video.
  • Forget about perfect. If you haven’t already, abandon the notion of pixel perfect designs across devices. An iPad isn’t a laptop isn’t a television. Build the perfect site for each.

Further Reading:

  • Future Friendly — An overview of how some of the smartest people in web design are thinking about the ever-broadening reach of the web: “We can’t be all things on all devices. To manage in a world of ever-increasing device complexity, we need to focus on what matters most to our customers and businesses. Not by building lowest common-denominator solutions but by creating meaningful content and services. People are also increasingly tired of excessive noise and finding ways to simplify things for themselves. Focus your service before your customers and increasing diversity do it for you.”
  • Building a Future-Friendly Web — Brad Frost’s excellent advice: “Think of your core content as a fluid thing that gets poured into a huge number of containers.”
  • There is no mobile web — “There is no mobile web, nor desktop web. It is just the web. Start with the content and meet people halfway.”
  • Responsive by default — Andy Hume on why the web has always been responsive, but was temporarily sidetracked by the fad of fixed-width sites.
  • COPE: Create Once, Publish Everywhere — NPR’s Director of Application Development, Daniel Jacobson, walks through how NPR separates content from display and uses a single data source for all its apps, sites, APIs and feeds. A great example of what Frost talks about regarding content as a fluid thing.
  • Support Versus Optimization — It can seem daunting to support dozens of mobile browsers, but if you aren’t up to the challenge of a few mobile browsers now what are you going to do when you need to support car dashboards, refrigerators, televisions and toasters, all with dozens of varying browsers?
  • The Coming Zombie Apocalypse — Not satisfied thinking a few years ahead? Scott Jenson explores further into the future and tries to imagine what the web might look like when devices all but invisible.

Techniques:

0
Your rating: None

Single-page, application-style websites offer web developers a way to replicate the user experience of native apps, particularly on mobile devices. Indeed, the application design model — that is, a single webpage that never needs to refresh or reload — is the basis for some of the web’s most popular sites like Facebook and Twitter.

But such app-based sites often break fundamental tenets of the web, eschewing HTML source for JavaScript, breaking the browser’s back button and removing the ability to link deep into the application. Some of these problems are addressed by standards like the HTML5 History API, which allows applications to update the URL bar without refreshing the page, but not every app bothers to take advantage of such recent developments.

The potential problems single-page apps can cause are not, however, sufficient reason to avoid them, argues Mozilla Developer Evangelist Christian Heilmann. Done responsibly and in keeping with the best practices of the web, the single-page app can be part of the future of the web, writes Heilmann.

Among the benefits of single-page apps are speed gains — stripping away the HTML means there’s very little to load initially and subsequent data loads can be done in very small increments, which makes for very fast apps. With the rise of web apps targeting mobile devices the speed advantages make single-page apps appealing to developers. Indeed, Heilmann believes “single page apps … are necessary for the web to be an apps platform.”

Naturally there will be problems with the rise of apps. “We have to battle two main issues,” writes Heilmann, “old conditioning of users and sloppy development for the sake of doing something ‘new’.”

In other words the danger isn’t the single-page concept itself, which, if done right, will yield an “app” that also has all the benefits of the web — deep linking, bookmarking, and indexing. It’s the latter problem Heilmann mentions, one that’s neatly satirized by sites like Hipstergrammers, that causes many developers concern: new just for the sake of new.

Heilmann’s post does a great job of cutting through the hype behind single page apps and presenting them for what they are — another tool with both positive and negative trade offs. Be sure to read through the whole article which offers a great list of potential problems and how to avoid them.

0
Your rating: None

I never know if one of my blog posts is going to take off. Most don’t. But yesterday’s post about apps not being the future probably set some kind of record. It got a lot of links and a lot of reads.

Had I known it was going to get so much attention I would have spelled out exactly what I meant by app. The question came up e-mailing with Brent Simmons who wrote a post about my post yesterday. I didn’t understand the confusion until I did a little back and forth with him.

I said this: “I mean app as in ‘there’s an app for that.’”

I’m talking about the newspaper or magazine that, when you click on a link to go to one of their articles, puts up an interstitial telling you that you could read the article in their app instead. Initially, I installed one or two of these. The other day I installed a big comprehensive one from Google. Flipboard is the original one of these reading environments that is not the web. The New York Times has a slow, buggy, huge app for reading their news.

Now don’t get me wrong; there’s no reason they shouldn’t produce these apps. Go ahead. They have every right. But I also have every right not to use them. And if they insist, as the New York Post does (its content isn’t available for iPad users on any other terms) I can just skip their content altogether (which in the case of the Post, who gives away their paper at subway entrances in NYC and is an awful Murdoch trash rag that would be an insult to dead fish to be wrapped in it, feels just right).

If that’s all there was to it, I probably never would have written this piece. But last week I read about a speech given at LeWeb in Paris by George Colony of Forrester Research, that got a lot of coverage. He said the web is over, and apps are the future. (BTW, when you search for George Colony on Google they’re so sure you meant George Clooney they don’t even offer the choice of George Colony.)

It was that speech, plus Google’s app, plus a well-timed interstitial that got me thinking: Why is it that I find this concept of the future so repulsive?

I wrote five pieces yesterday. I guess that was the best one. Sure hit a nerve. A lot of people agree. Enough with the apps already.

I think the publishers like the idea because it offers hope of a new paywall, an electronic one. My guess is that it’s a hope in vain.

Tablets are almost ideal reading environments. I don’t think, as some developers do, that the iPad is the ultimate. I think it’s heavy and cold, and makes my arm fall asleep when I read lying down. I think the software is a glitchy. Like great movies, great computer experiences are all about suspension of disbelief. If I forget I’m reading on an iPad and get consumed by the story, then the technology is working perfectly. The iPad experience is good, but there’s still a way to go. And all this business about apps is a real spoiler for suspension of disbelief. I’m clicking a link, expecting to learn more about what I was reading (that was certainly the author’s intent) but instead I get an ad for an app. If I seriously consider it, I’ve lost my train of thought. If I actually take the detour and install it, I’ve lost big time. The best way to minimize the loss is hit the Back button and skip it. But that’s a loss too. I clicked the link for a reason. And that was thwarted.

I’d be happy with a pref that says to all websites “I’m never going to install your app, so please don’t bother with the pitch.” Sort of like a No Solicitors sign on the front door of my house (which I don’t have; it’s too rude to people who are not solicitors).

BTW, I wrote a piece a month ago about Google’s search website on the iPad and how awful it is. They made it even worse. Now if you click on the Classic link at the bottom of the page you lose your search string and have to enter it again. At least in the past when you clicked Classic, after scrolling to the bottom of the page, you got the search results you were looking at in a more compact form.

To anyone from Microsoft who may be reading this far, here’s a chance to get a bunch of iPad users. Make Bing work exactly like Google on the desktop, on the iPad. Or offer it as an option. I will use your search engine from now on on the iPad if you do that. Google is deliberately screwing their iPad users. Now you guys can be the heroes.

All of this is of course IMHO, as if that needs to be said. But when there are a bunch of new Apple zealots reading stuff here calling me “some people” or “this guy” in my own blog, well it needs to be said.

Also, I let comments run more or less rampant in the last post. It got to be too much to moderate them all. Even so, if a comment required my approval and it was idiotic or unnecessary (How many times do we need to hear that there are things called intents?) I just let it sit there unapproved. You don’t have a right to place your ideas here. If I’m not reading your book-length comment, why should I impose it on my readers?

This post first appeared on Scripting News.

Dave Winer, a visiting scholar at NYU’s Arthur L. Carter Journalism Institute, pioneered the development of weblogs, syndication (RSS), podcasting, outlining, and web content management software. A former contributing editor at Wired Magazine, Dave won the Wired Tech Renegade award in 2001.
Follow @davewiner on Twitter.

0
Your rating: None

The BostonGlobe.com on mobile, tablet and laptop screens

Responsive design is no longer something confined to the portfolio websites of the designers and developers who pioneered the idea. Using CSS media queries to adapt a website’s layout to varying screen sizes is fast becoming a standard part of web development.

Today’s case in point is the newly launched BostonGlobe.com, which uses the adaptive layouts, font resizing and image scaling of responsive design to deliver an elegant, readable website no matter what screen size you’re using.

The Globe’s new website is attracting more attention for the fact that it will soon be behind a paywall (it’s free until the end of September), but for web developers the much bigger news is that one of the larger news sites on the web is embracing responsive design.

It’s not an iOS app; it’s not in the Chrome Web Store. No, the new BostonGlobe.com is just a good old fashioned website, but one that looks good no matter what you’re viewing it on thanks to its use of responsive design. Depending on the size of your screen — whether you happen to be browsing from a phone, a tablet or a desktop monitor — BostonGlobe.com will adjust its content to fit the pixels available. It will reflow its text columns according to screen size and also scale its masthead logo, the section menus, images, videos and even the weather graphic in the masthead.

Of course it makes sense that the BostonGlobe.com is a flagship example of what’s possible with responsive design given that developer Ethan Marcotte, who coined the term responsive design, was one of the architects behind the new Globe website. If you’d like to know a bit more about how the site was created, including some of the challenges any responsive site faces, head over to Marcotte’s blog and read his write up on the new site.

Also part of the team that helped build the site are the design firm Upstatement and the Filament Group, which helped pioneer the concept of “responsive” or “adaptive” images. That is, serving smaller images to mobile browsers and then using JavaScript to serve larger images to desktop browsers. Be sure to check out our earlier coverage of adaptive images.

While the Globe may have had the cash and cachet to hire big names in the field, that doesn’t mean you need an extensive team to create a responsive website. We won’t lie to you, building a good responsive website is more difficult than just slapping up a fixed width design. But, provided it fits with the goals of your site, it’s much easier than many of the alternatives, which often require building and maintaining two entirely separate websites.

If you’d like to know more about how the Globe team built the site there’s a video on the Globe’s other website, Boston.com, which gives a behind the scenes look at how the responsive design works. At around 1:22 you’ll see a shot of the design being tested on multiple devices simultaneously. The tool that makes that possible is Shim, a node.js app that enables simultaneous, synced web surfing across devices and browsers. You can check it out over at GitHub.

See Also:

0
Your rating: None

Web typography used to be something of an oxymoron, but recent browser advances and tools like Typekit have helped bring web typography out of the dark ages with custom fonts. Thanks to JavaScript libraries like Lettering.js you can tweak those custom fonts — targeting specific words or letters — and adjust them to your liking.

Lettering.js even makes it possible to do custom kerning on the web. Kerning refers to the space between characters in proportional width fonts. CSS has long offered the letter-spacing property, but because it applies to an entire element — for example an h2 tag — what you’re really doing with letter-spacing is adjusting the tracking.

To actually control kerning you need to target each letter individually. Because Lettering.js can wrap each letter in your text with span tags, you can then target each span separately, adjusting the spacing of individual letters, or, kerning.

But, handy as Lettering.js is, tweaking the letter-spacing, hitting refresh, tweaking some more and so on is still a rather tedious way to improve your kerning. That’s why designer Brendan Stromberger created the Kern.js JavaScript bookmarklet. Used in conjunction with Lettering.js, Kern.js allows you to adjust kerning by simply selecting and dragging letters (or you can use the arrow keys). Kerning adjustments can be made in pixels or ems, so even you if you have a liquid layout there’s no reason you can’t get in on the kerning fun. Once you’ve got your kerning looking the way you’d like, just hit the “finish editing” button and Kern.js will spit out the necessary CSS to apply.

Kerning is admittedly a somewhat nerdy pursuit in a field that’s already pretty nerdy to begin with, but if you’ve developed an obsession with good looking typography, you know that there’s more to it than just dropping in some Typekit fonts. Thanks to Lettering.js and Kern.js, you can finally improve kerning on the web without the tedium of endless page refreshes.

See Also:

0
Your rating: None

Google’s Page Speed testing tool, which recently went from a browser add-on to a web-based tool, now sports a new API. The Page Speed Online API allows outside applications to send URLs to Page Speed and get back a list of things the site developer can do to speed up the page in question.

If you’d like to try it, head over to the new documentation page and request an API key. Sample apps include using the Page Speed Online API to display suggestions for speeding up sites or even combining the API with the Google Charts API to show a visual breakdown of the page’s resources.

For a more practical example of how the Page Speed Online API can help out your site, check out the latest version of the W3 Total Cache plugin for WordPress. If you’re not already using W3 Total Cache in your WordPress installation, we highly recommend you install it, especially now that the plugin taps into the Page Speed API. W3 Total Cache now sends your pages to the Page Speed Online API and then offers Page Speed suggestions, right in the WordPress dashboard.

See Also:

0
Your rating: None

Rad headline font, dudeFor years web developers have bemoaned the state of typography on the web. We don’t have much control and we have to choose between a small handful of fonts. The only real guarantee is whether our text is serif or sans-serif.

A new JavaScript library solves the problem in a way similar to the long popular sIFR, but without requiring Flash. Called typeface.js, the library reproduces truetype fonts by converting glyphs to JSON. It uses canvas, SVG graphics, or VML, depending on the browser.

Like sIFR, it lets you keep your content in your HTML, but replaces the text with the appropriate shapes. That means that screen readers and search spiders can still get at your content.

The download weight appears slightly larger than sIFR, but still a reasonable size considering the information it holds. The main JavaScript file is 16K, with most fonts weighing in at about 50K.

Original sIFR creator Shaun Inman doesn’t appear all that impressed. In his link blog, Inman wrote:

“Dear type vendors, please save us from these convoluted stopgaps.”

Yes, it’s not as perfect a solution as a built-in standard. The library has three fonts available, plus a tool to convert other truetype fonts to JSON, as long as you have the right to embed the font. The tool won’t convert certain fonts it knows are restricted.

See also:


0
Your rating: None