Produxion

The personal weblog of Phil Powell

What If the iPad Magazine is Already Obsolete?

There seems to be a lot of coverage around the subject of magazine apps, and I found another couple of interesting articles. In one of his recent posts, Mathew Ingram considers the failings of the “walled garden” approach being taken by most publishers:

The biggest flaw for me is the total lack of acknowledgment that the device this content appears on is part of the Internet, and therefore it is possible to connect the content to other places with more information about a topic, or related material of any kind, let alone any kind of social features that allow readers to share the content with their friends. Some magazines have made some tentative steps in this direction, but so far they are few and far between. Meanwhile, Flipboard and Pulse have taken Twitter and Facebook and RSS and turned them into magazines — and much more appealing ones in many ways.

Navneet Alang goes one step further and questions the relevance of editorial magazines in the online space:

But another necessary question is this: What is the magazine? After all, other than its physical dimensions, what unites People, The New Yorker or Tennis? What really seems to unite a magazine into a coherent whole isn’t subject matter. The same magazine could contain a column on politics and a recipe. No, what turns a magazine into a single entity with a name is editorial focus: what the overarching purpose of the magazine is. It’s the idea of a magazine as a single editorial entity that makes it work.

But here’s the problem: the web allows you to collect and gather your own content from many many different sources, putting together your own set of things to read based on your interests and desires and social network. It is the opposite of a magazine. Instead of one entity providing all the coverage on a given topic, the web allows you to cull from multiple sources to put together your own collection of things you’re interested in.

Rethinking the Mobile Web

Fascinating stuff at yiibu, where they are questioning the traditional approach to mobile web development:

While this approach may be considered entirely sensible to the majority of folks in the mobile world, this isn’t necessarily the case for those coming from the more traditional (aka desktop) web world. The current approach can be so confusing, frustrating and discouraging that it’s no surprise desktop web developers ultimately focus on optimising their sites for just one device – the iPhone.

I think this rings true: I think most web shops consider optimising a site for iPhone is the same as optimising for the whole mobile ecosystem.

Given all of this, we began to wonder if it was now time to rethink the way we’ve been designing mobile websites. Could there be a straight-forward approach, simply building upon existing knowledge, rather than requiring designers and developers to learn entirely new and unique methods of working–specifically for the mobile web?

As a result of this, they’ve developed a site which acts as a proof of concept for the ideas and concepts they’re developing, which is explained in much more detail. They’ve also colelcted together a phenomenal amount of mobile reference materials and resources.

The 1Kb CSS Grid

I’m a bit late to the table with this one, but worth noting nonetheless. The 1Kb CSS Grid is a super-lightweight CSS grid system:

Other CSS frameworks try to do everything—grid system, style reset, basic typography, form styles. But complex systems are, well, complex.

Tyler Tate elaborates in the first of a series of posts:

With added complexity comes… well, complexity: a steeper learning curve, increased development time, and — cringe — tougher debugging.

Here is a fresh take on the CSS grid (loosely based on Nathan Smith’s 960 Grid System). Its mission is to be lightweight.

Is the iPad Really the Savior of the Newspaper Industry?

In-depth analysis from Mashable about the current state of newspaper applications for mobile devices. There’s nothing conclusive in the article, but it does include some interesting tidbits and some startling facts and figures:

The Harrison Group survey found that tablet users spend nearly 75% more time reading newspapers and newspaper articles, and 25% more time reading books. Those surveyed were apparently so convinced by the digital delivery and form factor, that 81% of tablet owners believe that it is inevitable that all forms of publications will eventually be produced almost exclusively in a digital format.

Those are some pretty compelling and encouraging numbers for content creators. So why are so many of the current apps failing to make the grade?

After looking at a variety of newspaper iPad apps, our main complaint — and we’re generalizing across the entire market — is that they don’t take enough advantage of the iPad’s wowing capabilities.

Uh-oh.

The solution could be found in a new “hybrid newspaper app” suggests Fidler, in which “automated sections with continuously updated news stories and more visually rich magazine-like sections created by editors and designers could coexist.” The Reynolds Journalism Institute is experimenting with exactly that kind of new publishing model.

The NAA also acknowledges the need for newspapers to “differentiate” content, and digital strategist Levitz says that consumers read longer-form content on the iPad, and they really enjoy the high quality of the visual images on the screen. She thinks newspapers can thrive in the tablet space if they take advantage of the device’s capabilities.

So essentially, what’s being said here is “people like pretty pictures and clicky, whizzy, shiny things.” This is where so many publishers and analysts seem to be missing the point. The IPad’s wow factors aren’t it’s ability to show high-quality imagery, nor it’s slick animations. The iPad’s wow factors are it’s pick-up-ability, it’s tactile and responsive interface, it’s ability to connect your offline world seamlessly with your online world.

So many newspaper publishers got it so wrong when they tried to transition from print to the web. They failed to innovate; failed to adapt their business models; failed to see the value in their content and the power of their readers. Amid that disruption, they appear to be about to make the same mistakes again: failing to innovate, failing to adapt; failing to realise that their content has become even more valuable, and their readers ever more powerful.

iPad as the new Flash

Jeffrey Zeldman compares the trend for creating novelty interfaces in publication apps to the bad old days when Flash spawned a million bad interface designs. He also succinctly picks up on an important point as to why web standards are so important:

Everything we’ve learned in the past decade about preferring open standards to proprietary platforms and user-focused interfaces to masturbatory ones is forgotten as designers and publishers once again scramble to create novelty interfaces no one but them cares about.

While some of this will lead to useful innovation, particularly in the area of gestural interfaces, that same innovation can just as readily be accomplished on websites built with HTML, CSS, and JavaScript—and the advantage of creating websites instead of iPad apps is that websites work for everyone, on browsers and devices at all price points. That, after all, is the point of the web. It’s the point of web standards and progressive enhancement.

There’s also some really good discussion to be found in the comments. But Zeldman nails the case for why this kind of stuff makes bad business sense for magazine publishers:

Unless your organization’s business model includes turning a profit by hiring redundant, competing teams, “Write once, publish everywhere” makes more economic sense than “Write once, publish to iPad. Write again, publish to Kindle. Write again, publish to some other device.”

End hover abuse now

Cennydd Bowles speaks out on the trend of using hover states in web interaction:

Designers who pop up information panels or move page elements on hover are using flawed logic, second-guessing what users want to do before they do it. The result, which I’ve seen in countless usability tests, is that users activate these controls accidentally. You know what happens? People actually flinch: “What was that?” They return with hesitation, less confident in their understanding of the site. It’s no accident that the Twitter worm propagated through hover— accidental activation meant users spread the worm unintentionally.

He makes a good point, particularly in a time when hover states are becoming a less reliable feature anyway, as the onset of touch devices makes hovering a non-entity.

Trent Walton has written a really useful and informative article about this subject:

As designers, we’ve turned to hover states to accommodate extra content and allow visual aesthetics to trump usability. Like it or not, those days are over and the interactions we design are going to have to stand on their own two feet.

jQuery AppMenu

A Mac-style Alt+Tab menu, implemented with jQuery:

AppMenu takes the default cmd+tab functionality on the Apple Mac and imitates it almost exactly on a website, instead using alt+tab (oroption+tab).

Not entirely sure of where this could be used in the real world – this kind of thing needs to be universal to be any use – but a really nice implementation nonetheless. A great example of what can be done with keyboard navigation.

The lack of URL referrers in Twitter links

Tim Bray offers up his thoughts about the lack of URL referrer info after one of his posts went viral:

I’ve now tested a couple of hypotheses, and I’m pretty sure the answer is: Twitter clients. At least, I’ve verified that for two different Twitter clients, one on Mac and one on Android, when they wake up a browser to follow a link, there’s no referer.

This could be because the URL shorteners are getting in the way. It could be because the API you use to send the default browser after a URL doesn’t have a slot for “referer”. I could investigate, but I bet someone who’s reading this knows.

This is a problem. If someone follows a link in one of my tweets, I think whoever owns that URL is owed the information that they came from http://twitter.com/timbray. It’s not that there’s no referer; it’s that the information is being discarded.

It’s an annoyance, yes, but I’m not entirely sure I agree with his assertion that anybody is “owed” referrer information: it’s nice to have, but it shouldn’t be a given. This is just how HTTP works. If a URL is referenced by another URL, then referrer info might be expected, but a direct link from an application: I’m not so sure. If I click on a link in an email, I certainly wouldn’t expect there to be any referrer data passed (although it seems quite a few webmail clients do!)

Seems that we’ve kind of become analytics junkies; we “expect” voluntary referrer meta data to be provided, and want to know everything we can about people who visit our content. This commenter sums it up for me:

I am slightly baffled that nobody here seems to think that this is how it is supposed to work. First and foremost I am considering it an issue of privacy and data hygiene. On the technical side, if I am getting to this URL through some other means than clicking on a link in my browser, I certainly don’t expect a Referrer URL to show in my request.

H.264 as MP4 with Compressor

I came across a slight bottleneck when trying to export some video with Compressor this morning. It seems that compressing footage as a native .mp4 file for web streaming isn’t straightforward.

I found a workaround after doing some searching, but since this would seem to be such a common task, I thought it would be worth briefly writing up here.

I needed to create a video file ready for streaming through a Flash video player, with the following specification:

  • Codec: H.264
  • Dimensions: 640 x 360
  • Bitrate: 700kb/s

Now, creating a preset for this is a cinch: it’s just a straightforward case of using a Quicktime preset, and then customising the settings appropriately. Using Compressor’s built-in MPEG-4 file type isn’t an option because it doesn’t provide control over important settings like the codec.

The problem with using this type of Quicktime preset though, is that there’s no way to override the type of file you’re going to get: no matter what settings you use, you’ll always get a Quicktime .mov file, which is no use in this situation (I’m not trying to create a file ready for upload to Vimeo or Youtube – I’m creating a file ready for streaming through a custom Flash player).

There doesn’t appear to be a way to get around this in Compressor, but I did find this handy little workaround which uses Quicktime Player to re-export the file.

Note that to do this, you’ll need to have the original Quicktime Player 7 installed – this won’t work with the new Quicktime X, which is badly crippled when it comes to doing any serious file-wrangling. If you’re running Snow Leopard, you can easily install the old version of Quicktime by following these instructions.

After creating a H.264 .mov file from Compressor, you just need to do this:

  1. Open the file in Quicktime 7
  2. Got to File ➝ Export…
  3. Select Movie to MPEG-4
  4. Click on Options
  5. In the Video tab, under the Video Format drop-down, choose “Pass through”

This will quickly do an export of the video file without re-compressing it - it’s just re-containing the video stream in a valid MPEG-4 container.

I’d really love to be able to do this in Compressor, without the need for this extra step – but until I figure out how to do that, this is the next best thing.

Keys.css

Keys.css is a really simple and elegant stylesheet from Michael Hüneburg for rendering beautiful keyboard-style elements. Compatible with all modern browsers, and degrades gracefully in older ones.

Top job! And no horrible font-wrangling or images in sight.