A few weeks back, I was searching for closed beta testers. The app was fairly well developed by then, but the beta was immensely useful in clarifying some interaction approaches and ironing out the final bugs.
The app is now done and has been submitted to the app store. So, say hello to Crème, the new iPhone Twitter app. See more info at cremeapp.com.
There’s so much more to post. I’m really happy that the project is done now, I think it came out quite well. But, of course, a lot of the features are missing still, and I’m already planning next versions.
For now, you can check out cremeapp.com for some nice screenshots and feature overview, and follow @cremeapp to hear more about when it will be available on the App Store.
[ Update: wow, I got great response. So, if you haven’t responded already, then… you may still contact me, but I may add you in a later round. Or just direct you to the app store for the complete version soon. 
Thanks to all who have responded thus far. ]
For some nights and weekends, I’ve been working on a yet unnamed/unbranded iPhone Twitter client app. I’ve looked at all the existing ones and I think I have some new things to contribute to the scene in terms of the UI, interaction and the overall experience.
I’m now starting a closed/private beta. To join, you need to have an iPhone (vanilla and jailbroken are both fine) and use Twitter at any level. You also need to have some imagination and patience because parts of the software are still broken or need some work. But, the app is not just a raw piece of rock any more. You can see the outline of the final thing, it’s starting to shape up and just needs lots of sandpaper—and your help, both in terms of technical testing and UI/interaction feedback. The goals of the test are to get to a good place with the technical quality of the app, and make sure the interaction is solid.
If you’re interested, contact me through some private channel (email, Skype chat) this weekend (Feb 13-14… happy Valentine ) to get set up. We’re going to use Google Wave (remember? Wave? Not Buzz. Wave.) as the collaboration tool. If you haven’t used Wave before, it will be an interesting experience from that perspective too.
Your main benefit will be participating in the test with me and a fun bunch of other people, and witnessing the app coming together. The final app will sell for a few dollars, and all the testers will get it for free. There’s no other material compensation. The beer, though, will be on me the next time we meet.
As a companion to my post on how OAuth works with Twitter, I thought I’d write another OAuth client for my own needs. There are several OAuth Objective-C libraries out there, and I am using some code from one of them, OAuthConsumer. But I did not like that the libraries overload existing classes like NSURL or some Twitter libraries. I like to put my app together of fairly loosely coupled pieces, and the OAuth piece should only do OAuth, and not much else. So, I wrote my own.
Get it
In November 2009 at Web 2.0 Expo in New York, someone from Twitter said that they will be phasing out Basic Authentication for their API in favor of OAuth some time in 2010. (This may or may not be 100% correct; I remember reading/seeing this but could not find the reference.) But regardless of what exactly they said, it is clear that they are moving towards OAuth, as are many other providers.
So, I decided the time has come for me to learn more about OAuth, and specifically how to work with Twitter API using it, instead of HTTP Basic Authentication. I found some shortcomings in existing docs and thought to write a post.
This post is for you if you:
- know how HTTP works on a general level: e.g you know what’s a request header.
- kinda sorta know what OAuth is and does even if you haven’t developed for it before; if not, read e.g Wikipedia or Beginner’s Guide to OAuth.
- want to understand how the protocol works for client apps on the barebones/wire level, instead of just using a client library.
Today, I thought I’ll buy an iPhone 3GS. I somehow broke the headphone connector on my old one, and it was annoyingly slow. I like the new features too, like better camera. So, why not.
First, I went to a nearby AT&T store. They had the phone, but they said I can only buy it with AppleCare. (Rushing ahead, the Apple Store people told me this is a lie.) But I didn’t feel like arguing with them, so I went to Apple Store instead.
Twitter is interesting because it is a new protocol. In connection with that, I’ve recently thought about three things that illustrate the questions it goes through as it grows.
Maintaining read/unread state
(Mentioned it previously, but it was so low nobody got to it, hence this new post.)
… or, more precisely, this is about maintaining “last read” position in your Twitter stream. I don’t think people will want to selectively mark stuff read and unread as you’d do with, say, email. But it is important to keep a pointer to what I’ve seen, so that it would be easy for me to tell the new stuff from old.
(Aside: read/unread would be one way to mark stuff as “to read later.” Currently, some people use favorites for this. Not a bad idea. But neither favorites nor read/unread are really for this purpose. Maybe we need something yet new…)
Currently, clients do this on their own, but do not share this data. For example, Tweetie exists on both my desktop and iPhone, but I still see the same messages twice. Nevermind other clients or Twitter.com itself.
One solution would be to create a third-party site to offer this as a service to clients. I don’t know what their business would be, but you can imagine clients sharing this data. And it can be with or without authentication. With, it’s secure but annoying. Without, you could find some downsides in privacy, but you could package the data up and offer it to the community. Who reads what and when? Is this sort of metadata privacy-intrusive? I don’t know. I myself wouldn’t care. (If I was more agile, I’d have the service running by now, it’s a few simple calls… basically setLastRead(user,lastReadId) and getLastRead(user) and that’s it.)
But really, this should be part of Twitter API, similarly to how your IMAP email, Skype Chat and Google Wave can keep track of what you’ve seen and what’s new.
I couldn’t fit this in the post about Skype Chat vs Google Wave, so here’s my biggest gripe with Wave.
It has many UI flaws, but those are just minor glitches that I can live with. The biggest flaw is that some Waves can simply break. There’s one in particular where some member attempted to do something with a plugin. After that “something”, the wave is simply BROKEN for EVERYONE and the content is inaccessible. When we try to access the Wave, everyone gets this message:
This is data loss, and not acceptable. (Yes, I have submitted a response and reloaded many times.) So, my approach is that you cannot yet trust Google Wave and better be careful what you put there. I will change this when they either fix a wave or explain that this is an irrecoverable problem and how they make sure it won’t happen again. Until then, watch out with your waves.
Google Wave looked interesting when it was first presented. I was looking forward to getting on to it. And I was intrigued by the actual interface when I got the invite a few months ago.
I was intrigued because it was a déjà vu from five years ago to me. It was the time when I was challenged with leading the effort to design Skype chat to support multiple people. I now thought a five year anniversary is fitting to document this part of Internet history. And furthermore, enough time has gone by to make sure that this doesn’t contain any proprietary info or doesn’t hurt anybody. A lot has changed with Skype chat and conversations, and I mostly wasn’t a part of the later changes. I can’t really explain the more recent work. I can only discuss how it came to be.
So, it was somewhere in 2004 and Skype realized they need to revamp their text chat/conversation system. Skype actually had one from the very beginning, but it was one-to-one and not very nice. It did support the basic concept of queueing messages that is extensively used today as well; that is, you could write a message to someone regardless of whether they were online or not, and it would be delivered the next time you would both be online. True to Skype’s serverless architecture, the message would simply be queued in your computer.
I sometimes build “interactive wireframes.” These are screens that you can click through, to explore main parts of navigation in some app. And you could also construct them in higher fidelity to get a feel for the final app, before actually engineering it.
Two previous players on the market were iRise and Axure, but I didn’t need it so much that I would have cared to invest in them. But recently Microsoft and Adobe have entered this market with Expression Blend and Flash Catalyst.
I went to the new Apple store opening. Made it there around 10:15am, saw a few hundred people in line.
Not a big fan of standing in line, so I went across the street to kill a few hours by seeing a movie instead. (“2012.” Don’t go. Terrible.) Came back, the line was gone, got in. Crowded, but shoppable.
I really like the first floor. It’s unusually high for a retail place. Feels more like an art gallery or something. You don’t see the ceiling on these pics.
From the outside, it’s less impressive than 5th Ave, no cube or such. But the inside is really quite something.
Lower floor is blah, simple Apple shopping, same as other stores.
Feed
Eesti keeles