Dog Rescue: The Aftermath

Published on by Nick Bradbury3 Comments

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

Published on by Nick Bradbury3 Comments

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

Published on by Nick Bradbury10 Comments

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

Published on by Nick Bradbury13 Comments

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?

Published on by Nick Bradbury2 Comments

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.

In Defense of Android’s Hardware Buttons

Published on by Nick Bradbury3 Comments

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

Published on by Nick Bradbury28 Comments

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)

Published on by Nick Bradbury7 Comments

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.

What the Upcoming Google Reader Changes Mean for FeedDemon

Published on by Nick Bradbury6 Comments

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.

Tiny Apps are Hard

Published on by Nick Bradbury5 Comments

When I started writing mobile apps, I figured, how hard can it be? Apps look dinky on the small screen, so it must be easy to create them.

But holy shit is it hard.

It's hard on Android, on iOS, on WP7. And from what I hear, it's even harder on Blackberry.

It's almost like the MS-DOS days when you had to figure out how to squeeze every last ounce out of the machine to get your stuff to work. Except now you also have to make your app look good.

But you know what? I'm loving the challenge. I've been developing desktop apps for so long that I just assumed I could keep adding feature after feature and option after option without worrying that I'd tax the system.

Now that I'm a mobile developer, I'm finding it strangely wonderful to have to consider things like battery life, reduced screen real estate and limited storage space. I'm forced to make sure that anything I add to my app is important, because if it's not important then it's not worth the trade-offs.

Regardless of whether I stick with mobile development, the lessons I've learned from it are ones I'll apply to everything I create in the future. Keep it simple, keep it uncluttered, and keep it focused. That's how you create great apps for any platform.