Incremental Blogger

After dabbling with creating thumbnails for tweets, I’ve come to the conclusion that although they’re quite useful, they’re probably best not done with the tools I have.

Here are just two problems: Script errors and pop-up windows. You’d think the .NET tools could work around this, but I guess not.

So it appears at this time that moving the thumbnail creation to a web service makes the most sense. Although, there are some thumbnail services already, this one needs to be tuned to twitter messages so it seems like yet another twitter service needs to be born. In that way, all of the twitter clients can use it to display good twitter thumbnails. Maybe this is a nice service for Google or Twitter itself.

Till then, I guess I’ll make my own.

Sure would be nice if there was a way to pass around more information that’s less web-page oriented to get around problems like this. If only we had archived RSS-like feeds for all of our content.

Isn’t there always one more thing? Heh.

With the recent chatter about the growing popularity friendfeed, I’ve been questioning whether it’s really worth it to try to add features to a twitter client (web page thumbnails, ink, and so on). After all, isn’t the current action over on friendfeed?

Yeah, for the leading edge folks I might be a little late to the game here. But oh well, I still think that for those of us who use twitter’s service that a better client will make it even more useful.

Also, twitter is a baseline communication service and outside of friendfeed’s commenting ability, friendfeed is more an aggregator. Two different animals.

But what does all this mean, for instance, if you want to draw a cartoon for instance and share it with others. In a sense, posting a drawing to flickr and relying upon friendfeed for others to see and comment upon it is not a bad idea. It avoids people having to broadcast particular items here or there on twitter. Maybe the self-selection on twitter is a good thing though. It sure cuts down on traffic. Of course, friendfeed doesn’t have an inking panel for drawing anything and posting it so for creating comic content friendfeed isn’t going to hack it.

On the other side, I also can see that friendfeed does a pretty job with listing videos. In fact, looking at what people share on twitter and what you see on friendfeed–at least for the people I follow–there are a lot more people interested in videos that what twitter lets on. This kind of suggests how twitter’s text-only mindset is maybe too limiting.

Well, back to my original question: Is it worth it to keep dabbling with a twitter client? Hmmm. At least a little bit more. If the growth continues on the friendfeed side though, it may simply be too late.

Now that I have the site preview thumbnails working better in Witty, it’s easy to see how often people refer to web pages in tweets.

For instance, out of the last 20 tweets I’ve followed, almost 50% (9) have urls in them.

(I’m thinking though, that I need to make my thumbnails a little smaller. With so many thumbnails, they eat a lot of space as it is.)

I’m at the point where I need to deicide about a couple features with the twitter client.

First, should I break the 140 character limit? Here’s what In thinking: Should a twitter client allow the user to type more than 140 characters and then if they’ve typed let’s say 200 characters then the client automatically splits the oversized message into two messages and then auto re-assemble them in the client into one message?

Yep, this violates the basic intent of twitter and most clients would not see the coalesced, single tweet, but for those that could, wouldn’t this be a compelling feature?

Maybe if you want to say more you should always link rather than tweet text.

Or similarly what if you want to write something and you’ve consumed 143 characters? Should a twitter client give you a suggestion window with edited permutations that fit within 140 characters? Auto-magically? Or is this type of feature too much effort for too little gain?

The other thing I’m thinking about is about ink editing, text tweets can’t be edited, but since the ink is placed on flick, maybe allowing editing for it wouldn’t be a bad idea. Now if irk editing is supporter, what does it mean? Should you be able to do tiny adjustments or simply replace the whole thing? Or both?

This is why I want to be able to tweet in ink and see image previews in my twitter client…

I want to be able to draw silly cartoons and share them easily… or better yet see other people’s GOOD cartoons as I scan through my tweets.

As I read this morning through some of the people I follow on Twitter using my tweaked Witty that displays web page thumbnails for urls mentioned, I can’t help but wonder if maybe these thumbnails are…hmmm…too big?….provide enough information?….need to be layed out differently?

It is kind of interesting how many people are mentioning URLs though today–especially using tiny links of some kind.

Bob was suggesting that rather than these web page thumbnails that we go with a tooltip that shows the actual site url. That would at least give the idea of where the tiny url points to without paying the performance hit of retrieving the web page thumbnail for the url or having to deal with its rendering issues. After playing with the thumbnails for a little under two hours I’m giving this more thought–at least as an option.

Next up? I want to be able to past images into the InkCanvas and be able to mark them up with ink. Hmmm….

I experimented a bit more with adding site preview thumbnails to the open-source Twitter client, Witty.

With a little bit more experimentation I got a first pass at the thumbnails showing for any web pages mentioned in a tweet.

There are several big problems with this though. First, it doesn’t appear like my eventing is right so the page doesn’t fully load before the thumbnail is created. As a consequence whole or parts of pages are left empty. That’s not necessarily a terrible thing, but it’s not right, either.

For instance, in Chris Pirillo’s tweet, the thumbnail should look more like:

rather than what’s shown in the previous Witty screen capture.

The thumbnail rendering can also add a noticeable time delay to tweet loadings. There’s probably no easy way around this. I’ve been wondering if I can trim down the posts by looking for RSS items instead and working off of their content and maybe pulling out a representative image or something. Hmmm.

Of course, there can be problems with JavaScript errors and the like too. So I’ll have to think through if this all of this is worthwhile. Maybe I’ll just have to live with it a few days to see if the benefits of the thumbnails outweigh the drawbacks.

Another ink experiment with an ink-enabled version of the Twitter client Witty.

I definitely have a background-setting problem or a cropping problem since the bottom of the image is picking up a black edge. Hmmm.

Following up on my tweaks to the Witty Twitter client yesterday, I went ahead and put the first stabs at ink into the client app. Here’s my first successful ink post via Witty:

What mods to Witty did I do to enable this? First, I added an InkCanvas to the UpdatePanel (the area where you write a tweet in Witty) like this:

Now if any ink exists in the InkCanvas, the ink is rendered to a png stream which is then uploaded to Flickr using the FlickrNet library and then a tweet message is contructed to point to this Flickr image.

After a couple quick experiments I realized that the UpdatePanel needs to be contained in a splitter window more like Messenger does so you can size the drawing area as large as you need it. Currently, the UpdatePanel size is fixed because that’s the way Witty was written. This was a reasonable assumption when all you could do was post 140 characters. With ink though, this limit is too, well, uh, limiting.

What’s next? Make the InkCanvas real. Not only do I need to move the writing/drawing surface to a splitter window, it also needs pen colors and an eraser.

Inch by inch.

Bob and I took a couple hours break this afternoon from our regular work to try and integrate pictures and ink into a Twitter client.

To recap from an earlier post, what I want to do is:

* Display thumbnails of flickr referenced photos where feasible
* Resolve tinyurls and the like so I can see what the links are actually pointing to
* Display thumbnails or web pages that are linked to where feasible
* Support ink drawings in the client which are then posted to flickr (or similar)

As I see it now, I don’t care if Twitter supports ink and photos directly. Adding these features to the clients is more than passable.

With only a couple hours at hand we didn’t get very far. One shortcut was to use the WPF-based open source project Witty. For the most part that got the basics going.

Then with a couple small adjustments we got images displaying as shown here:

Now when someone that I’m following (or myself I guess) points to an image directly or to a flickr image a thumbnail of the image is displayed. This works even if the person uses a tinyurl or similar url shortening service.

This turned out not to be too difficult. The approach we took was to change the low level custom control TweetTextBlock and derive it from RichTextBox rather than TextBlock. This gives lots more flexibility over what can be contained in the rendered tweet (since it can display a FlowDocument) as well as providing selection and copy to clipboard.

This didn’t turn out to be too difficult. Thumbnails of web pages was another matter. I tried using the new WebBrowser object in .NET 3.5, but I can’t get it to render anything to a image object. I guess I’ll need to ask around.

Unfortunately, the web page thumbnail problem took up most of the time so I didn’t get a chance to integrate in the ink yet. I’ve done this before with a Silverlight app–posting the ink to flickr–so I don’t think it’ll be too hard, I just need a couple hours of free time. Maybe this will be a good thing to do this holiday weekend.

As for now…it’s time to do the dishes.

Twitter client writers need to up their game. We all know you can write to the Twitter API and display 14-character tweets for those who I follow and maybe each user’s thumbnail, and a couple icons here and there to show whether a message is a reply or something I authored, and so on.

But none of the Twitter clients go far enough I think. None.

As you know, I’ve been a long time advocate of Twitter thinking beyond text. I accept the fact that it’s not going to happen. However, it doesn’t stop Twitter clients from working around the text biased limitation and emulating a richer experience. So here’s what I’m asking for: Add support for inline images and possibly audio or video in the clients. If you see a URL to flickr, show the flickr image in the tweet. If you see a URL in a tweet. Show a thumbnail preview of the site. If you see a link to an audio file, include an embedded audio player so I can listen to whatever it is without having to click out of the Twitter client experience. And if you see a link to a video site, see if you can embed a video preview in the message. For those of you interested in watching live videos like those by Robert Scoble and the like, just image what could be done here too. It could bring a whole new mindset to tracking news on Twitter too, I bet.

The arguments for and against supporting non-text media natively in Twitter is kind of like the original web arguments as to whether images should be rendered in a browser or whether images should be embedded within email messages or provided as external links. By and large I think those arguments are over. For the vast majority of users the answer is yes. For a handful of others who don’t want it, the answer is to turn off images or use a text only browser. These people, however, are in the minority. Let’s just accept this fact and move on. The Twitter client authors need to make this happen.

Of all the Twitter clients, GTalk is probably the closest to providing a good media experience for Twitter messages. Depending on whether you point to Flickr let’s say, it’ll give you access to your Flickr image. (Last time I checked though the link has to be a real Flickr URL, not a tinyurl.) The problem is the approach is Flash biased and doesn’t go far enough. There’s lots more to support direct Flickr content as well as content from other sites.

Unfortunately, most tweets don’t contain the full address at all. Many use tinyurl or some other URL shortening services. So what GTalk and all the other Twitter clients ought to be doing is following through links. If you see a tinyurl or similar, you have to chase it down. You have to see what it really points to and then render something more meaningful in the tweet message area if it makes sense.

OK, here’s what the Snitter client typically looks like for me what I’m wathing Twitter messages:

Note that there are two URLs mentioned in two different tweets. This happens all the time. People are pointing to one of their most recent posts or sometimes some breaking news. But URLs being URLs many times I can’t tell what the paths point to. Give me a thumbnail preview of the site to help me out in deciding whether I should click on a link rather than me having to play URL roulette. Is this another link to truemors, or a link to actual news? I want to know.

So here’s one cobbled of idea of what these tweets ought to look like in my book:

Both tweets that reference URLs have thumbnail previews substituted or supplied for them. Isn’t this more interesting to read and give you a quicker and better idea as to what the person is pointing to?

There are lots of interesting questions here as to how thumbnail previews or images or audio or video and the like ought to be rendered inline with tweets. For instance, should the images be placed at the end of the tweets or the urls substituted with images with text wrapped around or the images right justified or what? Or maybe site thumbnails shouldn’t be used, but rather thredr or Techmeme style image excerpts ought to be extracted from the sites and right justified? Or maybe only take image excerpts on certain news sites or from blog posts? And if site previews are used, should tinyurls at the end of posts be displayed or simply dropped? Lots of possibilities.

Let’s face it, thumbnail previews for sites make complete sense. So do replacing Flickr URLs with the images they are pointing to.

During the next major earthquake or flood or storm don’t you want to see an embedded Twitter image rather than just the link to a page that you have to visit to find out if it’s a link to an image or a news website you’ve already read or to a blog that links to a blog that links to the image you want to see? And I think a compelling argument can be made that live videos ought to be embedded too. Maybe I do or don’t want to watch the video. Give me a few seconds at least of content to decide.

There’s more to it than this, though. I think we’re missing some great non-text conversations. I can’t remember what debate was going on the other day, but it was something silly and although I wanted to respond with something appropriately silly and pointing out some irony yet I decided not to post anything because in such a short text message it’s so easy to be misunderstood. So I said nothing. But it struck me at the time, that what I really would have liked to do was share my thoughts in a cartoon. There’s a reason why political cartoons are so popular in print media. Why can’t they be too in the Twitter community? I’d love to see Hugh Macleod’s drawings inplace. They’d be perfect. And I think we’d see lots more creative types joining in with their edgy commentary if Twitter clients would work better to support non-text.

I think we’re missing some terrific opportunities for quick visual commentary. Some of these might be photos snapped at the most recent Apple event, or someone sharing a sunny day in their backyard, or someone drawing a cartoon that more poignently than any sequence of 140 characters gets to the real point of an issue. Yes, sometimes things are better said in wiggles than words.

Of course, all of this should be a feature so those that don’t want it can turn it off. However, I’m convinced that if we broke out of this text bias we’d see lots of interesting use of non-text content.

What do you say Twitter client authors? How about it? It’s not that hard.

Jack Dorsey and Biz Stone respond to some technical questions about Twitter and what they are doing to address some of the infrastructure issues. Looks like they are taking the first much needed step.

I will say that at times like this that often features are cut during the “rewrite” and, if we’re fortunate, new ones added that help the product grow.

As I write this, though, I’m trying to figure out what might get cut. Twitter’s feature list isn’t all that extensive. It doesn’t handle media types other than text. It’s web UI is sparse. And the Twitter API itself isn’t huge by any stretch of the imagination. Despite this, I’m betting something’s going to get cut–maybe features that have been built in that never made it outside the company. Hmmm. That’s the nature of ports when a new dev team takes over. They’ll say, “Oh, I don’t get this feature X,” so out it goes.

Likewise, the rewrite team has the opportunity to see in a fresh fashion where the new trends are and start adding in tidbits to enable them. So might we see images and the like finally find their way into Twitter? I’m going to put this at an 80% chance of happening.

Dare Obasanjo dissects the Twitter problem here and here as do others on TechMeme.

Dare explains the cost/benefits of push and pull implementations and single instance storage systems and suggests a naive implementation of either is probably not the way to go with a service like Twitter.

Well, of course. No off-the-shelf implementation is going to work the best. In terms of implementation models, there’s no off-the-shelf model that’s going to be optimal either. I think this is what most people are suggesting when they say Ruby on Rails is part of the issue. It’s because ROR is biased towards a handful of programming models. No way Dare can convince me otherwise. This isn’t to say C++ isn’t biased too. Where’s its parallel processing capabilities, for instance? Enough about languages though.

The issue that I think Dare is getting at and the Twitter team is now describing, is that operationally they have a brittle system. I don’t know how many times I’ve seen this happen before over the years. If it takes too much effort to deploy, testing is a significant pain for a small venture and it doesn’t get done. There’s not even close to enough time. It if takes too much to maintain, it’s going to scale poorly too.

A related aside: Content management systems have been a sweet spot for databases. Rolling back the clock, I didn’t quite see the benefit. It seemed just as easy to manage things by hand. The cost of managing and deploying the database was greater than the cost of manually managing files on a server(s). However, as more and more updates are made during a day or every hour…A.K.A. blogs…, the benefit grows rapidly. What I didn’t get initially, was that this incremental benefit was going to have a cross over point that was going to approach rapidly.

One reason I didn’t latch onto the benefit early enough? It was incremental.

Here’s the thing, I don’t think there’s a similar incremental approach to designing a system like Twitter–at this point. ROR, C++, it doesn’t matter. It’s going to take some concerted thinking to build an efficient system. I’ll take a bit of this back. A simple Twitter system can be built using any collection of tools. Whether it can grow over time or handle significant load is another issue.

That being said, I think it’s quite feasible to be a non-brittle system that scales up. I don’t think this is a hard problem. I’ve never done it before, but I don’t see how it’s a big deal iff the cache, messaging, and indexing is by design. I’m placing these first for a reason. Now maybe some existing tools can be used to take shortcuts here or there, but I don’t think they can be the core. Now I might be wrong as I was with early CMS. Maybe there’s something incremental going on with database technology that I’m missing. Could be.

My gutt is telling me, though, that the core is something more dedicated. The databases and PHP, ASP, ROR, etc, etc, etc stuff makes up the non-DNA features.

One other point that I think hints at the operational/brittleness challenges Twitter is having: Notice the percentage of down time that’s been happening since their lead developer left a few weeks back. My guess is he had a good mental model of the system, sufficient to repair things as they “failed.” However, there are so many steps on their abstraction ladder at this point, it’s challenging for others to figure out. With things being brittle it’s a challenge for others to poke around the system without breaking more things. They’ll get it though. It’ll just take some time and a little pruning here and there to simplify things.

All of the ups and downs of Twitter has me pondering if it really would have been all that much harder or slower or worse to code up the service in let’s say C++.

Back in the early days of the Net, I had lots of friends tell me to use this or that framework for building some web stuff I was working on at the time. I resisted–in large part because I knew C++ well and the various frameworks were so brittle at the time. If I stayed in control with everything and built things up one step at a time in C++, I knew I could get things done. With the frameworks, I figured I’d be spending most of my time learning their intricacies.

So I stayed with a CGI model–I tried some ISAPI stuff too–but kept with CGI for the most part. Oh, and we also built our own database and indexes–another unheard of thing.

Anyway, the product was a killer. It ran blazingly fast. It was trivial to install. And it worked well. Very well. Scaled up to very large installations too.

In some respects you could say I and the other dev lead were stuck-in-the mud laggards, by staying with C++. I guess we were. But it paid off huge. The founders of the company sold the company for a good penny and are now both “retired”–busier than ever doing things that they always dreamed of.

Looking back, I can’t say we were all that smart, just lucky. However, it did teach me a lot about creating products versus creating “products.”

An aside, a friend worked at a large competing company and worked on transitioning a C-based custom client-server app/database to an Intranet service about the time the one company sold. The product was very, very similar and probably could have been built from what we’d worked on. Anyway, the developers sold the company on the idea of porting everything to Java in 6 months as a way of getting to an Intranet-based product faster. Five years later the product was still not done and was canned. I’m not saying it was Java that made the difference; I don’t think that was the lesson at all. It was going to take a significant amount of time to get back to the level they were originally at plus add all the stuff management dreamed about having access to. It wasn’t a straight port. The Java platform didn’t magically help them avoid the issues of getting to what they really wanted any faster. It got them started faster, but not to the end goal.

I’m reminded of all of this as I read the various press accounts of the Twitter team and their work with Ruby on Rails (ROR). I’ve never used the platform/language so I have no idea what the issues are, but I can guess. And like ASP.NET or PHP or any of the others, I can imagine as much of the work in a significant product like Twitter can be about the frameworks as much as the core product itself.

That’s not a bad thing–and personally today I’ve gone more the platform direction myself using PHP and ASP.NET rather than build sites from the ground up. I’m doing this in part because this are “light” sites. Twitter isn’t (anymore) though.

Maybe ROR can keep growing with Twitter. I have no idea. But now, a couple years into it, as the growing pains keep growing the foundation question is a reasonable one to ask: Would it really have taken any longer to get to where they are now with another language? I think not.

Now maybe ROR gets you up and running very fast, but that initial speed to market (which may be critical from a business standpoint–don’t get me wrong), means proportionally less and less every single day the service stays up.

Something to think about. All this being said, it’s time I get back to my WPF development. (Yeah, sounds inconsistent doesn’t it. LOL).