The commercial model for software on devices is for Apps. That works great when an app matches the task you have, but falls down when you have to cross one or more apps. Android has made some progress in getting around this (intents); and iOS is starting to create corrals of apps (e.g. passbook); and Facebook has created the people-centric ‘Home’. Have we passed the peak of importance for apps, or is it the only viable commercial model?

Interface styles

Writing this on OSX, I count three main models of getting to things that I use:

• Websites (via a browser and short-cuts)
• Applications (via the dock or search)
• Files (via folders or search)

Appification

On iOS the primary way is apps, arranged in a grid on the home screen (springboard). This model has been very good for Apple and developers, and is much better than what was standard on smartphones before, but it does have limitations.

For example, moving data between applications can be painful. If I find something on a map, the options for doing something else with that are limited to what Apple decides, currently Facebook, Twitter, Mail or message. Android has gotten further with intents, which provides app developers an API for sharing things around.

However, it still doesn’t feel smooth and I don’t consider more complex tasks with a workflow (e.g. web development) even possible in this model.

Another pain point for apps is simply needing apps to do tasks. Why have an app for every single airline? The task is ‘show my ticket’, but you then need apps for Easyjet, BA, Ryan Air etc etc.

Scott Jenson is very persuasive on this topic:

It’s just not realistic to have an app for every store you go to, every product you own and every website you visit. This creates an ever increasing set that must be curated, organized and culled.

Apple’s passbook is an attempt to gather different providers under one app, but it hasn’t really taken off yet, at least not in the UK.

Other methods

When you look at the possible ways of using an operating system there are many organisational principles that are not generally used:

• Task, where software and storage are secondary to the task, such as updating a friends contact details.
• Object, where system objects (like your friends in Facebook’s home) are primary, and you have actions for them.
• Topic, where files and actions are grouped by topics (e.g. social, management, a project etc.). I remember this method from Jef Raskin, who thought this could be shown in a spacial way on desktops.
• Geographically, where actions become available depending on where you are. (See Scott Jenson’s Just-in-time interactions)

I’m not saying one of these is the best way, it’s likely to be a combination of these things will work best, and that combination will be different depending on your use-case, and will change over time.

Of these methods, the just-in-time interactions make the most sense to me as the next step. For example, you are in an airport and pull out your phone, your proximity to the Easyjet desk pops up the ticket for them. You can also imagine being at home, so all your home automation actions/apps appear. It could work by wifi and web services, GPS, bluetooth, NFC, or anything really, what matters to me is the interface.

Why still apps?

I started writing this post last year, but now seems like a good time to put a stake in the ground: I think we’ve seen the peak importance of applications on mobile devices.

Facebook has just launched ‘Home’, a people-centric interface on the top of Android OS. The Verge did a review, and see how Facebook has kept apps, but relegated them to a lower layer of the interface.

Windows Phone is a more content-oriented interface, surfacing information on the homescreen rather than making you open apps to see things. A small step but an interesting one, I like it.

Commercial model

Given all these options, why do Android and iOS still dominate with their app-lead approach?

Well, who would pay to create the inter-related functionality needed to provide a task, object or topic based interface? It would require a totally different system to be provided as part of the OS, and a level of integration between developers that is difficult to imagine, let alone co-ordinate. It lacks a commercial model to pay for it.

Not everyone is going to be enamoured with a Facebook interface, even if it is easier. However, it is difficult to see how an alternative comes into being without one company building the whole interface.

I think the most likely next step past the app-only model is to incorporate a proximity and/or geographical API (as Jenson envisioned), where certain actions/apps are promoted to the surface of your home screen by your proximity to a service.

A left-field option might be the web based Firefox OS, with an open-source ethos that could break out of the app-centric mold.

I’m also very intrigued to see what Apple do in iOS7, I suspect that will show what they consider the next direction.

I’ve been thinking about writing a post about this for a while, but I didn’t have the right visualisation. Unfortunately my design skills weren’t up to the task, but I just came across a great article from iA that demonstrates what I was thinking:

The article talks about typography being dependant on viewing distance, and at closer (typical) viewing distance the smaller text on the iPhone actually matches a desktop.

This is the same point I was making about CSS pixels: The unit manufacturers use to define how their browser renders website sizes.
For example, the iPad mini has a CSS pixel width of 768px (in portait), the same as the larger iPad with retina display, even though they are different sizes and different pixel densities.

What I would like to add is some Maths. (Or ‘Math’ if you’re from the US):

As the size of a CSS pixel is based on an angle, we can work out how far away the device should be held.

Working out the intended viewing distance was relatively straightforward, once I revised a little school level trig:

Putting that into a graph shows a smooth line, as you would expect from maths based on an angle:

So to answer the question in the title, you should hold the iPad mini 41cm away from your eye, and the large iPad 51cm.

Does that seem right to you?

What I noticed (given my recent experience) is how the screen ratios are starting to line up. You have:

• Apple devices lining up in the 3:4 (virtually all were used in portrait mode unless GA mis-reports that?)
• Traditional desktops at 4:3.
• Laptops (and probably some desktops) with 16:10 or 16:9 ratios in the 1280-1920 width range.
• Televisions or other monitors at HD size (1920×1080), this was mostly Windows (67%), some OSX (30%).
• iMacs at 2560×1440 (not an assumption – 98% of visits at that resolution were OSX).

The site in question had about 20% mobile device usage that month (as defined by GA), and is not technology focused. It is also worth noting that this is reported screen resolution, not viewport size (i.e. it doesn’t account for browser chrome or browser windows that are not full-screen).

I can’t help thinking that we should account for screen ratios in media queries in some way, but I’m not sure how yet.

From the article:

One would expect to see a device-width [for the iPad mini] more in line with those of similarly sized tablets like the BlackBerry PlayBook or second-generation Samsung Galaxy 7″—around 500 to 600 pixels, as shown in this chart.

However, the tablet comparison doesn’t seem to account for the difference screen size?

The width of the Nexus 7 is 3.75″ inches, and of the iPad mini is 4.75″. which is a multiplier of 1.267.

The CSS pixel width of the Nexus 7 is 600px (in Chrome), so how many pixels wide should the iPad mini be?

600px * 1.267 = 760px.

That isn’t very  different from what the iPad mini actually is: 768. I put up a test page and took a photo of them both at 16px, side by side:

Cropping down to just the text:

The snippet above is full size (from the camera), cropped to show the same bit of text side by side. The iPad is on the left, the Nexus 7 on the right. They seem the same size to me, although the Nexus’ high pixel density looks better.

Interestingly, I’ve been taking screenshots of the Nexus 7 on some test pages for a while, and Google have recently upped the default text size. At the (now) default 17px the text is slightly bigger:

But, that doesn’t affect when media queries will trigger, it just means text will take more space than expected.

It’s about the ratio

I’ve owned the Nexus 7 since it was released in the UK, and I like it, but I’m going to sell it because of the ratio.

The 16:9 ratio of the screen makes it either very tall (narrow columns) or a letterbox. It is great for movies, ok for reading books, but rubbish for websites. Reading websites matters to me more than movies.

Having played with the iPad mini I find the wider (4:3) screen more useful on websites, especially non-responsive ones. The picture below shows an BBC article. On the left I had double-tapped on the first paragraph, on the right the (default) mobile version on the Nexus 7.

In practice I’ve found text on the iPad mini is often bigger than the Nexus 7. The increased of text-size in Chrome helps, but I still find the narrow width in portait makes reading less optimal than a 4:3 screen, and navigating most websites is quicker at full size.

Another interesting point is that Firefox on the Nexus 7 uses a viewport width of 533px, making things appear larger. Perhaps we should consider that the iPad mini is smaller and lighter, and intended to be held more at phone-distance than laptop/iPad distance? The large iPad is actually more akin to laptops in terms of CSS pixels per inch.

So overall, I agree with the conclusion of the Alistapart article. However, the iPad mini has roughly the same CSS pixels per inch as similar devices like the Nexus 7, so perhaps they all need to decrease their viewport width?

EMs for layout

A recent example is an article by Steve Hickey on EMs for layout in my favourite web-design & dev magazine .net (ok, I may be biased as I also write for them!).

I struggle with the positive reasons for using EMs for layout though:

using pixels as a measurement unit messes up zooming for users who require it because it declares your font-size in units that are locked to a physical property of your screen.

That hasn’t been an issue since IE6, all browsers now default to a zoom mechanism which increases the size of all elements on the page. With the exception of a glaring Webkit bug, zoom and pixel-based media queries work very well for accessibility in IE and Firefox.

Also, what is wrong with using a unit that is a property of your screen?

As far as I can tell, browsers have to convert EMs (and other units) into CSS pixels anyway, so using EMs simply adds another layer of abstraction. It makes sense for managing CSS when relatively sizing your text, but not for layout.

it’s more theoretically pure to use ems for measuring type because it’s a typographic measurement, and if you’re already defining your content parameters in a typographic unit of measurement and proportion, it makes sense to apply the same idea across the rest of your layout as well.

It might be theoretically pure to use a typographic measurement for typography, but that doesn’t mean it transfers to layout. Making the layout relative to the device makes a lot more sense to me, i.e. percentages or pixels. That way the layout can flex to the resolution of the screen, whereas EMs may not be relative to the screen.

Hi PPI devices

Think about the difference between and iPhone 3 and iPhone 4 (“retina”) display. The iPhone 4 literally has 4 times the pixels (double height and double width) compared to the previous versions, making it a high PPI device.

If “a pixel is a pixel”, regular text would be unreadable. Therefore Apple doubles the width and height of everything on the screen, so it looks the same size (but sharper).

Engadget posted some pictures of the difference at the release of the iPhone 4:

In browser terms you do this using “CSS pixels”, where a CSS pixel can be bigger or smaller than the “device pixel”.

Talking about the future, Steve Hickey says we should move away from pixels:

instead of thinking in an abstract measurement system of device pixels, why don’t we just fall back to real-world measurements? And as luck would have it, we already have a basis for this system: points and ems.

But this misses a vital point about screen devices – variable viewing distance.

The W3C spec uses a CSS reference pixel to allow CSS pixels to vary by device based on viewing distance:

Without the abstraction layer of CSS pixels, text readable on your phone (e.g. 0.5cm high) would be unreadable on a desktop or TV device.

How many CSS pixels per inch?

I did a few tests to see what various devices would report as their CSS pixel-width. Then I divided the device pixel width by CSS pixel width to get the ratio. Then I divided the PPI by the ratio to get CSS pixels per inch (CSS PPI).

A lower CSS PPI will make page elements look bigger.

NB: If you have another device you’d like to add, please do check this page and tell me what the device is and the reported widths are.

You can see that small devices you hold close have a high CSS PPI, and large displays you view from a distance have a smaller CSS PPI. Also, despite the higher resolution of the Macbook Pro 15″ Retina, text is actually bigger on that screen than the 11″ Macbook Air.

I draw three conclusions from this table:

1. Devices in the same category can have wildly different device PPI. Therefore device pixels are not a useful measurement for web design.
2. The CSS PPI decreases relative to the assumed distance of viewing, and each class of device is within a certain range.
   Therefore CSS pixels are a useful relative unit across device types.
3. The device PPI does not map easily to the size of the CSS pixel on non-Apple devices. Apple uses a straightforward multiplier, but other devices do not.
   Therefore you cannot rely on images that use sizes under 1 CSS pixel.

With various devices out there (and TV possibly being an important one soon), browsers have to render the same content on a sliding scale of different sizes. A pixel is a relative unit, a building block, and it is a vital one so that content can be sized appropriately on different devices.

Be relative – use pixels (or percentages)

Using typographical units for layout works some degree at the moment because browsers convert them to CSS pixels. Using a real-world units like CM or picas would make content on larger screens impossible to read (or massive on small screens).

Using typographical units for some parts of layout (e.g. guttering, spacing between headings and paragraphs) makes sense in terms of managing your CSS rules.

For the main layout though, using a measure that is relative to the screen will work more effectively across devices. Percentages have been the traditional method of doing this, but when using media-queries (that work with pixel sizing), pixels can be just as effective.

Why go through the ‘math’ of converting pixels to EMs only to have the browser convert them back to CSS pixels?

Recently though, I have been puzzled by people suggesting that we should use EMs for layout, for two main reasons:

• Browsers translate EMs to pixels anyway, so why add a layer of abstraction?
• It is actually difficult for users to change the text size in browsers these days, so why do people think that EMs vary in a useful way?

In this article from Cloudfour on EM media queries, Lyza Gardner notes that the EM based media queries worked with zoom (in Webkit) and not with pixels.

However, that’s a bug in webkit. If you try the same in Firefox/IE/Opera, pixel based media queries work great with zoom. It just happens that a webkit bug for zooming EM based media queries has had some work, but not for pixels.

We noted that pixel measurement and divided it by the rough baseline of 16px to arrive at our em units. There may well be a better way to do this math, but this seems to do the trick so far.

If and when the bug in webkit is fixed, there would be no need for that maths, just note the pixel value!

Pixels (that is to say, CSS pixels) have always been a relative unit, but with new devices coming out that have higher (physical) pixel densities the relativeness is more obvious than ever.

There are some issues at the moment that can be worked around by using EMs, as shown in the Alistapart article. However, I think devices like the Kindle Fire are going to have to catch up and use CSS-pixels rather than hardware pixels. My Android phone does a great job of this, most websites have reasonable sized text and the site designers haven’t had to  jump through hoops.

Long term I bet that the pixel will be the most useful and consistent relative unit.

The people in the best position to decide what a (CSS) pixel should be on a device, are the people making the device. There are simply too many devices to test your website with; if web designers can’t rely on CSS pixels working across devices then those devices are going to loose out.

Device makers are going to have to make ‘normal’ sites readable and useful, so CSS pixels will need to be relative to the screen size rather than pixel density. This will be equally important on TV displays, where the resolution is quite high, but the distance from screen to eye is greater. So for TVs CSS pixels could vary by TV size even though they all have 1920 pixel wide resolutions (for HD screens).

Lets just make sure when we talk about pixels in web design, we are talking about CSS pixels.

Sidenote –  foreground pictures

Most things in web design scale to higher pixel-density displays nicely, for example, pixel sized text and css borders. Background images in the CSS can be adjusted with media queries, so you could have different background images depending on the pixel-density. (LukeW has some good resources on workarounds.)

Where the water is murkier is foreground pictures. We can scale down larger images with CSS, but that doesn’t affect the file size, so someone on a mobile connection might still get a 1MB image scaled down to 200px.

Something like Adaptive Images is probably the best solution to this at the moment, but I do wonder if it could be more automatic?

Progressive JPGs appear to offer a solution: You provide the biggest image as a progressive JPG (e.g. 3000px wide), and set the (CSS) pixels width in the HTML or CSS. The browser then downloads a sufficient amount of pixels to meet the device’s pixel density.

This thought was triggered by this example of photography on the iPad 3. However, to extend that idea, wouldn’t it be great if you could just use one image for every size from thumbnails up?

Having tried a quick test, unfortunately browsers (currently) download all the information, not just enough to fill the current size. Still, could it work? Is it worth considering?

A few things I learned from today…

From Cory Doctrow:

• Politicians struggle to regulate computers/networks in effective ways because computers are fundamentally flexible tools, you can’t restrict how they work without preventing them from working. (E.g. It’s like trying to regulate how a car works by changing the wheel.)
• Efforts to restrict the functions of computers always end up in software like root-kits. (E.g. the Sony rootkit they installed when people played CDs, or Nintendo’s methods of restricting content on their DS3.) I recommend checking out ‘What’s Inside the Box?‘, which questions who should be in control of the software running on computers you get into (e.g. cars), and those put into you (e.g. hearing aids).
• Efforts to restrict content end up in censorship. Part of his theme on “Censorship is inseparable from surveillance“, pre-internet preventing someone from buying a book could be handled at the publisher end of the equation. Now everyone can be a publisher, attempts to control copying mean checking every book you read.
• Software used for restricting internet access in schools is generally:
  • Ineffective, as kids routinely route around it.
  • Anti-education, as often teachers find resources they were going to use blocked.
  • Opaque, you cannot tell how it works. There is no central standard, so the black/white lists are either maintained by local sys-admins, or the company providing the software.
  • Provided by the same organisations supplying the countries we tend to think of as undemocratic.
• Copyright / copying is really only ‘level one’ of a war on general computing, as other industries will find these universal tools that run software hinder their business model. For example, 3D printers making small goods at the press of a button.

Should Digital Archives be open?

The presentations from Nick Poole and Ben White kicked off a couple of ideas, the issues seemed to focus around the institutions having missions centred around physical access, and not having the resources to digitise or share their resources effectively.

Reducing costs: I wonder what would happen if Libraries and Museums took a Seti/BitTorrent approach to distributing their digital resources? I.e. Allow interested people to install a programme that stores a tiny little bit of the site or resources. When requests are made through the central website, it proxies through to one or more people who are looking after the content. For larger resources it would make sense to use a protocol like BitTorrent so that it distributes the load over several computers/connections.

I could see people running that at home, and plenty of Universities would probably be happy to do that.

Making money: It seems the battle ground between institutions and the public is over the headline resources, the stuff people (in general) actually want to see. A win-win method might be to reverse what Pinboard did, which was to charge a little more for every subscriber to the service.

Institutions could charge a small fee for each item, but that fee decreases every time someone pays for it, becoming free after a certain amount of money has been raised.

That would take advantage of the long-tail of (mostly) Academics who would want to delve into niche areas, but the popular stuff would be free for all.

Defeating Acta

A great French duo treated us to a serious and funny couple of presentations, and although I didn’t follow it all, the politics involved are both intriguing and disturbing. At the very least Acta should be booted out because it’s trying to make legislation without going through the parliamentary process.

Realising the fight we’re in

Professor Lawrence Lessig is a very compelling speaker, and even though I’d seen some aspects of it before it was a great performance. It was one of those presentations where you won’t get much from just looking at the slides, so keep an eye out for the video on the ORG website soon.

The general argument was that copyright issues are important, but actually the core issue is the (over) influence of large business interests in the political system. A lot of the examples are from the US, but given that the same types of law are passed in the UK, there is something going on here as well.

Some of the points made me wonder about what type of organisations are best suited to different things. For example, the US has terrible broadband, and in many states they legally prevent citizen groups from providing their own. The for-profit science journals cost 9 times as much as not-for-profit organisations. In the UK we have better competition in mobile providers and much better deals than the US.

It seems that when dealing with a resource that cannot be competed with (e.g. cable broadband or the source material of journals) for-profit organisations seem to have the wrong incentives.

Where the aim is to provide a resource in a non-competitive situation, for-profit organisations are not effective.

Prison’s in the US are another recent example, where lobbyists for private prison companies are literally drafting laws that will put more people in prison, and they often get passed.

The undercover economist uses health insurance as an example of why a non-mandatory insurance will simply never work well for health care.

Back to Lessig’s presentation, and his core theme was that we need to attack the roots of the problem, which is how money affects politics. Although he didn’t mention it directly, I had already come across Rootstrikers, which outlines the plan.

TL;DR version

When your eye looks around a scene, it will automatically adapt to the differences in brightness. In photographic terms, your eye creates many ‘exposures’ as you look around a scene.

When you take a photograph at one exposure, it isn’t as adaptable so the contrast in a dark and bright scene is very harsh.

Therefore, an HDR pictures (multiple exposure combined into one) is more like what you would see than the ‘normal’ pictures.

However, like any effect, it can be taken too far.

Example

Wondering around Bristol last weekend, a saw the sun behind the main Cathedral, which is a pretty impressive building.

The ‘normal’ shot looks like this:

Ok, but nothing special. By normal, I just mean that I set the aperture to F5, and the camera took an average reading of the scene and decided on the exposure time. A lot of the time that means the sky gets washed out to white, as shown above. You can’t actually see the clouds that were there.

In this case, I took a bracketed shot, where you set the camera up to take three (or 5) shots. The first is the standard one, and then it takes an under-exposed version, and then an over-exposed version.

Those shots look like this, and you can see the sky properly in the middle one:

You then stick those shots into a programme like Photomatix or Photoshop and it blends them together to even out the exposure.

A lot of HDR looks rather fake, but the default isn’t necessarily unnatural looking:

The sky is a bit blue and the clouds a bit yellow, but you could handle that with any photo-editor.

You can also go mental with it, and you’ll see a few shots like this around:

However, if you aren’t so heavy handed, I quite like this version, especially at full size (click through for that):

For me, that is closer to what I was seeing, because at the time, my eye would flick to the building and I could see the details, and then flick to the sky and not see a washed-out white thing.

People, sky and water are not easy to capture with HDR, but it has found a place in my arsenal. If you are interested in HDR photography, I recommend checking out Trey Ratcliff’s StuckinCustoms. Apart from using Pixelmator instead of Photoshop (which I can’t use to save my life), I learned about HDR from his site.

I’ve noticed a bug in Webkit browsers (Chrome and Safari) that impacts accessibility: Zooming in does not trigger media queries.

To show the effect, take a recent responsive design such as the Boston Globe and zoom in. In Firefox, Internet Explorer or Opera and it behaves how I expected, the media-queries trigger and the layout adapts:

However, when you try the same thing with Chrome or Safari, the zoom works (text and images get bigger), but all within the same layout:

NB: I think it is around 200% zoom, but it may be a little off.

It gets even more obvious when you scroll down, as you have huge text in narrow columns.

Accessibility

It looks like a bug, but you might be asking what effect that has on accessibility? The main impact is on people with mild to moderate visual impairment who use browser controls to increase the visibility of websites.

The browser landscape has changed a lot in the last few years, including how browsers zoom. In ye-olde days most browsers allowed you to increase the text size. Now the default method across virtually all browsers is to “zoom”, which increases the size of everything.

Zoom works well for people who need things a bit bigger unless you immediately get horizontal scrolling. That is why responsive designs (which re-flows the layout at smaller resolutions) work well for zooming, because the layout adapts to the available width.

What is a zoomed pixel?

I don’t know what the root cause is, however, from a front-end development point of view it is as though Firefox and Internet Explorer increase the effective pixel size, so when you zoom in there are less pixels in the same area. Webkit does not seem to take the same approach.

It is not event-related, as reloading the page does not trigger the media queries (except the edge-case described below). Overall it is very odd, because the reported pixel size of the window does change, at least for JavaScript (test example).

Mobile Webkit uses a different style of zooming, as when you ‘zoom in’ the window stays the same, but your view zooms in without affecting the layout. I wonder if this is a conflicting method?

Another oddity is the difference when using EMs. I created a simple test case of max-width media queries in pixels and EMs. If you zoom in so the page reports less than 500px of width, neither triggers. However, if you then refresh the page, the EM based query (only) does trigger. Bizarre, but another facet to the bug(s).

I suspect that Google is aware of some issues to do with this, otherwise you wouldn’t get a red-banner warning if you zoom in on a Google Doc:

It might not affect many people at the moment (although that is debatable), but Chrome is rapidly gathering market share, so either it will affect people or it reduces Webkit browsers usefulness on the desktop.

I’m not in the Webkit browser world, so my question is: where’s the best place to report this?

Good points, and I certainly agree with not using HTML5 as the umbrella term.

However, I’m not sure Jeremy’s point that we didn’t need a catch-all term for “HTML4.01 plus JavaScript” is going to help. (We did have DHTML as an umbrella term. Ok, that is a tarnished example, but my point is that people still remember the acronym.).

Presumably the aim of the logo is to let (non-developers) know that a site is built with a certain set of technologies?

So the next question is: What should the umbrella term be?

I believe Eric Meyer has been using “Open web stack”, which is accurate and works with developers. However, I think we need something a little shorter and snappier (preferably an acronym of 6 letters or less that can be pronounced easily. Like AJAX.).

Something that combines W3C, open, web… the WOW stack? Maybe not, any other ideas?

We need something else, or HTML5 will become entrenched as the umbrella term.