Author: Nick Bradbury

Creator of HomeSite, TopStyle & FeedDemon for Windows, and Glassboard for Android. I'm a mobile developer at Automattic.

Glassboard 2.0: Nailing the Privacy Experience

Published on by Nick Bradbury

When we released Glassboard 1.0 last year, I think we nailed the privacy aspects. We built one of the only social apps that truly respects your privacy.

We didn’t, however, nail the experience. Glassboard 1.0 wasn’t ugly, but it sure wasn’t pretty, either.

I think we nailed the experience in Glassboard 2.0, though. The new version – which we released today on Google Play and the iPhone App Store – doesn’t just look better, but it’s also easier and more fun to use. Check out the screenshots at the bottom of this post for some examples of how the new version looks.

We also answered the #1 request of our customers and built a web-based version of Glassboard (currently in beta). My favorite thing about our web app is that it enables you to share PDFs, Word documents, MP3s, Excel spreadsheets, and many other files from your desktop with your friends, family and co-workers – even if they’re using our mobile apps.

There’s a lot more I could say about the new version – like how it enables viewing a gallery of photos people have shared – but hopefully I’ve said enough to get you interested. We’re really pleased with Glassboard 2.0 and we hope you’ll give it a try.

Girls Around Me Shows Why Privacy Shouldn’t be an Option

Published on by Nick Bradbury3 Comments

Earlier this week I wrote that privacy shouldn’t be an option. Privacy – like security – should be expected, not something that users have to enable.

Need proof? Just read about Girls Around Me, an incredibly ill-conceived app that takes advantage of women who don’t know they need to configure the privacy settings in the social software they use.

Software that isn’t private by default assumes users know how to make it private, which is an unrealistic – and, in the case of “Girls Around Me,” potentially dangerous – assumption.

I write the Android version of Glassboard, an app designed for private conversations. Find out more at glassboard.com.

Privacy is not an Option

Published on by Nick Bradbury1 Comment

Years ago, in the Dark Ages of desktop software, security was an option. People used software that was insecure by default, but if they knew where to look they could turn on various options that made the software secure.

Microsoft Outlook used to be like that: by default it would allow viruses to be emailed to you, but you could configure it to be secure if you knew where the security options were.

Then people started getting all sorts of nasty viruses via email, and Microsoft wised up. They stopped treating security as opt-in and started making their software secure by default.

Fast forward to today and we’re seeing a similar situation with privacy.

By default most social software isn’t private – it’s configured to share everything about you, not just with people you know but also with advertisers. You have to figure out where the privacy settings are – and what they mean – if you want the software to respect your privacy.

And as with the opt-in security settings of the past, today’s opt-in privacy settings are leading to all sorts of problems. Every day we see headlines about privacy violations that could’ve been avoided if we used software that didn’t treat privacy as an option.

Software developers need to look at privacy the same way we’ve learned to look at security: it’s not an add-on or a feature that customers have to turn on, it’s something built-in that shouldn’t be turned off.

I write the Android version of Glassboard, an app designed for private conversations. Find out more at glassboard.com.

Digital Ownership and the Path to Privacy

Published on by Nick Bradbury1 Comment

What does it mean to "own" something that exists only in digital form? If the answer is we don't really own things that are digital, then does that mean we don't own our private information when it's merely bits of data?

Those questions reflect our inability to value non-physical things. We as customers look at digital goods as less worthy of monetary value, and companies look at customer data as less worthy of privacy.  In both cases, we de-value things that we can't touch.

There are plenty of examples of companies who believe the rules of privacy and ownership are different online than they are in the physical world.  Mobile apps upload our address books without permission, websites track us without our knowledge, media corporations secretly install rootkits on our computers, and online stores sell us digital goods we thought we owned but merely leased instead.

Yes, the tech and entertainment industries pretend they value digital items when they rail against piracy, but they suddenly get fuzzy when it comes to valuing our digital rights.

Yet piracy also reflects how we as customers value digital data. Many of us pay for music, movies and software when it comes in a box but steal it in digital form, as though the real value of a piece of music is in its packaging instead of in its artistry.

We lash out against companies that violate our privacy, yet fail to see how our unwillingness to value their digital goods in some small way led to the prevalence of a business model that gives the actual product away and earns money by selling our personal information.

And we never noticed that in order to own all this free stuff, the free stuff gets to own us back.

Let’s Not Screw Up Mobile Privacy

Published on by Nick Bradbury1 Comment

This week we saw headlines about mobile apps that violate your privacy by uploading your address book without permission.

These kind of "mistakes" helped kill demand for desktop software, and I’d hate to see history repeat itself with mobile software.

Several years ago I wrote that desktop software is paralyzed by fear due to all the frightening warnings that show up when you try to install something. It wasn’t just the rise of Web apps that led people away from desktop apps: it was also because installing desktop apps became too damn scary.

The same thing could happen to mobile software. Repeated privacy violations will force mobile OS vendors to show more warnings, scaring customers away from trying new apps.

Mobile developers who want to avoid that possible future should accept the idea that data on the device must stay on the device unless the user has given permission to upload or share it. Being able to access data on the device in no way implies ownership of that data.

No More Free Tech Support

Published on by Nick Bradbury5 Comments

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

Published on by Nick Bradbury4 Comments

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

Published on by Nick Bradbury6 Comments

“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

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.