Symphony.

A new extension, "Device Categorizr" is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

Although ridiculously simple (all the work is done by Categorizr - I just add the resulting value to the parameter pool), this is my first extension, so I'd appreciate being informed of anything I've done wrong or possible improvements.

Your extension driver even beats my Unique Upload Field extension driver in terms of simplicity.

:-(

Thank you for creating this. Complements my User Agent Feature Detection extension nicely.

Complements my User Agent Feature Detection extension nicely.

Yes, could be good to use them together. I haven't tried that out yet - will definitely keep it in mind in case I need specific feature/spec detection.

Thanks Oliver for this extension!

Just what I need for my next mobile-first web page design. And I love that it also detects if Android is used on a phone, tablet or desktop...

AWSM. I nearly forgot this existed, this is exactly what I need, thanks!

@ijy:

That's fantastic. I hadn't seen that yet. It's certainly a step in the right direction but ideally I'd need finer control of media breakpoints by width declaration rather than just categorisations as each responsive design is unique and corresponding breakpoints will vary whilst designup 'up'.

Why not CSS media queries?

I tend to optimise larger files (i.e. images) based on device type and supply mobile-first/content-first CSS to all (fine-tuning which CSS is served to which device type if it's necessary).

Also see @briandrum's comment above if you need user agent details, and this discussion on high dot pitch displays.

Why not CSS media queries?

The styling of the site is all done with CSS media queries for layout and breakpoints but the problem comes when relying on media inserted into the markup of the page (images uploaded via the CMS for instance). At that point I need to need to dynamically switch the img tags (or ads/widgets etc) in my markup rather than force mobile users to download massive images.

This is basically what I'm aiming for where I can conditionally load tags based on the screen-width. Device Categorizr is definitely on the right track and the conditional checks in XSLT is what I'm aiming to achieve by dipping into parameters provided in the parameter pool. However rather than just say this is 'mobile' or 'tablet', 'tv' or whatever I'd like more fine-grained control over the breakpoints for conditional serving. In the majority of cases a simple width variable would be enough as long as that can be set dynamically according to the design in question. Something like this for instance:

<xsl:choose>
    <xsl:when test="$screen-width='< 320'">
        <img src="{$root}/image/1/300/0/{image/@path}/{image/filename}"/>
    </xsl:when>
    <xsl:when test="$screen-width='< 780'">
        <img src="{$root}/image/1/800/0/{image/@path}/{image/filename}"/>
    </xsl:when>
    <xsl:otherwise>
        <img src="{$root}/image/1/1000/0/{image/@path}/{image/filename}"/>
    </xsl:otherwise>
</xsl:choose>

Each design is unique and the breakpoints can come at varying sizes whilst designing & building 'up'. It's therefore important to have more fine-grained control over the breakpoints rather than categorisations. With the recent release of devices like the iPad Mini and MS Surface etc all adding new screen dimensions to the mix trying to categorise is a moving target but screen width just looks at the dimensions. I'm not sure if iPad Mini is classified as a Mobile or Tablet but either way I'd rather have control to decide so I know that between 320 and 780 exactly how it will look and if needed I can add an extra breakpoint in width. Does that make sense?

The User Agent Feature Detection extension sounds like it's also close with the use of cookies and JavaScript to bridge the gap to the server. I've had a read through but I think I might need another look to fully understand it.

You're never going to be able to do that I'm afraid, only make an educated guess at an average size to use.

This is the method I use, with Device Categorizr, and it's the best extension we have for UA sniffing as it does it the right way compared to other methods. Images and other size dependant media are delivered at the largest size the 'device' can cope with, which is a size I specify in parameters. There's no point in trying to change the media size based on a media query type of approach for every change, as media in modern browsers renders very well when the size is slightly less or more than it's original.

My work is here, but doesn't work properly yet. I have to iron out my silly mistakes (when I get time).

My work is here, but doesn't work properly yet. I have to iron out my silly mistakes (when I get time).

So these are your utilities to work in combination with Device Categorizr? Both of these are certainly a good start so I'll take a closer look at them both and see if I can do what I need to do with them.

it's the best extension we have for UA sniffing as it does it the right way compared to other methods.

Have you tried the User Agent Feature Detection extension at all? I've just been taking a closer look and on the surface it seems to provide the approach I had in mind. You seem to be able to define your own breakpoints for JIT images which seems to be quite useful. Out of interest when you say 'right way' what do you mean? DC seems to be reliant on the WURFL library underneath and both are just sniffing for workable widths rather than tethering to a particular device/model/browser etc.

It's interesting to get different takes on handling it. I'm still just trying to figure out the best approach so all tips and viewpoints are welcome.

So these are your utilities to work in combination with Device Categorizr?

That's true, yes.

Have you tried the User Agent Feature Detection extension at all?

I have read about it, and sadly it isn't really a great way to do what we need. The page needs to be loaded by the device in it's entirety to understand the device width, which completely defeats the object of providing smaller media for mobile devices.

From the readme:

On subsequent page loads the extension checks for the presence of those cookies and adds the values to the param pool.

DC seems to be reliant on the WURFL library underneath and both are just sniffing for workable widths rather than tethering to a particular device/model/browser etc.

That's not correct. Device Categorizr is built on top of Brett Jankord's Categorizr PHP, which he hand wrote to do device detection assuming mobile first. It doesn't output width's for devices, but rather which 'category' a device fits into. I have spoken to Brett personally about the future of his PHP approach, and it is almost future safe, unless device manufacturers decide to change how the build their UA strings. In this scenario, he is around to make adjustments for any future devices.

As part of my job, I've researched this a lot, and do believe that this extension is the better approach to figuring out devices. I'm certainly not shooing any other method, I have also been known to do it differently for different projects, but as an all round approach that I'm working on for a blog post here (soon), I think David had the right idea in providing this extension for us.

I could go on for hours and hours about this stuff, but I am hungry. ;o)

If you plan on providing an appropriately-scaled image to cover off the maximum size at which a visitor might see it, I think that can make sense. But you're then committed to having to use JS or a server-side device library that includes screen pixel dimensions. There are always new devices coming out with different dot pitches and sizes of display - I'd rather not have to know the exact pixel dimensions in order to serve it. (And this will become less relevant over the next few years as more and more screens come with higher and higher dot pitches.) So I prefer to keep it simple and provide images that are generally big enough for the device type. Though I'm interested in @designermonkey's utilities...

@DavidOliver yes, i'm most definitely not aiming for specific pixel dimensions but just wanting to match in the same way that I set my breakpoints in the CSS. You define those whilst building up from mobile (no media query is therefore your first media query) and progressively enhancing for devices with more screen real estate using min-width—best practice followed to the letter. The thing I want control of is what to serve in between the defined breakpoints. I'm just confused as to what the breakpoints are in Categorizr. Doesn't it make sense to match them with the breakpoints you defined in your CSS?

OK I think I'm starting to understand more about Categorizr. I hadn't really heard of it before so I'm just trying to figure out what it's doing and how it compares to other approaches. The confusing bit for me is why it has to categorise devices into one group or another and what it means to be in each category.

Just so we're on the same page I'm talking about a "mobile first" way of building. This seems to be Categorizr's differentiator on it's web site but to me that's a given when working on new responsive websites. Also I'm just focusing on serving up media (primarily images) in the markup itself.

"I truly believe that the way to go is responsive layout with adaptive content" —Markus Thiel

Categorizr seems to follow this approach by categorising devices and displays but to me there's just a bit cloud with regards to what elements go to make up that categorisation. Is it screen size? PPI? Definitions from somewhere?

In the CSS I define my own breakpoints according to content whilst working upwards:

"Start with the small screen first, then expand until it looks like shit. Time to insert a breakpoint!" —Stephen Hay.

In the same methodology this will also mean that categorisations in the markup will be different (let's keep this simple by just talking about screen width for now). So I may have set a breakpoint in my CSS at min-width: 500px and then min-width: 1000px, etc. These would be different to your normal device categorisations and browser widths.

"By letting the content itself determine the breakpoints of our responsive designs, we’re preparing our designs to look great in not just today’s landscape, but tomorrow’s as well." —Brad Frost

So naturally I would then need to serve up media in the markup to match these design breakpoints (roughly, not exactly, in an adaptive style approach) so that I know what size image will be served up between each breakpoint.

“it’s not about what happens at the breakpoints, it’s about what happens between the breakpoints.” —Jeremy Keith

But I'm having a hard time in finding out what those breakpoints are with Categorizr. By simply categorising as either mobile, tablet, desktop, or tv it's quite a broad scope. What about orientation which will change the screen-width? It's then throwing devices into each category but the details of that category aren't obvious. The categories are referenced online but there's no mention of sizes or characteristics at all. What about retina display and PPI?

What I'd like to do is to define those classifications (and even what I call them) myself in the same way I can when working with libraries like WURFL in PHP (others like DeviceAtlas are also very good):

if ($device->getCapability(‘resolution_width’) >= 500) {
    $tablet = true;
} elseif ($device->getCapability(‘resolution_width’) >= 1000) {
    $desktop = true;
}

Then I'm defining my own categorisations and the breakpoints fit in with my individual design and not a—somewhat myseterious—categorisation. To me this seems far more flexible and also the most future-friendly way of working because it says I don't care what you are or what category you fall into I just want to know how much screen real estate I have to work with. It could be a new tablet, and in-car display, or a futuristic refridgerator, it just wants to know about the screen width.

My concerns with Categorizr are:

• It doesn't seem very flexible in allowing your to define adaptive breakpoints for your custom designs starting from mobile up
• User Agent Strings can be falsified and therefore you could serve up the wrong information
• If relies on a third-party to keep the script up to date
• It doesn't differentiate between other features such as PPI, screen width, device width, etc
• If you link to the github repository it's also relying on that repository never being moved or deleted
• There are known issues

On the positive side:

• By simply reading UA String it doesn't require a first full page download and seems to look at Session thereafter
• It can be self hosted (also be a disadvantage as it relies on the developer to update regularly)
• It makes for a simple general categorisation for simplicity within templates
• It comes with a rather handy ready-made extension for Symphony. ;)

There's no silver bullet and I'm just trying to better understand it with consideration to other options to see which route would be the best to follow.

Are there any known Symphony extensions plugging into WURFL at present that I can compare with? Does anyone know if User Agent Feature Detection is being maintained or if it currently works on Symphony 2.3.1?

Nice discussion. :-)

Device Categorizr's purpose is not to provide exact details of the device. It's a more general tool.

Because it purposely remains limited to device type, we can use it for things other than device display pixel dimensions and dot pitch, e.g., if the device is mobile or tablet we know the visitor won't be hovering over elements and can make sure we cater for touch.

Device Categorizr isn't about breakpoints. It's there purely to categorise. What you do with that very limited information is up to you and depends on your particular project.

A (fairly major) issue with serving JIT images sized exactly to the maximum width of the device type is that there will be loads and loads of differently-sized images needing to be cached on your server. (But maybe that wasn't your intention, anyway.)

As mentioned, my approach is to serve images which are roughly sized appropriately for the device type. If the visitor is using a mobile, I know the image is going to be shown at roughly 6" wide/tall maximum, so I'll use JIT to pick appropriate pixel dimensions based on that. img { max-width: 100%; } does the rest. This won't give a 1:1 pixel mapping from image pixel to device pixel, but that's fine with me.

I haven't got into conditionally serving larger images for high dot pitch displays yet, but there is a method where you serve double size and then heavily compress; apparently this gives good results and relatively low file sizes. Then there's @designermonkey's utilities, which I understand will help with images for high dot pitch displays.

I suggest you consider letting go of trying to know exact device display dimensions. But if you do want to go that route, you'll need to sort something else, e.g. WURFL, or the User Agent Feature Detection extension.

It doesn't seem very flexible in allowing your to define adaptive breakpoints for your custom designs starting from mobile up

It's not inflexible - just limited in purpose.

User Agent Strings can be falsified and therefore you could serve up the wrong information

If someone's chosen to provide a "wrong" UA string, it's not my fault if they get the "wrong" media.

If relies on a third-party to keep the script up to date

Device Categorizr (the script itself, not this extension) assumes mobile unless it detects something else. This greatly negates the maintenance issue, but I understand Brett Jankord is going to be around to deal with adding tablet, TV and desktop browsers. And it's open source, anyway.

If you link to the github repository it's also relying on that repository never being moved or deleted

This extension includes the script and isn't reliant on Brett's repo at Github.

There are known issues

I should read through these properly, but I think Brett's script gets it right for the vast majority of devices. I try to use device type to optimise file sizes of images rather than to fundamentally change content, so the right information should still be served. If some new desktop browser comes out and it's not detected by Device Categorizr as such (instead being categorised as a mobile), my CSS will still respond to the greater width of the viewport and give the proper "desktop" layout.

A very good discussion. It's always good to get different viewpoints and from those who have already tried implementing sites with particular approaches. :)

It seems that Categorizr deliberately tries to keep it simple with it's categorisations and from what you've mentioned I can see the plus points in that. And of course, there's JIT images! So there's still flexibility in what size images you serve in between each categorisation. Hmmmm, that may work in my case then...

A (fairly major) issue with serving JIT images sized exactly to the maximum width of the device type is that there will be loads and loads of differently-sized images needing to be cached on your server.

No I'd never aim to be 'exact' in any responsive web design. I'd still only ever have maybe 3 or 4 different sizes of images based on breakpoints but I'm just saying those breakpoints are dictated by content and not typical device widths. I'm purely just talking about what size image to serve up when the min-width is X (just as in the CSS — mobile first & min-width up). This is where I'm unsure about what will get served up with Categorizr because what constitutes it's opinion of 'mobile' or 'tablet' etc?

As mentioned, my approach is to serve images which are roughly sized appropriately for the device type.

Ditto.

If someone's chosen to provide a "wrong" UA string, it's not my fault if they get the "wrong" media.

Ha, this is down to the manufacturers. Due to UA detection abuse in the past manufacturer's have been known to falsify information to circumvent any exclusions and has been one of the main reasons why UA detection has a bad reputation. In the case of RESS now however it's being used to enhance rather than exclude. In other cases manufacturers just don't distinguish. Although not really relevant in this particular discussion it appears the iPad Mini is undetectable which goes to highlight a lot of potential issues with UA detection.

When talking about server-side detection, the User Agent and/or device libraries, such as ScientiaMobile’s WURFL is the way to go. The User Agent thing is a mess and there is no simple rule to follow and, when a company like Apple decides to user the same User Agent for all devices, there is no server-side only solution that can help us.

—from above link

but I understand Brett Jankord is going to be around to deal with adding tablet, TV and desktop browsers. And it's open source, anyway.

I'm sure the intention is there but naturally with just one guy updating things it leaves a lot of reliance there when thinking about larger organisation such as ScientiaMobile. Updates wil naturally be quicker and assurances higher. Not meant as criticism but just down to numbers and not intent.

If some new desktop browser comes out and it's not detected by Device Categorizr as such (instead being categorised as a mobile), my CSS will still respond to the greater width of the viewport and give the proper "desktop" layout.

Totally. But the inappropriately sized media will no doubt still be an issue for clients. :)

I totally get where you're coming from though and I think I understand the purpose of Categorizr and Device Categorizr a lot better now. It's aimed to be much broader in it's categorisations for simplicity. In most cases I can imagine this fitting and in my current case I think I may be able to get this to work in combination with JIT images as you mentioned so I'll give it a go. If that fails I'll probably try to take a stab at a first Symphony extension in trying to get integration with WURFL or DeviceAtlas for feature detection rather than UA detection.

The bar is certainly raising for web developers these days. :)

what constitutes it's opinion of 'mobile' or 'tablet' etc?

Literally what type of device the visitor's device is - nothing more. Mobile phone = 'mobile'. No inferences of display size made - that would be down to you infer if you wish, based on project-specific considerations.

I'm sure the intention is there but naturally with just one guy updating things it leaves a lot of reliance there when thinking about larger organisation such as ScientiaMobile.

Anyone can fork if necessary. :-)

But the inappropriately sized media will no doubt still be an issue for clients. :)

The idea would be that the new unrecognised desktop browser would be added to Categorizr. In other words, not a long term issue. If you look at the source code, it's all very simple and easy to add to.

If that fails I'll probably try to take a stab at a first Symphony extension in trying to get integration with WURFL or DeviceAtlas for feature detection rather than UA detection.

I previously made a couple of attempts (look at all that lovely info - resolution_width/height and max_image_width/height!) at integrating with Handset Detection using its API, but I failed - my PHP isn't very good at all.

respondhd-abandoned

respondhd

I was just reminded that Handset Detection provides for geo-location which I may need on a project soon, so maybe I'll have another go!

Started to use the extension and ran into a few questions. I'm new at this so please let me know if I'm out in the weeds.

Initially I thought to use include or import to load device specific stylesheets depending on catagorizr. With xsl stylesheets import & include have to be top level nodes so they can't follow <xsl:choose> as a means to conditionally include/import. Using a variable name in the include/import statement is not allowed either.

Instead I did something like what's below. I'll probably end up using media queries eventually and group devices like tablet and phone together, but for now it's based on the README example:

<xsl:template match="/">
<xsl:choose>
    <xsl:when test="$device-categorizr='desktop'">
        <xsl:call-template name="desktop"/>
    </xsl:when>
    <xsl:when test="$device-categorizr='tv' or $device-categorizr='tablet'">
        <xsl:call-template name="tablet"/>
    </xsl:when>
    <xsl:otherwise>
        <xsl:call-template name="phone"/>
    </xsl:otherwise>
</xsl:choose>
</xsl:template>

Curious what others are doing, and/or if this is a bad idea? Maybe there's a better way? [edit: as I've got a little further it looks like more tests in other areas are almost certainly needed.]

Second, for phone & tablet I'm thinking of using HTML5 as that seems to be the 'thing to do'. Unfortunately <xsl:output> must also be a top level node. Which means there's no way to set the DOCTYPE based on browser sniffing in an extension. In other words I couldn't figure out how <xsl:output> could ever follow <xsl:choose>.

As a work-around I set the DOCTYPE to HTML5 style html vs. xml on a site-wide basis no matter what type of device it is. I ended up declaring it this way:

<xsl:output method="html"
    doctype-system="about:legacy-compat"
    omit-xml-declaration="yes"
    encoding="UTF-8"
    indent="yes" />

Which produces:

<!DOCTYPE html SYSTEM "about:legacy-compat">

I'm not sure if this is compatible with older browsers and it doesn't seem like a good idea. My thinking is to leave the desktop code as more compatible with older browsers for now while serving HTML5 to mobile devices (smartphones and tablets) which are likely to have newer browsers. Maybe that's not true? In any case I can't figure out how to do it.

Would appreciate any advice from the experts. Thanks a bunch for putting the extension together.

[PS: I edited my original post for clarity]

On your first point: I'm no XSLT expert, but as far as I know there's nothing wrong with using call-template to do what you're doing.

On your second point: I haven't tried to switch between "old" HTML and HTML5 using Device Categorizr. I'd be interested to hear more about how older phones cope with <!DOCTYPE html> and <!DOCTYPE html SYSTEM "about:legacy-compat"> and how you get on with doing this. If it looks necessary, maybe you could tweak the HTML5 Doctype extension so that it conditionally does its thing based on $device-categorizr.