As I push towards the v1.0 release of Detector I’ve decided to focus on refining the list of tests that form the core of Detector’s ”browser map.” My original listing of tests was cherry-picked from Modernizr’s “build tool.” While a useful listing it doesn’t cover every feature that may be of interest to developers. Especially, as I found, those developers primarily interested in mobile.
The draft listing of Detector’s v1.0 tests is available as a Google Doc. I wasn’t sure of the best way to leave feedback so I guess you can either reply to this post or put your comments in the “User Contributed Notes” section of each sheet. The primary criteria for a listed test is simply my own interest in that particular feature. The only type of tests that I’ve ruled out for now are ones that simply test browser performance (e.g. FPS).
The listing was built using the following resources:
In locations where I’ve listed that a test doesn’t exist (primarily Modernizr) I simply mean that it’s not included in the official repo for that library. It could exist elsewhere. Ringmark didn’t contain every test I expected (e.g. battery) so maybe I overlooked something there as well. Suffice it to say it’s been a few late nights.
I also referred to the following material as reference:
To explain the organization of the sheets a little bit… Each sheet is my attempt to organize tests into logical groups. There is overlap. The most important column is B as that determines what’s happening with a particular test. The key is included at the bottom of each sheet.
I would love feedback on the list. Suggestions of tests to include or remove are very much welcome. I know the doc is overwhelming but I wanted to record as much information as I could while doing this process rather than have to look up things later on. I haven’t looked at performance issues yet, fine-tuned tests, or anything as I’m simply trying to decide if the features could prove useful to developers and act as a quality snapshot of a UA. All of that will come as I narrow down what will be in the v1.0 test suite.
In preparation for some summer projects I cleaned up my PHP & Modernizr-based browser- and feature-detection library, Detector. You can get a taste of what it can do by visiting the feature list page or checking out the RESS template demo. The code and feature-set are essentially where I want them to be for 1.0. I could stand to add proper unit tests and the like. I’ll attempt to add them in the near future but my schedule is getting really busy. The highlights for this release include:
a better job of handling browsers that don’t support JavaScript or cookies. This extends to customizable family properties for those same browsers as well as search engine bots. Learn more in the docs.
the ability to change the family property for a browser via a request variable. For responsive designs this could mean “desktop” mode. Learn more in the docs.
Modernizr-based tests can now be run once per-session for those features that need to be tested on a per browser basis but won’t change in subsequent requests (e.g. pixel density ratio). Learn more in the docs.
in general I’ve tried to DRY up the code & reduce memory footprint
On the face of it it doesn’t seem like a whole lot happened. More changes are listed in the CHANGELOG. This release, in my opinion, makes Detector a robust and flexible library that brings PHP developers that much closer to their front-end brethren. Now we can build dynamic, future-friendly applications that can take advantage of browser properties server-side.
In higher education we really like “best practices.” We like solutions that are proven and that we can easily implement as we dip our toes into new technologies. I’ve watched this happen with social media and I’m now experiencing it with mobile. Part of the reason we try to find and follow “best practices” is our need to get the most bang for the buck. Another part of it is the fact that many of us wear so many hats that we need to rely on “experts.” Lastly, I think another part of it is that for so long we’ve seen our industry as behind-the-times that, yet again, we must be behind with this technology and therefore there must be guidelines to follow; things we can follow to “get it right.” Here’s what I’ve learned about mobile though…
Everyone, in every industry is figuring this out at the same time, it’s fucking messy, and, for the most part, anyone spouting off about any particular solution as being “the right way” is full of it. And the reason they’re full of it? One size doesn’t fit all (no matter what it might say on the package).
This is why I get peeved when people we should all hold in high-esteem drop blog posts with overly pithy summaries that actually end-up muddying the waters that much more.
In early April 2012 usability expert Jakob Nielsen turned his attention to mobile and penned a piece entitled, Mobile Site vs Full Site. The summary for the article follows:
Good mobile user experience requires a different design than what’s needed to satisfy desktop users. Two designs, two sites, and cross-linking to make it all work.
The very first and, to quote him, ”very clear” guideline that Jakob lists for mobile-optimized websites is ”Build a separate mobile-optimized site.” [Jakob’s emphasis] Now the article is essentially correct in highlighting that the rules for mobile design can be different than desktop design and that most of today’s websites don’t properly address these issues. Josh Clark’s (@globalmoxie) rebuttal is very much worth reading and others picked apart the salient points at the time the original article was written so I won’t re-hash them. The thing that bothered me then, and does again in light of his equally good and bad article Repurposing vs. Optimized Design (another good overview so I won’t re-hash it either), is the definitive stance regarding an overall solution that Jakob takes when, in fact, he’s really only suggesting this “usability tip” for a particular subset of sites or use cases.
In a follow-up article on .net magazine, ”Nielsen Responds to Mobile Criticism,” Nielsen offers clarification on this original article and answers the following question that is based on one of the primary arguments used against his original post:
.net: The strategy of forking content for separate sites has been described as “a content strategy nightmare” – it’s too hard to maintain and will result in inferior experience for users.
JN: I would assume that most industrial-scale sites[emphasis mine] would be generated from a single back-end product database and content management system, with the different designs represented by templates and rules about what information goes into what version.
Later, in answer to the same question, he says:
Many companies and government agencies have products and information that don’t speak much to the mobile use case, and they can usually get away with having a single website that’s optimised for desktop use but with some adaptations to make it reasonably accessible on mobile devices.
So Jakob’s first, ”very clear” guideline is now not so clear. It gets worse:
.net: Multiple URLs for a single piece of content is often thought of as a bad idea.
JN:There are at least three different ways of implementing different user interfaces for different devices:
Each version lives at a different URL.
The same URL serves up different versions, depending on the device used to request the page.
The same code is transmitted to all devices, and the client side transforms this into the different designs, using responsive design.
As long as each user sees the appropriate design, the choice between these implementation options should be an engineering decision and not a usability decision.
.net: Why have you made no mention of using Responsive Design?
JN: Because I was writing about user experience, not implementation * [emphasis mine]*. As mentioned above, responsive design is one of the ways to achieve different user interfaces for different devices.
Suggesting ”Build a separate mobile-optimized site,” again his very first guideline, screams implementation. So, based on the .net Magazine clarifications, we should revise his original guideline to be ”If you’re a very large, centralized organization with mobile use cases it behooves you to do… something mobile-friendly.”
And the kicker to all that? If you just read Jakob’s material and weren’t hooked into the people who were involved in the backlash you may never have found the clarification. You may have implemented his suggestions as a “best practice” (I mean, it’s Jakob freakin’ Nielsen), found a vendor, spent some money and… been stuck with a site and a mobile strategy that didn’t fit your content, your internal processes, or real use cases as the web on mobile evolves into the “just in time” internet.
Figuring out what mobile will mean to your institution requires time spent thinking critically about goals, technology, and then trying to understand how these new tools can match up to your existing processes and, honestly, the culture you already have at your institution. To succeed with mobile you’ll have to be willing to be critical, to fail, to reconfigure, to iterate, to learn and to develop your very own “best practices.” Unfortunately, there is no such thing as a turn-key solution or list of tips that will help you easily guide your institution into the new age. No matter what Jakob, or I, might say.
I understand that this article can and probably will come across as the pot calling the kettle black. I take strong stances myself. I do hope that I appropriately add caveats to what I write but maybe I don’t. When I talk to people about mobile and they question how we’ve implemented and learned so much I tell them something my father told me a long time ago about what he told students he was teaching in a brand-new math class, “I’m only a chapter ahead of you.” Seriously, all of this stuff is a moving target.
I’ve pushed out v1.4.0 of ua-parser-php. ua-parser-php is the PHP library for the official ua-parser project. Why use ua-parser? If you need a simple library to slice & dice user agent strings into understandable components (e.g. browser, OS, device) then it’s the project for you. ua-parser-php goes a step further by also attempting to categorize browsers as mobile, tablet, computer, or spider.
Setting Up ua-parser-php With Cron
As the ua-parser team updates the YAML file and its regular expressions you will want to update your local copy of regexes.yaml. The easiest way to do this on a *nix system is to use cron. I’ve added some simple flags, -silent and -nobackup, to make it easier to set-up an intelligent cron job. -silent is very important and I highly encourage you to use the flag if you use ua-parser-php with cron. By default, ua-parser-php writes out process updates to the command line as it fetches the regexes.yaml file. When using cron this will end up as an email and will either fill the spool on the machine or your inbox.
So here are some examples of commands you can use with cron:
Quick “redirect” Example
Because the PHP version of ua-parser supports extra browser categorizations like isMobile you can use ua-parser-php as the basis for a simple redirect script. The following should show just how easy it can be:
Recent User-Agent Updates
Obviously, the big feature of ua-parser is matching user-agent strings and giving you usable data. The following user-agents have been added and tested:
I gave a talk at RefreshPittsburgh (@refreshpitt) last night that hopefully served as an introduction to RESS and Detector. I believe RESS can help developers address some of the realities of deploying Responsive Web Design-based sites so it was awesome to share the concept. I can’t thank Jason Head (@gjhead), Val Head (@valh), and Geoff Barnes (@texburgher) enough for giving me the opportunity to present. It was a really fun time with a good group both during and after the event and I can’t recommend Refresh Pitt enough. The other talk of the night, given by Patrick Fulton (@patrickfulton), reviewed Compass and was really informative. If you’re in Morgantown or Pittsburgh make sure you follow @refreshpitt on Twitter and attend the next event.
The talk description:
Responsive web design has become an important tool for front-end developers as they develop mobile-optimized solutions for clients. Browser-detection has been an important tool for server-side developers for the same task for much longer. Unfortunately, both techniques have certain limitations. I’ll show how both front-end and server-side developers can take advantage of the new technique called RESS (Responsive Web Design with Server Side Components) that aims to be combine the best of both worlds for delivering mobile-optimized content.