Take this little example, for instance:

$ for file in *.txt; do mv $file "$file.old"; done;

If I’m typing that at a command line, my expectations that I’ve typed it exactly right the first time are pretty low. In fact, just now I had to try a couple times before I got everything right for that example (I forgot the “do” the first time, and then I had “for $file”). So just before I hit enter I always have a feeling of hope mixed with fear: I hope that I got it right, but I’m prepared to see a disappointing error message and have to try editing my input again before submitting.

Here’s another example:

Phone number:

Is that going to work when I submit the form? Maybe, but I’ve also had plenty of times when a form gave me an error message because I didn’t format the phone number right. So I’m not completely confident that my input is going to be accepted, even though it’s just a phone number.

Fortunately there’s a well known solution to this kind of problem: WYSIWYG. In a WYSIWYG interface, What You See Is What You Get. In other words, the input interface shows you what the output is going to be. So when you hit print in Word, you’re not crossing your fingers that your printout is going to have the right words in italics. You know those words are going to be italicized because Word is displaying them in italics right on your screen. WYSIWYG gives the user assurance that their input has been understood.

Unfortunately, web forms are usually not WYSIWYG. You’re typing into an input box and hoping that you’re not going to get any error messages after you hit submit. This is an unpleasant experience. A lot of web apps could be improved if the input provided feedback as you typed. Today, programmers might try to do some of this by showing error messages next to the input box in real time, or by making a custom UI control. But to me the ideal thing would be to have a nice text input box where I can use native keyboard shortcuts, copy and paste, and tab around, while still being able to have a visual indication that my input is (or isn’t) being understood.

So to make that possible I just started a new mini-project, which I’m calling Rich Text Input.

The goal of Rich Text Input is to provide an enhanced text input box that uses HTML formatting to give feedback about how the user’s input is going to be interpreted. It’s not a rich text editor – the output is still plain text, and behind the scenes the user’s input is still going to a regular <input> element. The purpose of the rich text formatting is to give the user feedback, and give them confidence that their input is going to be understood as intended.

Here are some possible uses:

• syntax highlighting code snippets
• validating credit card numbers, phone numbers, and zip codes
• styling email addresses and tags

If you wrote some code to round-trip the input to the server (like search engine auto-suggest inputs do today), you could do some even more interesting things:

• a tag list in which the color of the tags represents how “hot” they are
• a search engine input where special operators like site:fettig.net are highlighted in a different color

The current code is not at all ready for production. But it demonstrates the concept, and I hope to have it ready for production projects soon. So check it out and let me know what you think of the idea. The project page is here, and the code is on GitHub.

Being at Google was a great experience, and I’m grateful for it. I learned a lot, got to work with some great people, and enjoyed the feeling of being smack-dab in the center of the tech industry. But after three and a half years I was itching to have more time to experiment and work on my own projects. So I decided it was time to move on.

Over the next few months I’m going to work on a couple of ideas for products I’ve been thinking about. I’m looking forward to doing some full-stack web development again. There’s also a bunch of interesting technologies that I want to get up to speed on, including html5, MobileSafari touch events, geolocation, node.js, Redis and other NoSQL databases, and more.

I’m also considering taking on some contract work. For the past 5 years I’ve been doing lots of serious Javascript programming, and from talking to people it sounds like experienced Javascript experts are hard to find. So if you need outside help on a Javascript-intensive web application, feel free to check out my resume and get in touch.

I’m really looking forward to this next phase of my career. Exciting times. Stay tuned.

Here’s a breakdown of the total cost of ownership in both cases. The subsidized Nexus One costs $179, with a $79/month plan. The phone without service costs $529, $350 more. But then you can sign up for T-Mobile’s “Even More Plus” plan, and get the same 500 minutes + unlimited data and text messages or $59/month ($20 cheaper).

So, over 24 months you save $480 in service charges, more than making up for your extra $350 investment up front ($130 net savings). Plus you’re contract free and in position to sell your Nexus One on EBay and/or jump ship to another carrier when a newer, shinier phone comes along.

The savings are so substantial that you’d even come out ahead if you put the $350 extra on your credit card at 20% interest and put the $20 a month savings towards your credit card bill (you’d have the $350 balance paid off after just 21 months). To put it another way, if you go for the subsidized plan it’s like you’re borrowing $350 from T-Mobile, and then paying it back over 24 months at a roughly 30% interest rate.

One last comparison, total cost of ownership numbers over 24 months:

Nexus One (no plan) + T-Mobile Even More Plus (unlimited text messages, 500 minutes): $1969
Nexus One with bundles T-Mobile plan (unlimited text messages, 500 minutes): $2099
iPhone with AT&T iPhone plan (choice of 200, 1500, or unlimited text messages, 450 minutes): $2000 / $2240 / $2360 (depending on text messaging plan)

Update: billshrink.com has a chart comparing total cost of ownership of various smart phones, including the Nexus One, but they don’t seem to be using the Even More Plus plan prices.

As a learning exercise I wrote my first command, status-in-gmail, which you can subscribe to on this Ubiquity Commands page. The status-in-gmail command will update your Google Talk status message in any Gmail tabs you currently have open. You can supply an arbitrary string for your status message, or have it use the selected text on the current page.

I chose this for my first command because I’d written a similar command for Quicksilver and Adium a while ago using AppleScript, and I’ve missed it since I switched to using web-based chat in Gmail. The Ubiquity side of things was really easy to implement – they’ve done a great job providing simple APIs. The only hard part was figuring out how to script Gmail to do what I wanted.

The current code is alpha, of course, and still has some limitations – you can only change your status message, not your available/busy status, and it will throw an error if you try to use it without being signed into chat. But feel free to give it a try and let me know what you think.

Now, who’s going to write the first Quicksilver-to-Ubiquity bridge? :)

Finally I came across a weblog entry that mentioned looking at the console to see the sync log. I opened /Applications/Console and saw this message:


2008-02-18 22:57:38.111 AppleMobileSync[652] CFLog (0):
CFPropertyListCreateFromXMLData(): plist parse failed; the data is not proper UTF-8. The file name for this data could be:
/Users/abe/Library/Application Support/SyncServices/Local/clientdata/[really long numerical directory]/[really long numerical file name]


Apparently that file with the really long name was causing the problem. So I went ahead and moved it out of the way (I put it on my desktop so I could restore it if it turned out to be important). Then I tried to sync again… and it worked! I did get a couple of messages about resolving sync conflicts, but they were easily resolved and now everything appears to be working fine.

Take this for what it’s worth; I don’t know if this will work for you, or make matters worse. I have no idea what that file was supposed to do, and randomly removing application files from your computer is generally a bad idea. But if you’ve got a similar iPhone syncing problem, and nothing else works, you might want to check your Console log and see if there’s a similar file causing your problem.