Ideas For Dozens: useful web Archives

February 11, 2008

Using Sandy with Web Snippets

Welcome to the third in my series of tutorials on getting the most out of I Want Sandy, the "virtual personal assitant" from Portland company Values of N. In the last two installments, I covered how to communicate with Sandy on the go using SMS and Twitter and outlined a Sandy-specific version of the Quicksilver append trick. This time, I'm going to show you how I use Safari's new 'web snippets' feature so that I always have quick access to all the stuff I've stored with Sandy.

I know what you're saying: 'Web snippets? Isn't that a Dashboard feature? Personally, I'd be perfectly happy if Dashboard never launched again!' I know, I know; before figuring out this little trick I felt similarly. But, believe it or not the combination of Sandy and web snippets has actually made Dashboard useful to me for the first time since its inception. So put your well-deserved Dashboard skepticism aside for a moment and listen up.

Now that you've been using my first two tips for awhile, Sandy's starting to know about a lot of your appointments and all your other little tidbits, but what's the best way for her to give you easy access to them? Sure, you can query Sandy for individual bits of information when you're on the go, but there are some things — like your calendar and TODO list — that you've just got to have close at hand in full. Creating web snippets out of Sandy's monthly and tag views is the best way I've found to accomplish this.

A 'web snippet' is simply a chunk of a web page that you select from Safari. Safari then creates a Dashboard widget that will be constantly kept up to date with the current content of that little bit of the web. What we want to do is to create web snippets out of the pages on Sandy that have our most relevant information. For my part, I've settled on the Monthly view and the view for my @computer tag (more about that in a minute). Here's how I got those created:

Login to IWantSandy.com/home.
Click on Daily Digest > This Month (the 'This Month' link under the Daily Digest drop down).
Click the web snippet icon as shown above.
Drag the highlight box around the yellow pad part of the screen containing your reminders. Sometimes, the box will lock onto individual sub-portions of the page making selection easier, but you can also drag its corners around as well.
Click the "Add" button in the top right.
Dashboard will launch. You're done.

Now, you'll have a custom-made widget with all of your reminders for the month available anytime you invoke Dashboard.

So, how do I use this? And what's so great about it? Couldn't I just visit Sandy's perfectly nice website anytime I wanted to view my stuff?

I've made two Sandy-related widgets: one for my appointments for the month and one for my items tagged @computer. I use the @computer tag in a GTD-ish manner to specify TODO items that I can accomplish at my computer (click on the image below to see a larger version):

Each of these uses demonstrates a different big advantage of accessing Sandy from Dashboard. The key is: the AJAX bits of Sandy's interface still work here, so I can edit items and mark them as done directly from these widgets.

For example, when I complete an item from my @computer TODO list, I simply click the 'x' next to its entry in the relevant widget and the item gracefully fades away never to return:

Similarly, I can edit details of appointments if they change, simply by clicking on an item from my monthly calendar. The first click pops up a box with some more details:

Clicking 'Edit' brings up a form where you can change everything from the date to the description to when you want Sandy to send your reminder:

Each of these web snippets really starts to feel like a tiny little custom desktop client for a single specific bit of Sandy's functionality.

One of the big lessons I've learned from my attempts at doing GTD has been the importance of putting your inboxes and other TODOs directly in your path, someplace you'll stumble over them in the course of your normal daily operations. And these little applications are a really lightweight way to do just that, eliminating nearly all the friction involved in maintaining and making reference to my lists and reducing the opportunity for fiddling to a minimum.

Tagged: sandy, gtd, safari, web+snippets

Posted by Greg at 6:40 PM | Comments (0)

February 8, 2008

An iwantsandy Port of the Quicksilver Append Trick

As a follow up to my last post on mobile communication with Sandy, here's a trick I use to communicate with her when I'm sitting in front of my computer.

My favorite super-fast way to tell Sandy about new reminders is nearly identitcal to the famous Quicksilver append trick. In that legendary tip, Merlin Mann advised combining Quicksilver's raw text entry option with it's ability to append information to existing text files in order to quickly add items to lists for tracking everything from TODOs to groceries. My Quicksilver-Sandy technique is almost exactly the same, but here, instead of popping our text on the end of an existing file, we're going to have Quicksilver stick it in an email and send it off to our favroite fictional personal assistant.

If you're experienced with Quicksilver, you can probably figure this out for yourself, but for the rest of you here are the gritty details:

Invoke quicksilver.
Hit period so the first pane goes into text mode.
Type your message to Sandy (i.e. "reminder thrusday meeting with mikey").
Hit tab to bring up the second pane for selecting an action.
Type "e", "m" (enough for Quicksilver to pick "Email To...(Send)" as the action). Caveat: Make sure you have the "Email To...(Send)" option checked in Quicksilver's Actions preference pane or it won't be available.
Hit tab to move to the third, "indirect object", pane.
Type "s", "a" (enough for Quicksilver to select Sandy from your contacts (obviously, this presupposes that Sandy is amongst your contacts — which happened for me simply from emailing her a lot; I don't use Address Book).
When all three panes look right, hit enter.
There is no step 9.

That's it. Just like the tips for mobile Sandy communication, I really like this way of telling Sandy about my stuff because it reduces for adding new information so much that it makes it easy for me to actually achieve the "ubiquitous capture" the GTD geeks are always talking about.

Next time, to complete my trifecta of Sandy-related posts, I'll talk about how I access the info that Sandy's storing for me using the new Dashboard "web snippets" feature so that it's always easily available to me.

Tagged: iwantsandy, quicksilver, append, 43folders, email, gtd

Posted by Greg at 6:14 PM | Comments (0)

January 21, 2008

I Want Sandy with SMS and Twitter

sandy I've been happily using I Want Sandy, the virtual email-based personal assistant from Portland-based Values of N for some time now. (Disclaimer: Sandy is the brainchild of Rael Dornfest who I'm proud to count a friend.) The service's friendly avatar-driven interface masks a powerful task and event storage and reminder system that actually feels surprisingly similar to the Ruby Golbergian contraption of Rake tasks, Remind, and Geek Tool that I'd previously hand-rolled for myself.

Until recently, the one part of my interaction with Sandy that hadn't left me totally satisfied was the ability to add tasks and reminders from my phone. Since I've been a straggler in the iPhone stampede, the main interface I use to get data to and from my phone is SMS. It was a synch to teach Sandy to send reminders via SMS, but I had never been able to close the loop on sending new information to Sandy via text.

It turns out the problem was mostly me. There are actually two different ways to get setup to send your reminders to Sandy from SMS: via the secondary email address and via Twitter. Both of these are relatively easy to setup and have different uses depending on the context. Here's what I did to get them working:

Setting Sandy up with SMS

Login to iwantsandy.com
Navigate to the settings page.
Under the heading "Secondary email address", enter the email address that your carrier redirects to your phone via SMS. For Verizon users this will take the form <YOUR PHONE NUMBER>@vtext.com and other carriers have similar services. If you don't know what yours is, try sending a text message to your own email address and seeing what the from address turns out to be.
Once you save your settings with your phone's email address, Sandy will send you a message with a link to confirm the address. When the message arrives in your phone — it will be in the form: iwantsandy.com/confirm/<SHORT CODE> — visit the url in the browser.
That's it, you're ready to go! Add Sandy as a contact on your phone (enter the address listed as "Sandy's Email Address" as her email address) and you can send her info in just a few clicks any time.

Setting Sandy up with Twitter

Go to Sandy's Twitter page and click the button to follow her.
Go to your Twitter settings page on Sandy.
Tell Sandy your Twitter account name.
She'll send you a direct message on Twitter with a confirmation code.
When that message arrives, return to your Twitter settings page on Sandy and enter the code in the box.
That's it. You're ready to go! You can now send Sandy a Twitter message in the form of "d s remember that I left my cell phone at the bar" from anywhere you can send Twitter messages: Twitterriffic, the web, IM, by texting to 40404, through the Twitter API, etc. Note: they use "s" as Sandy's Twitter name because it's fewer characters to type on a phone.
Sandy will respond to your Twitter message telling you what she gleaned from it.

While both of these processes are somewhat lengthy to describe, they each only take a minute to actually execute. And the result of doing so, at least for me, was a major imrpovement in not forgetting things. Instead of writing things down and then sending them to Sandy later when I return to my computer, I just tell her about them immediately when they come up. Plus, now I can access all the stuff I have Sandy store from anywhere. If I want to know what errands I'm supposed to do while I'm out doing them, I just text/twitter "lookup @errands" and Sandy replies with everything I've tagged as an errand.

Tagged: sandy, twitter, sms, reminder, email

Posted by Greg at 5:48 PM | Comments (2)

December 17, 2007

What Happens When Web-Scale Computing Becomes a Commodity?

With the announcement of Amazon's much-anticipated SimpleDB service this week, we now officially live in a world where the kind of enormous systems run by Google, Yahoo, Ebay, et al — systems that power huge portions of the web (where 500+ million users is totally mundane) — are available on demand in small doses and at reasonable prices to anyone who needs them. Amazon Web Services now provides all the necessary infrastructure to run applications that host millions of files for download, persist hundreds of millions of database records, and run thousands of processes, all without building or maintaining any physical infrastructure.

On this infrastructure, the only real difference between running a small application (a custom CMS for a medium-sized non-profit, for example) and a large one (say, Digg) is the size of your monthly bill. And as other companies besides Amazon enter this market as a relatively simple way to monetize their huge existing infrastructure costs the size of that bill will fall as well.

So, what are we talking about here? Within a few years, a scale of computation that is currently only available to a handful of multi-billion dollar companies will be available to any pair of dorm room-bound hacker kids with $30/mo. and a pair of MacBooks.

Just as the rise of commodity server hardware and open source software revolutionized the web over the last ten years, it would be reasonable to expect changes of similarly breathtaking scope as we undergo the commoditization of web-scale computing over the next ten.

For a few clues as to what happens when the current, if obscure, state of the art becomes an industry-standard lowest common denominator, it helps to look at some history. This has happened at least twice in the last thirty years: once when industry standardization around x86 hardware lead to the collapse in prices for DOS- and then Windows-compatible PCs that made them ubiquitous around the world; and again when these same PCs reached a level of power and the open source software written to run on them reached a level of affordability and reliability that, together, they displaced the expensive and proprietary server systems and radically lowered the barrier to entry for web-development leading, as Tim O'Reilly has clearly outlined, to Web 2.0.

Each of these transitions had the same two high level effects: they made it cheaper to produce professional caliber work and they increased the value of openness.

The rise of the ubiquitous, cheap, and powerful PC has created near-universal access to the best digital tools available. Professional accountants, graphic designers, record producers, photographers, and countless others do their work on exactly the same relatively cheap hardware available to the average consumer playing games and writing email.

Similarly, the precipitous pricing drop in web application development and deployment environments caused by the birth of the LAMP stack and the commodity servers on which it runs made it possible for startups like del.icio.us and Flickr without first raising millions of dollars in venture funding to buy Sun Workstations. (And this doesn't even take into account the second order revolution in the content industry caused by the cheap-to-free hosting publishing tools created by these very startups and run on commodity web hosting.)

The openness story is, if anything, even more shocking. Like fruit flies spontaneously generating out of garbage, Linux grew out of the universally available commodity PCs with their high levels of hardware compatibility. The same process that filled the PC landscape with identical gray boxes running Windows made it possible for a few OS geeks from obscure countries to build, in their spare time, an operating system that could feasibly run, for free, on all of them.

Similarly, the commoditization provided by the triumph of the LAMP stack made it possible for a handful of people to build non-profit web applications like Wikipedia and Craig's List whose only mission is to make useful information universally available to anyone who wants it.

Now. What form will these two kinds of changes take with the use of web-scale computing?

Let's start out with the ability to produce professional caliber work more cheaply. Currently now, it was only feasibly to build web-scale applications if the market for them was also web-scale. That is, you only got to use resource intensive technologies like full web spidering or massive file caching if you were building a mainstream service with a potential audience of 500+ million daily users. This meant the basics: search, ads, maybe games.

But, when doing these things only costs a couple hundred bucks a month, a great many smaller markets suddenly become lucrative. Could you build value on top of a dynamically updated list of every mention made of every stock ticker symbol anywhere on the web? How about every mention of every trademark? Or every mention of every mp3? Since the overhead for extracting that value no longer includes building and maintaining enormous data centers it might actually become feasible to build service with such requirements.

(As a side note, it's worth noting that one of the corollary effects of such a change is that it's no longer necessary to take tens of millions of dollars in venture funding in order to run a business that requires web-scale computing. This means even more leverage for startups when negotiating for what little funding they do need and even shakier times ahead for the VCs out there looking to invest their billions in only a small handful of huge deals.)

And what about openness? What new prospects for collaborative networked volunteer-driven world-improving projects might we see?

How about a Web OS that runs on top of a peer-to-peer network of commodity machines that's available to anyone who contributes some spare cycles to the cause — like a Google-scale Linux install running on top of SETI-at-home? Or what about a world-wide effort to federate the tracking of all manufactured objects via their RFID tags in order to maximize the efficiency of their recycling, discover any of their toxic effects, and rollback global warming?

These ideas may seem silly or grandiose, but so did Google when Larry and Sergei were still students or Linux when it was just an excuse for mailing list flame wars. This is one of those times. A lot of new things just became possible.

Tagged: simpledb, amazon, google, web-scale, computing, linux

Posted by Greg at 8:08 PM | Comments (7)

December 5, 2007

Why Don't Social Networks Provide RSS Feeds?

no facebook rss

The total lack of RSS feeds on many of the most popular social networks seems shocking. More and more, across the net, RSS feeds have become the standard way to make important oft-updated information universally and easily accessible. In addition to increasing user convenience, feeds allow sites to participate in a whole galaxy of mash-ups, pipes , and remixes. Meanwhile, social networks are like black holes: they suck in your data and attention while emitting nothing in return. Facebook's failure to offer one for your "News Feed" (it's most prominent UI feature) glares especially darkly in this regard since they explicitly describe this information as a feed without offering it to you as one.

I can think of three reasons why social networks might not offer feeds, none of them especially flattering:

Lack of Demand, Part 1. It's possible that the average Facebook user is so technically unsophisticated that the company's UI designers made a conscious, informed choice, based on real research, and decided that explaining and implementing the feature to their high standard of clarity and usability was just too challenging a prospect. Possible, but unlikely. No less populist a site than Blogger managed to explain not only the process RSS subscription to their audience, but also a whole series of RSS publishing options — a much more complicated topic.
Lack of Demand, Part 2. It's also possible that, when it comes down to it, people don't actually have an urgent need to know what's going on in their social networks; the updates to their News Feed — the fact that "Cameron Hill added the Vampires application" or that "Marcus Estes removed 'hidden telecommunications'" from his interests" or that "Jamie Freedman added the Optical Illusions Challenge application" — may just not be all that vital. Oh, how I wish I believed this was true. In reality, though, the number of hours clocked on the site itself by each of Facebook's 50 million users seems to debunk it pretty thoroughly. I mean, the mere existence of the word Facecrack on its own seems to end the "Lack of Demand" conversation pretty conclusively, doesn't it?
Greed. With Lack of Demand shot down, we're pretty much left looking greed unavoidably in the eye. As Cory Doctorow recently righteously griped — and as the growing Facebook Beacon scandal confirms — nearly every technical decision Facebook makes is designed with a sole mission in mind: generating more ad impressions. Why don't Facebook notification emails contain the message's actual content? So you'll click through to the site and view more ads, of course! Not that you can't put ads in feed items (or even emails), but I'm sure the average trip to Facebook generates more than a single page view, which amplifies impressions, and removes a modal change, which improves click-throughs and conversions.

There are, of course, exceptions to this logic. Digg, Twitter, and a few other sites, mostly with more technically savvy audiences, generate feeds galore (and, in the case of Twitter, actually push their content out to a variety of messaging platforms most of which present major obstacles to advertising), but the general story remains: Facebook and MySpace, the mainstream social networks, don't generate feeds.

And I think this is an opportunity for someone.

What would you do with an RSS feed from your social network of choice? What could you mash it up or remix it with? Would having access to a feed change how you operate your account? How would a highly feed-oriented social network that emanated data and activity in all directions be different from today's black holes? Would it be better?

Tagged: social network, feed, rss, greed facebook

Posted by Greg at 2:11 AM | Comments (3)

October 3, 2007

What's Wrong with Google Reader

A few weeks back, having ditched my dying beer-stained PowerBook for a shiny slightly-used MacBook Pro, I found myself trying out news readers for the first time in a long time. I've been a NetNewsWire 2.0 man for nearly ever, but I thought: it's a new computer, a new architecture, heck, practically a new century since I last looked at the competition.

I took a cursory look at Vienna (too ugly) and NewsFire (too pretty). I took a serious look at NetNewsWire 3.0 (too familiar). I asked around on Twitter.

Google Reader kept coming up. There's a massive migration towards it going on now in the geekosphere. And I could see the advantages to an online subscription experience: access from any machine, truly native re-publishing, etc. Maybe it was mostly peer pressure, but I was sold.

I'm only a week in at this point, but I think I'm starting to settle on a verdict that's taken me quite by surprise: Google Reader is shockingly schlocky. Don't get me wrong, it has its upsides including a surprisingly smooth and snappy reading UI (for a browser-bound app), and all the cool Google-y features like search, recommendations, stats, et al.

And the problem isn't the look: I've tried it in its natural state and with Jon Hicks' beautiful Mac-ish mod. I like both pretty well.

The problem is the details. With an app like a news reader that you use everyday -- heck, that you practically live in -- the details make or break the experience. With repeated use, any slightly sharp or awkwardly-shaped bits are going to leave scars and sprains; any especially slick or well-made bits will make your whole day better.

And Google Reader is covered in sharp bits. Here's my running list:

OPML import doesn't respect folder structure. This meant that when I imported my existing 700-ish subscriptions, they were just thrown in chock-a-block. After a week I still don't have them all categorized so I can't just read, say, my batch of watch feeds from various wikis or anything else I might want to scan for urgent changes.
Entries in imported feeds get the wrong dates. At least for me, on importing those 700+ feeds, all unread items displayed with the date I did my import. This made for a disastrous time trying to follow ongoing threads and conversations.
Feeds display most recent first only. This is subtle, but it's a big one. Its effect is to force you to read feeds in the reverse of the order they were written, preventing you from following any continuity.
Paging through items jumps the current item around on the screen. Another biggie. In both list and combined views, hitting 'j' to cycle through unread items jumps the expanded item around on the screen depending on its length and position in the list. Unlike the three-column view seen so commonly in desktop browsers which allows you to keep your eyes still in a single spot on-screen through which items cycle, this jumping causes major eye fatigue and confusion.
Scrolling through items marks them as read too early. If you want to avoid the jumpiness of hotkey paging through entries, you might try scrolling down feeds as I did. If you do that you'll soon discover that feeds below the one you're currently reading will get marked as read before you're ready for them to be, i.e before you've even glanced at them.
No ability to mark something unread. If a post does get accidentally marked as read, there's no way to restore its unread status so you can remember to come back to it later. (UPDATE: Thanks to trusty reader, Will, I now know that hitting 'm' toggles an entry's read/un-read status. Check out his comment below for some other great tips on hidden Reader hotkeys.)
Feeds with one unread entry require a click to mark as read. If a feed or folder only has one unread entry, it will be show on the screen when you select it, usually allowing you to read the full entry. However, the entry will remain as unread until you click on it.
Poor support for increased font size. When you plus-up the font size in your browser (an essential prerequisite for reading large swaths of text like you're constantly doing in a news reader), all of the Google Reader menus go a little haywire and become pretty unusable. Also, being trapped in a browse, obviously Google Reader can't remember your font size preferences between sessions.
Bad Safari support. Running Safari 2.x on OS X, at least, scrolling is all kerflooey. Sometimes the whole page scrolls when only the subscription or entry list should. Sometimes the subscription list jiggles as you click through entries. Sometimes the currently-selected entry jumps off the bottom of the screen. Ugh.
No way to see all feeds/folders at once. Another big one. Whether you're in 'all' or 'updated' mode, the subscriptions panel only shows about 25 feeds or folders at a time. If you have a lot of feeds this will be only a small fraction. There's no way to tell which feeds or folders have the most unread entries or if any feeds or folders you especially care about have new items. It's impossible to get a handle on your whole world of feeds.
No podcast support. Maybe this one is a lot to ask of an online feed reader, but given the excellent experience I've been having the last few days with AmazonMP3.com and its download tool it no longer seems impossible or unreasonable. And podcast downloading is a lot of what I do with a feed reader, so it makes a big difference.

Believe it or not, this is an abridged list.

Taken together, at least for me, all these relatively small problems add up to a death of a thousand cuts. While I still think I'd like some of the features of an online news reader, I don't think I can give up the usability of an honest-to-goodness Mac app with its (even partially implemented) Human User Interface guidelines, rich dependable UI, etc. I think I might try NetNewsWire 3.0. Its NewsGator integration is a baby step towards getting comfortable with an online reader, I'm familiar with the UI and the most recent improvements (especially the previews in the tabbed browsing) seem significant.

Here's hoping Google Reader's OPML export support is better than its import...

Tagged: google, reader, rss, feed, netnewswire, vienna, newsfire, osx, mac, news

Posted by Greg at 2:41 AM | Comments (6)

September 23, 2007

On the Expectation of Privacy in Social Web Applications

Alex Payne from Twitter has an interesting post up about the costs of privacy in social web applications. The thrust of his argument is that respecting the complex privacy requirements of the average non-geeky user increases the complexity of developing and using social software. While geeks might be happy to broadcast their comings-and-goings to the world, non-geeks (by which he basically means girls) have to worry about creeps and hooligans contacting them or, worse, seeking them out in real life.

Without privacy concerns, Twitter would be an incredibly simple service: basically just lists of posts and lists of users, exactly the kinds of data that database-driven web applications excel at providing. But, as Alex says, "privacy mucks this happy scenario up."

"Ask for a list of users on a social network with privacy controls and you're kicking off a complex series of computations behind the scenes. The database can't just retrieve a simple list when privacy is in the mix. Instead, it has to jump around its tables of data figuring out who's allowed to see who. The web application now has to provide different decorations to denote the private users, so you need extra logic and some new icons. Everything just got twice as hard: harder for the machines, harder for the programmer, harder for the designer, and (before this was a common UI pattern) conceptually harder for the user."

Reading this got me thinking: why isn't this a problem in real life? Why doesn't the coexistence of groups of people with conflicting privacy concerns cause problems in the actual public square? If this is really a problem stemming from the introduction of non-geeks, why doesn't it happen at sporting events or in malls where non-geeks are all too prevalent?

In real life, there's no universal system for privacy that tries to work equally well for all people everywhere. Instead there's a custom solution for each place and each community. In America, the governing law here is the Fourth Amendment and the surrounding jurisprudence, which created the doctrine of 'reasonable expectation of privacy'. In other words, our communal sense of how much we'll be seen or overheard in any particular place actually determines whether and to what extent other people are allowed to observe us there. For example, in our own homes we expect what we say and do to stay within our own walls so police are not allowed to eavesdrop on us there without a warrant even though that prospect becomes technologically easier each day. On the contrary, in an obviously public place like a mall food court covertly observing us (or photographing, videotaping, and RFID-scanning us, etc.) is fair game for cops, mall security, and even our fellow citizens.

Put in terms of social web apps: in real life, which of our data can be read is determined not by our social relationship to the person doing the reading, but by which network we're using and what constitutes a reasonable expectation of privacy there.

Seen this way, the real problem that social networks like Twitter are encountering when enforcing privacy is that they are trying to be all places to all people. They want to build one space in which you can broadcast your political beliefs to the world while I, simultaneously and conterminously, whisper my darkest secrets to only my closest friends. In the technical realm, this creates a major problem by preventing the existence of one coherent privacy policy (the way a bank's site might have). Instead, sites like Twitter are required to enforce as many different privacy policies as there are possible relationships between their users. In the social realm, this creates confusion and conflict by hampering the construction of the kinds of social norms that allow for agreement on what constitutes a reasonable privacy expectation to take hold (the way Wikipedia, with its dead simple, basically non-existent, privacy policy does have). Instead, sites like Twitter become cyclotrons filled with constantly colliding communities with different privacy expectations: if I just use the service to keep in touch with my closest friends then even emailing me about each stranger who starts following my updates can become invasive.

The implication of this seems to be that, like in real public places, online communication platforms will eventually have to sort themselves into the general categories of public and private rather than trying to be both at once. And our most successful platforms are already pretty clearly sorted: you know exactly what amount of privacy to expect when sending email or posting to a blog. Since one of the hallmarks of the new social web apps like Twitter and Facebook is that they're trying to break down this very division (or at least host both halves of it under the same roof) they are going to be running smack into this problem on a regular basis. I wonder how long it will take them to do better than the authors of the Constitution...

Tagged: twitter, social network, privacy, constitution, fourth amendment, al3x

Posted by Greg at 3:52 PM | Comments (3)

February 25, 2007

The NY Times Explains the Ratings

In honor of today's 79th Annual Academy Awards telecast, I'm proud to present: The NY Times Explains the Ratings. Continuing the tradition of ridiculous web apps begun with Largehearted Goat, TNYTETR aggregates the short blurbs at the end of each NY Times movie review summarizing how the movie earned its rating.

Ranging from highly-detailed ("'The Number 23' is rated R (Under 17 requires accompanying parent or adult guardian). It has adult language, scenes of animal endangerment, and one realistic-looking slit and spurting human throat.") to pat ("'The Queen' is rated PG-13 (Parents strongly cautioned). There is some tart language.") and sometimes even all the way to cheeky ("'Music and Lyrics' is rated PG-13 (Parents strongly cautioned). It has some sexual situations and naughty language. Parents of a certain age who see it with their children may have to endure some uncomfortable questions about the '80s."), these blurbs function as a kind of highly concise criticism of the movies they describe. When separated from the reviews they originally accompanied, they offer intriguing portraits of movies that consist only of taboo-bendings: violence, sex, profanity, animal endangerment, etc. In fact, taken as an aggregate, the blurbs present a view of what's going on at the local multiplex that looks a lot like what the typical religious right culture warrior sees there.

On launch, TNYTETR only features a small pool of reviews (the ones I was easily able to find on nytimes.com last night, with bleary sleep-deprived eyes), but I'll be adding to it as new reviews are posted and as I find the time to scrape through some of the archives.

But, for now, I'm off to watch the Oscar telecast. It's an exciting race this year. Between "strong language, nudity and intense violence", "salty language", "dirty language and bloody action", "tart language", and "extremely graphic combat violence", it's really anybody's game.

Tagged: ny, times, movie, reviews, academy, awards, oscars, ratings, mpaa

Posted by Greg at 3:34 PM | Comments (0)

December 11, 2006

Web 2.0 or Captcha?

Call them fads, trends, or memes, there's a type of idea that resembles kudzu. It may have evolved to conquer the requirements of a particular intellectual landscape, but eventually it becomes so wildly well-adapted that it spread way wide of its origin.

Case in point: Web 2.0. Starting as a carefully crafted intellectual framework for understanding emerging trends in the architecture of websites, it evolved into a lucrative tech conference and publishing juggernaut, and from thence into a wriggling and omni-present ecosystem of blogs, pundits, technical gurus, and commercial come-ons of all kinds.

When plants like kudzu reach truly far-flung places they begin to become a real problem, choking out native varieties and reducing the richness of the local ecosystem. At this point, the epithet 'invasive species' tends to get attached to them and people start to get t-shirts for participating in efforts to eradicate them.

So, in the spirit of doing a little bit of activist gardening (or at least some jocular mockery), I present:

Web 2.0 or Captcha?

It's a quiz! Below, you'll find ten strings of letters. Half of them are the names of Web 2.0 companies; the other half are the text of captchas I encountered on Blogger (captchas are those little distorted images of words that websites use to make sure that you're really a person before letting you submit information).

See if you can tell which is which. When you've got your guesses, click the links to find out if you're right. Ready…go!

Not that I mean to seriously argue the similarity between Web 2.0 companies and computer-generated bot prevention devices, but don't captchas even look a bit like web 2.0 logos (especially this one)? At least a few fit in each category from The Font Feed's ontology of Web 2.0 logo aesthetics. There are Softies, Futurists, and Classics.

Have we somehow reached a point where all of the barrier-lowering factors which Tim O'Reilly described in his original essay have actually created a kind of Web 2.0 assembly line that grinds out social networking, photo uploading, and information tagging sites so quickly and uniformly as to rival the growth of weeds? And if so, isn't it about time for a higher form of life to emerge and get to grazing?

Tagged: web2.0, logos, captcha, o'reilly, kudzu, quiz

Posted by Greg at 7:51 PM | Comments (3)

November 5, 2006

Safari is an inbox

Do you know that moment between when Safari hangs and when you realize it's about to crash? Or when you accidentally hit 'cmd+q' when what you meant was 'cmd+w'? There are a frantic couple of seconds where you're desperately trying to remember everything you had open, maybe hitting Exposé while you still can and trying to memorize what shows up. You know those seconds? Well, the other day, I had a revelation during them:

Safari is an inbox.

At any given time, my Safari is filled with bits of research, things I plan to watch, things I want to read or buy, blogs I intended to subscribe to, mp3s and applications I'm going to download, etc., etc. Right now I've got about 27 windows open with countless sub-tabs. When I hit Exposé, it looks like this:

Yikes! No wonder Safari crashes all the time, right? And no wonder I'm so horrified when it does. A suddenly and inappropriately emptied inbox means necessary tasks won't get done, new inputs won't get properly acquired, precious research time will be lost.

And yes I know there are ways to get Safari to remember your open tabs. I've tried Saft; I'm not sold. And yes I know that Firefox will prompt you if try to close a window with multiple open tabs; I prefer Safari.

But losing lots of open windows isn't really the problem. The problem is having them open in the first place. Since I hadn't realized that Safari was an inbox, I wasn't treating it as one: processing the items that come in, acting on the ones that require it, filing those that don't, getting it empty. I was suffering from bad 'inbox hygiene', just letting things stack up and stack up and vaguely worrying about them.

But not anymore. Now that I've realized that Safari is an inbox, I know how to deal with it. I can del.icio.us the pages I want to be able to recall in the future. I can capture the tasks represented by my open pages into to-do lists. I can close all my open windows without worrying I've forgotten anything.

In fact, screw you guys, I'm going to shut up right now and go do it. When you next hear from me, I'll have my Safari at Inbox Zero.

Tagged: gtd, inbox zero, 43folders, safari, osx

Posted by Greg at 9:43 PM | Comments (6)

June 26, 2006

The Conversations Network

IT Conversations is kind of like NPR for the web. They provide original interviews as well as audio recordings of conference presentations and panels on a diverse range of subjects of interest to technology enthusiasts. I've been a fan of the site for a long time. Awhile back, I even compiled a list of some of my favorite IT Conversations shows.

Like NPR, IT Conversations is listener supported. Which means that, in addition to a ton of great free and public-minded content, they provide one of public radio's most powerful products: guilt. At the start of each mp3, Doug Kaye, the site's founder, comes on to remind you that IT Conversations only survives because of listener donations and that, as a non-subscriber, you are a worthless parasite.

Recently these pleas for funding changed. Kaye started pitching The Conversations Network. The Conversations Network's website describes it as "a non-profit online publisher of recordings of spoken-word events" and IT Conversations as simply its first channel. It's starting to look like Kaye is really taking up the task of creating a new public radio system for the internet age, rather than simply a public-interest audio site for nerds. And the recent premiere of TCN's second channel, Social Innovation Conversations, confirms that impression. SIC, picks up and extends a theme that ran through many IT Conversations programs: innovative uses of technology, business, and social organization to attempt to solve the large-scale problems of the world: global warming, third-world poverty, etc.

The advent of Social Innovations Conversations finally pushed my guilt meter far enough into the red that I could no longer help myself from becoming a paying member of TCN. I just finished the process of starting a Basic Level subscription for $5 per month, and in oder to encourage you to possibly do likewise, I've compiled another set of my favorite recent shows, this time from both Conversations Network channels:

Globeshakers -- Dean Kamen: Despite the misfortune of being best known for his only real failure, the Segway Human Transporter, Kamen's inventions, including an external automatic pancreas and a sophisticated indoor mobility device, have made real differences in many parts of medical practice. This interview delves into Kamen's current attempts to improve the world on a grand scale: FIRST, his program to make science and technology as attractive to US teens as sports and entertainment, and his attempts to develop decentralized, cheap, and widely available sources of electricity and clean water for the third world.
Peter Diamandis -- The X Prize: The X Prize offered $10 million to the first private company which was able to launch a human-carrying vehicle into space and in the process launched an entire private space flight and development industry designed to bring about all those middle-of-the-twentieth-century dreams about mundane space travel and suburban communities on alien worlds. Diamandas also discussed the prospect of using prizes like this to solve the world's more intractable problems like sustainable energy and universal health care. The best part is the new sport he's working on founding: airborne rocket-car racing!
David Bornstein -- How To Change The World: Bornstein is one of the world's foremost experts on "social entrepreneurship", the process by wish people who want to see large scale improvements to the world harness market forces and individual human ingenuity to acheive them. He studied the Gramin Bank, which provides micro-loans of ten and 25 dollars to small Indian farmers and villages so they can buy a donkey or a generator or start a local cell phone distributorship.
Alex Lindsay -- The Next Generation of Digital Craftsmen: Lindsay is the founder of the Pixel Corps, a kind of internationally socially conscious media-workers guild modeled on the organization of the organizations formed by 16th century skilled laborers. He makes a coherent, believable, and optimistic account of the future of the globalization of high skill media labor.
Drew Endy -- Open Source Biology
: A fascinating look at the IP and access issues starting to come up in biological engineering, which is, apparently, getting to the point where the tools are cheap and the methods simple enough that anyone could do their own genetic engineering if only the basic building blocks of life hadn't already been patented.
Rob Curley -- The Newspaper in an Online World: Rob Curley is a caffeine-fueled firebrand of online newspaper revolution. In this talk he explains how he helped transform the sleepy Lawrence Journal-World into a cutting-edge interactive community-driven local-obsessed multi-media juggernaut. From covering local little league teams like they were the New York Yankees to forcing political candidates into direct online chats with their constituents, Curley uses the best of internet publishing technology to fulfill the long-standing missions of local journalism.
Don Gould -- Pure Water 4 All: It's hard to put my finger on exactly what was so exciting about this conversation. It's about a clay water filter designed to be built, distributed, and sold locally in poor countries around the world to prevent water-borne diseases. There's something about the elegance of the whole project: from its low tech but extraordinarily sophisticated engineering to its brilliant bottom-up distribution methodology, every part of it is incredibly carefully considered, even beautiful. It approaches a problem which often attracts abstract, utopian, and ultimately temporary solutions (poverty-based health issues in the poorest parts of the world) with an idea that is concrete, natural, and organic.
Jamais Cascio -- The Participatory Panopticon: Exciting and scary talk about how ubiquitous recording technologies like cameraphones and other "personal memory management" aids, which appeal to our desire to document and perfectly recall all of our experiences, will gradually evolve into a restricting universal observation system that penetrates even into our own memories and most private moments. Cascio descibes this dis/u-topia as evolving gradually not via top-down imposition by some Big Brother, but step-by-step through our own choices.

Tagged: itconversations, doug kaye, social, innovation, conversations, conversations network,summer listening

Posted by Greg at 4:26 PM | Comments (1)

May 29, 2006

Toward Actual Open Source Web Applications

In the twinkling buzzword constellation that constitutes the Web 2.0 firmament, "open source" is one of the brightest and most twinlky of stars. In Tim O'Reilly's original article announcing the concept, the phrase appears in no fewer than seven different (highly jargonic) contexts: (1) commodity servers running open source operating systems, (2) open content creation through peer-production methods, (3) open editing of collective knowledge repositories, (4) open architectures that build collective value automatically through users pursuing their own "selfish" interests, (5) users treated as a collective of co-developers, (6) software that remains in perpetual "beta" -- a state of constant development in which the product is never declared finished -- and (7) open access to data via RSS and APIs.

As O'Reilly tells the tale, contemporary web applications have interacted with the open source software community in just about every way possible: they've consumed its products, they've aped its architecture, and they've even co-opted its rhetoric and style. The one thing they haven't done is actually open source their own applications. And I'm beginning to wonder why not.

Why aren't there any websites that are truly open source? Why aren't there any websites that are actually written and maintained by a hierarchy of volunteers checking out and modifying liberally-licensed source code from a public repository?

Open source thrives in the context of commodity software that's needed by a large number of people, especially geeks, and for which branding and marketing provide little competitive advantage: think Linux, Apache, and Firefox. The web certainly has no shortage of applications that fit this bill (search and wikis come immediately to mind). So what are the practical obstacles preventing open source coders -- who've rushed eagerly into just about every other class of software -- from building web applications? What's the hold up?

One obstacle might be infrastructure. Where desktop and server software can be easily compiled and run locally on each individual contributor's computer while they work on it, mainstream web applications (e.g., Google) require extensive server hardware and voluminous bandwidth capacity far beyond what is available to the average web coder.

On the other hand, these need not be barriers to the development of such applications, merely their deployment. Contemporary development platforms, such as Ruby on Rails, come packaged with everything necessary to be built, tested, and run locally including a lightweight development server, a full-stack application framework, and a fully-integrated testing environment. With smart use of good testing practices such as mock objects and fixtures the run-of-the-mill personal computer can become a viable development platform even for large and complex web applications which require enormous quantities of data. And further, if such an application were designed in the emerging contemporary style as a series of independent modules which communicate via an API, the problem would be even further reduced, becoming mostly one of coordination and management like any other open source effort.

And the deployment problem is not necessarily intractable either. I see two potential solutions: the benevolent giant and the swarm of peons. Think of the enormous server and bandwidth resources devoted to open-in-spirit web applications by such non-profit organizations as the Wikimedia Foundation, and the Internet Archive. An entity at that scale could easily step up and provide the necessary infrastructure for an open source web application that was being written by volunteers. Further, such an organization would almost definitely have the clout and community mindshare to create such a project in the first place if they wanted.

The second potential solution is a little more out there. With just a dash of wickedly ingenious infrastructure mojo, the massive computing demands of a start-up open source web application could be distributed amongst its organizers, maintainers, and testers themselves. Using a shared computing architecture along the lines of Berkeley's SETI at home, the big chunks of data processing required by, say, the spidering and indexing capacity of our open source search engine, could be broken up into bite-sized bits and chewed up by a network of volunteer personal computers.

I'm sure each of us could think of a handful of other obstacles, both technical and social, facing anyone wanting to build a true open source web app. But I'm also sure that if the conversation got started, we'd just as quickly start coming up with solutions. That's the advantage of open source. As the old chestnut -- which I'm sure I saw quoted in O'Reilly's essay -- goes, "with enough eyes, all bugs are shallow".

Tagged: open, source, software, web, application, web2.0, o'reilly, ruby, rails

Posted by Greg at 3:02 PM | Comments (0)

March 13, 2006

Why Rails?

While in a less than fully sober state after the Less Distracted Party last night, Chirs made a disturbingly sound suggestion: now that I'm posting Rails tutorials with some regularity, it might be a good idea to write something about why I find Rails so exciting in the first place and, more specifically, how it fits in with the kinds of things I've always posted about here in the past.

Anyway, what's my answer to Why Rails?. My answer doesn't involve any technical mumbo-jumbo about it being a "fully-integrated web mammy-jammy that requires less XML flim-flam"^[*], my answer is simple: Rails lets me make my ideas real. Let me give you an example.

For the past week, I've had a couple of ideas cooking for posts. They're both in the classic IDFDZ style: ideas for ways that common technical experiences could be improved or that technology could be made more useful in everyday life. They would fit comfortably amongst posts like: Bloggable Public Space, Hyperlinks for iTunes, and Use Automator to Append from Anywhere -- things I tend put into the category of Useful Web. The thing is, I haven't posted them because, now that I know Rails, writing them up seems like almost as much work as actually executing them myself.

Here are the ideas:

(1) Mp3 Blog-o-Sphere Influence Map - As part of my preparation for the coming At Dusk New Album Promotion Whirlwind and Clambake^tm, I spent a big part of a recent evening making a mental map of the mp3 blogosphere. Now, if you're interested in mp3 blogs, but don't have the thousands of hours it would take to even glance briefly at, say, the two hundred most interesting ones, there's a variety of search engines, indexes, and compendia like elbo.ws, Web Nymph and, of course, Hype Machine (which is easily the best of them) to help you out. They're all great for finding a few of the best blogs or some that might happen to cater to your particular taste. But what they won't give you is a sense of the overall geography of the mp3 blogosphere itself: who listens to whom, which are influential but more obscure, who gets the hot leaked tracks first, who sets opinion in each genre, etc. While staring at my text file with more than 250 urls for mp3 blogs, I had an idea for an app that might be able to start to answer some of these questions. It would begin with a database containing those blogs names and their urls. Then, it would include a script that would, periodically, look at each of the blogs to see which ones linked to which others, to start a map of the social connections. Next, you could start to track songs as they appeared on each blog (by looking at the text of links and even the names of the files that get linked to) and tracking their progress as the got picked up by more blogs and moved through the chain of influence. To put a cherry on top, you could even use the Technorati API to find out which blogs talk about which other blogs and which posts shared common tags. With the data I'd already collected and just the tiniest bit of programming elbow grease, you could start to put together a pretty good picture of how the mp3 blogosphere worked, a picture that might be of interest to quite a few people: aspiring bands, recruiting labels, music pr and marketing muscle, etc.

(2) The Useless Flickr Historical Weather Search - The last week, we've been having incredibly bizarre weather in Portland. It even snowed heavily late one night, enough to stick if only for a few hours. Being a night owl, I caught a picture:

While I was uploading it, the thought crossed my mind that the snow's appearance was so brief that, for plenty of Portlanders waking up the next morning, the presence of my picture in their RSS inbox might be their only direct evidence of it having snowed at all. Also, I realized that, in the metadata to my photo (and I'm sure plenty of other people's), there was as cogent a weather report as I'd ever seen. Tags: "portland oregon night snow storm" and Date: "Taken on March 9, 2006". Pretty soon I was clicking around the tag cloud and realizing that you could, with erratic success, use Flickr to tell you what the weather had been like in a particular city on a particular day. I could see an app: type in a city, state, or country and a date in the past, and find out the weather, with pictures. Did it snow in New York on your grandmother's birthday last year? Was it a White Christmas in Chicago? Once you'd correlated the weather, location, and date together, you could show pictures of what it looked like. Graphs! A widget! You get the point: useless, somewhat playful, kind of surprising use of a photo sharing site to reverse-predict the weather.

Now neither of these ideas are particularly technically challenging or all that innovative or exciting. There's probably no money in either of them. What they are, basically is frivolous. The thing is, now, I'm almost sure that I've spent longer writing them up than it would have taken me to build Rails-based sites that would constitute at least basic 0.1 alpha versions of them. Since Rails handles all of the things that get repeated across each new web application project now matter how big or how small (and handles them with a great deal of grace and ease) it makes the small ones almost too easy. Without the overhead, all you're left with is the idea. And if it's modest enough, as these certainly are, and you've articulated it clearly enough to yourself, there's really very little work involved in making it real. Rails makes building frivolous applications practicable.

For example, the biggest single chunk of time on the mp3 blog app would be taken typing in the names and urls of the blogs themselves (in fact, it would almost definitely be faster, at this point, to write a script that would import them wholesale from my text file). On the Flickr app, the big technical challenge is actually talking to the Flickr API (I've been glossing over this: API stands for "application programming interface". With web apps like Blogger, and, especially, Google the companies behind them make their data and functionality publicly available for use by other people over the web. That's how you see Google maps on every new website and blogging software than can send your posts directly to your Blogger blog.). But there are such great tools for talking to the Flickr API in Ruby, that doing so has been compared to writing florid love poetry.

Rails development is so easy and quick that there really doesn't have to be a practical motive (let alone a financial one) for taking on small projects like these. Put another way, Rails makes it possible for web development to become art: an expressive medium whose practice is an end in itself.

^[*]Some technical jargon may have been removed from this sentence for your protection -- ed.

Tagged: ruby, rails, api, app, development, rapid, agile, why

Posted by Greg at 4:03 AM | Comments (0)

February 1, 2006

Secret Structured Google Music Search

I do a lot of Google-searching for lyrics. I mean, a lot. I spend part of my day hand-screening suspicious looking new MFDZ uploads for piracy (for example, I don't think that cutegirl457 really made the song "50 Cent - In Da Club"). I've found that the best way to suss out more subtle pirated uploads (ones that don't provide the name of the actual artist or the song themselves) is to compose a Google search that includes the word "lyrics" and some of the words that you can pick out from the song (one big obstacle to this strategy is that you've got to find lyrics that aren't such a horribly common cliche as to be useless, which can be a challenge with some of the terribly cheesy music that gets uploaded). These kinds of searches usually return a page full of links to lyrics or fan sites and I can usually hunt down the song from there.

I do this so regularly that I was totally shocked last night when I idly searched for "M83" and the top hit took me off to a whole Google music universe that I never knew existed.

For each artist, they've got links to a list of their tracks, to their homepage, to the results of a Google image search about them, and to a Google group for discussing their work. The goodness goes all the way down to with album pages with track listings, links to reviews, and album art as well as track pages with links to various different download purchase options. (I wonder if Google is an iTunes affiliate and gets paid when people click on these links. If that's true it might make the universe explode.) Their catalog of who shows up seems to be pretty robust, too, insofar as my five seconds of test searches can show: Broken Social Scene was the only thing I tried that didn't work, Madonna, Metallica, The Arcade Fire, The Strokes, Philip Glass, Animal Collective, Juan Martin, and Madvillain were all in the system.

This seems like an incredibly helpful service and kind of an excellent model for ways of aggregating raw search data into meaningfully arranged structured data. Way better than the artificial user-entered system of Google Base. I mean this is all user-created data itself, after all. Just in this model people are able to create the data wherever they want all over the web and then Google can subtly combine it together into a useful service rather than forcing people to come to them to play.

I wonder if they do this for any other types of information. Books? Movies? Government transcripts? It kind of seems like they should. . .

Tagged: google, music, search

Posted by Greg at 4:59 PM | Comments (0)

December 6, 2005

Feature Request: Where'd I Put That Darned Link!?!

A couple of days ago, I was doing some research on the web. It was totally run of the mill stuff: opening a bunch of windows each with countless tabs and then jumping back and forth between them in order to compare or capture certain aspects of a bunch of different similar things. In this case, I happened to be trying to find a Ruby class that would help me help with screen scraping (Rubyful Soup turns out to be the best solution, if you're curious), but I might as well have been looking for indie rock music venues in California near universities, the submission email addresses for mp3 blogs that might write about my band, or maps of apartments around town that my shiftless basement-dwelling sub-leaser could rent. We've all done this kind of thing. A lot of us do some task that involves this kind of workflow on a regular basis.

One problem that pops up in a task with this structure is: You're looking at a link. Is it already open in one of those other zillions of tabs marching across any of your quadrillion open windows? And if so, which cotton-pickin' one? Now, your browser will tell you whether or not you've visited the linked page before by changing the color of the link's text, but is that tab still open? And where is it? These are harder questions.

It seems pretty obvious that the browser should help you out here. What are the odds, really, that you want to have the same page open in more than one tab? The default behavior when clicking on a link to a page that's already open should be to bring that open tab to the front. You could probably write an Applescript (or use Greasemonkey if you swing that way) to hack your way to this behavior, but it would certainly be nice if these so-called modern browsers would step up and handle it. If we're going to have a browser war, at least we could get some tasty conveniences out of it!

Tagged: browser, tab, RubyfulSoup, Safari, Firefox

Posted by Greg at 6:30 PM | Comments (0)

November 29, 2005

Use Automator to Append from Anywhere!

It turns out that one of the hardest parts of accomplishing things is remembering that you wanted to in the first place. The productivity pros call this 'capture': the ability to catch your ideas and to-do's whenever (and wherever) they occur. Now there's lots of good ideas for systems you can use to achieve capture that's as effortless and as universal as possible. For a while, one of my favorites has been the 43 Folders' Quicksilver append trick.

What's great about the append trick is that it lets you achieve capture without shifting away from what you're already doing. That way, you catch your ideas without losing the thread of thought or getting too distracted from the work that brought you to them in the first place. Now, an obvious next step would be to figure out a way to have this same option available to you when you weren't sitting in front of the computer.

Recently, a blog post on how to put your mac to sleep by sending an email gave me an idea for how to do it. I started working on an Automator action that would look for new emails from my phone with the subject line "todo" and append their contents to my master TODO.TXT file. Here's a screen shot of the final action (it's kind of long):

And here's a more detailed breakdown:

Finder > Find Finder Items (give it the location of your todo.txt file)
Finder > Open Finder Item (set open with to TextEdit)
Mail > Find Messages In Mail (find messages, not mailboxes or accounts, set the Sender to your phone's email address (mine was my phone number @ vtext.com, if you don't know yours, you can find out by sending yourself a text message -- you may have to explicitly set your spam filters not to catch this address, they seem to like addresses with lots of numbers in them) also, make sure you use the arrow to tell this action to "ignore results from previous action")
Mail > Combine Mail Messages (this will output the email messages as text)
TextEdit > Filter Paragraphs (in order to avoid ending up with a bunch of ugly mail headers in your todo file, you've got to filter out a bunch of lines -- I set up rules to return paragraphs that are not empty, and do not contain: "*", and do not begin with: "SUBJECT", "DATE", "SENDER", and "RECIPIENT")
TextEdit > Set Contents of TextEdit Document (set the pulldown option to "by appending" so you don't delete the whole contents of your file each time)

Now, all you've got to do is follow the instructions in the how-to-put-your-mac-to-sleep blog post to learn how to trigger this action whenever an email arrives from your phone and you're good to go. With this system, you can get one step closer to never forgeting a great idea or an important responsibility again.

Tagged: automator, mail, append, quicksilver, 43folders, applescript, todo, capture, gtd

Posted by Greg at 12:02 AM | Comments (7)

October 18, 2005

How To Do More Than One Thing At Once: On "Lifehacking"

With Clive Thompson's article in this weekend's NYT Magazine on "Life Hackers", a recent growing trend has reached a fever pitch: a kind of nerd revolution against nerd-made tools. As the article outlines, "Multi-tasking" became the expected mode of office work -- all computer-based work, really -- with the universal adoption of the PC and its subsequent networking. Once all your work and all your communication takes place through the same box, you end up constantly distracted, interupted, harried. Suddenly productivity geeks like Merlin Mann and Danny O'Brien find themselves trying to find ways to simplify, reduce, and focus, to turn off the metastasizing bundle of "multi-tasking" tools so they can, for godsake, actually get something done.

Part of the problem, it strikes me, is in the metaphor of "multi-tasking" itself. While the modern GUI is composed of an ever greater number of applications running simultaneously, the user ends up not using them all at once, but cycling rapidly through them one at a time conducting a series of different -- and often unrelated and mutually disruptive -- tasks. It might better be called "sequential tasking" since it's only ever the computer that's doing multiple things at once (keeping all those apps open in the background, patiently waiting for your attention to flit back over to them).

Now, after two years of working at a French dessert shop, I'm a pretty efficient waiter. You might say that when it comes to all the systems for prepping dessert and drinks at Pix Patisserie, I'm a power user, an alpha nerd. What makes me an efficient server isn't that I move any faster than my co-workers, or even that I know where everything is better than they do. My real advantage is that I've figured out all the places where I can do more than one thing at once: while I'm waiting for a teapot to fill, I prep the mug teabag, and other drinks; while a chocolate cake is heating, I scoop the ice cream that goes with it; etc. I've learned that their are some taks I can comfortably overlap (checking in with the host while making coffe drinks, for example) and some I can't (answering questions about prices while adding up tabs).

What it comes down to is if the tasks are different enough in mode (communication vs. dexterity) I can overlap them, but as soon as they get too similar (adding v. remembering numbers) I get confused and it takes me longer to do both tasks than if I'd taken them on in succession.

Similar limits take effect while working on the computer. I can listen critically to a podcast from IT Conversations or On The Media while working in Illustrator, but not while composing a Music For Dozens press release or reading 43 Folders. Contrarily, while writing or reading, I can listen to MFDZ tracks to screen out My Chemical Romance songs, but I can't watch a movie or TV show in the background and still follow the plot.

Finding sets of tasks like these that overlap well is the greatest possible productivity win. Much better than more efficient modes "multi-tasking" that let you switch rapidly between incompatible activities in order to minimize the ill effects of interruptions. When you've got a good overlap going, it's like your available time doubles. You are actually getting two sustained tasks done simultaneously.

The key to successful overlap sets is that each task utilize different sensory inputs and different modes of concentration: listening for recoginition of a song uses your ears and an automatic type of attention (when you hear a familiar song, you know it without having to do anything active).

Unfortunately, many of our tasks are stuck in one media type or another and so we're stuck tackling it using a fixed sensory input. I can't read email while I'm working in Illustrator, not because my brain couldn't handle it, but because both of those taks want to use my eyes as their input paths. We don't just need bigger screens, as the Thompson's article seems to suggest, we need ways of translating our taks away from our eyes, more information chanelled through auditory, and even haptic outputs. Here are some wild ideas for accomplishing this:

automated email reading using good voice synthesis: When I'm using Illustrator and I get a new email, my mail client should know to read its content aloud without Mail ever having to switch into the forground or even display anything on the screen. (For this -- and some of my other ideas here -- better voice synthesis than at least I've heard would probably be a necessity, or at least a great luxury).
haptic alerts: My chair pokes me or my bluetooth cell phone vibrates when a process completes and my computer knows that I'm in the middle of reading a web page. In order to never have to break my task overlap, I should also have a button or key-combo I can hit to trigget an obvious next action to follow the alert (for example, opening a disk image that just completed downloading or playing some audio files that just finished ripping).
smart web page readers: A tool that can read the actual content of a web page while ignoring the ads and other navigation. Maybe this exists already (it seems like it must for accessibility) but I've never seen it packaged as a productivity app. Again, this requires really good voice synthesis that I don't have to struggle to understand and that won't drive me batty over a long article. Another way of accomplishing this would be for more content providers to offer audio versions of their articles. In the world of podcasting, this seems desirable under its own merits anyhow.
tools that make it easy to switch seamlessly between modes: If I start reading a long NY Times in front of my computer and then I have to go downstairs to get and fold my laundry or if I have to go out to run my errangs, I should be able to switch over to an audio version (either speech generation or a provided human-read mp3) at exactly the place I left off. And then I should be able to switch back to reading when I return to the computer so that I can simultaneously listen to music.

(If anyone can think of any other wild ideas like these, or ways of accomplishing some of what I'm dreaming of I would love to hear about it in the comments.)

Technorati Tags: lifehacks, 43 Folders, productivity, multitasking, Merlin Mann, music

Posted by Greg at 1:07 AM | Comments (3)

September 14, 2005

An Upload Manager for the User-Writable Web

Uploading a bunch of photos to my Flickr account as well a live performance art recording to MFDZ in the last couple of days, I began to get frustrated with how the file upload process as a whole works on the web.

There's basically no support for uploading at all in any browser I've ever seen. While your file's heading over to the site's server, the browser just waits to hear back. Often times, even though the browser's given you no feedback to this effect, closing the window will disrupt the file transfer, preventing the file from actually uploading.

Sites that take user uploads all the time have had to build nasty hacks around this problem: reminders not to close the window, tiny little windows that open up and hide in the background, crazy ad hoc progress bars with a million page refreshes, whole helper applications that have to run on the desktop, etc. While some sites, Flickr comes strongly to mind, have managed to minimize the pain, the process never seems natural, like you're forcing the browser to do something it doesn't want to.

Contrast this with what happens when you download a file from the web. The browser does all the work for you. A nice little window pops up with a progress bar and a record of your previous downloads. This Download Manager makes it convenient to find files on your local drive once you've downloaded them or to kill any uploads while they're still in progress.

As the web becomes ever more 'two-way writeable', as we start to spend more of our time online uploading our own creations rather than just passviely consuming those of other people, we're going to start to need Upload Managers. I'm sure there's all kinds of technical details I don't understand what it would actually take to implement something like this, but I've got some suggestions for what I'd like it to do from a user's point of view. I even dummied up a little visualization:

Here's the way I picture this working:

Fill out an upload form (like Flickr's Upload Manager) and click the "Send" button.
Your browser's "Upload" window pops up with a progress bar for your new item (like the bottom entry in my mockup). Simultaneously, the browser loads a return page on the site that sent you.
While the upload is in progress, you can use the Upload window to keep track of its progress or to cancel it. You can also keep browsing around the web as normal without having to keep a particular window open.
When the upload finishes, the browser sends an alert just like on the completion of a download (Safari, in OS X, hops up and down in the dock). Also, the progress bar disappears and the Upload window display links both to the original file on your drive (the folded paper icon) and to the appropriate url on the destination site (that would have to be supplied by the site to which you were uploading). This history would stick around until you manually cleared it, giving you easy access to all your most recent uploads around the web.

It seems like once this process became widely adopted, sites might want to be able to trigger JavaScript on the completion of a download or be able to access the Upload manager for other reasons (or bookmarklets might want to use that event for something so cool that it would be hard to think of now). It could be a platform for all the new types of user interactions we're going to need for this new kind of user-writable web.

Technorati Tags: Upload, Manager, Flickr, Web 2.0, Safari

Posted by Greg at 5:27 PM | Comments (3)

May 27, 2005

A Little 43 Folders Love

Nothing gooses me out of a laziness-inspired blog hiatus like a good linking. Today, Merlin Mann of 43 Folders, a better and better read blog dedicated to "a bunch of tricks, hacks, and other cool stuff" related to productivity and organization, wrote an entry about my Guest Check PDA idea. Before I saw the post, I was kind of wondering why 400 people seemed to have looked at a couple of the pictures in my GCPDA Flickr photoset today and now I know why.

If you are coming here for the first time looking for info about the Guest Check PDA, check out the original post. Welcome.

Tagged: 43folders, Guest Check PDA, hipsterpda, PDA

Posted by Greg at 7:08 PM | Comments (0) | TrackBack