Shared publicly  - 
Had no idea Carbon started life as a Windows Phone, and then WebOS Twitter client. Definitely platforms that benefit from third-party attention.

Oh, and, yes: I generally agree and find M. Saleh's take on settings overload to be insightful.
A word on options & settings

If you ever used Carbon on webOS you'd know that Carbon had every options in the world, from short-url, image-upload services options to Instapaper and Read It Later(Pocket now). We had options like, "jump to top after refresh", "tweet on Enter", you name it we had it. As a matter of fact, the settings screen was so long, we were thinking of redesigning it into separate pages.

Then came Windows Phone version of Carbon. The same story, we had so much of customisability options that I ended up adding kitchen sink included in the app's description. Short-urls, image services, read later services, different notification settings, compose/search tiles, options for enabling inline Image previews on Timeline, in-app browser, geo-tagging and places, jump to top after refresh, double-tap to reply, quote-tap, some of our own Carbon-only features, you name it we had it.

Two apps took a different approach, Graphite for webOS and the current Carbon for Android. Started with a clean sheet of basic Twitter, with concentration on Twitter's own content that grew dramatically from the first time I wrote a Twitter app. I came to this conclusion, content first, experience second, customisability can come at anytime, because at the end of the day, those are just a bunch of switches, and not features really. A week ago I released the first update of +Carbon for Android and today, I have way too many things added to to it, and those are features instead of settings, of course I threw a bunch of settings there too. 

Here's why I took this approach. When you start with all the options and settings, at some points of app design you'll be forcing the app to change design or functionality based on your settings screen, so your settings screen will dictate the way you code the rest of your app, which is wrong, in my experience, the main app features will suffer as a result of that, I can see some of competition apps stuck with their designs and features because of just that! And re-writing code is a bitch when you go inside-out, instead of outside-in.

At design stage I spent most of my time designing the "Quick Timeline" something that lost its name in Carbon for Android as a result of the way I divided it and extended it to the home screen. Now, if I had to make that a setting instead, say, adding Lists to home screen, the whole design would've depended on that setting screen. Instead, revisited Carbon for Windows Phone's QuickLine design and re-aligned it for the new interface, with a new way of interaction.

Now I know Android is all about customisability  and I've received hundreds of emails requesting options for Font Sizes, Notification settings for Vibration & Ringtone, etc... And all those are coming. Tweetmarker? Darn straight that's coming too, but for now Tweetmarker is causing performance issues for Timelines and taken the back seat. Inline browser and Reading mode? All coming. I'm taking a different approach this time around, but all are coming.

And with the new approach, I had a different audience in mind, and it looks like I hit the targets as Carbon reached 100K downloads yesterday, and from the language of support emails, majority are folks who moved from the standard Twitter app. Mission accomplished, more like started.

#Android   #CarbonStillo
Tony Fleming's profile photo
Carbon is not the perfect Twitter app. But if you get over how different it is and just use it you find out how easy it is to just use. I still think their are better power Twitter clients. But Carbon just becomes comfortable and second nature to use after a while. 

But they have to emphasize the two finger swipe. 
Add a comment...