Monthly Archives: August 2012

Choosing Native

Development, Mobile

Links the kitty!Andrey Butov: “The people who really seem to benefit from using the abstraction layers are web developers who aren’t comfortable with native code (C/C++/Obj-C/Java), but who are very strong in Javascript/HTML5/CSS. I’m not in that camp, so having to skip a native-code implementation, in favor of Javascript, would actually be a disadvantage for me, rather than a benefit.”

Andrey does a great job of sharing some of the reasons it’s best to choose a native platform over something like Titanium.

I guess we all go to our comfort zone when it comes to life, and that holds true for software developers as well. I prefer to use the platform tools, so I have a history of writing in C, C++, and now Objective-C. Yes, it’s painful to learn a new platform, but I think it’s worth it.

UPDATE (8/26/2012, 2:20PM)

Branch: A Blow To HTML5: “Facebook has now largely moved away from HTML5 in favor of native Objective-C code with their new iOS apps. And the results speak for themselves. Facebook had been one of the companies that most vocal in their support of HTML5 as the future of everything. The apps suffered as a result. And now they’re changing their tune. Is HTML5 still just not ready for prime time? At least on mobile?”

HTML5+JavaScript is never going to be as fast as a native application. I think it depends on the goals for you application. If you’re ok with a lowest common denominator experience, a web site will do just fine. If you need a rich, interactive, experience you may want to create a native application, especially on mobile. When I use my desktop I don’t mind visiting website based services as much. I think it comes down to screen real estate and I can easily switch away from the site and dow something else, while it loads.

I guess the bottom like is, I believe native is a better choice, at least for the foreseeable future.

Iconfactory on the future of Twitterrific

#twitter, Indie, iOS, Social

Ollie!Iconfactory: “For the past several months, we’ve been working on a major update to Twitterrific that we’re very excited about. There were concerns that this new version might end up on the cutting room floor prior to Twitter’s announcement, but after reviewing the new restrictions and speaking with the team at Twitter, we’re pleased to report that our plans remain unchanged.”

Very exciting news!

Twitter Display Guidelines

#twitter, Business, Design, Development, Social, ,

A wonderful boquet of flowers.In the wake of the new Twitter 1.1 API changes announcement I thought I’d focus my attention on the Twitter Developer Display Guidelines so I can understand the changes I’ll see to my favorite Twitter client; Twitterrific.

The guidelines will make our Twitter experience more consistent, boy howdy. Basically every Twitter client will look pretty much the same or it won’t be allowed to use the Twitter API, and a client that can’t use the API is useless.

Please note, if you’re using a Twitter provided client, these rules don’t apply, so you have nothing to worry about.

How do the various clients display Tweets in the Timeline? See the Timelines section in Display Guidelines.

Twitterrific

Twitterrific is my favorite client because it’s darned simple, great UX and UI design. Twitterrific is unique amongst the three clients we’ll examine because it shows a reply icon in every tweet. Note the arrow in the lower right corner of the image. Tapping on that icon will display a menu of choices that includes Reply, Direct Message, Retweet, and Retweet with Comment. Not even Twitter’s native iOS client provides this functionality.

Twitterrific: What needs fixing?

I use the term fixing loosely. Here is a list of the rules Twitterrific breaks, according to the Display Guidelines.

  1. Tweet Author
    • The user’s name and @username should be displayed on one line, with the name first.
  2. Retweets
    • If the Tweet being displayed is a Retweet, the name of the user who Retweeted it and the Retweet icon must be displayed under the Tweet text. e.g. “Retweeted by Josh Brewer”. The name should link to the the Retweeting user’s profile [1].

The @username doesn’t appear in the tweet and the retweeted by text doesn’t show below the tweet. It’s not seen here, but the retweet text displays to the right of the users name. One of the great things about Twitterrific is how it displays tweets in different colors depending on the context of the tweet. I’m not sure how Twitter will feel about that, but the guideline doesn’t call it out.

That’s not so bad, but it does mean Iconfactory will need to fix some things.

Tweetbot

Tweetbot: What needs fixing?

  1. Tweet Author
    • The user’s name and @username should be displayed on one line, with the name first.
    • The avatar must be positioned to the left of the name, @username, and Tweet text.
  2. Timestamps
    • Tweet timestamp should be displayed in the top right corner.
  3. Retweets
    • If the Tweet being displayed is a Retweet, the name of the user who Retweeted it and the Retweet icon must be displayed under the Tweet text. e.g. “Retweeted by Josh Brewer”. The name should link to the the Retweeting user’s profile [1].

Tapbots has a bit of work. In most cases the users avatar is displayed in the proper position, unless its your tweet, then it’s on the right. That’s an easy fix for them. Once that is fixed the timestamp will move to the proper position in the upper right corner. The Retweets item is interesting. The rule states it should display the name of the user who retweeted it. Tweetbot does that, sort of. If the retweet was by you it displays “Retweeted by You”, which doesn’t fit the rule to the letter.

Twitter

Twitter: What needs fixing?

  1. Retweets
    • If the Tweet being displayed is a Retweet, the name of the user who Retweeted it and the Retweet icon must be displayed under the Tweet text. e.g. “Retweeted by Josh Brewer”. The name should link to the the Retweeting user’s profile [1].

Not surprisingly Twitter does the best job of following the rules, but they do break this one. In the Twitter iOS client a retweet icon is display in the upper right hand corner of the tweet and the user’s name isn’t displayed.

Random Note

In the Individual Tweet section under the Branding bullet point this is listed.

The Twitter logo or Follow button for the Tweet author must always be displayed in the top right corner.

Emphasis on the word Tweet is mine. Twitter didn’t coin the term “Tweet”, the fine folks at Iconfactory did.

EOL

It’s not all bad

Business

Dave Winer: “Bottom-line: Twitter is selling their channel to advertisers. They need to prove to them that they have control of how their messages will be seen. I don’t think any of what they’re doing is stupid or evil or misguided. However, it might not work. It might not turn out to be the big value in what they’ve built at Twitter. But it certainly is one theory.

The good news is that as Twitter focuses, and pulls back, and makes their product smaller — this will create space for new things to blossom and possibly flourish. So it’s a good time to be thinking about and doing new things.”

Emphasis is mine. I like this take on it. It’s not evil or misguided, but it will ultimately hurt many businesses. I’d imagine the free lunch is over for third parties, but there is always hope in something new.

Tapbots Blog [Paul Haddad]: “There’s been a lot of fear, uncertainty and doubt generated by Twitter’s latest announcement. I wanted to let everyone know that the world isn’t ending, Tweetbot for Mac is coming out soon, Tweetbot for iOS isn’t going anywhere. So sit down, grab a towel and let’s go over some of these API changes.”

Watch out! It's a blog fly!As Twitter has evolved it’s become more of a place for movie stars and corporations to sale their wares. That’s ok. The good news is we have a lot of power. We can choose to tap, or click, the Unfollow button for people, or companies, that start to annoy us. If things get too darned annoying in the new model people will leave, and that should send a clear message. In the end Twitter has to make money or it will cease to exist, which is a definite possibility.

There are already alternatives blooming, as Dave likes to say, so buckle up and hold on. It’s going to be an interesting ride.

Are Third Party Twitter Clients Doomed?

Business, iOS, Mac, Mobile, ,

Things aren’t looking good for Twitter clients, I know, I’m reading a lot into it, but it sure looks bad.

Last night Gedeon Maheux of Iconfactory posted this on Twitter.

This morning he followed up with this choice tweet.

It really reads like Twitter is shutting the door on third party clients that display a stream.

This bothers me for a lot of reasons, but mostly because I’m a fan of Iconfactory’s work and they’ve done nothing but contribute great work to the Mac and iOS community for years.

I hope I’m wrong, but I don’t think I am.

Long live Ollie.

Amen, Brother

Family, Life

Jerry Fahrni: “All I have to say is football season is here. Finally! Finally I can listen to sports talk radio again. Finally I can watch grown men try to kill each other on the football field. Finally I get to see Ray Lewis blow up some poor schmuck. Finally I can vent my anger at something besides people. Finally Major League Baseball will slide into obscurity again until next year. Finally football season is here. Holy crap it feels like years since I watched an NFL game.”

What he said.

Twitter Cards

Business, Social,

All Things D, by Mike Isaac: “This was a big deal. Countless numbers of smaller start-ups rely on access to Twitter’s public-facing feed, using the tweets in their own businesses for any number of reasons. If the terms of access were to be altered significantly, it could impact the livelihoods of thousands. The company didn’t elaborate on what exactly those guidelines would be, and has said little else since. The key takeaway echoed in one repeated word: Consistency. Twitter’s future plans strove for consistency across the platform.”

I had started a post to talk about where I thought Twitter was headed, but there’s no need to finish it. Mike Isaac did a great job in his article, and can actually write. It’s better to stick with the pros.

I wonder where this is all headed, given the Delivering a consistent Twitter experience post June 29:

“Related to that, we’ve already begun to more thoroughly enforce our Developer Rules of the Road with partners, for example with branding, and in the coming weeks, we will be introducing stricter guidelines around how the Twitter API is used.”

If cards are a future piece to the Twitter puzzle and they’re after a consistent user experience where does that leave third party client developers? Has Twitter made contact with them to share how they should proceed with their implementation of Twitter Cards?

The Ugly Option

I still believe there is a slight chance Twitter could pull the plug on all third party clients, but I hope not. This would give Twitter full control over all clients and allow them to kill off all their native clients and go straight for HTML in the browser.

This is, of course, a horrible idea. HTML on mobile is still disgusting, slow, and provides a horrible user experience. Why go that route?

The Compromise

Twitter could be a real standup citizen and provide third party clients with guidelines for the inclusion of Twitter Cards, and other options, in client applications. They could also provide an expected timeline for inclusion of these features and allow the clients to operate without the new feature until that date. When the date expires and the client doesn’t include the new feature implemented in a Twitter approved way, they’re cut off until they are compliant.

If you’re interested you can read about Twitter Cards on the Twitter Developers site.