Please read Alex’s original post, if you haven’t. What follows are some thoughts in response to his post.
These are all native OS X apps:
I also think they all fly in the face of UX consistency within a system GUI, which I think is one of the things people bitch about with non-native apps.
The definition of “native” is really fuzzy here. it seems like you mean “uses the GUI toolkit that ships with the OS.” By this definition, though, I’d argue that many popular OS X apps are not “native,” even though they’re Cocoa apps. On Linux, Gnome and KDE apps are both “native,” but they certainly don’t look the same.
Some of your examples of people wanting native apps are people simply liking an app better because it’s designed better, and provides a consistent aesthetic with the rest of their desktop. That can and is often accomplished independent of the SDK you use. “Native” is not in any way synonymous with “better,” but lots of people toss it out there as if the argument is so obvious, it needs not be explained. It’s a lot like saying “it scales.”
Cross platform and “native” aren’t necessarily mutually exclusive. It’s harder, yes, but not impossible. there are tons of variables involved, and I think you’re oversimplifying a pretty complex problem.
Cross platform is not, by definition, user-hostile. It can be harder to file off the rough edges, depending on the dev platform and the application, but I think that’s a matter of UX effort.
IME, “Native” UIs matter way less to users on mobile. Like, unless it looks like a fucking turd and totally nonfunctional, most users don’t care. Is it relatively smooth to navigate? Bonus. Spaz webOS is, from what I can tell, probably the most popular Twitter client on webOS. Why? Because it’s free. You know how many of my users have praised it for using “native” widgets, for the most part? Like 4, and they are all ultranerds.
Many (most?) of the AIR apps I’ve seen really should just be web apps, because there’s no great benefit to them being desktop apps.
Why are we okay with using some web apps if it’s such a huge issue? I prefer to use Gmail’s web interface, for example, and I prefer to use Google Reader in a SSB — although with a custom theme. Is it just that my expectations are different?
I think for many teams, like the one you mention, the choices are probably these (pick one):
Which do you choose? I guarantee you that for a company like Pandora, it does not make financial sense to do native Windows and OS X clients. Folks who 1. care and 2. would pay are grey-bearded unicorns in the grand scheme of things.
So why don’t devs want to do native apps? I’d argue it’s because it’s too hard, especially when you need to support multiple platforms with widely varying capabilities. If you want better integration with the rest of the devices, make it easier for the people driving new app dev to do so. Asking them to jump from JavaScript to ObjC is not something most will swallow, and the trend is not going to reverse back to devs doing lower-level coding. Some types of applications will always require it, but many (most!) won’t. A high-level language like JavaScript (especially with the work that’s been done to speed it up) with hooks into a fast GUI toolkit (not the DOM) is, I believe, where we should be headed.
<li class="comment">
<a name="7476" class="comment-id anchor"></a>
<div class="comment-author">Nick Carter</div>
<div class="comment-author-url">http://thynctank.com</div>
<div class="comment-date">01/18/2011 12:46:40 PM</div>
<div class="comment-body"><p>Finally got around to reading both of these posts. Or at least Alex’s edited post. Parts of his post speaks to the UX snob in me, and this post mostly to the pragmatist, both from a dev and a user perspective. I think overall performance and those consistent keyboard shortcuts are super-important, way moreso than consistent-looking widgets. But that’s just me.</p>I do think AIR in particular has its annoyances, particularly the two-step install and confusingly separate runtime. Most users won’t understand or care about this space/bandwidth-saving maneuver at all, they just know it’s odd. Likewise, the need to sign apps with expensive certs or face warning dialogs presented to your users is a real shame, particularly when OSS could (did?) have so much to do with the uptake of AIR in the first place.
Titanium is a step in the right direction, with the ability to package the runtime with the app, greater entrenchment in terms of system access, and on mobile, those native widgets (dubious though their importance may be).
So long as developers can present the important bits of an application in such a way as to please their most important/abundant consumers, everything else - consistent UI, toolchains and languages all - is absolutely unimportant.
</ul>
Huawei could definitely have done better than the appalling client they rebadged for telcos, considering the millions of units sold. (At the most trivial level, the version I have was shipped with log4j debug settings left on, let alone the higher level problems). I don’t think Java was to blame, so much as a symptom - of aiming low - and achieving your goal.
The other problem is when developers clearly just don’t get that there are standard keyboard shortcuts people expect to use. I can’t recall what it is, but there is one program I have that doesn’t offer a keyboard shortcut for quit. That’s ‘user-hostile’ in my book, but I don’t think it’s intentional, so much as born out of ignorance. And that’s as true for Windows native applications as anything else – in the 2 decades I’ve been doing commercial development, I don’t think I’ve ever seen a company give any formal training in those aspects of development, or into a test plan.
You are probably right that on mobile this may not be an issue - but I think that’s largely because there isn’t yet a consistent vocabulary that users are used to.
(Although I can think of one example - someone developing x-platform native clients for iOS and Android, but who only understands iOS, may miss the possibilities of the application-as-a-service architecture in Android, being used to application-as-a-silo).
It’s certainly an issue with web apps – I completely surprised a colleague of mine by dragging-and-dropping within a Flex application, because he didn’t know you could do it, and he’d ‘trained’ himself not to drag’n’drop inside the browser window. People don’t expect keyboard shortcuts in web apps either, especially where the logical key has a browser level meaning. How should CTRL-A work?
Of course that is irrelevant to the 95% of users who never use any shortcuts at all … but it feels like a step backwards at times.
A good x-platform GUI toolkit won’t give you any of that - it’s about understanding the platforms you are working with, and expectations of users. Which I OK, because most of them have low expectations!