Web developer, writer, speaker. Co-founder of his company Algonquin Studios as well as evolt.org. Has co-written “Usability: The Site Speaks for Itself,” “Web Graphics for Non-Designers,” and “Web Professional's Handbook.”
If you are a web pro then it is likely that you heard that Google's search results were going to change based on how mobile-friendly a site is (you probably heard a couple months ago even). This change took effect yesterday.
As with almost all things in the tech world that affect clients, the press hit yesterday as well, and today clients are looking for more information. Conveniently, our clients are golden as we went all-responsive years ago.
If you already built sites to be responsive, ideally mobile-first, then you needn't worry. Your clients have probably already noticed that the text "mobile-friendly" appears in front of the results for their sites in Google and have been comforted as a result.
If you have not built sites to be responsive, or have had no mobile strategy whatsoever, then you may be among those calling it, or seeing it referred to as, mobilegeddon. A terrible name that clearly comes from FUD (Fear, Uncertainty and Doubt).
If you are someone who relies on a firm to build and/or manage your site, then you should also beware the SEO snake oil salesman who may knock on your door and build on that very FUD to sell you things you don't need.
From Google Webmaster Central
For that latter two cases, I have pulled the first three points from Google's notes on the mobile-friendly (a much better term) update. I recommend reading the whole thing, of course.
1. Will desktop and/or tablet ranking also be affected by this change?
No, this update has no effect on searches from tablets or desktops. It affects searches from mobile devices across all languages and locations.
2. Is it a page-level or site-level mobile ranking boost?
It’s a page-level change. For instance, if ten of your site’s pages are mobile-friendly, but the rest of your pages aren’t, only the ten mobile-friendly pages can be positively impacted.
3. How do I know if Google thinks a page on my site is mobile-friendly?
Individual pages can be tested for “mobile-friendliness” using the Mobile-Friendly Test.
From Aaron Gustafson
Aaron Gustafson put together a simple list of four things you as a web developer can do to mitigate the effects of Google's changes, though the simplicity belies the depth of effort that may be needed for some sites. I've collected the list, but his post has the details for how to approach each step:
Embrace mobile-first CSS
Focus on key tasks
Get smarter about images
Embrace the continuum
What Is Your Mobile Traffic?
I've been asked how to find out how much traffic to a site is from mobile users. In Google Analytics this is pretty easy:
Choose Audience from the left menu.
Choose Mobile once Audience has expanded.
Bear in mind that this just tells you where you are today. If that number drops then it may be a sign that your mobile strategy isn't working. At the same time, if that number is already low then it may not drop any further owing to unintentional selection bias in how your pages are coded.
Oh, By the Way
Google isn't the only search engine. When I mentioned that on this blog before, Google had 66.4% of the U.S. search market. As of January 2015, that's down to 64.4%. Bing is up from 15.9% to 19.7%.
Google Sites led the U.S. explicit core search market in January with 64.4 percent market share, followed by Microsoft Sites with 19.7 percent and Yahoo Sites with 13.0 percent (up 1.0 percentage point). Ask Network accounted for 1.8 percent of explicit core searches, followed by AOL, Inc. with 1.1 percent.
While I Have Your Attention
Two days after the initial announcement of this change, word also came that Google is working on a method to rank pages not by inbound links, but by trustworthiness, in essence by facts.
When this finally hits, pay attention to those who refer to the change as Truthigeddon. Be wary of them.
If you have to wear a ring, then perhaps you have experienced the discomfort of putting a cold ring on your finger (maybe in the morning in a cold house). I decided that I could do something about that using the only tool in the modern developer's toolbox — the smartphone app.
I'm kicking off the new year by announcing that my Ring Warmer app is done. Well, it's a web app. Actually, it's just a web page. Living as nothing more than a block of code at CodePen. Regardless, I started this in late 2012 and then mostly forgot about it, so I'm thrilled to call it done.
The opening image is an animated GIF that shows how one might use the Ring Warmer app. I've also embedded the same animation as an Instagram video (or view it directly on Instagram):
The idea here is that you can choose a ring size and a warmth level, place your ring in the designated spot, and wait patiently for it to work its magic.
The idea is, of course, absurd.
In the strictest sense, it can work. At the lowest setting (warm), only the red LEDs will light up, carrying one-third of the total heat a pixel can produce. As you move to the highest setting (hottest), all the LEDs are lit to generate white, so each pixel is producing its maximum heat as the red, green, and blue LEDs are all lit.
Of course, the amount of heat this carries is negligible. You will transfer more heat to the ring from the warming battery than from the pixels. The ring itself might not get very warm unless you also fire up the radio antenna (I left that feature out as a courtesy).
Now that I've gotten as much pranking out of this fake app as possible, I figured I'd at least write it up a bit.
Very simply, I use a border radius with some box shadows to make the glowing ring. Then I drop the white glowing dot (using box shadows and border radius) onto one edge and rotate the entire thing in perpetuity. It's a mess of mixed sizing units, questionable animation syntax, and useless elements.
Then I made a form so you can change the ring size and the temperature. The ring size isn't matched to any real measurements, except in Chrome on my Samsung Galaxy S4 the default size matches my ring. All sizing after that is based on ems, so it doesn't scale like a real ring. The temperature change is nothing more than colors with CSS transitions and some JavaScript that sets explicit styles instead of classes. In other words, it's a terrible idea to copy this code.
For a few years now web developers around the world have celebrated Saturnalia Christmas with advent calendars covering topics related to the web. Some come and go, but you'll probably recognize a few regulars on this list.
I may have missed some, so please pass them along if you know of any. As I learned in prior years where I have tracked them, I don't know them all on December 1, and update accordingly. Some of this is because the sites don't promote the new calendar on the home page.
1. 24 Ways
24 Ways, the one that most of this think about for web development calendars, is back again. It's been going strong since 2005 and based on its history this year should have some good articles.
2. Perl Advent Calendar
Perl Advent Calendar goes all the way back to 2000 (and back then looked a bit more like a traditional advent calendar, too) and has been dispensing tips for Perl developers ever since.
3. 24 Jours de Web
24 Jours de Web is starting its second year as an advent calendar for web folk. Written in French, it is clearly primarily targeted at French speakers, but a round of Google Translate will open it up to far more readers (like me).
4. UXmas
UXmas is an advent calendar aimed at the user experience community. Coming from Australia, American readers may be thrown just a bit by the schedule. The calendar promises everything from sketches, to articles, to tools, to videos.
5. Webkrauts
Webkrauts has an all German advent calendar, and it also dates back to 2005. It covers general web topics, but being in all-German readers like me will benefit from a Google Translate version of the page.
6. Web Accessibility Advent Calendar 2014
Web Accessibility Advent Calendar 2014 is in Japanese, and thanks to the wonderful powers of Google Translate, I can tell you that it is a calendar to make the talk about Web accessibility (based on this statement: Webアクセシビリティに関する話題でつくるカレンダーです。). If you know Japanese, I welcome any corrections. The site Adventar.org appears to host other advent calendars, some about web technologies, some about ramen.
7. 24 Pull Requests
24 Pull Requests is less an advent calendar than it is an effort to mobilize developers. The goal is to get developers to send a pull request every day in December (up to Christmas), thereby supporting your favorite open source projects. There are even Coderwall badges for those who collect those sorts of things.
8. SysAdvent
SysAdvent is targeted to systems administrators, but there is a some cross-over to web developers. It has posts dating back to 2008, so there is plenty of good material there if you're too impatient to wait for each day to be revealed.
9. Lean/Agile Advent Calendar
Håkan Forss's lean/agile calendar was recommended to me by Martin Burns, to whom I generally listen on this topic. Håkan is an Accredited Kanban Trainer (AKT) and a Kanban Coaching Professional (KCP), and his first post seems pretty good, so I've added it. Also, LEGOs.
10. Performance Calendar
Performance Calendar hails this as the speed geek's favorite time of the year, ostensibly because of the tips it has been offering each December since 2009. It isn't just server optimizations you'll find here, so don't shy away because you're not a system admin. While I had it last year, it hadn't launched when I posted this, so I've rectified that.
11. Free Font Calendar
The Free Font Advent is providing information on and links to, you guessed it, a free font every day. The site is in German, but Google Translate will be more than enough to get the narrative written for each typeface. I picked this one up from Deborah Edwards-Onoro's advent calendar post.
12. Amazon Web Services Calendar
AWS Advent is dedicated to sharing information on features and services available from AWS. If you are an AWS user and have something to offer, as of this writing there are still five slots open for contributions. I also picked this one up from Deborah Edwards-Onoro's advent calendar post.
Not Web Related
The Royal Institution has something called Things to Do with Stuff that might be like an advent calendar, given this statement: Throughout December inspired by the 2014 CHRISTMAS LECTURES, we're releasing little nuggets that'll encourage you to interact with and understand the tech that surrounds us. The very first item is how to make a movie projector with a smartphone, a magnifying class, and a box.
I just finished a webinar for the National Association of Government Web Professionals where I provided an overview of responsive design. I always struggle when I cannot see the audience, but as always my ego carries me through to the end. The slides are embedded here for any and all to see.
Much as I would like to say that I will be speaking at the National Association of Government Web Professionals (NAGW, I don't know where the "P" went, perhaps it was originally "Webmasters?") conference in September, I won't be. I was, however, asked to do a separate webinar for members for one of the conference topics I submitted — an intro to responsive web design.
As far as I know you need to be a member of NAGW to be able to attend the webinar, so I can't share a URL, let alone a Google Map. I can, however, point you to the slides from a similar talk I gave last September: Slides: Responsive Web Design Primer
While the federal government may have its own crack web team now (or so the reports claim), state and local governments don't have that same team and can't as easily share their expertise. It seems NAGW fills a gap by providing a forum for these web professionals to share and help one another, as noted in its own description:
NAGW is the National Association of Government Web Professionals, an organization of local and state government web professionals working together to share knowledge, best practices, innovative ideas, and other resources. We collaborate on technologies, and network with other web professionals to improve our capacity to provide value across the web to our communities.
If you are a member, the webinar is Tuesday, October 21 at 11am mountain time. I hope I am able to provide some value to its membership, and if not, maybe they can be amused by how deftly I don't do webinars.
With more and more people relying on a mobile device as their primary computing platform, it stands to reason that more and more mobile users may want to print web page content — whether directly to a printer or as a PDF for later use (or display as in the case of scannable bar/QR codes).
Past
The state of print style support on mobile browsers has been abysmal for some time. At my talks on making sites printable I even demonstrated that by showing support in the latest and greatest (based on your platform preference) at the time (Samsung Galaxy S4 using the default Android browser). If you look at the slides (slide 50 from Stir Trek and slide 51 from WordCamp Buffalo) you'll see that the output was pretty much just the mobile layout centered in a sheet of paper, despite well-defined print styles.
Screen shots of printed output from a Samsung Galaxy S4 using the default Android browser, circa May 2013 (I forget which Android release this was). I didn't output to PDF because I couldn't at the time.
Present
Fast forward and support for print styles in mobile browsers has improved. At least for Android.
My tests on an iPad were futile, as Safari and Opera Coast both want to print to a printer (which I don't have at home) and not to a PDF. I tried to print to Google Cloud Print from Chrome on the iPad and got 404 errors. Opera Mini just doesn't seem to offer the option. Anyone with an iDevice who would like to chip in, I used the Algonquin Studios jobs page for my tests, as it typically fits on one sheet.
On Android I had better luck. The default Android browser, Chrome and Firefox all allowed me to print. None of Yandex, Opera, Opera Beta, Opera Classic nor Opera Mini offered a print option. Screen shots of where you can find the print option in these three browsers:
Screen shots of print dialogs from default Android browser (Mozilla/5.0 (Linux; Android 4.4.2; en-us; SAMSUNG SPH-L720 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/1.5 Chrome/28.0.1500.94 Mobile Safari/537.36), Chrome (Mozilla/5.0 (Linux; Android 4.4.2; SPH-L720 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.141 Mobile Safari/537.36), and Firefox (Mozilla/5.0 (Android; Mobile; rv:30.0) Gecko/30.0 Firefox/30.0).
Unlike last year's tests, the print output of each of these browsers shows that they are using the site's print styles. Which means they are truly honoring responsive design by following the appropriate media query in the appropriate context. Examples of the output:
Screen shots of the PDF files from each of the three browsers (left to right, Android browser, Chrome, Firefox). Select an image to see the full PDF, but note that the Android browser (the first one) is a 14.7MB PDF while the others are less than 60kb.
Chrome for Android
Chrome did a great job of rendering all of the elements as I expect, namely similarly to how Chrome does on my Windows machine. By default it disables background colors, which is good for me since I have two errant declarations I did not clear. It also rendered the QR code which is only generated when the user prints the page (or performs a print preview). (I have a tutorial on how you can auto-generate QR codes at print-time should that feature interest you.)
Android Browser
The Android browser behaved a bit differently than Chrome. While it also ignored background colors and also pulled down the QR code, it didn't use the custom fonts. It also greatly reduced the margin at the top of the page. Most oddly of all is that it rendered the PDF as a bitmap. A 14.7MB bitmap. Whereas in the Chrome PDF you can zoom in to see crisp edges on the text and logos (SVG), the Android browser PDF shows the constituent pixels of every otherwise vector item.
Firefox for Android
Firefox honored the background colors (oops) and the typefaces. It failed to render the QR code. Firefox also scaled the text larger than Chrome and larger than Firefox on my Windows machine. Most interestingly of all, however, was the paper size. Unlike Chrome and Android browser (8.5 × 11 inches), the paper size on Firefox's PDF is 6.67 × 11.11 inches.
Other Platforms
As I noted above, I couldn't get print to work on my iPad. I also went to the Apple store to try it, but none of the devices that I checked were either connected to a printer or could print to PDF. I don't have a Windows Phone, though I also went to the Microsoft Store and still had no luck. I don't have immediate access to a BlackBerry of any kind. If you have a device and/or browser combo I did not test, feel free to comment below and let me know what you saw.
What to Do
(Continue to) make print styles. So far it looks like they will work on current mobile browsers that allow printing or that export to PDF.
Related
If you want to learn how print media queries can be useful to you, check out any of the following links (which themselves may contain many more links).
November was kind enough to test on an iOS device and saw the same output as I got from Android. That's two platforms covered, which is good news in general.
@aardrian print via Safari on iOS (current version) ends up looking exactly like your Firefox on Android sample.
If you work much with accessibility, then you might consider the title of this post to be an oxymoron, a self-contradicting mess. Frankly, I tend to agree. Barring a compelling use case, I never start a project with Bootstrap and I resist including it when explicitly requested (so far successfully in nearly every case). Of a few reasons, accessibility is the biggest issue I have with it.
There are, however, a couple options to mitigate the accessibility mess that is Bootstrap.
I should note that this post is a follow-up to the Q&A after my talk at HTML5 Developer Conference, Selfish Accessibility, where I gave some advice about Assets which, at the time, was using Bootstrap 2 (it has since moved to version 3).
Assets.CMS.gov
The Centers for Medicare & Medicaid Services (CMS), a division of the US government (specifically HHS), has emerged as an unexpected champion of accessibility for Bootstrap and made its own framework, Assets (first announced in late 2012). This may not be a surprise to many when you consider CMS's role working with people who are older and/or in need of some form of medical assistance (equipment or services). Arguably, its constituency stands to benefit the most of any division of the US government.
Assets was just updated to use Bootstrap 3 (which should make many a Bootstrap user happy). Assets promises you:
Section 508 compliant, cross-browser compatible UI components that you can use in your accessible web site or web application. Assets is an accessible, responsive, modern framework.
If you are an organization that works with the federal government to build web-based applications for the general public, then it may be a no-brainer to use this framework. Arguably your Section 508 accessibility requirements are met to a high degree, and where the framework fails you may be able to make a case that you are using a government-sanctioned tool. It doesn't let you off the hook for more fundamental accessibility failures (color contrast, images as text, infinite scroll, etc.).
There are some caveats. On the spectrum of Internet Explorer versions, it only supports version 8 and above (the last version, built on Bootstrap 2, also only supported IE8+). The files are served from a US government CDN, which while not bad in and of itself, should require you to test them to make sure it serves the files as well as a commercial CDN. For example, icon font FontAwesome is served via the Assets CDN, though you may want to compare against others given its ubiquity on the web.
The Assets documentation also provides links to a Medicare style guide and a Healthcare.gov style guide, both of which require a login to see, severely limiting their value to sub-contractors.
PayPal's Accessibility Plug-in
If you refuse to use anything from the US government, you can head to the other end of the spectrum and use the accessibility plug-in from PayPal.
According to PayPal:
This plugin adds accessibility mark-up to the default components of Bootstrap 3 to make them accessible for keyboard and screen reader users.
Because it's an add-on to your existing Bootstrap 3 code, it should just work. It will make the following default UI components accessible: Alert, tool-tip, pop-over, modal dialog, drop-down menu, tab panel, collapse, and carousel. You can pop over to the demo page and test it out with and without the plug-in (use a keyboard to understand the benefits).
As with Assets, this doesn't guarantee that what you build will be accessible. You still need to consider the same items I cite above along with many many more accessibility elements which cannot just be handled with a plug-in nor a checklist.
Related
The Canadian government has created its own framework, also intended to be accessible, usable, interoperable, mobile friendly and multilingual. The Web Experience Toolkit (WET) has just moved up to version 4.
While not a framework nor an accessibility add-on, the United Kingdom has a handy style guide to make all its gov.uk properties look consistent: GOV.UK elements
There may be hope for government web sites after all, though just don't try to use Section508.gov with a keyboard.
In my post What to Consider before Using Free Getty Images one of the many caveats I outlined was the lack of responsive support in Getty's iframe code. Of all the issues I raised, this one is actually pretty easy to get around.
Background
While the other points still preclude me from readily using Getty image embeds, I recognize its value to clients and want to be able to allow them to use these images without fear of breaking the responsive sites we've coded. I also wanted a solution that won't require my clients to do any extra work, such as embedding HTML wrappers, adding classes or IDs, inline script, or generally mucking about in code.
If you've read at least a few of my last 15 years of writing, you might know I have a general aversion to scripted solutions and generally start trying with a CSS solution. At first glance, there is an example dating back five years at A List Apart that I thought might work, Creating Intrinsic Ratios for Video.
Another post tackled other embeds (Vimeo, Slideshare) in 2011 using the same technique expanded just a bit. Five years on and a new article popped up (just a couple weeks ago, Making Embedded Content Work In Responsive Design) that is targeting more third-party embeds (calendars, Google Maps), but leans on the A List Apart technique — and by leans on I mean just uses it outright but for more services.
The A List Apart solution and its variations don't work for two reasons: 1) they violate my requirement of not making my authors create HTML and 2) they rely on knowing the ratios. Every Getty image can have its own aspect ratio that I can't expect my authors to calculate.
The Getty embed has another factor not accounted for in these other solutions — regardless of the image aspect ratio, there is always a credit box below the image at a seemingly fixed height. This bar will always occupy that height, so scaling the image's height based directly on its width ends up leaving an ugly vertical white bar on the right of the image. This precludes any simple ratio as a solution.
I decided the best approach was to write a JavaScript function that accounted for the height of the image credit as it calculated the image ratio. Then it would apply width and height styles that would scale the embed without leaving the ugly white gap on the right (barring rounding errors, which are evident in the portrait images).
I opted for JavaScript instead of a block of jQuery because I knew this would be maybe a dozen lines of code in total, and requiring an additional 29-82KB (depending on your minification and zippage) for the jQuery library is, well, absurd. Also, I am not a fan of dependencies, particularly when most developers rely on hosted libraries.
I did some screen captures of Getty image embeds and identified the image credit bar is 69 pixels tall. That number may (will) change in the future. You may want to populate that variable from your chosen CMS so you don't have to do a full testing and deployment pass just to update one variable in your JavaScript functions file or page template (across all your sites) when Getty inevitably changes it.
The Getty iframe has no unique ID or class to make it easy to identify on the page, nor any other unique attributes, with the exception of the src attribute. So I loop through all iframes on the page and only grab those with the Getty URL.
I then get the iframe's width and height attributes, subtracting 69 from the latter, and calculate the ratio. From there I scale the iframe to 100% width and then get its new pixel width to feed to the ratio to calculate what its new height should be, finally adding 69 to it.
In my example page, I call the function at the bottom of the page and also in an onload in the body. There are better ways to do this, but given all the variations that are already out there (and that you may already employ), I leave it to you to figure out the best approach to handle for users who resize windows or rotate their phone/tablet.
What is compelling to me about this solution is that my clients (site authors) don't need to worry about adding or modifying any HTML on the page (most don't know HTML anyway), let alone CSS or script. When they paste the embed code, it should just work.
The Code
function responsiveGetty() {
try {
// Get all the iframes on the page.
var iframes = document.getElementsByTagName('iframe');
// Height in pixels of the Getty credits/share bar at the time of this writing.
var crHeight = 69;
for(var i = 0; i < iframes.length; ++i) {
// Check to see if it's a Getty embed using the only attribute that's unique, the src.
if(iframes[i].src.indexOf("//embed.gettyimages.com") != -1) {
eachIframe = iframes[i];
// Get the current ratio after excluding the credit bar.
picHeight = eachIframe.height - crHeight;
picRatio = picHeight / eachIframe.width;
// Set the iframe to fill the container width.
eachIframe.style.width = "100%";
// Set the iframe height to correspond to the ratio, adding back the credit bar height.
eachIframe.style.height = ((picRatio * eachIframe.offsetWidth) + crHeight) + "px";
}
}
} catch(e) {}
}
responsiveGetty();
Feedback
There are probably ways to optimize my code or factors I did not consider. If you see something wrong or that could be improved, leave a comment.
Depending on how much you spend staying up on web browsers, you've probably heard the cry of Opera did it first more than once (though the low-hanging fruit, browser tabs, wasn't technically Opera first). When Google announced that Chrome would offer a data compression mode, you may have figured you'd hear it again owing to Opera Mini.
Chrome for mobile devices has been climbing in use, partly because Android devices have started to move away from the default Android browser (though this doesn't affect all the Android 2.x devices and many of the 4.x devices that will be out there for a while). By adding support for data compression, Chrome is that much more appealing to users who have bandwidth caps, poor connections, or any other factor that limits how well they can see fat pages. Interestingly, some of the data compression comes from converting all the images to WebP (ol' Gil has finally found a way to make that format work). Chrome also automatically puts you into Safe Browsing mode as part of its compression process.
So I fired up both browsers, chose a list of web pages/sites that I haven't surfed using either of them, dropped into 3G and started my compressed surfing. These are the results:
Chrome requested 18.70Mb of data and compressed it to 4.83Mb, for a compression rate of 74%.Mini requested 12.9Mb of data and compressed it to 3.7Mb, for a compression rate of 72%.
This test was by no means rigorous or scientific. While Chrome compressed just a bit better overall, I felt like the experience was slower than on Mini. Chrome was also served much more data, perhaps owing to browser detection scripts offering more "features" to Chrome, or Mini's rendering engine just ignoring some of the elements it didn't know.
For those who have decided that Google is the great new evil, you may want to consider that Google proxies are between you and the web for every request when using Chrome's compression. For Mini users the same is true of Opera's servers, but far fewer people seem to be concerned about demonizing Opera Software. How much stock you put into Google's Safe Browsing technology behaving as some sort of censor is up to you and your own paranoia. I don't much care either way, but some folks might. As someone who's used Opera Mini for years when I travel outside the U.S., I'm very comfortable with it and doubt I'll switch — it's easier for me to just fire up Mini than it is to navigate Chrome's menus to enable compression.
Ganesha may or may not be stealing chocolate from the advent calendar.
For a few years now web developers around the world have celebrated Saturnalia Christmas with advent calendars covering topics related to the web. Some come and go, but you'll probably recognize a few regulars on this list.
I may have missed some, so please pass them along if you know of any. For those I know are not returning, I have listed them at the end.
1. 24 Ways
24 Ways, the one that most of this think about for web development calendars, is back again. It's been going strong since 2005 and based on its history this year should have some good articles.
2. Perl Advent Calendar
Perl Advent Calendar goes all the way back to 2000 (and back then looked a bit more like a traditional advent calendar, too) and has been dispensing tips for Perl developers ever since.
3. 24 Jours de Web
24 Jours de Web is starting its second year as an advent calendar for web folk. Written in French, it is clearly primarily targeted at French speakers, but a round of Google Translate will open it up to far more readers (like me).
4. UXmas
UXmas is an advent calendar aimed at the user experience community. Coming from Australia, American readers may be thrown just a bit by the schedule. The calendar promises everything from sketches, to articles, to tools, to videos.
5. Webkrauts
Webkrauts has an all German advent calendar, and it also dates back to 2005. It covers general web topics, but being in all-German readers like me will benefit from a Google Translate version of the page.
6. 12 Devs of Xmas
12 Devs of Xmas will also start the day after Christmas and go for 12 days from then. When all the other calendars have wrapped up, you'll still have one to read. The site is silent on its return, but this tweet suggests it's gotten writers and has a plan.
7. Freelancember
Freelancember 2013 is targeted squarely at freelancers. Its daily entries will consist of downloadable gifts in the form of PDF worksheets. Think of this as less about web-tech and more about MadLibs for projects. It has last year's calendar there as well, and so far (as of December 1) I cannot tell the calendar will just be a repeat of last year.
8. Mozilla Developer Network Holidays calendar
Mozilla Developer Network Holidays calendar includes brief links to resources or demos and suggests that you can edit them (if they are MDN resources). It doesn't link to previous years, but you can just hack the URL.
9. SysAdvent
SysAdvent is targeted to systems administrators, but there is a some cross-over to web developers. It has posts dating back to 2008 (and yet I missed it in last year's collection), so there is plenty of good material there if you're too impatient to wait for each day to be revealed.
10. Performance Calendar
Performance Calendar hails this as the speed geek's favorite time of the year, ostensibly because of the tips it has been offering each December since 2009. It isn't just server optimizations you'll find here, so don't shy away because you're not a system admin.
11. Web Accessibility Advent Calendar 2013
Web Accessibility Advent Calendar 2013 is in Japanese, and thanks to the wonderful powers of Google Translate, I can tell you that it is a calendar to make the talk about Web accessibility (based on this statement: Webアクセシビリティに関する話題でつくるカレンダーです。). If you know Japanese, I welcome any corrections. The site Adventar.org appears to host other advent calendars, some about web technologies, some about ramen.
12. Creative Bloq Advent Giveaway
Creative Bloq Advent Giveaway posts aren't collected in one place, so you'll have to find them on the site yourself (I linked the first one). Creative Bloq is the parent of .net Magazine, but you can expect most of its freebies will be targeted toward designers. Also, not all the gifts will be free, some will be discounts.
13. 24 Pull Requests
24 Pull Requests is less an advent calendar than it is an effort to mobilize developers. The goal is to get developers to send a pull request every day in December (up to Christmas), thereby supporting your favorite open source projects. There are even Coderwall badges for those who collect those sorts of things. This entry via Creative Bloq.
Not Returning
A handful of calendars aren't returning this year (so far), but in most cases content from previous years is still available. These include Font Deck's Adfont Calendar (which also skipped 2012), the Fronteers advent calendar (in Dutch, and also skipped 2012), Web Advent (it's taking a year off), HTML & CSS Advent (this is the 2012 calendar), She Said It (no access to old calendar), 12 Days of Podcasts (or at least there is no indication on its site or Twitter).
Not Web Related
ScienceGeek Advent Calendar Extravaganza is not web-related at all, and frankly it isn't promoted nor is it tagged (although I linked to “special” since that tag had the first day and nothing else). It is, however, probably going to be neat stuff given the first day is a giant image of the Christmas Tree Cluster.
Yesterday I had the pleasure of visiting the University at Buffalo (my alma mater) to give a presentation for its CIT professional development series. I got to talk about responsive design.
Knowing in advance that the room would have technical and non-technical users I went for a code-free presentation. One thing I learned is that code would have been useful, so if you're looking for any in here you won't find it.
I understand there is video from the event, and as soon as I have it I'll share it here as well. In the meantime, enjoy the slides without any context. Which may be more entertaining than my typically awful attempts at humor.
Yesterday Opera announced the release of its newest browser, Coast, built specifically for iOS tablets (I would say just iPads, but if my fridge gets an iOS tablet UI then I'd be wrong and will have paid too much for a fridge).
Background
Recently Opera moved away from Presto as its rendering engine and hitched its future to Blink, the rendering engine born from WebKit that powers Chrome. Now instead of Opera worrying about the rendering engine, it is focusing on the user interface, the place where it can set itself apart from the other browsers.
Essentially Opera is removing the browser chrome (implying to the user that a web page is just an app) and adding gesture support. Given that Opera was the browser that introduced us to mouse gestures well over a decade ago, and given that a touch screen is an inherently gesture-based UI, this seems like a natural fit.
Bits for Developers
Sadly, my office wifi was down and I couldn't play with the browser immediately (my crusty iPad 2 is wifi only). So instead I took some time to read through the developer notes.
Tablet First
Overall Opera recommends general responsive design current best practices, though it promotes a tablet-first approach. Opera offers some CSS you can use to specifically target iPads Mini, 2, 3 and 4 (Retina and non-Retina), though it leans on vendor prefixes with only a brief note to also use other prefixes and unprefixed rules.
Responsive Images
It's also clear that Coast supports the new srcset option for responsive images. It even offers a code example: <img src="image.jpg" srcset="retina.jpg 2x">
Note: As Bruce was kind enough to inform me (because I missed it in the dev notes), responsive images will be supported only in iOS7 and up.
Update as of September 20, 2013
According to Opera, iOS7 did not come with a WebKit update. That means Coast cannot support responsive images via the srcset attribute without a polyfill. Nor can Safari, of course.
TileSpeed Dial Web App Image
Instead of "Speed Dial" icons/images, Coast now looks for a "web app image." If you don't have one, Coast will first look for a Windows 8 tile image, then an Apple touch icon, then a shortcut image, then just a favicon. You can, however, create your own 228 × 288 pixel image and stuff it into your site with the following HTML:
<link rel="icon" href="$URL" sizes="228x228">
User Agent String
Don't use this to do any browser sniffing. Browser sniffing bad. This is instead handy for recognizing it in your logs:
Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Coast/1.0.2.62956 Mobile/10B329 Safari/7534.48.3.
General Review
Getting going is pretty easy, just start typing into the only field on the screen. As you type you can see a Google preview on the left, which you can tap at any time to go to Google, or a list of icons on the right which correspond to sites you might mean. The icons start out just displaying the first letter of the site, and then identify the site's tile or shortcut image.
Note the handy ".com" and ".net" options that appear above the right end of the text box.
Once you are on a page, you can go back by swiping from the left, forward by swiping from the right, or reload the page by pulling down from the top — but not too far or you get the iOS menu instead.
Vine of me playing with back, forward and reload in Opera Coast.
Opera Coast skips tabs and windows altogether and, frankly, feels a lot more like Internet Explorer for Metro than other current tablet browsers. It's pretty easy to see the open "tabs," flip through them, get more details, and discard them. It's also incredibly easy to forget you have so many tabs open. I regularly found myself littered with tabs because of all the links opening new windows.
Testing Opera Coast window/tab management.
While in that tab view, you can also see how "safe" the page is and can get to options to share it, email it, print it, and so on.
The arrow on the right gives you all the share options.I don't have a printer installed, so I'd love to hear feedback on how Coast honors print styles.
Adding and removing a bookmark, tile, whatever, is pretty easy. It took a few swipe-fails, but I got the hang of it well enough to show the whole process in one uninterrupted Vine:
It takes a little getting used to, but it's not too hard
Gotchas
There were a few things that threw me off. Perhaps because I am a power user, perhaps because I only played with it for one evening.
Swipe History
The swipe for back/forth is handy, but conflicts with behavior I have already learned. In Chrome for Android, swiping left or right has the infuriating feature of bringing me to the next or previous tab in the stack order. For those rare sites that implement a slide that is swipe-friendly, imprecise swipes will move me back and forth in the history instead.
Web App Images
Using the browser in portrait view, the additional screens of tiles (speed dial icons if you are already familiar with Opera) aren't immediately apparent. It wasn't until I turned to landscape that I saw them. The tiny dots under the Coast icon weren't enough for me to intuit that. They also aren't nearly large enough to tap to jump to a specific screenful of tiles.
Hit Sizes
The 9-box grid at the center bottom as well as the three rectangles at the bottom right are the only real browser chrome in play as you surf. They are also maddeningly small to tap. And I have dainty, lady-like fingers, so I suspect it may cause consternation for others.
Address Bar
If I am on a site and I want to change the address of the current page (maybe I fat-fingered and got to a 404, or I know a super-secret URL), I could not find a way to bring up the address bar and change it. It also made it impossible to know the current page address at any time. As someone who regularly looks at the URL for familiar addresses, indications of scam sites, quick commitment to memory, and so on, this alone takes it out of the running as an everyday browser for me.
Email a Page
I did not care for the email feature one bit. Not only does it embed a screen shot of the page (with a Coast watermark), the screen shot won't display on other devices. Outlook blocked the image because the attachment ended in .com (not .png or .jpg). Had it not come from me, I wonder if Outlook would have blocked it as spam. My Android email client couldn't display it because there was no file extension to give it a clue.
What you see when you choose to email a web page from Opera Coast.Best case scenario of what the email recipient sees, though the attachment was blocked in Outlook and unusable in my Android email client.
Tweet a Page
Tweeting a page left me similarly dissatisfied. By default it includes a Twitpic screen shot of the current page with an Opera Coast watermark. When composing the tweet, I tapped the paperclip icon to see if it would do anything, but nothing happened. I opted not to tweet again.
Overall, I like the browser. I like what it's trying to do for consumers. As a power user, however, It's not a fit for me though I'd be interested in bringing it in front of some other members of my family.
I also didn't get to try out unsafe sites, printing pages, responsive images (need iOS7), or poorly-built sites. My opinion might change as I continue to play with the browser.
Open Question
There are a lot of Android tablets out there, not just the four screen size offerings from Apple. So how long before we can see Coast on my Nexus 7, if ever?
Updates
I'm adding notes throughout the day as they come up.
Surprising no one, the following reviews from more mainstream sources completely fail to include any screen shots or videos that weren't pilfered from Opera. I only say that to remind you that by reading this post you have gotten the most in-depth review currently on the web and you should be excited and send me a thank you note and maybe read all my other posts and high-five me on the street.
These articles are, however, worth visiting just to see the comments and how others are reacting to it.
I started this post way back in March after reading Brad Frosts' bit on carousels. Then I let it sit unfinished. With the buzz around ShouldIUseACarousel.com this week, I figured I'd finish it up. The data is old, although I offer updated numbers at the bottom.
The Process
I looked at all the visits to my home page between February 1 and March 3 to get 30 days of data. Of those visits to the home page, 83% of the time the home page was the landing page. I figured if a smaller percentage of initial visits to our site came via the home page then I would not read too much into the value of these numbers as the user might have already been through enough of the site to get what he or she wanted, but 83% is a pretty big number.
The home page has many content areas, but by far the most prominent is our carousel. During the time frame tested, there were 5 different carousel images with accompanying text. Each one has its own Google Analytics event tracker so I can tell which carousel item has been clicked.
For those playing at home, and using Google Analytics, it's as simple as adding an onclick to your anchor: a href="/Products" onclick="_gaq.push(['_trackEvent', 'Slider', 'Columns']);". In this case I am tracking a custom event named "Slider" with the value of "Columns" (so I know which specific image/slide was chosen).
The Results
In the 30 days I tested, the carousel links were clicked less than 1% of the time the home page was visited — 0.8% to be slightly more precise.
Every other element on the home page received at least twice as much activity, with the tabs getting used nearly 10% of the time. Site-wide, the skip navigation link got clicked (tapped, followed) half again as much as the carousel at 1.2%.
To qualify this a bit, the carousel wasn't intended to serve as our only call to action on the home page. It's more about presenting a message to help brand the company as part of our new marketing push. Adding this tracking feature has allowed us to track how the carousel gets used, if at all, and which images/messages are more compelling.
The Latest Results
For this updated version of my draft post I looked at the last 30 days again (June 11 to July 11, 2013) to see what activity we've had on the carousel. The last 30 days are a good fit since we haven't been showing off the features of the slider to clients (which results in activity that is a function of people playing, not truly discovering and naturally using).
For the last 30 days, the number of clicks on the carousel is much lower. 0.2% of unique visitors clicked a carousel slide. For every 500 unique visits to the site, someone clicks on the carousel. Interestingly, this is the same number of people who print pages from our site and lower than the "skip navigation" activity in the same time period.
About the Carousel
Our site is a great place for us to experiment with the carousel since we can quickly refactor it, tweak it, replace it, and so on. Since its launch 7 months ago I have made a number of tweaks to the technology and we have played around with the messages to see what sticks.
We're revisiting the design of the carousel now to see how its relative size and different images and messages can affect its use. At some point it may go away, but not until I've had a chance to gather lots of data.
The carousel itself is both swipe-friendly and keyboard-friendly, uses a linear flow with a clear start and end, has indicators to show where a user is in the overall collection (also allowing a user to jump to a specific slide), and pauses when there is any action taken on the carousel (hover, click, tap, etc.). I built it to also serve images at appropriate sizes for appropriate devices, something which I am regularly tweaking. The base for this is the Royal Slider.
There is a nifty tool at MQtest.io which gives you a breakdown of how your device reports features you might use for media queries. To use the tool's own explanation:
This test isn’t about what media queries your device can or cannot see (but it does show an 'unsupported' label if a device doesn‘t support something). Instead it shows you which dimensions your device will respond to when using ‘width=device-width,initial-scale=1.’
As one of the seemingly few owners of a Windows 8 tablet (specifically the Asus Vivo), I sometimes get asked to check sites to make sure that a developer's media queries work properly. It was testing my own site that led me to discover the prefixed styles that IE10 needs in Metro view (which lead to my surprisingly popular post, IE10, Metro, and Media Queries).
Armed with the features that MQtest.io can help identify along with a Win8 tablet, I figured perhaps others without a Win8 tablet could benefit from some screen shots showing the MQTest.io results in various configurations of Internet Explorer 10. Please bear in mind that the numbers are for my device, and probably will not match those you would get from a Microsoft Surface or another Win8 device. At the very least, however, these will show you what tests will run in Win8/IE10 and the types of values you can expect to see.
Screen shot of Internet Explorer 10 on Windows 8 in desktop mode, with the tablet turned horizontally (wider than it is tall).Screen shot of Internet Explorer 10 on Windows 8 in desktop mode, with the tablet turned vertically (taller than it is wide).Screen shot of Internet Explorer 10 on Windows 8 in Metro mode, with the tablet turned horizontally (wider than it is tall).Screen shot of Internet Explorer 10 on Windows 8 in Metro mode, with the tablet turned vertically (taller than it is wide).Screen shot of Internet Explorer 10 on Windows 8 in Snap Mode, with the browser in the narrow view.Screen shot of Internet Explorer 10 on Windows 8 in Snap Mode, with the browser in the wide view.
Yesterday Matt Cutts from Google tweeted that Google search results for users on smartphones may be adjusted based on the kinds of errors a web site produces (of course I was excited):
Important: if your website has smartphone errors, we may change rankings for smartphone users: goo.gl/x8R4A#smx
Matt links to a page that outlines two examples of errors that might trigger this downgrade of a site's position in the Google search results and, right in the first paragraph, links to Google's own common mistakes page:
Many webmasters promote their site's apps to their web visitors. There are many implementations to do this, some of which may cause indexing issues of smartphone-optimized content and others that may be too disruptive to the visitor's usage of the site.
Based on these various considerations, we recommend using a simple banner to promote your app inline with the page's content. This banner can be implemented using:
An HTML image, similar to a typical small advert, that links to the correct app store for download.
I think it's good that Google links to the Apple article. I think it's unfortunate that Google does not link to Microsoft's own solution. If you read my blog regularly, or just follow me on Twitter, you may know that I covered both Apple's and Microsoft's app banner solution in January in the post "App Store Meta Tags."
You might also note that I stated that Google Play offers no such feature. Google, the force behind Android and the one now (or soon) penalizing sites in its search engine for app interstitials, provides no corresponding alternate solution of its own.
A great thing that Google could do for its Android users, for its search engine results, and for app developers, is to support a custom meta tag that allows web sites to promote their own Android apps in the Play store. Developers can start to replace awful Android app interstitials on web sites, users can get a cleaner experience, and site owners who can't conceive of other ways to promote their apps on their home pages can move toward something that is easier to maintain and doesn't penalize them.
I think it's nice that Google is paying attention to web devs by adjusting search results, but my rantytweets are probably falling on deaf ears. The web would be indebted to someone who can get Google's and Android's ear on this.
For a few years now web developers around the world have celebrated 
Yesterday 
