Archive for the ‘Mobile’ Category

Publishers aren’t learning from the web

Oliver Bothwell ponders the current state of publication apps on tablets, concluding that publishers just aren’t learning lessons from the web:

And now it is quite easy to see why the media apps are failing. They are all difficult to navigate requiring too many swipes, flicks and scrolls to find things. Eureka has a lovely opening navigation and the magazines have contents pages but where are the search bars? Have they learnt nothing from the web? Where are the related articles, tags and comments. They are not taking advantage of the fundamental tools available to them. Instead they are creating gimmicky apps without any real substance. Media companies are changing but without realising what is their best asset, their quality journalism and ability to edit, which they sacrifice to fads and pointless interactive content. Newspaper and magazine sales are down because the internet allows easy consumption and access to lots of information; the only way to start making money is by championing this in their apps and combining with excellent user-interface and editorial design. At the moment there isn’t an app which is better to use than the newspaper or website equivalent and this should be worrying to an ailing industry. The approach is entirely wrong; it is not the content that is the problem, it’s the way it’s being presented.

I’ve, personally, yet to find a media app which feels “right” — even the very popular and innovative Flipboard doesn’t fit the bill, for the may of the reasons that Oliver flags up: too many swipes, no way to effectively filter and search.

Native iPad accessibility: is it enough?

I’m writing this on a shiny new iPad, having finally made the leap from laptop to tablet. I’m finding the experience generally wonderful & it’s certainly proving a much more comfortable and convenient way to navigate online spaces. I’ve yet to really get to grips with using the keyboard for any serious amounts of writing – touch typing is a while new learning curve – but I think practice will make perfect in the department.

One of the reasons I was keen to give this device a proper road test was to explore the accessibility features. I need to work up close a lot of the time and regularly use the built-in zoom tool on my desktop and notebook Macs. I also tend to vary the screen brightness depending on the task at hand and the lighting conditions. So seeing how I could adapt my iPad experience to make it as comfortable as I could was top of my priority list.

Being able to selectively zoom the whole screen using simple three finger gestures is great, and is a welcome complement to the two finger pinch-and-zoom functionality found in Mobile Safari. And being to invert the screen colours can be a helpful aid when contrast is making my reading or writing experience uncomfortable or tirimg.

Here’s an example to help you understand what I mean.

I’m currently writing this with the WordPress iPad app, which would ordinarily look like this:

The WordPress iPad app as it appears by default

I’ve tweaked the UI though, by switching to “White on black” through the accessibility settings – so my screen actually looks like this:

The WordPress iPad app, with the native "White on black" setting activated

It’s a simple, but really useful feature, which eases the strain on my eyes and makes for a more productive and comfortable experience. It’s not perfect though: the setting simply applies a filter to the whole screen to invert all colours. So although black on white, or greyscale interface elements like the keyboard translate well, the contrast of other UI elements is actually reduced. Just compare the “Save” and “Publish” buttons in the top of those previous screenshots for an example of what I mean.

These little quibbles are bearable when it’s just text-related content, but it becomes a very disorienting experience when it comes to using apps which feature more graphical and illustrative elements. Browsing my Twitter stream, as an example, shows everybody’s avatars in a strange, inverted x-ray fashion:

The iPad Twitter app, with the native "White on black" setting activated

Notice too that because the whole screen is inverted, the subdued dark background which frames the central stream is now hemmed in by two large zaps of light, which detract from the high contrast of the main content.

Page zooming is also great in many situations, but starts to have failings when it comes to creating content, as opposed to just consuming it. Using the WordPress app as an example again, the very clever screen zooming can start to prove cumbersome. The default text size in the app is pretty small, and can’t be changed. Ideally, I’d prefer to be able to zoom in on it while I type – look what happens though:

The WordPress iPad app using the native Zoom controls

Because the entire screen has been enlarged, the keyboard is now practically unusable. So, I just have to guess-type and proofread later on.

Of course, these are just restrictions of these particular assistive tools, and I’m trying to push them beyond what they were designed for. They’re assistive, and can’t be expected to fix the varied needs of different users for every application – one size doesn’t fit all.

But I think it does highlight the number of mainstream apps which are being developed without the consideration of simple, adaptive accessibility features.

Perhaps that’s because Apple have done such a good job of implementing OS-level accessibility: developers don’t see the need to worry about it, safe in the knowledge that at least a basic level of access will be baked right in. I also suspect that in some cases, it’s due to a certain amount of preciousness over pixel-perfect design treatments (and if you remember the terrible trend for pixel fonts on the web at the turn of the century, you’ll know just what kind of route to hell that can lead you down).

But I think it’s important for developers of these apps to consider extra features which allow users to adapt their experience to suit their particular needs or preferences. Simple things like allowing users to choose text sizes, change colour palettes, adjust white space and remove clutter are all simple and effective ways to allow more granular control, enabling the user to adapt their experience so that it’s more comfortable and enjoyable.

Twiiter for iPad is just one example of an app which could quite easily be improved in this respect. Twitter for iPhone allows me to change the font size for tweets throughout the app; but the iPad app is missing that feature, and I would really like to have it. It wouldn’t compromise the design of the app, but with that one simple feature, it would allow me to enhance my experience while using the app.

This post was prompted by the fact that I was considering a purchase of the iA’s Writer app, which is an absolutely awesome distraction-free writing application: simple, elegant and impeccably designed. But when I was trying to find out more about it, I noticed that all of the screenshots showed black text on a White background. I wanted to know if the app supported a setting for white text on black – I really don’t want to spend lengthy periods of time staring at so much whiteness.

Turns out that it doesn’t have that feature, but I bought it anyway because I can use the “white on black” setting built in to the OS – despite it’s annoyances.

But why not include that feature? Why should I have to use generic assistive features when more granular, app-specific settings would do a much better job? The lack of this kind of feature was almost a deal-breaker for me, but when I considered the alternatives, I decided that iA Writer was best-suited to my approach to working, even with the clunky white-on-black compromise.

But I think that summarises my point quite nicely: why compromise? Despite all of it’s little idiosyncrasies and faults, The iPad is a wonderful, enabling device. But I wonder if a lack of imagination amongst the developers of its apps might be stifling that enabling power for a huge number of people looking for a more assistive experience?

Notes

  1. I’m not singling out the iA Writer app for criticism here – I think it’s a wonderful application. I’m just using it as a real-world example of where I’ve had a desire for a feature which would improve my personal experience of their product. And the iA team were very forthcoming with feedback when I contacted them about it on Twitter.
  2. While writing this post, I found that the WordPress app was just too cumbersome and buggy for serious writing, and so switched over to using the iA Writer app in earnest instead. It proved a much more comfortable experience, and the default font size is just perfect for my needs: not too small, not too large. The distraction-free approach really does suit the iPad’s form factor and will prove to be particularly beneficial for many disabled users who are overwhelmed by the usual breed of text editors.
  3. As I’ve written previously, when considering accessibility features, it’s not just disabled users who benefit. Thinking of accessibility as something which only helps people with disabilities is very misguided.

Developers don’t rush to new platforms

Great analysis from Marco Arment about the misconception that developers will instantly flock to a new platform:

A common fallacy is assuming that any new platform in an exciting market — recently, smartphones and tablet computers — will be flooded with developers as soon as it’s released, as if developers are just waiting outside the gates, hungrily waiting to storm in.

In two recent cases, that’s exactly what happened: the iPhone and the iPad. (And probably the Mac App Store next.) So important people, including the tech press, consumers, and many hardware manufacturers themselves, assume that every new hardware platform will be greeted with the same rush of high-quality software.

It’s really worth reading the full article, which proposes that the iPhone and iPad development ecosystem is thriving so much for three reasons: dogfooding, install base and profitability. And he concludes with this question:

Now, consider this fall’s tablet computers. Can you say with confidence thatany of them will address these three needs well enough, and for enough developers, to ensure a steady supply of quality software?

A hint at Facebook’s plans for tablets

Ben Parr summarises his opportunity to quiz Facebook CEO Mark Zuckerberg and Mobile VP Erik Tseng on Facebook’s plans for the iPad:

After a bit more back-and-forth between Zuckerberg and me, Tseng stepped in to explain that Facebook is still trying to figure out its approach and strategy for tablet devices. Because tablets are a new form factor, it requires a new approach.

The real hint to Facebook’s iPad plans, though, is that Tseng focused on the form factor and not iOS. This could mean that Facebook’s looking to build an HTML5 version of its website optimized for tablets. At the very least, Facebook seems intent on keeping a consistent experience across all tablet devices.

What’s most telling though, is Zuckerberg’s response when asked about the iPad at a mobile press event:

iPad’s not mobile. Next question.

Microsoft’s strategy for Silverlight has shifted

Unlike Adobe, Microsoft seem to be understanding that HTML5 is the only true cross-platform solution:

When Microsoft first showed off Internet Explorer 9, its most HTML 5 compliant version of IE to date, in March of this year, questions began to arise about the company’s commitment to Silverlight. Officials insisted that the two would coexist and that Silverlight would be Microsoft’s cross-platform development platform for mobile, Web and PC platforms for a number of years to come, as HTML 5 was far from becoming an accepted standard.

But in the past few months, Microsoft’s backing of HTML 5 has gotten more aggressive. Microsoft is pushing HTML 5 as the way developers can make their Web sites look more like apps.

This is a smart move by Microsoft: they can continue to develop Silverlight as a development platform for Windows Phone, whilst encouraging developers to create cross-platform applications with HTMl5 – best of both worlds, and it won’t cost them anything.

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.

Flash is not a de facto standard technology

John Gruber continues to hammer home the reasons why Apple’s abandonment of Flash on mobile and touch devices is a good thing for web standards:

If no one releases a popular web browsing platform that lacks Flash support, then web sites that already publish Flash content are never going to move away from it. I think the web would be a far better place without Flash, or, at least, with Flash relegated to a position like that of Java applets: there if you want it, but not a major foundation.

Flash is never going to decrease in popularity so long as all web browsers support it. Flash might decrease in popularity because of iOS. If you believe that Flash’s current position as a de facto standard technology is harmful to the web, then users — not just iOS users but everyone using the web — would benefit if that happens.

I don’t think Flash is quite as evil as some commentators make out – it can be a powerful tool. But I agree that it needs to be repositioned: less as a standard web technology, and more as a bespoke application platform. So much of the stuff people use Flash for can now be achieved almost effortlessly with modern Javascript frameworks and clever use of CSS. I’ve yet to see a practical example of where Flash could be applied to applications on a mobile device.

Motorola acquires 280 North. But why?

280 North wowed people with the creation of their web application framework Cappuccino, which is built on an impressive new programming language, Objective-J. The whole framework is modelled on desktop development with Objective-C for Mac OS X, and it can do some pretty amazing stuff – it’s like Cocoa but for the web.

Techcrunch report that 280 North has been acquired by Motorola for a whopping $20 million, quoting a Motorola spokesperson:

“I can confirm that Motorola acquired 280 North earlier this summer. The transaction provides Motorola with specialized web-app engineering talent and technology that will help facilitate the continued expansion of Motorola’s application ecosystem. We believe 280 North will be instrumental in helping us continue to foster the Android ecosystem with innovative web-based technologies and applications.”

I really don’t understand the logic behind this acquisition, and suspect it could mean the end of the great open-source work that 280 North have done.

  1. Motorola are committed to developing for the Android platform, so why acquire technology which is so intrinsically tied to the Mac platform? Objective-J is essentially a webified version of Objective-C; the look-and-feel of Cappuccino’s UI elements are based on the Mac UI, and the development tools feel just like Mac apps.
  2. Cappuccino’s aim was to bring the ease of developing desktop applications to the web: it’s about creating web applications which feel like desktop applications. Motorola have very firmly positioned themselves in the mobile market, so why the interest in web applications which feel like desktop applications? Even if they are branching out into the development of tablet devices for the home, surely it makes sense to develop technology for a touch UI? Touch is not what Cappuccino is about – Sproutcore is way ahead of the game in this area.

I’m ready to be proven wrong, but this seems like a knee-jerk acquisition. This isn’t about acquiring 280 North as a viable company, or Cappuccino as a platform for further development – it’s about acquiring the clever brains behind this web app framework for Motorola’s bespoke purposes. It’s right there in that Motorola statement: “the transaction provides Motorola with specialized web-app engineering talent”.

Announcing the jQuery Mobile Project

John Resig on the forthcoming jQuery mobile project:

The jQuery project is really excited to announce the work that we’ve been doing to bring jQuery to mobile devices. Not only is the core jQuery library being improved to work across all of the major mobile platforms, but we’re also working to release a complete, unified, mobile UI framework.

This looks great, and with a track record of delivering solid, well-documented code, this is going to be a welcome addition to the jQuery family. A unified approach to mobile web UI is desperately needed, and sounds like they are going to be targeting a wide range of platforms:

The critical difference with our approach is the wide variety of mobile browsers we’re targeting with jQuery Mobile. We’ve been working hard at bringing jQuery support to all mobile browsers that are sufficiently-capable and have at least a nominal amount of market share. In this way we’re treating mobile web browsers exactly how we treat desktop web browsers.

And, they’re approaching the visual design in a good way: talking in terms of “design language”:

From a design perspective, we have a unique challenge because we need a universal design system that will feel “right” on a broad range of devices instead of directly mimicking the design style of a particular platform.

To that end, we aim to synthesize a touch-friendly design language that can work well across a range of form factors from smartphone to tablet and a range of mobile platforms. A new ThemeRoller tool will be developed that will allow designers and developers to quickly design a custom theme that fits their color scheme and style to make a highly branded experience possible across all devices and browsers.

It’s worth reading the entire strategy statement.