dmolsen.com

Feb. 27, 2012: A small update, v0.5.1, was made to Detector to clean up PHP Notices as well as add two methods to push Detector data to the browser so the data can be used a la Modernizr.

Detector v0.5 has been posted to GitHub. The Detector demo site has also been updated to reflect the new version.

About Detector

Detector is a simple, PHP- and JavaScript-based browser- and feature-detection library that can adapt to new devices & browsers on its own without the need to pull from a central database of browser information. Detector dynamically creates profiles using a browser’s (mainly) unique user-agent string as a key. Using Modernizr it records the HTML5 & CSS3 features a requesting browser may or may not support. ua-parser-php is used to collect and record any useful information (like OS or device name) the user-agent string may contain.

With Detector a developer can serve the appropriate markup, stylesheets, and JavaScript to a requesting browser without being completely dependent on a front-end-only resource loader nor a browser-detection library being up-to-date. Detector can be used with a solution like Mustache to provide robust templating support.

The following are the major changes in this release:

ua-parser-php Integration

I was unhappy with the original browser detection library in Detector so I created a PHP-based pseudo-fork of the ua-parser project called ua-parser-php. It is included as a submodule of Detector and provides a much more robust classification system for browsers and mobile devices. Because of the number of attributes it parses out of a user-agent string it should give developers more flexibility when developing solutions.

Browser Families

With the new families feature in Detector developers can organize browsers that share certain traits into groupings. With families a developer can test for a browser’s grouping rather than each individual feature that browser may support when displaying content. This might be especially useful for templating solutions.

Expanded Feature Tests

Modernizr 2.5.2 has been included with this release as well as an expanded set of features including tests for cssremunit, deviceorientation, devicemotion, and lowbandwidth support. See the full list of Detector’s core tests.

Detector Wiki Added

I’ve attempted to grow the documentation for Detector beyond the original, limited README by using the wiki that comes with a GitHub repository. Content includes:

Other Changes

Those are the big changes but their are a few other, minor changes:

a configuration file for setting debug mode as well of locations of files & directories is now included
both core and extended profiles can now be versioned
the original layout of the files has been cleaned up some
two simple demos, one for including a YouTube video and the other for templating, are now included
while not a change in Detector per se, the archive of user agents now contains 170+ user agents and their associated feature tests

If you have any questions about the project please feel free to drop a line in the comments.

This article was posted Feb 21st, 2012

I recently purchased the book Head First Mobile Web by Jason Grigsby (@grigs) and Lyza Danger Gardner (@lyzadanger). I follow Jason and Lyza on Twitter as well as read their blog posts on Cloud Four so I figured it’d be a good read. It was really useful and I learned quite a bit from it. Read on for my Amazon.com review. And if it comes off really gushy it’s because I really liked the book.

When talking “mobile” apps seem to get all of the attention but a mobile-optimized website is a necessity for many businesses. Any company that relies on email or social media to help spread the word about their offerings (think “web links”) really should make sure their website is easily viewable on a phone. Jason and Lyza do a fantastic job of taking a “new to mobile” developer through the various options that are available for making a website mobile-optimized (their are many!).

The book includes hands-on lessons with each chapter (including code you can download) and useful “case studies” to make it clear how each technique should be used. By covering the latest trends like Responsive Web Design and HTML5 APIs and some old school techniques like device detection and CSS-MP “Head First Mobile Web” makes a great resource for anyone looking to get into mobile web development or, like myself, looking to brush up on their skills.

What I think I appreciate most about the book, beyond the depth & practicality of the information, is Jason’s and Lyza’s frankness in the pros and cons of each solution and being clear how each can be useful. I was most struck by this in the WURFL section. A lot of time is spent talking device detection (one of my favorite mobile techniques) but they’re very clear about some of the licensing downsides to the product. They don’t just gloss over that very important issue.

It’s a surprisingly quick read considering the thickness of the book. That’s probably because, rather than being big blocks of text talking theory, it has a lot of practical examples, tips & tricks and uses a great conversational tone. This book really is designed to be, above all, practical and easy to learn from. If you’re at the start of a project and want to know what is available to you with mobile web or using web technologies (they also cover PhoneGap for making HTML-based apps) you should really pick this one up.

This article was posted Feb 2nd, 2012

Update on May 2, 2012: <a href="https://github.com/dmolsen/ua-parser-php">ua-parser-php</a> is now included in the official ua-parser repository on GitHub.

Update on February 11, 2012: <a href="https://github.com/dmolsen/ua-parser-php">ua-parser-php</a> was updated to v1.0.0. The list of supported browsers and devices was greatly expanded. A number of bug fixes were also added by Bryan Shelton.

<a href="https://github.com/dmolsen/ua-parser-php">ua-parser-php</a> is a PHP-based pseudo-port of the <a href="http://code.google.com/p/ua-parser/">ua-parser</a> project. ua-parser-php is designed to parse a user agent string and return certain properties like browser name, OS version, and, in some cases, device name. ua-parser-php utilizes the user agents regex YAML file from ua-parser but otherwise uses its own set of properties to describe a browser, OS, and device. ua-parser-php was created as a new browser-detection library for the browser- and feature-detection library Detector.

If you want, you can test your browser against ua-parser-php. As usual, the code is available on GitHub.

Usage

Using ua-parser-php is straightforward. Simply include it in your project, make the call to parse the user agent and you’ll be returned an object with various properties of the user agent. Examples follow:

NOTE: Using this feature will overwrite a number of changes I’ve made to the user_agents_regex.yaml file included with the ua-parser-php distribution.

Credits

Thanks to the ua-parser team for making the core data available to others so we can build our own solutions.

This article was posted Jan 30th, 2012

Karine Joly (@karinejoly) of Higher Ed Experts is currently running a survey regarding the state of mobile web at higher education institutions. Please, take a moment and fill it out. In the interest of full disclosure, I will be presenting on mobile strategy for Karine and Higher Ed Experts on March 13, 2012 as a part of the Higher Ed Mobile Summit. I will be joined by Stewart Foss (@stewartfoss) and Nick DeNardis (@nickdenardis). It promises to be a good overview of what mobile means to higher education as well as useful tips on how to get started.

The full note from Karine regarding her survey is below:

Hello,

I’d like to invite you to complete this short survey about the state of the mobile web (mobile websites, apps, etc.) at your institution:
higheredanalytics.com/mobile

This is the second edition of this survey and 105 of your colleagues already completed it but we need more. Its goal is to assess how colleges and universities respond to the needs of the increasing population of mobile device owners.

Please take the survey whether or not your institution has a mobile solution - as I’m trying to evaluate the current state for higher education as a whole – and not just for early adopters.

The results of this survey will be used for presentations and articles. Anybody who completes the survey will receive a copy of the executive summary of the survey report as well.

If you have any questions, please let me know. Thanks for your time and your help.

Karine

Higher Ed Mobile Web Summit
http://higheredexperts.com/mobile

This article was posted Jan 18th, 2012

Feb. 21, 2012: v0.5 of Detector was pushed out. Read about the new features.

Feb. 27, 2012: A small update, v0.5.1, was made to Detector to clean up PHP Notices as well as add two methods to push Detector data to the browser so the data can be used a la Modernizr.

With the initial release of Yiibu’s Profile, Detector is already YABFDL (Yet Another Browser- and Feature-Detection Library). The main question behind Detector, ”How does one go about intelligently combining browser- and feature-detection into one package?,” has been floating around in my head ever since I heard Yiibu’s talk, Adaptation. Because of two recent events, our holiday card project and the OpenDDR/WURFL/ScientiaMobile kerfuffle, I decided to finally tackle that question and see what I could come up with to answer it.

Introducing Detector

Detector (demo & code) is a simple, PHP- and JavaScript-based browser- and feature-detection library that is still in its infancy. Detector gives server-side developers information about what types of devices may be requesting their content as well as the HTML5 & CSS3 features a requesting browser on that device may or may not support. With Detector a developer can serve the appropriate markup, stylesheets, and JavaScript to a requesting browser without being completely dependent on a browser-detection library being up-to-date nor completely dependent on a front-end-only script loader. Detector is based on Modernizr, modernizr-server, and the browser-detection library from Mobile Web OSP. It also benefits from a healthy dose of inspiration from Yiibu’s Profile. Want more of the gory, technical details? Check out the README for more information.

Why Create Detector?

With Yiibu’s Profile, Luke Wroblewski’s (@lukew) article, ”RESS: Responsive Design + Server Side Components,” and the Future Friendly movement I think that more and more folks are accepting that server-side technologies still have a large part to play in delivering mobile-optimized solutions. That being said, browser-detection cheerleaders like myself can learn a thing or two from the responsive design/feature-detection folks. Detector was created as a way of, hopefully, combining the best of both browser- and feature-detection and giving server-side developers a lot of power and flexibility in developing cross-browser, as well as mobile, solutions.

Flexible & Future Friendly

I wanted to address two primary goals when developing Detector. The first goal was to create a solution that was forward looking and could adapt to new devices and browsers on its own. I didn’t want a developer to have to worry that their website might break if a new a browser came out with a different user-agent than those already being tracked. This is one of the real strengths of using feature-detection as a solution. A feature is either available or it isn’t. The first time Detector gets a visit from a new user-agent string it tests that browser for all of its available features and saves that profile to disk for future use with other browsers with that same user-agent. In this way Detector can grow and adapt to changes in the browser & mobile landscape. Also, because Modernizr (and it’s long list of pre-built tests) serves as the core feature-detection library of Detector a developer can add and track their own tests just by using the Modernizer.addTest() plug-in API.

Open Browser & Device Knowledge

My second goal was to see if I could find a way to capture and share device knowledge. While Detector is focused on browser knowledge as opposed to device knowledge I think the information is still useful overall. Especially to web developers who are, for the most part, only ever going to interact with the browser anyway. I feel very strongly that their should be a central, open resource for developers to rely upon to not only learn what browsers support what features but a way to use that data within their applications. Because of that I have signed onto the Open Device Knowledge Collaborative. Detector is not nearly stable enough to help create that resource now but I do hope that it can in the future. At some point I will create a central repository of browser profiles that anyone can use in their applications (with or without Detector!) and, via Git, developers will be able to submit their own profiles back to the central repository for others to use. It’s an ambitious idea and their are a lot of hurdles yet to overcome but I do think it’s an important goal for Detector and the community at large.

Where Detector is Going

Detector is far from perfect as a solution. As I said, it’s in its infancy. I’d love to see the following get addressed:

New profiles could contain bad data that, in its current incarnation, wouldn’t get updated by more “reliable” browser visits in the future. Basically, is there a sampling and/or confidence metrics that could be used to re-test browsers?
Modernizr-based media query tests seem to be really flaky and it’s obviously a problem with Detector itself. When I use the media queries outside of Detector they work as expected.
Versioning of profiles as well as creating that central repository so profiles can be used by anyone.
Most importantly, Detector needs more browsers to use it to really test its capabilities and accuracy.

While it is still early days for Detector hopefully lessons can be learned from its implementation for others developing similar solutions.

Helping Me Test Detector

If you can, please hit the Detector demo (http://detector.dmolsen.com/) on, preferably, your mobile device of choice and see if Detector works as expected. If it doesn’t please shoot me a note from the contact link under the Browser Profile information.

*[YABFDL]: Yet Another Browser- and Feature-Detection Library