Nick Bradbury

Jenny Blogs Up a Storm

If you haven't checked out the Glassboard Blog lately, you should stop by. Our own Jenny Blumberg has been posting some great stuff there.

Here's a smattering of recent posts I've enjoyed:

• The Rise of the Planet of the Monkeyspheres
• The two types of social networks: Are you just spraying people or actually connecting with them?
• Ads, if I ignore you will you go away?
• Keeping track of the trackers: Collusion exposes browser cookies for you

Try the Glassboard v2 Pre-Release for Android

The new version of Glassboard we've been working on is such a huge improvement over the previous release that it's been really hard to keep quiet about it.

Although the entire team was pleased with what we accomplished in the first version, we all knew the user experience needed work. So we buried ourselves in wireframes, mockups, PSDs and all the other necessary evils of design until we created something we were proud of.

The end result is Glassboard v2, which will be available in the App Store and Android Market Google Play in a few weeks. But if you're an Android user who can install non-market apps, you can get an early look at the new version by clicking this link from your Android phone.

After you've installed this pre-release, tap "Enter Invitation Code" in the app's sidebar then type in this code:

ckanq

This will add you to our "Android Testers" board, where I hope you'll tell us what you think about the new version.

We're really pleased with Glassboard v2 and hope you will be, too. It's the app we wish we would've created the first time around.

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

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

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

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

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

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.