To improve the search experience for smartphone users and address their pain points, we plan to roll out several ranking changes in the near future that address sites that are misconfigured for smartphone users.
They list two common misconfigurations:
Sites that redirect every desktop page to the mobile home page;
Sites that show content to a desktop UA but an error page to a mobile UA for the same URL.
There’s more and this should matter to some people.
I like jQuery and rarely do a Web project of any size without using it. But always nibbling at me, only a little and usually in the background, is the fact that it’s big and it slows things down, so before typing in the <script> tag I try to ask myself if that whole big library needs to be loaded.
Well on it’s way to becoming a trendy buzzword, “Responsive Design” means very different things to different people. An obvious statement, sure, but a designer/developer*, replete from months or years of reading, experimenting, and struggling with the difficulties of implementation has a very different understanding of the term than a busy, harried small-business owner wanting to upgrade their 5-year old brochure-type Website so it looks good on a phone, and the different perspectives will require some effort to consolidate if the developer and the client hope to work to their mutual benefit. .
He has build a sweet, simple responsive demo-site, very useful for showing to a client (the busy, harries, small business owner of the first paragraph) what we developers mean when we say “responsive”, and by extension, to show that “responsive”, at least to a Web-developer, has a more restricted meaning than “works good on a phone.”
The demo is best used (of course in my opinion) with a full-sized browser which you can then gradually shrink to demonstrate the layout changes that occur at different breakpoints.
* I’m not certain there’ such a thing as a designer/developer in the Web domain anymore. Both are hard and require a lot of time to stay sharp, and it’s not easy to see how someone can do both well. I could be discussing my own limitations.
Consider the famous design maxim — “Fast, cheap and good: pick two.”
The point so tersely made here is that every project involves tradeoffs, so that if something must be done quickly and cheaply, for instance, it probably won’t be very high quality. Or, if you want some high-quality thing developed cheaply, it’s probably going to take some time.
In the Web development universe, the maxim mostly holds true if we recognize that it’s a simplistic rule useful for broad guidance but not necessarily for detailed decisions. I provide the maxim to my clients from time to time when circumstances force them into difficult deliberations and it helps.
In the last few years, I’ve noticed (and this is the reason for this post) that “fast and cheap” have left “good” in the dust, that I have conversations that include statements like “We don’t have much money for this…” far, far more than statements like “This needs to be really good…”
As the pace of change in the Web domain keeps accelerating, working Web developers, all of us but especially freelancers, struggle with finding the time to: 1) work; and 2) not get too far behind the technology curve.
This book was written to help with that struggle:
The book begins by describing stuff that’s in a fairly advanced state of deployment, for example, elements introduced in HTML5 and WAI-ARIA properties, then moves through the spectrum to things not quite loose in the wild yet, like Web Components and CSS Variables. The author assumes some proficiency with Web technologies, sparing the busy reader long introductory explanations.
You will get a lot out of this book — in fact, I think you will get the most out of it — by first reading it through without concerning yourself too much with the plentiful code samples and implementation details. You’re unlikely to encounter a more articulate and engaging mid-level overview of the future of the Web platform anywhere, and the opportunity to gain a sense of how it all meshes by a quick read-through should be seized. You can re-read what is most timely for your current project, and then follow the links to further reading for more detailed and up-to-date information.
There is a good bibliography and suggestions for further reading appended to each chapter, and the references are gathered together again near the end of the book.
I found a lot in this book that I knew about, and more that I had never heard of, and came away with some confidence that I know where the technology is heading. I highly recommend this book for working Web developers.
The Modern Web
Publisher: No Starch Press
Released: April 2013
From HTML5Doctor comes the news — the <hgroup> tag is obsolete and is not to be used.
The spec., rather an “Editor’s Draft”, offers advice on how to mark-up subheadings using here-to-stay elements, under the subheading “Common idioms without dedicated elements”.
For example, use this mark-up…
<h3 style="background-color:#E3E3E3;padding:1em;">3D films set for
popularity slide </h3>
<p>First drop in 3D box office projected for this year
despite hotly tipped summer blockbusters, according to
Fitch Ratings report</p>
…to get this display:
3D films set for popularity slide
First drop in 3D box office projected for this year despite hotly tipped summer blockbusters, according to Fitch Ratings report
You should know right away: this book is short, 41 pages, stem to stern.
The prose can get clunky. Not unclear or incoherent, just lacking in grace, and there is one serious code error, already noted in the errata page for the book at O’Reilly Media. Hahn makes no mention of the active community of developers using and extending Jasmine nor of Jasmine’s shortcomings (it’s not good at testing DOM manipulations without an additional plugin) – this is very much “How To Get Started With Jasmine”.
Minus “why you should test your software” arguments and some enthusiastic coverage of CoffeeScript and Ruby, you’re left with something roughly equivalent to a high-quality Web tutorial. That’s nothing to sneeze at, but it’s not “The Definitive Guide”, either.
I’ve made a demo, here, illustrating a light-weight technique for equalizing the height of Website columns in a dynamic environment using jQuery. There’s a link to a GitHub repository included.
Despite the knowledge and enthusiasm of the authors, this book is a botched shot.
The first two chapters introduce the framework. There are many errors in the sample code and so many blocks of code lacking instruction on where to put them or how to use them, that most of the examples don’t work without a lot of debugging and trial and error. It’s probably simple if you already know the framework — but people buying the book, presumably, don’t.
The third chapter purports to be about workflow, but really is a description of the authors’ development environment — Linux, Yeoman, WebStorm, etc. There’s plenty on duplicating the environment, but if you don’t want to (or can’t — Yeoman, for instance, doesn’t work on Windows), there’s little explanation of why things go where, how you start, what you think about, etc. A generic workflow description would be very useful but is missing.
The fourth chapter “analyzes” a simple AngularJS application, providing code listings for the files that make up the application along with explanations of what’s going on in the files, but the explanations often refer to elements that aren’t in the code listings, again, there are many code errors, and the sample data — the model of the model/view/controller pattern — is mentioned in passing at the beginning of the chapter without any clues about how to incorporate it into the app. The “finished” application has no data and it’s hard to see how it could ever have worked.
The rest of the book seems to be mostly a rehash of the online documentation.
I like what I know about AngularJS, I’m motivated and have put a lot of time into working through the book’s shortcomings, but have decided after struggling through chapter 4 that it’s just not worth the effort.
Look at the Errata page before you decide to buy, and if you do decide to buy it would probably be wise to get an electronic edition in case O’Reilly issues a version with corrections.
This book represents an opportunity missed, and that’s an awful shame.
That sounds real handy, but if people are reading your content away from your context, the benefits are accruing to others, to some extent that seems unclear. The point of writing is to be read, for sure, but Amazon must be thinking they can piggyback a tiny part of their business on your content, in the same way that they piggyback a tiny part of their business on the reviews you write for them.
But then, I have a Kindle and like it very much, and as a reader I like the idea of this plugin a lot.