App idea: search CocoaBuilder for current Mail message

There are times when I'd like to find out the CocoaBuilder URL corresponding to a message I'm reading in Mail. For example, say I'm composing a message to cocoa-dev and I want to refer to an earlier thread that was relevant for some reason — maybe to say "this was already discussed to death <here>", or "I'm trying the code so-and-so posted <here> and I can't get it to work".

Another example: I might be doing something in my code based on what someone wrote on cocoa-dev, and I want to paste a URL into my comments for attribution and/or explanatory purposes.

Or maybe I want to include the link in a blog post, or in a tweet.

For whatever reason, I'm looking at something in Mail and I want to get the URL for it. If it's very recent I might just go to CocoaBuilder.com and page backward in time until I find it. But if not, I'll have to enter search terms and poke around until I find the thread I want.

It would be much more convenient if there were a little app sitting in my Dock that I could drag the Mail message to. The app would construct a search that is likely to find the message I want and it would take me to my web browser to show me the search results. (Instead of using CocoaBuilder's search feature, I would prefer to use Google with a site:cocoabuilder.com option, but I think this violates Google's terms of usage.)

Why would I be looking at the message in Mail? Why wouldn't I have searched for it in CocoaBuilder in the first place? The reason is that Mail does very fast substring searches against a local index, whereas CocoaBuilder only does keyword searches, has more latency, and can't search based on email addresses since those are stripped out of the archives. Searching in Mail can be much faster if you're pretty sure you have the messages you want in your mail archives.

I've had this idea for a while, but the reason I felt like posting it now was a recent thread on cocoa-dev. If this app had existed already, I could have used it to help me link to that thread — well, except for the fact that I wouldn't have written this in the first place.

App idea: the Steve Ward diet

In an article called How the Web and the Weblog have changed Writing, Philip Greenspun writes:

In the 1980s Steve Ward, a professor of electrical engineering and computer science at MIT, described a sure-fire dieting scheme. "All that you need for my diet is graph paper, a ruler, and a pencil," Steve would explain. "The horizontal axis is time, one line per day. The vertical axis is weight in lbs. You plot your current weight on the left side of the paper. You plot your desired weight on a desired date towards the right side, making sure that you've left the correct number of lines in between (one per day). You draw a line from the current weight/date to the desired weight/date. Every morning you weigh yourself and plot the result. If the point is below the line, you eat whatever you want all day. If the point is above the line, you eat nothing but broccoli or some other low-calorie food."

Steve noted that this could also be called the "Bang-Bang Servo Diet" but that would likely be confusing to non-engineers (see http://en.wikipedia.org/wiki/Bang-bang_control).

Steve's diet is probably more effective than most popular diets. How come he isn't a bestselling diet book author? How do you turn an idea that can be explained in one paragraph into a diet book that people will buy?

I also wonder: has someone created a web site where people can implement this diet without needing even the graph paper and pencil? It could be sponsored by one of the bathroom scale manufacturers. People could choose to make their charts public and give each other moral support. The web site could send automatic email feedback — congratulations when you've hit a milestone, encouragement and suggestions if it detects you've been slipping, and gentle nudging if you haven't updated the chart in a while.

Seems to me this would also be a natural idea for a desktop and/or iPhone app, with or without some sort of online aspect. I wouldn't be surprised if somebody's done it already, but I'm too lazy to search the App Store right now.

P.S. One reason I thought of the email reminders was something I saw on The Skeptical Hypochondriac:

A recent study found that email reminders can make a huge difference on the amount of physical exercise done by recipients.

Idea: iagity.com

Perhaps you've heard of lmgtfy.com. It provides you a snippy answer ("let me Google that for you") when someone asks a question that could easily have been answered with a Google search. I find that pretty annoying myself, especially when there are obvious search terms (often embedded in the question itself) that would seem likely to produce relevant hits.

Them: Where can I find the Moriarty sample code?

You: http://lmgtfy.com/?q=moriarty+sample+code

The link goes to an animated page that literally spells out for the questioner how they could have done their own Google search if only they hadn't been so clueless and/or lazy.

But now let's turn that around. What if you're the one with the question, and you've already tried the obvious Google search and there were either no helpful results or too many results for you to pick a good answer? Or you have a feeling you could find the answer with the right search terms, but none of the searches you tried was quite right?

To take the example above — if you'd seen Apple's Moriarity code mentioned somewhere, you might easily misremember it as "Moriarty", as in the name of Sherlock Holmes's archenemy. (Remember an early precursor of Spotlight was called "Sherlock".) You might easily search for the "wrong" thing and wonder why the heck the "obvious" Google search didn't work.

Enter iagity.com. It would present a page that says "I already Googled it, thank you", followed by a link to the Google search you tried.

You: Where can I find the Moriarty [sic] sample code?
http://iagity.com/?q=moriarty+site%3Aapple.com
http://iagity.com/?q=moriarty+sample+code

Them: Google for "moriarity sample code". Note the extra "i" in "moriarity". You could also have found it by Googling for "moriarty" on developer.apple.com instead of apple.com.

By providing an "I already Googled" link, you can pre-empt the wise guys whose first instinct will be to send you an unhelpful "let me Google" link. With two clicks they'll be able to see for themselves why the search you tried didn't work for you. If they have a helpful suggestion of what to Google for, they can tell you to Google for it. But they can't accuse you of not trying.

The iagity home page should provide a bookmarklet that I can add to my Favorites bar. When I'm looking at Google search results, I should be able to click the bookmarklet and it should convert the Google search URL to an iagity URL. I wish lmgtfy.com had such a bookmarklet, because when I tell people to Google something I usually Google it myself first. (Before you tell me http://lmgtfy.com/?q=lmgtfy+bookmarklet — I already Googled it, thank you. There are bookmarklets, but I haven't found one that does what I described.)

As of this writing, iagity.com is available. I might take it, but I'm behind on so many things already. If someone wants to beat me to it, knock yourself out.

Idea: text files plus svn for iPhone list makers

[Note: What follows is just an idea, very possibly a flawed one. I doubt I'll try to build this any time soon. Feel free to beat me to it!]

I just switched from the iPhone's built-in Notes app to an app called Notebook, by Appigo. It's nicely done and looks really good in Verdana 14, but of course it isn't exactly what I want, because no text editor in history has ever been perfect for anyone.

Besides looking as nice as Notebook, here are three features I'd like in an iPhone notes app. If such an app exists, I'd love to know about it.

  • Svn for online storage: Do svn checkouts and commits against a repository where I've stored text files. Do svn adds and deletes as appropriate.
  • Paragraph-based operations:
    • Have gestures for moving the current paragraph up and down. This would help move a paragraph without having to stupidly delete it and retype it.
    • Have gestures for cutting and pasting the current paragraph. If you're a vi user, think "dd", then navigating somewhere else in the doc, then "p" or "P". Unlike in a desktop app, cutting shouldn't be allowed if the paste buffer has something in it, and pasting should clear the paste buffer. This is to prevent accidentally blowing away something I'd cut and meant to paste somewhere.
    • Have a separate gesture for deleting the current paragraph without affecting the paste buffer.
    • The paste buffer should survive between launches of the app.
  • Randomness: View five random paragraphs.

"Svn for online storage" comes from the fact that I want to edit my files on both my iPhone and my computer.

"Paragraph-based operations" comes from the fact that I use text files for lists. I've tried list-oriented apps but I keep coming back to text files.

"Randomness" comes from the fact that I jot down all kinds of things in a single text file on my iPhone. (Indeed, I might not mind if my hypothetical app only supported one text file.) My text file contains not only to-dos but odd things people said, random philosophical musings, ideas for apps I wish existed, the attendance list from the last CocoaHeads (no reason, I'm just a packrat for this kind of info), book titles I see at the store and want to Google when I get home, and so on. I don't prune the list as often as I should and sometimes stuff in there is months old.

I think it might trigger interesting thoughts to see a random sampling once in a while. Imagine shaking the iPhone, or doing some other gesture that means "random," and seeing the following appear (actual items from my list):

  • Hot dog rebar
  • Bear little brain simple caveman
  • Pacquiao Hatton
  • Try Bee apps
  • Exploit my appetites

("Hot dog rebar" is a technique one of my coworkers mentioned for making meatloaf.)

It seems to me the hardest technical and design challenge would be using svn. Appigo's app lets you sync your notes online if you have a Toodledo account, and this works very nicely, but it doesn't merge changes: the last update of a file wins. So if I make some edits on my phone, then get home and without thinking make some edits via the web site, doing a normal sync will cause me to lose data.

This is why I've been keeping the to-do list for AppKiDo in a text file in svn. I can edit it on my laptop or my desktop without having to remember which machine has the latest edits.

I don't know if the iPhone can be an svn client. It might have to upload files to a hosted directory somewhere that would be a proxy for the iPhone, and tell the host to perform the svn operations. This means writing server code, but might be the only/easiest solution.

What about svn conflicts? Offhand I don't think I want to resolve conflicts on the phone. It's too ugly a task even in a desktop app. My first thought is to check first if there's a conflict, and if so, don't do the svn operation. Then I need to figure out some other way to get the changes from the iPhone into the document and get the merge back down into the iPhone.

Svn diffs would be tricky to do well, but could be valuable so I'm reluctant to leave the feature out altogether. It would be nice to come up with a nice way to view diffs on the phone, but worst case, I could view the raw output of svn diff.

Just to play my own devil's advocate for a minute: instead of all the work of figuring out an svn-based solution, maybe I could live with the Toodledo model, and just be careful to sync my iPhone frequently.

I haven't thought much about a name for this hypothetical app. How about "iNapkin"?

UPDATE: A possible alternative to solving the svn problem, which may or may not make sense: how about when you "upload" the file from the iPhone, the entire file gets HTTP-POSTed to an "upload URL" that you specify. The response is some XML that may contain a modified version of the file that will replace the file you uploaded. Then people can implement the server side of this — the thing the URL points to — however they want. There's probably some smarter pattern/implementation for this already. Just putting the idea out there — and now I have to run to something I'm late for…

UPDATE: I have switched editors again.