Nick Bradbury

No More Free Tech Support

Developers sometimes dread meeting new people. We suspect that when people find out what we do, they're probably going to ask us to fix a problem they're having with their computer.

The same dread occurs at major holidays when we get together with extended family. While everyone else is enjoying their time together, we're off by ourselves fixing their computers, or getting rid of a virus, or uninstalling the dozens of toolbars that suddenly appeared in their browsers, or figuring out why iTunes won't sync anymore.

It's not that we don't want to help. It's just that we spend all day (and sometimes all night) in front of our computers, so it'd be nice to forget all about tech at social events.

But this situation is unlikely to change soon. Despite our attempts to make software easier to use, it's still too unfriendly, too breakable, and just too damn geeky. People rely on their computers so heavily that we're going to be asked for free tech support for many years.

So here's what I propose: offer to trade your time doing tech support for their time talking about how they use their computers.

Yeah, I know that sounds silly, but hear me out.

A big reason software is still so unfriendly is that most developers spend very little time understanding how non-geeks experience the tech we build. We surround ourselves with fellow techies and start thinking everyone uses software the same way we do, so we keep building stuff for ourselves.

The only way we're going to stop spending so much time giving free tech support is by making stuff that's easier to use and less breakable. It's when we step into the world of non-geeks, where people type URLs into Google's search box instead of the address bar, that we start to understand what we're doing wrong.

So the trade seems like a fair one to me.

The Friction in Frictionless Sharing

Facebook claims that frictionless sharing makes sharing easier. They've improved the usability of sharing by taking away the friction.

So let's look at it from a usability perspective.

This is an oversimplification, but we can think of frictionless sharing as an attempt to replace something like this:

With something like this:

Instead of requiring the user to confirm every single article they choose to share, just give them a one-time dialog that enables them to share everything down the road.

That's a lot less work for the user, right?

Well, no, not really. Because in the past the user only had to decide whether to share something they just read, but now they have to think about every single article before they even read it. If I read this article, then everyone will know I read it, and do I really want people to know I read it?

That creates more friction, not less.

And let's not forget the friction the user experiences as they browse around the Web. Now they have to remember which sites are automatically sharing what they read. Did I allow a Facebook app to share what I read on this site? I don't remember, so I'd better not click that link.

So frictionless sharing isn't frictionless after all. All it does is trade the small friction of having to choose what to share with the large friction of having to think about whether what you're about to do will be shared.

Android's "Legacy" Nonsense

"You keep using that word. I do not think it means what you think it means." - Inigo Montoya.

Lately I've noticed Google using the phrase "legacy apps" to refer to apps built for Android versions prior to 3.0.

But based on Google's own data, almost everyone is using a version of Android prior to 3.0.

So "legacy apps" are ones built for the most prevalent versions of Android?

Dog Rescue: The Aftermath

Given how much of my life is consumed by my two dogs, I'm surprised I haven't posted about them since adopting them a few years ago.

When I say "consumed," I mean it literally. For example, here's a couch they consumed one rainy day when I skipped their walk:

In other words, they have a lot of energy and need a lot of exercise. They're also very strong, especially Bella. She's an Alaskan Malamute mixed with white German Shepherd. Ripley, the black dog, is Bella's puppy. She's much more Shepherd in appearance and attitude, but the Malamute in both of them is apparent when I walk them.

Actually, it's not really walking. It's being dragged by beasts bred to pull large loads. I've stopped going to the gym because being pulled by 130 pounds of dog every day is more than enough full-body exercise.

It's not risk-free exercise, either. Late one night I made the mistake of letting their leashes get behind me right before they spotted another animal in the woods. They took off full speed, tripping me up and dragging me across the ground for several yards before I could right myself. My wife still laughs at the memory of me coming inside with leaves in my hair.

Another risk is other dogs. Bella is incredibly gentle and sweet with people - she loves everyone - but she's the polar opposite with other dogs, at least ones that annoy her. If she sees another dog she usually ignores it, but if it makes the mistake of barking at her she instantly changes from a big teddy bear into a raging wild animal that's very hard to control.

Barking is something my dogs rarely do, though.  In fact, I've never heard Bella bark - but I have heard her howl plenty of times (it sounds like this). The neighbors probably think we own wolves.

And did I mention the fur? Both dogs blow their coats twice a year, which means everything we own is covered with either black or white dog hair for several weeks. When I brush them, they shed enough fur to build another dog with.

Sometimes I look back at the day we adopted Ripley and Bella and wonder whether I would've done it had I known how much work they would be. I have to admit, there are days that I wish I was dog-free.

But despite everything, these two dogs are like best friends to me. I've connected with them in a way I never have with other dogs I've owned. I've come to truly respect their combination of strength and gentleness, and I admire their intelligence and independent natures. I wouldn't trade them for anything.

But I am looking forward to them being a few years older, when they'll hopefully be a little less energetic.

Wireframing and the Reformed Cowboy Coder

Wireframing - sketching out the interface of your software with a focus on what it does rather than how it looks - was something I used to avoid.

I figured I'd end up laying out the interface in my programming IDE anyway, so why make extra work for myself? Just skip the wireframes and go straight to the IDE.

Besides, weren't wireframes only used by teams in order to collaborate on design? I was a one-person company when I created HomeSite, TopStyle and FeedDemon, so wireframes seemed pointless.

But I was recently tasked with designing the next version of Glassboard, and I'm not the only one working on that so wireframes suddenly made sense.

And you know what? I should've relied on wireframes all along.

Sure, it's extra work. And it can be pretty tiresome, too. It took me a lot longer to wireframe the app than I thought it would.

But once I was done, seeing an overview of every screen turned out to be enormously helpful. I better understand the relationships between those screens than I would have if I stuck with my "cowboy coder" ways and designed in the IDE.

Plus, writing out the purpose of every major area helped me clarify the UI and UX. I ended up re-thinking a lot of initial design decisions after I had trouble explaining them.

So consider me a reformed cowboy coder. I was wrong to think that only teams need to wireframe their software. The primary benefits I got from wireframing would've helped me even when I developed alone.

PS: I'll probably be asked which wireframing tool I use, so I'll say here that after trying a number of tools I chose Balsamiq Mockups. I like how its "lo-fi" approach reinforces the idea that you're sketching out your design rather than deciding every last detail.

Hateful Hiring

This post on the 37signals blog struck a chord with me.

Interviewing programmers by requiring them to tackle problems on a white board is a lousy way to find successful developers, yet this practice has existed for years.

I've experienced it myself a few times, and each time I failed. Badly.

On one occasion I was interviewed by four separate people during a single day, all of whom expected me to answer on a white board. None of them asked any questions about previous experience. One of them hadn't even read my résumé prior to the interview.

I've also been asked to tackle problems way outside my area of expertise. Perhaps the silliest was when I was expected to answer a problem which required knowledge of graphic chip architecture even though I was being interviewed for a front-end programming position that had nothing to do with graphics.

Yes, despite the fact that I've written several very successful programs, I wasn't asked back for a second interview because I suck at answering irrelevant technical problems on a white board.

I agree with 37signals that the best way to gauge the potential success of a programmer is to see what they've already done, even if it's just side projects they worked on in college. Interviewing via a white board is like deciding how good a musician is by asking them to write tablature instead of listening to them play.

Immobile Apps

Many of my favorite mobile apps are immobile. I can't take them with me.

At least not if I'm going somewhere that doesn't offer a fast internet connection. Like the small town I recently visited for five days.

I couldn't use Twitter there because it kept timing out before downloading the latest tweets. And Facebook was completely useless - it wouldn't even let me view stuff that had been previously downloaded.

Almost all the apps I use - including some games that shouldn't even need a connection - became immobile.

It reminded me of the early days of desktop development, when too many developers assumed that everyone had a computer as fast as theirs. These days too many developers assume that everyone has a connection as fast as theirs.

One of the most painful things we did when developing Glassboard was ban ourselves from Wi-Fi for a week. I live in an area where cell coverage is really spotty, and using our app without a fast connection was eye-opening and humbling. I spent the next week rewriting huge chunks of the app so it would better handle poor (or non-existent) network connectivity.

If you're a mobile developer, I urge you to do the same. Spend several days using your software without a fast connection, and chances are you'll find - as I did - that you've unwittingly built an immobile app.

Are You Paying Attention to Facebook?

Way back in 2004 I wrote about how a scrappy young Google was replacing an increasingly stodgy Microsoft as the predominant tech company. A year later I wrote about how Google hoped to benefit from knowing what you're paying attention to.

These days Google is turning into the stodgy company and Facebook is the scrappy upstart. And now Facebook is the one hoping to benefit from what you're paying attention to.

Frictionless sharing is Facebook's latest attempt to find out what you're paying attention to. They want to know what sites you're visiting, what songs you're listening to, and pretty much everything else about you, so they can surface more relevant content in your newsfeed and show you more relevant ads. They also want to build a more thorough profile of you in order to enable up-and-coming features like timeline, and to open up more possibilities for those who develop apps on their platform.

But if Facebook wants to collect this information, they need to do it in a way that doesn't lead customers to believe their privacy is being violated. And based on the reaction to frictionless sharing, it appears they've failed to do that. They're gathering - and exposing - all this attention data in way that scares an awful lot of people and will surely invite increased government investigation. That could backfire on them in a big way (remember how diminished Microsoft was following their wrangling with the DOJ?).

All of this makes me more confident of our decision to make privacy the focus in Glassboard. When we created Glassboard, we anticipated an eventual backlash against popular social networking services that violate your privacy. And based on the news we read every day, it seems like that backlash may come even sooner than expected.

Announcing Glassboard 1.2

Last month I wrote about a beta version of Glassboard which included a handy "invitation code" feature which makes it much easier for others to join your private boards.

Well, it's out of beta now - you can get it from the Android Market and the iPhone App Store.

If you'd like to find out more about this release, stop by the Glassboard Blog for details.

In Defense of Android's Hardware Buttons

Lately I've seen a few posts criticizing the Android hardware buttons. I get where they're coming from - especially regarding the sometimes confusing way the back button is handled - but now that I've switched to Android, these buttons are among the things that make it so hard for me to use an iPhone again.

As an Android developer, I love that I can tuck actions into the menu button instead of having to use precious screen real estate for icons that perform those actions, as iPhone developers are forced to do.

Seriously, how many iPhone developers would love to stop fretting over where to place their settings icon, or their accounts icon, or their mark all read icon, etc.? Wouldn't it be nice to have a common place to put all those things so you didn't have to clutter your UI with them?

I'm also a fan of the much-maligned Android back button. Yes, some apps intercept the back button and make it act weird. I hate that, too - which is why I don't use those apps. Those crappy apps  aside, I like having an easy, consistent way to navigate between activities and apps.

Now, by this point iPhone users may have written me off as an Android fanboy, but that's not the case. There are plenty of things the iPhone does better than Android - most importantly the iPhone wins on overall UI consistency and attention to detail. But as both a developer and an end user, the hardware buttons make Android easier and simpler for me.

The Long-Term Failure of Web APIs

Years ago, when developers such as myself started the transition away from OS-specific APIs to web APIs, we believed that doing so would empower our software and save it from the confines of the desktop.

And we were right.

But we've also learned that while web APIs enable us to tap into a wealth of data, they can only be relied upon in the short term. The expiration date of software we create has been shortened due to the whims of those who create the web APIs we rely on.

I wrote the first version of HomeSite back in 1994, and seventeen years later I can still run it on the latest version of Windows.

I created FeedDemon 1.0 in 2003, and it was the first app I wrote that relied on web APIs. Now those APIs no longer exist, and almost every version of FeedDemon since then has required massive changes due to the shifting sands of the web APIs I've relied on.

You might think you're immune to this problem if you only integrate with APIs created by large players such as Twitter, Facebook and Google. But in recent years we've seen Twitter switch to a new authentication system, Facebook deprecate FBML, and Google discontinue several APIs. All of these changes have broken, or will break, existing apps.

The end result is that developers are spending more time upgrading their software to ensure that it continues to work with web APIs they've integrated with, and less time adding the features and refinements that would really benefit their customers.

That's a long-term failure, any way you look at it.

Anti-social FeedDemon (Killing Features, Part II)

Last night the changes to Google Reader went live, and as promised, they've removed the sharing features. This means that the sharing features in FeedDemon which rely on Google Reader will eventually stop working, so I'm forced to remove them.

A few years ago I wrote about the pain and pleasure of killing features, but deleting sharing from FeedDemon has been all pain and no pleasure. Those features took a long time to create, and I relied on them every day. Seeing what my friends are sharing, and sharing back with them, has become part of my daily routine.

I don't fault the Reader team for removing those features - it makes sense for Reader to integrate more tightly with Google+. And I certainly don't fault them for eventually removing those features from their unofficial API. If anything, I want to thank them for letting developers such as myself use their API for free for so long.

But I'm surprised that the Reader team didn't make the transition to Google+ an easy one. I realize that Reader users are a dwindling bunch, and most of them never used the sharing features. But many of those who relied on sharing are influencers, including well-known tech journalists, bloggers and developers. It strikes me as a bad idea to leave these people with a sour first impression of Google+, yet that will be the result of the painful transition from Reader sharing to Google+ sharing.

As far as FeedDemon goes, in a few days I'll have a build ready which removes the sharing features. But I'm going to hold off releasing this build for a little while since sharing still works at the API level. In other words, right now you can still use the Reader sharing features in third-party apps like FeedDemon even though those features aren't available in Reader itself.

Before the end of the year, though, there will be a new FeedDemon release which does away with sharing, and every FeedDemon customer will need to upgrade. That pains me, because like every developer, I'm used to having new releases improve upon previous ones. For some this release will feel like a downgrade, and I know I'll take some heat for it since many customers won't be aware of the reasons for the loss of sharing.

Tell Us How You're Using Glassboard

This strikes me as strangely funny: we want to talk about how people are using Glassboard, but we made it so private that we don't know how people are using it unless they tell us.

That's right, we're so committed to privacy that even we can't see how Glassboard is being used.

So if you've got a story to share about how you're using Glassboard, please drop us a line at stories@glassboard.com. We'd love to feature your story in our blog and elsewhere to let others know the benefits of private group sharing.

What the Upcoming Google Reader Changes Mean for FeedDemon

Yesterday Google announced some big changes to Google Reader which will impact FeedDemon (and every other application that uses the unofficial Google Reader API).

In an effort to better integrate with Google+, Reader is retiring friending, following and shared link blogs. That means the social features in FeedDemon that rely on Google Reader will eventually stop working.

They won't stop working right away, though. Google will continue to support those features in its API even after they disappear from Reader's UI. But at some point (I don't know when yet) they will cease to function, and you'll be unable to share articles in FeedDemon or follow the shared articles of other users.

Before that happens, I'll release a new version of FeedDemon that removes those features. But I won't do that until the new Reader goes live and I have a chance to test against it, which will likely take a few weeks.

I am, of course, disappointed to see those features disappear. I know a lot of FeedDemon customers will miss them, and I'll personally mourn the loss of shared articles since that's something I use every day.

Glassboard for Android: What Else is New?

Yesterday's post showed off the new invitation code feature in the latest beta of Glassboard for Android, but that's not the only thing that's new.

For one thing, the obsession with performance that FeedDemon customers have come to expect from me has finally surfaced in Glassboard - this app is fast, even on low-end Android phones.

And it's fast even when the network connection is lousy. The entire Glassboard team banned themselves from using Wi-Fi during development to make sure our apps worked well regardless of the reliability of the network, and we're very pleased with the results. Quite frankly, we're surprised that more app developers don't do this - we tested a number of high profile apps that became almost unusable in the absence of a fast Wi-Fi connection.

I've also put a lot of effort into improving the experience when viewing a board containing a lot of photos. Pictures load much faster, and you can now fling your way through all the photos shared in the board.

If the new invitation code feature isn't your cup of tea and you prefer to stick with inviting by email, then you'll be pleased to hear that you can now select multiple people when inviting from your contacts. The contact list combines people from your Android contacts with those who belong to boards you're a member of, and it's filterable so you can quickly find the people you're looking for.

Those are the most obvious changes, but there are a ton of tweaks and UI improvements throughout the app. If you're already using Glassboard, I think you'll like this pre-release. And if you're not using Glassboard, please give it a try - I think you'll find the focus on private group sharing a refreshing change from the over-sharing found in so many other social apps.