Steve Jobs was Google's first choice for CEO
Why I Choose the BlackBerry PlayBook Over the Competition - BerryReview
Poof! After Wireless, the Computer Mouse Turns Invisible.
AngelConf: A How-To for Prospective Angel Investors
Scripting News: SXSW panel idea: Why panel discussions suck
US Senator Robert Byrd dies at 92.
Samsung N230 netbook ships with 13.8 hours of pretend fun.
Will e-readers eventually be implanted in our retinas? Maybe not, but you might be able to unfurl them on the subway.
Live-blogging is interesting and important.
The idea is that there is some event that is creating news in real-time. You want to open a window and start taking notes and have those notes published quickly as you type, without much distraction. Readers who are tuned into your updates will see them in near-real-time.
There are a lot of activities converging on this focal point. Twitter, for example, could be considered a live-blogging environment. But its user interface is pretty klunky for this kind of note-taking. And it tends to bog down or fail when news is happening in real-time.
The popular tech blogs, esp the gadget blogs -- Engadget and Gizmodo -- do live-blogs of press events. Not sure what their editorial tools look like. As a reader, you open their web page and watch it update. Very easy to use, but you can only watch one flow at a time, a disadvantage over Twitter, which joins the flows.
Clearly some of the live-bloggers have advanced editorial tools behind the scenes. For example, I was watching the NY Times soccer site live-blog yesterday's game between Ghana and the US. Lots of structure evident there. Wonder what their editing tools look like?
Also, the EBS for Twitter would likely be based on RSS feeds. Then I came across SocialWhale, a neat Twitter client from Greece that integrates with RSS and Twitter. Twitter is a corporate platform, RSS is not. That's how you evolve from being dependent on a corporate platform, by supporting both, during an interim period. If there's a need to break free, you're already halfway there. Why we had to wait for a Greek developer to lead here is a mystery. John Borthwick, Iain Dodsworth, et al -- please take note.
Anyway, all this leads to a simple idea which I now believe I am ready to implement in Scripting2.
1. The blogger designates a post as the source of the live feed for the blog. There's a fixed pointer in the head section of every page that points to the live-blog feed. It's distinct from the post-level feed. It contains roughly tweet-size mini-posts that are part of a single post.
From day to day the source of the live feed may be a different post. Some days there's nothing new in the live feed. Other days, when there's lots of news. Key point, the live-blog is also part of the chronology of the blog, and the contents also appears in the main feed, but under a single item. In the live-blog feed, each chunk is its own item.
2. As with all other posts in Scripting2 it is edited with the outliner.
3. When you save the post that maps onto the live-blog, the feed is rebuilt automatically.
4. It supports Realtime RSS, so any subscriber who has requested notification will receive it. No polling is necessary.
5. You can watch through the website, as with the NY Times example. Or you can watch through an RSS-aware Twitter client (and hopefully someday Twitter itself).
That's the rough sketch. I'm going to try to get this working in the next few hours. Wish me luck! ">
Update: The features of live-blog and link-blog posts are pretty much the same. My first "live-blog" post actually is a link-blog post.
If you're lucky enough to be one of the first users of a new product while it's being developed, here's a primer on how to think about it, if you want to be as helpful as possible to the process -- if you want to help the product become as great as it possibly can become.
Imagine you're moving into a condo, but the building is still under construction. Your apartment is on the third floor of a fifty story high-rise, and some of the upper floors don't even exist yet! There are no washing machines in the laundry room. There are doormen but they're more like cops. They wear hard hats. Be aware that the pipes are broken and there are live wires exposed in weird places you won't expect them. But if you are brave you will be able to use the tool to do what it was intended to do. You can sleep in the bedroom, watch TV, cook and eat a meal. In fact it might all be much better than normal because you get the sense that you're part of the process that will create a building instead of being someone who just lives there.
User's Manual: Be zen-like. When you spot a problem understand that it is going to be part of the software forever, it will never be fixed. That way if someday by chance it does get fixed you will feel very very very fortunate.
More zen. You're starting a cross-country trip. Think: The trip is just beginning. Even when you reach the half-way point. It's still just beginning. Even when you're in the last 500 miles. Still a long long way to go.
That's the way the lead developer, if the product is going to be any good, is viewing it. In the past I've rushed through development of these things and made bad decisions. It felt like I was going fast, but in fact I was building something that could never be finished. The times I've made good products that won awards, made the users happy and made my investors rich were the ones where I took my time, paced myself and always thought of the journey as just beginning.
I think the same approach works if you're a user too. This way the users and developers can be on the same page, think about it the same way.
Update: Ironic feature request considering the topic. ">