Some sites that I work on get more than half their traffic from mobile devices (tech-speak for “smart phones”). Not all of them — some businesses appeal more to a demographic of people looking at a big screen on a desk — but many, and the number will do nothing but increase. For while we’ve known that the mobile era is coming. Now it’s arrived. (To be accurate, it arrived a while back when I was paying attention to other things, but now I’ve noticed it.)
The mobile era won’t change the fact that some 95% of web interactions begin with search and the importance of search presence (SEO, SEM, etc.) won’t diminish along with the use of big screens, so, as we choose strategies for adapting our site designs for different screen sizes we need to check in to see how those strategies will effect our search rankings.
In this article, Google settles the question:
We recommend using responsive web design because it has many good aspects:
- Using a single URL for a piece of content makes it easier for your users to interact with, share, and link to your content, and a single URL for the content helps Google’s algorithms assign the indexing properties for the content.
- No redirection is needed for users to get to the device-optimized view, which reduces loading time. Also, user agent-based redirection is error-prone and can degrade your site’s user experience (see “Pitfalls when detecting user agents” section for details).
- It saves resources for both your site and Google’s crawlers. For responsive web design pages, any Googlebot user agents needs to crawl your pages once, as opposed to crawling multiple times with different user agents, to retrieve your content. This improvement in crawling efficiency can indirectly help Google index more of the site’s contents and keep it appropriately fresh.
So, that’s one thing we don’t need to think about anymore.
Assuming little knowledge on the reader’s part, the author skims the important points in developing a responsive web site. Starting with the basic building blocks, HTML and CSS, then continuing on to media queries, work-flow, design philosophies, typography, navigation design, and more, Peterson skims quickly over the subject matter, slowing when things get difficult (as in navigation design). The result is a quick, readable introduction to what you need to know if you’re setting out to build a device-responsive web site, along with links to additional information and more thorough explanations.
The book could be valuable to novice web developers, enabling them to include device responsiveness in their initial repertoire of skills, or to designers launching into flexible designs interested in learning the technical constrains they will be dealing with and need to understand. I appreciated the discussion of work-flow, and useful information even though I’ve build several device-responsive sites, so although it’s mostly for beginners, others may find something of value.
I’m put off, though, by the author’s reluctance to use pixels as a measure of media query breakpoints. Insisting on using “em”, a measurement relative to font size, rather than “px” to set breakpoints is bad advice, especially to novices.
I read an early release ebook which was missing some illustrations and had some typos, but those will be filled-in and fixed-up prior to release, no doubt. The book was made available through O’Reilly’s Reader Review Program.
Learning Responsive Web Design
Simpson’s book is a very welcome addition to my effort. The book is short, covers its subject clearly and comprehensively, the style is good-natured with an insistence of getting things right, and uses examples simple enough that you don’t need to tap out code to get the point. If you’re already fairly experienced with the language you can read this in bed. It was a pleasure to read and a cinch to understand. Here’s a sample: “Closure is when a function can remember and access its lexical scope even when it’s invoked outside its lexical scope.”
You Don't Know JS: Scopes and Closures
The first half of the book was very good. Osmani introduces the reader to the theory behind Backbone.js, then carefull walks through the development of a simple “To Do” application, providing code (error-free!) and discussion of how newly-introduced code parts integrate with what we’ve already done and what they mean in the Backbone.js environment.
After two courses through the increasingly complex demo application, the book went beyond my level of interest, introducing extensions like Marionette and then covering modularization using Require.js. No doubt those latter parts were as carefully written and reviewed as the first parts, so developers with a deeper interest in the framework shouldn’t take my lack of interest as any sort of criticism.
I did notice in my first solo project that I had little idea how to implement the “model” part of the MV* (as he calls it) framework. Looking back, I saw that the total utilization of that part of the framework in Osman’s first demos totaled a dozen lines of code, mostly setting some defaults. I see that as a shortcoming of the book and is the reason for 4 rather than 5 stars.
This book was provided to me by O’Reilly media in exchange for this review.
Developing Backbone.js Applications
This took me longer than it should have to figure out yesterday, so I’m putting this here in case it might help anyone else.
A “Category Blog”, one of the selectable Menu Item Types in Joomla!, displays articles in a category or a set of categories in a blog-ish format, with lots of configuration options which, assuming your template supports them, provide enough customization that you shouldn’t have to hack your template to achieve a desired result.
In the default configuration, when the selected category contains more articles than are being displayed on the page a list of additional article titles appears at the bottom of the page, above the “prev – next” navigation. Keep in mind all of this is configurable and so might be irrelevant to your installation or template.
This is what it looked like in my development domain:
This category blog on the client’s site had hundreds of articles and the short “More Items” list confused people and needed to be removed, but there was no obvious configuration setting to remove it.
Except that there was, just not obvious to me.
In the Menu Manager for the item, under “Blog Layout”, there’s a control labelled “#Links”. That configures the “More Items” list and can be set to “0″ to remove the list. Like this:
“Much easier,” I could have said. A while back I reviewed Eric Meyer’s book CSS Fonts (actually a pre-released chapter of a forthcoming book) after putting some information in it to use immediately, applying a purchased font to a critical section a client’s website.
The ease of that small task encouraged me to work on a larger scale, so a couple of days ago I made the time to install a custom web font on a personal blog. You can see it at Frogs For Snakes. The font (as I write this) is “Delicious”, a free font from the exljbris Font Foundry. I like the font but not for this particular site, which I think needs something less spartan, so it may have changed by time you read this.
Below I list the ridiculously simple steps for using custom fonts on a website. You should take some care, if you decide to do this, to ensure that the fonts you select are licensed for your use, and you should contribute to the extent you can to the foundries and to the websites that make the fonts and the tools to use them available. Everybody deserves to be paid. There’s nothing wrong with buying a font, either.
Rick Mulready at Entrepeneur quotes a Facebook rep:
[Facebook is] getting to a place where because more people are sharing more things, the best way to get your stuff seen if you’re a business is to pay for it. … We expect organic distribution of an individual page's posts to gradually decline over time as we continually work to make sure people have a meaningful experience on the site.
A loose translation of that might be “if Facebook is part of your business strategy prepare to open your wallet.”
Not being particularly sociable, I' not a big user of social media and I don’t have a Facebook account. So, this may be colored by personal predispositions but I have never thought it was a very good idea for a business to make a strategic commitment to a third-party platform unless the relationship was something close to symmetrical. If one party has all the power, and in the case of Facebook or Mircrosoft or Google it's them, they'll evolve according their own needs without regard for yours, and one thing you can count on is that somewhere along the line they will want more of your money than they're getting. And then they' take it.
I don’t know if it’s time to “Ditch Your Facebook Strategy” as the article suggests, but a strong branded presence under a domain you control is always going to provide a foundation to build on if you need to revise, and reduce the importance of, you social media strategy.
I read a lot and usually write up a review of some kind for what I’ve read, partly as an antidote to shills and partly because I just enjoy doing it. In the interest of sharing the reviews as widely as possible without giving free content to any wealthy corporations, I recently took a little time to revise my WordPress templates, structuring the content using schema.org microdata so that book reviews would stand a better chance of showing up in search results.
Everything a developer needs to know about fonts.
In this thin, focused volume (68 pages in the print edition), the author tours the CSS fonts specification, explaining what the spec. means and describing how it’s implemented. He provides many mark-up examples demonstrating how to control the appearance of fonts on a web page, examples that cover most, maybe all, of the actual situations a working developer will encounter. Most of the book expansively explicates the @font-face rule which enables reliable (more-or-less) use of imported fonts, which is increasingly freeing us from prior typographic constraints.
The book helped me immediately, providing a detailed solution to a troubling problem a few minutes after downloading a copy. Besides being handy, it’s exhaustive treatment has made it an often-used reference after that first moment of glory.
A little distracting, without affecting the value of the content, this appears to be a single chapter from a longer book — “Chapter 1: Fonts” shows up at the front but there’s no Chapter 2 (unless the separately published CSS: Text is Chapter 2). Also, there’s no sign of the publisher’s standard, and welcome, “Who is this book for?” preface, making me wonder a little what the game is we’re playing.
Even with that distraction and the short length, I recommend the book. Meyer knows the subject matter, theoretically and practically, has a straightforward and subtle sense of humor, and comes across as a friendly, helpful guy who happens to know more about the subject than you.
Designer/Developers interested in expanding their typographic skills will find the book useful, as will developers in collaborative relationships with designers. Designers without technical skills would probably find this hard-going, but with some effort it could provide a sound summary of what’s typographically possible these days.
My copy of this book was provided by O’Reilly Media in exchange for this review.
Switching to Git after years using SVN, I had trouble finding my way around the new environment even though I only need pretty basic source control. I didn’t “get it”, and things that should have been easy were difficult.
Two earlier books, both acknowledged by Mr. Silverman in his preface, helped, but in striving for completeness they both obscured the basic instruction I needed in an enormous wealth of detail.
A “pocket guide” seemed just the ticket, and the author’s intent, stated in the preface, showed a lot of promise:
“The primary goal of this book is to provide a compact, readable introduction to Git for the new user, as well as a reference to common commands and procedures that will continue to be useful once you’ve already gotten some Git under your belt.”
He accomplished his goal by half, I think. Although compact and readable, the book suffers (mildly) from a lack of clarity that, for me, prevents its use as a reference. Take this:
“If the current branch is tracking an upstream in that remote, Git then tries to reconcile the current state of your branch with that of the newly updated tracking branch. If only you or the upstream has added commits to this branch since your last pull, then this will succeed with a “fast-forward” update: one branch head just moves forward along the branch to catch up with the other.”
There’s nothing wrong with that paragraph in terms of narrative flow, but if you try to use it as instruction you notice it has a lot of subjects taking action — “the current branch”, “Git”, “you”, “the upstream”, “this”, “one branch head” — and among all those actors doing things it’s hard to sort out what YOU need to do in order to make something happen.
The author’s two goals may conflict unavoidably, so I don’t want to fault him too much. He’s produced an easy-to-read narrative overview of a technology but I’ll be going back to the thick versions for an easy-to-use reference guide.
I don’t mean to say this is a bad book. It’s not — it’s pretty good. But rather than being one I keep handy when I need to remember how to do something, it’s a book I got a lot out of the first time through but probably won’t pick up again.
This book was provided to me through O’Reilly Media’s Blogger Review Program. It’s available for purchase at O’Reilly Media.
Git Pocket Guide
Richard E. Silverman