Recently in High Geekery Category

I belong to a lot of social networks. Pretty much any time I hear about a new one, I sign up for the "bbrown" username. I have learned my lesson about waiting to register for these things: having a common first name and surname, the late bird gets the "bbrown217" or other such contortions. (I almost had bbrown.com, after Burr-Brown was acquired by Texas Instruments in 2000. I checked every day waiting for the expiration hold to come off. Every. Single. Day. Except on my birthday, that is, because I was busy. Guess when the hold came off. I still bristle at that loss.)

But I have to say that I don't have much passion for any of them. I like Twitter a lot—mostly because there's a high signal to noise ratio on the people I follow and the 140-character short form makes it drop-dead easy to write something. But mostly I don't care for them because your content is locked away, subject to the whim of the provider to allow you to export it out of its cage.

I may be biased, but owning your own domain and hosting your own content is the best and safest form of expression. As long as you pay your bills, no one can really silence you and you—mostly—get to decide what the public can see. On the social networks, other people can decide that your views are "hateful" or "spam" or "worthless tripe" and get it taken down.

Over here, though, I get to say whatever I want however I want. This is my soap box.

In my time on the Internet, I've seen many sites come and fade into obscurity. I've seen social networks actively worked and then slide into disuse—fallen prey to passing whims both personal and corporate. This Web site's been active for the better part of 9 years now and there's no reason to suspect that it won't be around for another decade or two.

MC Frontalot just released Solved, his fifth album (CD? Set of downloads?), and it's an excellent piece of work. (If you're in Phoenix, you simply must attend his concert on September 10th. I've been to all of his other shows in town over the years and they're wonderful.)

Here's how I'd rank his CDs:

1. Nerdcore Rising
2. Solved
3. Final Boss
4. Secrets from the Future
5. Zero Day

Solved is just that good! Now, there's great songs on every one of the previous albums, so this is just a perspective on them as an aggregate. I've listened to it about a dozen times since I got it—like many of Frontalot's works, you have to ease into them.

Here's my rundown of the best of Solved:

1. I'll Form the Head: I watched Voltron every morning as a child and this song just cracks me up. Money line: "I think it's time that we combine and rip this thing to shreds / but only if you promise me that I can form the head!"
2. Captains of Industry: I'm also a fan of MC Lars, so this collaboration worked really well for me. I really like when Frontalot begs for his audience to actually compensate him for his work. Money part:

   Try to sell music, they look at you funny.
   Not a transaction that necessitates money,
   not with the true cunning of the kids in the know.
   But you look at them cheering -- notice what? They don't sew.
   Don't go to the print shop and silkscreen their own,
   yet they're always needing something to cover the torso.

3. Stoop Sale: very catchy tune. Frontalot doesn't often journey into the storytelling genre, but he's a master at it when he does. Money line: "And that's when you have to endure / the regret that accompanies said decision-making: / all the other wishes in the world that you've forsaken."
4. Just Once: this track is a crackup—could this be a problem he'd like to have? Money line: "Just once, I don't want to hump tonight. / Why can't we hang out and talk?"
5. Front the Least: a track of modesty. Money line: "And the worst thing about my mistakes is they're all reruns."
6. Nerd versus Jock: playing to the audience, to be sure. Solid effort. Money line: "Look at now: demand for nerds. Old jocks: stock on clearance."
7. The Sketches: this is the first album of his where I don't generally skip through the interstitial sketches. They're funny and I'm glad to have been introduced to Wyatt Cenac.

I'd recommend this CD to anyone intrigued by nerdcore hiphop, the genre of rap that MC Frontalot created in 2000. He's an amazing wordsmith and produces some really funky beats as well.

Today's new version of Kindle for iPhone/iPad adds support for page numbering. I was wondering how to cite a "location" of text from a Kindle e-book: this update shows the page numbers from the book edition alongside the "location" numbers.

I'm trying to think of what iBooks gets me over the Kindle app. Useless page-turning animations? Advanced highlighting-edge graphics? Integrated book store? Having to sync up with iTunes to safely store your notes, highlights, and positions? None of these are compelling.

As the Mac guy at work, many have asked for my opinion of the new iPad. In a nutshell, I think this is an astonishing device that truly represents a revolution in computing. (Other tablet devices have preceded the iPad, but revolutions aren't defined by failed attempts. Success counts for a lot.)

At home, I have a Dell netbook, an iMac, a MacBook, and an iPhone 3G. The iMac is in an office, the Dell is on a shelf somewhere, the MacBook is propped up next to the couch, and the iPhone 3G is in my pocket. At night after the kids are in bed, my wife and I start our computing tasks. She takes the MacBook and I go with the iPhone. Most of my time is spent in my apps but there is some browsing otherwise. It is an astonishingly capable general computing device: it's comfortable to just sprawl on the couch, holding the phone in one hand, and just tap-tap-tapping away. There's no fan and it never gets hot; it's fairly speedy given what I'm throwing at it; and it has a broad selection of apps that are very well-designed.

The MacBook, on the other hand, is less comfortable. It's requires a particular set of positions to work with, gets hot pretty quickly, and there's an inherent disconnect between the trackpad and the cursor on the screen. While the user interface is much better than any other operating system out there, the iPhone's simplicity and intimacy has made me realize the window/mouse/filesystem paradigm's deficiencies. (I bought the Dell netbook because I thought it would suffice for my needs, which are generally Web-based with a modicum of text entry. It truly is the worst of all the tradeoffs and the Dell's keyboard was designed by someone who clearly hates contractions.)

There is something very intimate and intuitive about using your finger as a pointer. "I want to open that link." "Let's open that app." "Move to the next picture." It's no accident that most user interfaces in the science-fiction future involve access by voice, sight, and touch. These input methods are in-born, always available (barring disease or defect), and natural. The reason why they were science fiction (and the science present was stuck in mice and keyboards) was because current technology just couldn't process the intention behind those methods quick enough to make them practical. Voices are inherently variable and muddled; touch is generally too soft to detect and materials too weak to withstand continual, harder pressing.

Steve Jobs said that the iPad will offer the best browsing experience and I fully believe him. I even expect that I will become a fairly proficient typist using its virtual keypad. At this point, I am faster typing on my iPhone than I was on my old BlackBerry with a physical keyboard. It surprised me when I was able to compose a blog entry using the WordPress app and do a passable job at it. With the keyboard dock, this could easily become my main computing machine.

The most revolutionary aspect of the iPad is the abstraction that it represents. Gone are files, windows, cursors, directories, and installers. The user of the iPad never has a sense of the computer within—this is enormously freeing for developers because they needn't worry about the detritus of computing. All he knows are applications, documents, and content. This is a machine for doing, not the relentless tweaking, customizing, and other time wasters.

If this thing takes off (and I think it will), then it will spread throughout the computing ecosystem as much of Apple's recent work has led by example. Poo poo it all you want today, but five years from now this will be the dominant user interface out there. It is the Microsoft Surface for your hand and the possibilities that that entails are dizzying.

[UPDATE (1/29/2010): Added link about the freeing nature of the iPad. {via}]

[UPDATE 2 (1/29/2010): There's a lot of great commentary along these lines, but I think that Fraser Speirs (he of the great FlickrExport) has nailed what I was driving at.]

[UPDATE (1/30/2010): Fixed a link.]

I've recently switched to Google Reader for all of my feed reading needs. This is the latest iteration in a long line of trying to find the perfect feed reading experience. Here's what "perfect" means to me in this context:

• Readily available so that I can polish off a few items whenever I have a spare minute
• Enables me to clear out a batch of unread items easily
• Fast
• Navigable by keyboard for faster reading
• Native applications for whatever platform I'm on plus a Web application backend
• Sync between work, home, and phone

I subscribe to 250 feeds presently so the primary consideration is staying on top of them. There is a real cognitive weight to having 1,593 unread items and I strongly dislike declaring "feed bankruptcy." So I have spent the last few years testing different options.

For most of that time, Bloglines was my go-to solution. It was fast and fairly efficient. But I was never satisfied because it was Web-based, lacked decent keyboard navigation, and required an Internet connection to access at all. I tried Google Reader when it first came out but it left me cold. Since I spent my working life on a Windows XP machine, I resigned myself to a Web-based application.

Then I got a Mac at work and suddenly all of the great Mac OS X feed reading applications were available. I again tried all of the ones I had evaluated at home: NetNewsWire, NewsFire, Shrook, and some others that I can't remember now. I settled on NetNewsWire because of the NewsGator syncing, the native iPhone application, and decent keyboard navigation. I still wasn't completely happy with the set up because the NewsGator Web application is terrible: no keyboard navigation, slower than you'd think possible, and hard to mark items as read.

As I said earlier, Google Reader is my current solution and I think it's going to stick this time. The Web application has matured substantially since I looked at it four years ago. It lacks a native Mac OS X application but I found a way around that earlier this week, which I chronicled in this Super User answer:

1. Download Fluid.app.
2. Save this PNG image (or this higher-resolution one) to your Desktop.
3. Open Fluid.app and use the Google Reader URL, name, and newly-saved icon.
4. Launch the Google Reader application from your Applications folder.
5. Buy Byline or use the really good mobile version of Google Reader (you can save it to your Home screen to boot).

This setup is very fast, feels native (Fluid.app even displays the unread item count as a badge on the Dock icon), syncs between all environments, has great keyboard navigation, and is always available. I've gotten my total unread item count down to 8 and kept it in double digits for the last week, something I haven't done since I started feed reading.

It's refreshing to have that load off my mind.

I now have a horse in the URL shortening drama. My Meme Obfuscation Machine doesn't work for tweets. Try as I might, I just can't get something by Twitter's automatic URL shortening. Seriously, what's the fun in Rickrolling someone with a carefully-crafted, seductive URL when it gets turned into bit.ly/NauRm.

In the interest of contributing to the wealth of tips on WWDC, I'd like to share what I learned this week about the event itself—I can't talk about the session material since it's under a non-disclosure agreement.

1. Don't lose your badge. I didn't, thankfully, but the attachment of the badge to the lanyard is very precarious. Everything—everything—revolves around that badge and there's security everywhere. They will balk if they can't see the full badge.
2. There is no Apple-provided dinner except for the Bash. From the original Web site, it seemed like Apple would provide dinner daily, but that was emphatically not the case. The Bash food, incidentally, was excellent. I was stuffed from the sushi, hot dogs, pizza, Chinese, pasta, cookies, and quiescent confections.
3. You can leave on Friday. I booked my return flight for Saturday morning thinking that sessions would run as normal on Friday and I didn't want to rush around dealing with luggage and transportation to the airport. Turns out, the last session ended a little past 2 o'clock and they have a luggage holding station at Moscone West. I could have easily left that day. There's a lot to see in San Francisco, of course, but I was ready to go home.
4. Don't miss Stump the Experts. I didn't learn anything at all from the session but it was hilarious. This was the 20th Stump the Experts event and it made me feel nostalgic even though this was my first time attending.
5. The labs run concurrently with the sessions. There were many great sessions that conflicted with one another, but most of the good labs also conflicted with those great sessions. The best bet, I found, was to skip a Q&A here and there to make use of the session interstitials. Even still, I missed several opportunities. If the videos came out in a timely manner, I'd say to only go to the sessions for the Q&A (or to ask your Qs at) and focus on the labs. You can watch the video at your leisure but you're never going to get that kind of face time with an Apple engineer otherwise.
6. The WiFi access was excellent. I consistently got five bars throughout Moscone West during the entire conference. I also was able to connect via VPN at will. I'm not sure why the online accounts I read had WiFi trouble in the past, but Apple appears to have gotten its act together.
7. Complaining about the lines is an effective icebreaker. WWDC, for me, was a series of lines: lines for the sessions, lines for the labs, lines for the urinals, lines for the sinks, lines for the food. Witty observations about this led to many interesting conversations with line neighbors. Not that you need an icebreaker: I never had any trouble striking up a conversation with anyone and the bonhomie was palpable throughout.
8. Use the elevator. There's an elevator near the stairs that was almost never being used. If you're on the third floor after a Presidio session and you want to go to a lab, your best bet is to skip the line for the escalators entirely and go straight for the elevators. I generally rode it alone; I have no idea why so few people took it.
9. Plan on getting in line for the Keynote by 8 o'clock. I waited until 9 AM to mosey down to Moscone and the line had already wrapped around nearly back to the main entrance off Howard. By 9:45, we had barely moved. I ended up getting seated in the overflow room, which had quite a nice view of the Keynote, about 10:20 AM and missed the hardware announcements entirely.
10. The Interface Design consultation is by appointment and they fill up quickly. I was planning on having an Apple engineer give my iPhone application a once-over, but I didn't realize you had to reserve a spot so they were gone by the time I got down there. If I were doing it again, I would make this action my top priority.

Was WWDC worth it? Big time. It was hard being away from my family—video conferencing via iChat helped considerably—but I learned so much and got direct answers to my questions that I can recommend it without reservation. Plus, I got a developer's preview of Snow Leopard that is wonderful. iPhone OS 3.0 and Snow Leopard are going to be great, people. Make sure you upgrade when they become available.

One of the most exciting aspects of the WWDC keynote announcements was the pricing of Snow Leopard at $29 and a five-pack family pricing of $49. I've purchased every version of Mac OS X for $129 since the original 10.0 (except 10.1 obviously), only occasionally catching a break due to buying new Macintoshes.

Every version was worth it, mind you, but it still felt like an ongoing cost of owning a Mac. (I must here disclaim any sense of entitlement: I know that previous versions of Mac OS X continue to work after the new ones come out and I have taken that route for non-essential computers. This feeling arose from my inner cheapskate more than any sense of deserving something for nothing.) Every new version required a careful calculation of benefits and review of features for ancillary machines.

But I don't have to think twice at a $29 (or $49) price point. On this point, David Pogue has it right. But his reasons for the pricing barely scratch the surface. I paraphrase his four listed reasons as follows:

1. This release doesn't have enough features to justify $129.
2. They want to get this out to a lot of people.
3. They want to embarrass Microsoft with this ridiculous value of the release.
4. The lower the price, the likelihood that people won't even blink at upgrading.

There's a lot more to it than that, though. 10.6 requires an Intel machine. If you've got an Intel machine already, it's likely that you've running 10.5 and that you'd gladly pay $29 to recover 6 GB of space much less for a slew of new features. If you're running Tiger on an Intel machine, you have to shell out $169 for the Mac OS X Box Set. And if you're not using an Intel machine, you cannot upgrade to 10.6 (and presumably any future releases either). So this release cycle effectively communicates to those still on Tiger or the PowerPC platform that their days of being supported by Apple are nearly over.

Finally, if 10.6 is truly laying the groundwork for future plans, then Apple has an interest in having as many developers making use of its new technologies as possible. But historically developers will not migrate to these new systems until a critical mass of users have made the move: supporting two disparate versions of a feature is expensive for small developers and they won't do it unless there's a absolutely compelling reason. Pricing 10.6 at this level will induce a substantial number of consumers to upgrade. On the iPhone, I can imagine that 3.0-only applications will come about soon because the upgrade friction is minimal there.

With a solid base of applications using 10.6 features, Apple can sell future hardware in a way that Microsoft-based vendors cannot. With the gigahertz arms race faded, hardware vendors are competing on multiple cores, multiple CPUs, and RAM. But consumers quickly discover that all of this extra hardware encounters diminishing returns on the software that they use—either the software can't make use of memory above 4GB or these extra cores are mostly idle. 10.6's promise is that it makes using these hardware features seamless to the developer through mechanisms like Grand Central Dispatch, OpenCL, and completing the transition to 64-bit.

These strike me as more substantive reasons for the pricing than Pogue's facile ones. I believe 10.7 will resume the $129 price cycle as people catch up to the Intel/Leopard transition and Apple wants the third-party applications to be there waiting to sell the hardware's value.

In speaking with a co-worker, I mentioned a couple email tips that he hadn't heard. Thinking that others may be in the same boat, I offer them here:

• Gmail: you can put periods throughout the username and Google will ignore them. So "bbrown" can be "b.brown," "bbr.own," or even "b.b.r.o.w.n." and the emails will come through.
• Gmail: you can append a plus sign and additional text to the username and Google will also ignore that text. "bbrown+specialdeal," "bbrown+spam," and "bbrown+yahoo" all get to their proper final destination. This and the other tip plus Gmail's filters enable you to create disposable email addresses without preplanning.
• Mailinator is the king of throwaway email addresses. In a form, enter something@mailinator.com and you can access that username's messages through the mailinator Web site. Anyone else can access the email, so this isn't really useful for anything besides anonymous emailing. Some sites have caught on and check for the mailinator domain name, but there are plenty of aliases available (you can even point your own domain's MX record there).

The following code is used to make a request and get the results:

contents will contain the HTML of this blog if the server gives a 200 OK response. Anything else will throw a WebException. You can wrap the snippet above in a try-catch to handle a non-200, but the exception is thrown in the GetResponse call so you get nothing from the actual response. 404? May as well be a 500.

Today I discovered that the WebException itself has two properties: Response and Status. This Response is the same as the resp above so you can extract out the server response in the catch.

This whole behavior of HttpWebRequest is counterintuitive in the sense that a non-200 is not an exceptional circumstance; I would have expected the response to be accessible and the status code to be populated.

Yesterday I released my latest project at work. I call it CheckBot and it is a Windows service that pulls down messages from a third-party service, checks them for domain names, and replies with whether those domain names are available. I built it using a plugin architecture, so adding third-party services is a breeze.

The first plugin was Twitter. A Twitter user just has to follow domaincheck and then send that bot account a domain name through the direct messaging system. Within seconds, CheckBot will respond with its availability and include a link to register it on GoDaddy.com if it is available.

I am very proud of this application because I did it fairly quickly and I like the simplicity of the design. There was only one bug that came up during testing and it was both minor and quickly resolved. This sort of thing is exactly the reason why I love my job and the Gadgets Team I lead.

[The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of Go Daddy Software, Inc.]

Last week saw the introduction of the first Android phone, the T-Mobile G1. I've been following Android's progress with interest because it seems to be the most compelling competitor to Apple's iPhone so far.

This video by Engadget really helped me to understand the phone and operating system in a way that all of the specs and press releases have not. This particular video was better than most of the other ones I've come across because the phone's operator was quite familiar with its features.

Here are the things from the video that I really liked:

• That little drop-down panel notification that appears and disappears after a few seconds. It also appears to be able to be recalled at any time. It's especially handy for background processes and applications, neither of which are possible on the iPhone.
• The compass rose on the Google Maps application. This is a third-party integration, like a plugin or Greasemonkey script, that provides additional functionality not originally conceived by the app developers. This sort of customization is impossible on the iPhone and could be the basis for a much richer experience.
• The Street View responds to movement on all axes by changing the view accordingly. This is pretty sophisticated positional analysis. Like the compass rose, it appears that Android can tell the application not only the phone's coordinates but also its orientation on all axes. That's not available on the iPhone and could be very useful.

That being said, I believe that Android is doomed to failure. First, it has forsaken multitouch ubiquity. After the pioneering efforts of Jeff Han, Apple and Microsoft have clearly embraced multitouch as the user interface of the future. By not requiring hardware manufacturers to support multitouch (or touch at all, really), Google has seriously limited application developers. If a developer wants to do a multitouch application once Android supports that, he is either limited to a subset of the customer base or he has to make it degrade gracefully on phones that don't support multitouch—neither is an appealing option.

And openness has proven time and again to not be a huge selling point to the average consumer. There are already open mobile operating systems but people are clamoring for iPhones. There's a certain abstract benefit to openness that is hard to communicate to users. The freetards may whine but the average person just looks at the iPhone and drools. They don't particularly care that their phone isn't open. Why? Because most phones in the past never were.

I predict that Android will linger forever on cheaper phones where a free operating system could make for increased profits. The Big Three—Apple, Microsoft, and Nokia—will barely notice its share and Google will mostly abandon the project due to its corporate ADD.

I've been a consumer of the Facebook.NET framework for a few months now as I've developed several Facebook applications in ASP.NET. I chose that framework instead of the official Microsoft one because it seemed more logical and straightforward.

Honestly, I'm not at all certain why I originally chose one over the other. I read all of the blog commentary about each, I looked over the source, and I checked out the sample applications included. Facebook.NET struck me as elegantly designed, well conceived, and actively developed. Sure, Microsoft had commissioned and paid for the development and maintenance of the Facebook Developer Toolkit, which meant it was more likely to be around in the future. This possible objection was easily dismissed since Facebook.NET was open source and could be extended privately as long as need be.

What I couldn't have foreseen were sweeping changes by Facebook to the underlying API within six months and a complete abandonment of the open-source project by its sole maintainer. Facebook has made a lot of mistakes in handling the transition but there's precious little that I, as a third-party application developer, can do about that. So my sole responsibility is to keep up with updates to the framework and alter my code to accommodate the new (or changed) functionality.

Faced with a framework that isn't getting updates, the responsibility expands considerably. One must either abandon the abandoned framework to search for greener pastures or one must take up the mantle of leadership by forking the project. Neither is a path to be chosen lightly for each entails considerable pain.

The choice was made easier for me by the fact that the Facebook Developer Toolkit was just as inactive at the time. I tried corresponding with the Facebook.NET maintainer and even succeeded a couple times: I would much rather have been a developer on a project than the man responsible. In the end, it became clear that the maintainer had moved on to other projects and that I was going to have to fork.

The result is fb.net. I largely brought it up to parity with the API changes in a span of two days but then I got distracted by work, family, and other projects myself. As it stands, there's just a little more to go and then I can make a release candidate.

My only hope is that I can get this framework ready for a full release and then start looking to build a community that can assist in its maintenance. The Facebook.NET maintainer got it off to a good start; now it's my turn to finish the job.

My team just got moved to another group within Go Daddy on Monday. We had put a lot of information up on the old group's SharePoint Wiki and needed to put it somewhere. The new group didn't have a unified Wiki, leaving it up to each team. I hadn't really looked at the Wiki world in a while and I imagined that I'd need to go with something like MediaWiki.

Then I remembered that Jeff Atwood had written favorably about a .NET Wiki called ScrewTurn. A cursory investigation indicated that it was pretty damn awesome!

In no time, I had a solid Wiki system up and running. It's very easy to install and configure and it appears to hold to MediaWiki markup syntax, which is a big plus. I replaced its authentication system with Active Directory integration through an easily-installed plugin—enabling any employee to log in and edit pages.

The hardest part was migrating the content from SharePoint. It was brutal, tedious work but you only have to do it once. If you're an employee and reading this on our network, you're welcome to check out my handiwork. (If you need any help setting up your own ScrewTurn Wiki, let me know.)

[The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of Go Daddy Software, Inc.]

I've just finished reading Scott McCloud's comic book introduction to Google Chrome, Google's new browser that will be released tomorrow in some fashion. I am very intrigued by this new player and I think McCloud's work is an accessible introduction to the basic ideas behind the design. (Of course, it could have been summarized in a single page or blog entry much more efficiently than being spread over 40 pages but McCloud did a great job in explaining things.)

When Jason Kottke first began speculating that Google was working on its own browser, I dismissed it just like I did his notion of Google OS—a Linux distro with Google branding. (I'm not sure Kottke can count this as a win, by the way, since five years worth of bupkis does not make for a successful prediction.) It seemed like an overreach for Google, well outside its focus. The intervening years have proven that Google views its mission as pretty much everything on or related to the Internet.

But I think Google Chrome makes a lot of sense. For one thing, Google now has some skin in the game. It can act in such a way that Microsoft and Apple have for so long: if there's some special feature that it would like to be prevalent, it can implement it in its browser and propose it as a standard to some friendly standards body. Microsoft got XMLHttpRequest in there early (among many other examples) and Apple got the canvas element accepted in exactly that way. Google, previously, had to work within the Microsoft-Apple-Mozilla constraints and now it gets to be the interloper, the mole. I think that's a powerful position and likely well worth whatever money Google is throwing at this project.

Also, it clearly has some innovations to bring forth. Putting each tab in its own process is genius. At once it solves the issue of memory leaks and the expansive memory footprint that afflicts every modern browser as well as protecting the user from malicious code in a very effective way. Google also developed its own Javascript virtual machine called V8 to couple to the open-source WebKit. Refactoring the Javascript engine has become a hobby with the browser makers: SquirrelFish from Apple, TraceMonkey from Mozilla, and excuses from Microsoft (paraphrased thusly: "Oh, Javascript isn't really that important. We focused our performance improvements in IE8 on everything else that stunk about IE.") The neat thing about Google's Javascript optimizations is that they took a completely different approach to speeding things up, which means the other browser makers will likely copy them. Innovation in the browser space is an unmitigated good thing.

Finally, as the most popular set of properties on the Internet, Google can drive adoption of its browser by offering improved performance and heightened functionality when visited using Chrome. It can tie its sites into the browser in a way that it never could if it weren't a browser maker itself.

In the end, each of these reasons for developing its own browser also benefit the user so I applaud Google's decision and hope that they can succeed in following through—which has always been a problem in Google's application ADD environment.

[UPDATE (9/2/2008): Google Books has a better version, so I've updated the Google Blogoscoped link to point there.]

Today, a co-worker and I, both fans of the iPhone, were discussing how to do text selection and cut/paste operations. I'll confess that I didn't have much of anything to add to the conversation beyond being a good listener and carefully considering his ideas.

He had a pretty decent notion of using one finger as an anchor position while the other could drag around to set the other anchor. With our hands, you could cover the screen completely and even handle scrolling through longer documents. We weren't really sure how to implement the cut/copy/paste side of the equation, but we guessed that an alert panel with applicable buttons would suffice.

After seeing David Friedman's tweet about his take on the subject, I knew that he had nailed it perfectly. His solution is captivating in its simplicity and obviousness. If any Apple iPhone engineers are reading this and haven't read his entry, get out of here right now. Also, hey, good job on the iPhone—can you pull some strings and get me in the beta program?

The iPhone as trackpad is just genius, sheer amazing genius.

For years, I've struggled with finding a decent set of tools to practice Getting Things Done. I started with the Hipster PDA and moved on to some notepads and Zen To Done. I've tried just about every permutation of Web-based application. Heck, I liked GTD-PHP that I bought the domain and host the project for free.

But none of them have worked for me. The Hipster PDA was good but it suffers from all of the problems of paper-based systems: there's no indexing or searching and you always have to carry around a pen. The notebooks were even more inconvenient; the desktop applications didn't help if I wasn't carrying my MacBook which I almost never do; and the Web applications had monthly fees and required a computer with Internet access to function. So I bided my time and kept on the lookout for the Holy Grail.

I can confidently tell you that I have found it! It's OmniFocus by OmniGroup. It's Mac-only and $79.95 but it suits me perfectly. Its power stems from the fact that the desktop application at home can sync with the desktop application at work which can sync with the iPhone application in my pocket. $79.95 (plus $19.99 for the iPhone version) is certainly expensive, but I found it invaluable after using it fully for its 14-day trial.

It has a bunch of nice touches: parallel or sequential task lists, quick entry that really is, the focus modes. It's a competent implementation of GTD—the incidentals of the UI aren't important. But the syncing is worth every penny of the cost. When you're away from a computer, you have access to your projects and contexts. Check something off and it's synced to your home and work computers. It just works—you never have the problem of managing database files and shuttling them between the computers in your life.

And that makes getting things done the focus rather than maintaing your system.

Prior to attending F8, I believed that the new Facebook profile redesign was motivated by de-emphasizing third-party applications, making more room for ad space, and enabling more integrated ad placement. It was such a radical change and I was aware of the pathetic CPM of the Facebook ad inventory, so I concluded that this move was about Facebook the business.

Having been through three sessions and two keynotes, I now think that the changes are truly user-centric. The justifications presented today by very earnest and sincere Facebook developers and designers ring true to me. In case you didn't want to wade through my copious (and possibly inscrutable) notes from the sessions, the basic rationale behind the radical revamp is to emphasize the feed as a social stream and build user trust by limiting and segregating third-party applications.

They made the excellent point that the current profile easily becomes unwieldy and forbidding after adding just a couple of applications. The tabular nature of the new profile gives the user control over what to emphasize and what to display. The more time I spend with the new profile, the more I like it.

At the same time, I've been working on the open-source framework Facebook.NET in anticipation of the concomitant API changes. At the API level, Facebook has frequently dropped the ball. There are breaking changes, insufficient documentation of other changes, and frequent revisions that aren't discussed unless you happen to notice slight alterations to the documentation. It's truly frustrating due to the flux even though it's supposedly stable and released. I'm hoping that this is the last significant API change for awhile, or, better still, the Facebook platform team realizes the cardinal rule of API design: maintain backwards-compatibility at all costs.

[UPDATE (7/27/2008): I had written this on the plane coming back from F8 but I forgot to publish it when I got connected back on to the Internet.]

Talk with Jerry Cain, Ari Steinberg (Manager of News Feed Team), and Tom Whitnah.

• Use the right channel to deliver the right message. Overview of the old ways of communication with users. Requests: when one user wants another user to take a specific action. Notifications: user-to-user to tell a user an action has been taken towards her, app-to-user to tell a user about something important to her from the application. Feed story: when a user wants to share actions they've taken.
• Feed is the center of communication on Facebook. Old: single stream, not interactive, only 25 slots. New: top stories as highlights, multiple streams of news, more room for application stories to appear, commenting on stories.
• feed.publishTemplatizedAction: disaster, user-specific token sets made aggregation very difficult.
• New methods: feed.registerTemplateBundle and feed.publishUserAction
• Allow template bundles to include several templates per story size, ranging from user-specific to more general. You can define different templates within a bundle to handle 1, 2, and many aggregated stories.
• Before you launch your application, think about the sort of templates you're going to be using. Calling the API method only allows for one-line stories. Feed forms: FB.Integration.showFeedDialog()
• Great communications = happy users. Respect users' attention and their friends' attention.
• Higher acceptance, lower ignore = more requests allocated.
• Notifications: user-to-user, can be sent to any non-friends who are also users of the app; app-to-user, allocation is approximately seven per week per user.
• More read, fewer hidden / spam = more notifications allocated.

Q&A

• Allow access to News Feed? Nope.
• Handle instead of a bundle ID? Not yet.
• Facebook applications versus Facebook Connect? No differentiation.
• (me) Disclose allocations per user instead of aggregate? Can put it on the short-term roadmap, but wary of disclosing who is a tattletale.
• Statistics data available via an API call? Someone was working on that but he didn't know the status of that work.
• Set privacy in News Feeds? Not at this point but hopefully someday.
• Timeline for new statistics to appear? In the next week or so.
• Give visibility into an app's spamminess? Talked about it with the Reviews application but have found some spamminess within the Reviews application itself.
• What kind of history for allocation reductions? Spamminess metrics last about a month.
• Expand News Feed on friends to see more of a story? Haven't really thought it.
• In stories themselves, possible to see how many times one was read in News Feed? Would like to, but not a high priority.
• Add or view comments, available through API? Probably through fb:comments, not allow to add comments programmatically due to spam concerns.

Talk by Ruchi Sanghvi and Josh Elman. Here are my rough notes on the presentation:

• The never-ending profile was the motivation behind the redesign.
• Emphasizing feeds: increases engagement and encourage content creation
• Simpler, cleaner profiles: easier profile navigation, clearer identity, more control
• More control over profile: users decide about tabs, when to publish, and look of stories
• "It all starts with the Wall": feed, publisher, profile boxes
• Stories: one-line, short, or full (up to 500x700). Done with feed forms, using FBML or Javascript.
• Publisher: different versions for user and friends,
• Info tab: deep integration with structured information, should represent information about what the user's done. Info stuff is enabled through canvas page button using FBML or Javascript.
• Tabs: provides the richest expression, hybrid of a profile box and canvas page (solely FBML, no advertising), no caching, 760 pixels wide, no autoplay, fb:visible-to-owner
• Profile boxes: profile_main -> narrow, on Wall, wide and narrow appear on Boxes tab, Bookmarks will be migrated, must manually add a bookmark otherwise.
• New permissions/lack of adding: reduces friction. First access provides user ID, friends, pic and names, publish feed stories, send requests. Add require_login to links to trigger permissions solicitation.

Q&A:

• How do users first get into the app if they're not adding?: About page much more static.
• Should apps offer all integration points and let users decide or pick some?: Both, but mostly the latter.
• Is user info going to be available to all? Still limited to privacy settings.
• What can the Publisher do?: Rehashed already shown options
• Smiley app? Uses shared preferences, which has been available for 9 months
• Can you detect whether a user is in new profile? Yes, part of API.
• Widened Wall, is it final? Yes.
• (from me) Extended permissions, is the Wiki list definitive? Yes.
• Engagement metrics, what are they? Bunch of them. User can reorder boxes.
• What are these info sections? Not a mini-feed, opposite of one. More for static information. Button on canvas page shows example, the user allows it, adds it to profile, and edits inline.
• What new stats will be available, users who have added tabs? Yes.
• Logged in user for tabs is viewer or user? Viewer. Tabs focus should be on the user.