Category Archives: Nadyne

Systers meet-up on Sept 18 at 7pm

I nearly forgot!  I’m hosting a meetup for women in tech in conjunction with Systers and the Anita Borg Institute at VMware’s headquarters on Wednesday, September 18, at 7pm.  We’ll be discussing how to get the most out of the upcoming Grace Hopper Celebration of Women in Computing.

If you’re a local woman in tech but aren’t attending GHC, feel free to come anyway — most of what we’ll talk about will be applicable to other conferences.  This is a great opportunity to meet other local women in tech, learn about GHC as well as other conferences, and have some great conversations.

RSVP here, or email me if you’re having trouble RSVPing on that page.

multitasking impacts both your productivity and mine

There’s already plenty of research out there that says that multi-tasking is a myth, that you’re just context-switching and not actually getting any of your individual tasks done any faster.  New research suggests that it’s actually worse than that: not only does your multi-tasking keep you from getting your stuff done any faster, but it also impedes others from paying attention.

Let’s look at this the context of Anil Dash’s recent strawman-filled diatribe against those who wish people would turn off their mobile devices when they’re at the cinema, in which he says the following:

I hear the arguments the fussy film people are making. They’re all super, uniquely sensitive to light pollution, and the brightness of the screen is incredibly distracting to viewing the screen.

It’s not just people who are “fussy” or who are “super, uniquely sensitive to light pollution”.  It’s distracting, and (as the author of the study I referenced above puts it) disrespectful to your fellow audience members.

I’ve been trying to leave my laptop back in my office when I’m in meetings, unless I’m actively taking notes with the laptop (since I type faster than I write).  This gives me even more reason to do it.

things I learned today: the origins of the tree swing cartoon

I don’t know about you, but I’ve seen the tree swing cartoon a million times.  It’s a great cartoon that illustrates the difference between what the user wants and how it’s interpreted by various groups in engineering.  I’d never seen it attributed to anyone, and as I learned today, its origins have now been lost.  There’s lots of variations of it, too.  That article is an interesting one about the history and variations that the author has been able to track down.

Gmail gives the cloud a bad name

The cloud isn’t always an easy concept for people to grasp, even before we add in complexities like public cloud versus private cloud versus hybrid cloud.  For a non-technical audience, I usually use webmail to help them understand the cloud.  I can login to Yahoo! Mail, or Outlook.com1, or Gmail, from any computer in the world, and I’ll see everything the same on that webmail service.  Since there are lots of webmail users, starting off with a known concept and explaining how it’s one type of cloud helps them grasp the idea.

The problem is that webmail in general, and Gmail in particular, is a public cloud.  It’s a public cloud that you’re not paying for.  Servers, storage, and bandwidth are not free.  To pay for the resources that Gmail needs, Google shows you ads that it thinks are relevant to you.  But now, Google has explicitly said that its users should have no expectation of privacy:

Just as a sender of a letter to a business colleague cannot be surprised that the recipient’s assistant opens the letter, people who use Web-based email today cannot be surprised if their emails are processed by the recipient’s [email provider] in the course of delivery. Indeed, ‘a person has no legitimate expectation of privacy in information he voluntarily turns over to third parties.

Users can have a legitimate expectation of privacy of information that they voluntarily turn over to third parties.  There’s plenty of data that I voluntarily turn over to a third party.  Every conversation that I have with my doctor or my lawyer contains data that I’ve voluntarily turned over to them, and I have the expectation that they’re going to keep that information private unless I authorize them to do something else with it (say, use it anonymously as part of a medical research study).  As a researcher myself, I get lots of sensitive data from the participants of my research, and I’m very careful to ensure that my participants’ sensitive data is not revealed to anyone.  When I’m reporting results to my own team, I would never say “Eddie Dinel, Director of Program Management at VMware, said …”.  Instead, I always say “Eddie, a senior manager at a technology company, said …”2.  I make sure that the information that participants share with me is kept private.

If you’re using a cloud for sensitive data, you should be careful to understand what the privacy policy is of that cloud.  Gmail has told you that you can’t expect privacy from them.  This might or might not change your usage of Gmail, but don’t assume that their stance on privacy applies to every other cloud out there.

  1. née Hotmail, née Windows Live Mail, née Windows Live Hotmail, and I’m sure I’m missing other interim names too.
  2. I use Eddie as my example because he’s my officemate.

a different test of your product

I mentioned that you could do a quick test of your product by asking your users to describe it to you.  There’s a related but different test of your product that you should do.  Get the senior leaders of your application to describe, in a sentence or two, why people buy your product today.  Make sure they focus on the version of the application that your users are using today, not the version that they’re working on.

Doing this by itself will tell you what your team thinks your app does and why people buy it.  You’ll learn a lot if their answers are similar or disparate.  If their answers are similar,  then you’ve got a great starting point for making design decisions.  If their answers are disparate, then a useful exercise is to understand what the points of commonality are and where the points of disagreement are, and then try to determine how to bring the team into alignment.

If you do this in conjunction with asking the same question of your users, then you can compare the answers of the two groups and make sure that they’re aligned.  If they’re not aligned, then you’ve got the opportunity to help your team better understand what your users actually do, or want to do, with your application.  If they are aligned, then you’re in an awesome position of being able to make an even better product in the future.

This is a very small piece of research that you can conduct, often just in hallway conversations, and is very illuminating.  If I’m working on a product that I’m not familiar with, or with a new team, I’ll often start here to understand the landscape.  It’s quick, it’s easy, and can form the basis of future research efforts.