konch blog
-
Woo Yay new App funz… but wait this is just likes/+1’s filtered by your friends right? So unless your friends are using it you have no point of reference. Sure you can Stamp stuff you think is awesome (like) but what about the new things you don’t own/haven’t been to?
You have no clue what to do, which means you have to sit at home or wander around aimlessly and stare at a blank (albeit well designed) UI ***cough*** Color ***cough** or you could just use the iPhone in your hands and well, call your friends and ask their opinion…
It’ll be interesting to see how this evolves and whether it overtakes Oink which seems to be the same thing but with more features and not quite as refined UI. There was a lot of hype for Oink (and I presume there will be for Stamped) and I’ve seen some usage in my Twitter feed but I’ve yet to be convinced.
-
The Facebook app fuck ups seem to be because they’re more interested in dicking around with HTML5 even though anyone with any taste knows building a fully native app is 100% better. One part of Google’s app fuck ups are similar. But at least I get that. These guys want to cut corners. Why spend time crafting a beautiful app when you can just add a nice layer of polish to a turd and shove it out the door?
parislemon: Speaking Of Shoddy iOS Apps…
Believe me, I’m usually the last to defend Facebook or Google, and I completely agree that the Gmail app is a half-assed disappointment, but I think this is a pretty glib take on “web vs. native.” I’ve been a Cocoa developer for a long time now, and my sympathies are very much with Apple, but I am increasingly convinced that we’ll someday look back at these early days of the iOS as a kind of bubble for old-school native software development.
This is not to say that iOS won’t continue to be successful as a platform, or that developers will abandon the App Store en masse. I just think that the current situation—in which many companies whose engineering efforts have traditionally not extended far beyond basic web technologies are suddenly expected to maintain complex native development projects for multiple platforms—seems a tad untenable. I feel pretty confident in asserting this because, for whatever perceived benefits native apps offer, they also presents a lot of very significant challenges—many of which are likely to be quite surprising to anyone who is accustomed to web programming.
To me, one of the textbook examples of something the web is made for but is practically rocket science on iOS is text rendering. While users are accustomed to thinking of iOS apps as exceptionally beautiful and visually sophisticated, UIKit’s text rendering capabilities turn out to be frustratingly primitive, making it quite a challenge for even expert iOS developers to match the advanced page layout and text formatting capabilities of web browsers. This is less of a problem for a utilitarian service like Twitter, where content is uniform, unformatted, and basically free of inline media. But when you start attempting to replicate something like the Tumblr Dashboard or Facebook News Feed in native code, you’re faced with a formidable engineering challenge.
Many of the, shall we say, least experienced iOS shops (read: content companies) have solved this problem by essentially shipping 200 MB InDesign layouts masquerading as general purpose software. Other, more sophisticated companies have attempted to get around this problem, at great development cost, by building rich text rendering and CSS-like styling facilities into megalomaniacal frameworks like Facebook’s three20. The problem with that approach, in my experience, is that you don’t have to go very far down the path of text rendering before you’re basically reinventing HTML and CSS. Considering that, as I said, the web is designed for media, content, and rich text, I don’t think a decision to rely on a web view for something the web is exceptionally good at is a sign of laziness—in fact, it may be a sign of prudence. I suspect this realization, not mere half-assedness, is behind Facebook’s decision to back away from their fully native, three20 based approach and instead focus on building a hybrid mobile platform.
None of this is to say that I think native apps are bad or that I’m trying to discourage companies from investing in them—far from it. Developing iOS apps is what I love, and I hope to continue doing it for some time. I just think that most companies could use a bit more nuance in their mobile strategy than the current “native is king” thinking usually implies. I’d personally prefer to see more companies develop a great baseline mobile web (or hybrid) product rather than feeling obligated to slavishly (and often poorly) recreate their entire product in native code.
(via buzz)
(via buzz)
-
Neven Mrgan's tumbl: Labeling the Back button
Makes complete sense - have already sent this over to the rest of the guys over at The App Business
Most “deep” apps require some amount of navigation, moving the user deeper into child views and then back out to the parent view. That navigational backtracking is typically done with a “Back” button, positioned in the top-left corner, and denoted by a pointed left side. You’ve all seen it:
…
-
Neven Mrgan's tumbl: Broken iOS icons
@flarup ’s App Icon Template is pretty rock solid as long as you export & submit the “Squared Icons” you get by running the included Photoshop actions. I’ve yet to produce a “hairy” app icon as a result of using it. Looks like some folks below should be using it too.
Something is rotten in the state of iOS icons. More and more, I’ve been noticing app icons with good ideas behind them, pretty solid execution for the most part, and one hair-raising screwup practically designed to get the goats of oversensitive designers such as myself. These are some apps I just…
