Beautiful Interfaces

This topic seems to get into the air about once a year, and I normally avoid it like the plague. Most of the time it seems to result in pointless hand-wringing and, if anything, harms us tech women by calling us out. But stubornella’s excellent blog post stirred up my thoughts, and the relative civility of her commenters gave me hope. Also this latest brouhaha started around jsconf, which I attended myself, and which helped shape my own thoughts on the topic.

So these are a bunch of scattered thoughts, that together are my attempt to honestly describe my own experience.

1. A little story

I didn’t start programming until I was in high school. I was never even aware of programming until I took my first class, I think it was my sophomore year. (We wrote Hangman in Pascal.) Honestly, it just never crossed my mind.

At that point, I was already behind. Because real programmers start when they’re 8, don’t they? Real programmers get started seemingly at birth, and know what they’re meant to do right away – there aren’t really other options. (I’m speaking in stereotypes, of course, but they are stereotypes that the field itself promotes.)

When I started college I realized how far behind I was. I did well in my first couple of classes, but I wasn’t the best. And other things seemed so much easier – writing was easier, and art was, and all of these other things. So I didn’t stop programming, but I switched out of CS into InfoScience, and made up a Digital Art major, and did all of this other stuff. (Not sticking with CS is my biggest college regret.)

When I graduated I decided to become a designer. After all I wanted to work in the tech field, but I “wasn’t smart enough to be a programmer”, and with my love of art, design seemed like a good compromise. Besides, that’s what nerdy chicks do – they become designers. Right?

I was fortunate enough to explore the design and UX field at a company where I could easily switch back to programming. And I did, once I realized that design wasn’t for me.

I learned some valuable things from this experience. But how much better would I be at programming now if I hadn’t taken that 2-year detour? How much further ahead would I be if I had had the self-confidence to stick with CS, and the understanding that I could actually catch up, if I just worked really hard?

This has to do with gender because it has to do with stereotypes, and with how I measured myself against those stereotypes and found myself lacking. And you’d think I would have learned from it, but I still do the exact same thing.

2. Ambient sexism

I have never had anyone personally treat me rudely because of my gender. I’ve never been the target of serious disrespect, or been denied an opportunity as far as I know. (I’ve had dudes be really awkward or try to hit on me, but whatever. I can deal with that.)

This is a totally awesome thing! It’s a big change from when my mother was an engineer in the 70s. (She has some stories that you might not believe, about behavior that was just accepted back then.) Progress has happened, and we nerdy chicks owe that generation a lot.

It also makes this kind of difficult or confusing to talk about. Most of the programmer guys that I know are totally awesome people, and would never think of themselves as sexist. And yet there’s all of this general objectification and disrespect that floats around in programming culture and makes it really hard to be female in certain venues. Call it ambient sexism if you will.

A lot of that stuff comes from people who would probably be perfectly nice to me as an individual. How do these two things reconcile?

3. Yes, you are.

“Oh, we’re not talking about you” is never a valid excuse.

4. Get to know me, I dare you.

I find that as soon as I get the chance to actually work with someone, gender instantly becomes not an issue. As soon as I get the chance to show what I can do, to get into technical topics, to talk geek with someone, then all of the awkwardness and misbelonging disappears. They stop seeing me as a woman and start seeing me as a programmer, and then things are fine.

(The tricky thing is that I’m actually both.)

5. female X awkward = even more awkward!

I’m a great big introvert, as many programmers tend to be. I’m also shy – not cripplingly so, but it still takes a lot of energy and mental preparation to face a big group of people that I don’t know.

Gender is not the root of this problem, but it serves as a magnifying factor. When I’m the only woman in the room it makes it even harder to connect, harder to overcome my natural shyness, harder to find a point of entry to the conversation. It serves as an isolating factor, and makes the barriers that already exist that much higher.

6. I <3 nerds

Talking to smart programmers is one of my favorite things in the world. Talking to smart female programmers is even better, because they tend to be “my type of folks”. But I’ll geek out with anyone – as long as I don’t feel too intimidated by them.

7. Learning French

You learn how to get by, in this man’s world. You learn to make yourself bigger, to consciously take up more space, to pitch your voice lower and louder to be heard. You learn how to dress to minimize staring, and when to choose a t-shirt over a blouse. You learn what topics to steer away from in conversation, and which threads on websites to never ever click. You learn to fit in, to minimize the differences that would keep you separate, to adapt to the common culture. It’s like learning to speak French. You learn, or you leave.

People learn and live in other languages every day; but native speakers will always have the advantage.

(Sometimes two cultures collide and create a new language, a creole, that contains concepts from both of its parents. I want to know, how do we go there?)

8. Community

There aren’t too many place where I really fit in, so when I find one I tend to become attached. Because of this, I’m completely sympathetic to guys who have found a community and a home within programming culture, and who want to preserve and defend that culture.

I can understand how it might seem unfair and threatening when people talk about wanting to change that culture, like in that famous study about geeky environments and tech appeal. Because they value that culture the way it is right now; it’s brought good things to their lives and they don’t want that to be lost. That makes perfect sense to me.

But dammit, I’m here too, and I also want community!

There has to be a way to do both – to extend the culture, without replacing core functionality.

9. It’s not about the dick jokes.

I actually have a pretty coarse sense of humor. So I’m fine with the dick jokes, seriously. I’ll #twss with the best of them – just check my Twitter feed. I think my sense of humor is pretty standard for the field.

Except. Except it all changes when I’m already feeling unsafe and isolated. When I’m feeling in a hostile environment where I have to be on my guard. Then the joke that I might find hilarious under better circumstances suddenly starts to feel like a threat – just another reminder of how much I don’t fit in.

It’s not about the dick jokes, it’s about the overall atmosphere.

10. The relevant parameters

I love programming. It’s not just what I do, it’s What I Do. Nothing else gets me into a state of flow so easily and so quickly. I love it for itself: for the joy of unraveling a complex system and seeing it all take shape in your head; for the love of creating something that’s minimal and effective and Right, with nothing extra added and nothing left to take away; for the satisfaction of making something with my own hands that other people will use, that improve their lives in some minor little way. (The fact that it makes me money is a nice side effect.)

None of this has anything to do with gender. What does have to do with gender is all of the auxiliary stuff, all of those human and social things that turn out to be so important in careers.

So far the first thing has outweighed the second, and so I stay. But I can see how that calculation might be different for someone else.

I can see how easy it might seem to go and find someplace friendlier, where it’s less of a struggle just to be.

11. Hills

There are two runners. One is running on perfectly level ground, and the other is struggling up a big hill. They both might get to the same place eventually, but which one is going to have the easier and more pleasant time?

Being female in the tech industry is that hill.

(And yet. Runners run hills to get faster, don’t they?)

12. Hard words for a hard problem

So maybe you have to work twice as hard to be accepted. Guess what? Go out and work three times as hard.

Do you have to be twice as good to be heard? Be four times as good, and be impossible to ignore.

Feel like you have to know twice as much? Learn five times as much, and then teach others.

Be constantly learning. Work your ass off. Put in your 10000 hours, and then put in some more. Make your skin thicker, and just go on.

Yeah, it can seem unfair. Guess what? Life’s unfair. The only way forward is to suck it up and go make some awesome stuff.

You can let this make you miserable, or you can let it make you better.

(I’m talking to myself here.)

13. That’s what she said.

Yes. Yes, it is.

Sites and apps

During discussions about accessibility, I always wonder whether accessibility goals should be different for different types of web projects. Are there cases where accessibility is less important? And if so, what are the relevant differences that make it that way?

“The web should be accessible” is an easy blanket statement, but the web is very diverse. Many sites and applications exist that aren’t accessible in various ways, but are still useful and popular. Are we to say that these sites should not exist at all, and everyone else misses out? On the other hand, people have a right to get the information they need and perform the tasks they need to perform. How do you balance these two things?

For websites, whose primary purpose is conveying information, it’s no question to me that the site should be accessible. First off, most sites that exist to convey information want it to be widely seen; accessibility is in their own best interest. These also tend to be the sites where accessibility is easiest and can be achieved by following simple best practices. There may be some flashy ajax stuff going on, but it tends to be window dressing. At the worst case you might have to provide textual alternatives to rich media like videos or Flash.

But there’s another category that I think is much more of a grey area, which I’ll call web apps. It’s tough to categorize web apps, so I’m going to take the lazy way out and say that they are the complement set of the above category, containing any site whose primary purpose is not to convey information. So if the app exists to let people create something, or to play a game, or to do something complicated with data, it may be reasonable for the app’s creators to set the bar higher in terms of what is required to use that app. This may mean requiring javascript or the use of a mouse, or the ability to view visual images, or even specific browser features. (You won’t be using Bespin in IE, for example.)

Another way to look at it: Importance and relevance

Anything that’s both important and relevant to a large number of people — such as job applications, reference information, and government agencies’ sites — should always be widely accessible in as many ways possible.

If it’s important but not widely relevant, consider your target population and gear support towards their specific needs.

If it’s widely relevant but not important to people’s lives, like for example many browser-based games, prioritize accessibility based on a cost-benefit analysis of how many people you’d like to reach.

If it’s neither important nor widely relevant, go nuts; knock yourself out with crazy features.

I feel like this could be somewhat controversial; what do you think? Should there be a difference in how accessibility is prioritized for different types of projects on the web?

The growth of the mobile web and touch screens has created more browser diversity than ever before. I think it’s useful to categorize browsers into four major categories, along the axes of screen size and input type.

Probably the most growth is going to come in the large-screen touch category (mainly because it’s starting from the lowest place overall). If anything, I would expect the small-screen mouse input category (i.e. Blackberries) to decrease — but not to disappear entirely, because businessmen sure do love their physical keyboards.

Making web apps that work with minimal adaptation across all four quadrants is the challenge. (And you thought dealing with different screen resolutions was hard?)

Why?

Server-side javascript has been a hot topic for awhile now, especially since node.js was announced. But after reading about it here and there, a big part that I felt I was missing was the “why”.

I mean, for those of us who really enjoy javascript (which I do), enough said. Javascript on the server? Hell yes!

I realize, though, that most of the world doesn’t share my love of this particular programming language. So, while at jsconf this past weekend, I tried to collect some reasons why everyone should consider javascript on the server.

1. It lets you write things once instead of twice.

The more logic that you’re running on the client-side, the more code you have to write twice: once in your server-side language of choice, and once again in javascript. The classic example here is validation code. You want to validate on the client-side for a good user experience, but you have to validate on the server for security reasons. As a result, you have two whole different sets of validation rules to be written, updated, and maintained over time.

Now wouldn’t it be great if that could be just one piece of code? You’d cut your codebase in half, and make maintenance a lot easier.

2. It could make progressive enhancement easier.

Server-side javascript has the potential to make progressive enhancement a lot easier, by requiring you to do less special planning for it. With a hijax-type approach, which seems to be the current best practice for supporting non-scriptie users, you have to create your site first without javascript, and only then add all of the dynamic stuff in.

In a world of limited budgets and tight deadlines, this may seem like a lot of extra work to support a very small number of users. But with server-side javascript, there’s the potential that for those users, you could just run the javascript on the server-side instead and return the page in its new state.

I’ll be honest, this would probably be a pretty slow experience with a lot of extra page reloads, but it may still be better than the unusable state of many current sites with javascript turned off. (There was a fab talk at jsconf by Philly’s own Jenn Lukas on the sad state of no-script support on major sites.) At least this way people could get what they to wanted, even if the experience was slow.

This isn’t a topic I’ve heard discussed very much yet, but if there was a way to make progressive enhancement basically automatic, that could turn out to be a big win.

3. It lets you stay in one headspace.

Ok, this could be considered a weaker reason, which is why I put it third. But it’s well-known that switching between tasks harms productivity, and it’s much better to focus on just one thing at once. Now consider that many developers are generalists who do some server-side and some client-side code, and as a result have to hold (at least) two different languages in their heads, with two different sets of APIs and quirks and syntaxes and styles, switching between them all of the time.

I know that I personally try to use console.log in Objective-C, trace in a javascript file, or echo in a Flex app at least once a week. And that doesn’t even get to the subtler traps of forcing one language into another’s paradigm.

Now imagine that you could take a large portion of that brainspace and devote it to just one thing. One language, one syntax, one set of patterns, one set of common bugs. Wouldn’t it make you more efficient? Wouldn’t you get so awesome and productive and ninja-esque at that language?

Because.

I’m sure using js on the server has its downsides as well, but I don’t really know enough yet to speak to what they are. But I’m convinced now that it’s more than just a toy, and is worth at least a look from people who care about the good things above.

It’s true, I really am.

Also, I love this time of year, and I’m back.

I get annoyed by credit-card readers. You know, the kind used at gas pumps and ATMs. I always have to look at it and try to figure out which way I’m supposed to put my card in, because it differs from one to another. In order to do that, I have to look for the ubiquitous instructional diagram and try to match my card to the illustration, because there’s no perceived affordance on the device itself.

Okay, it’s not rocket science. It takes maybe 2-3 seconds, and a tiny bit of thought to figure out. BUT. But why should I have to spend this time and effort at all for something that really could be effortless?

It’s like the example of the doors that Don Norman covers extensively in The Design of Everyday Things. You shouldn’t need to label your doors with instructions — “Push”, “Pull” — because people should know this intuitively from the shapes of the handles. Likewise, you shouldn’t need to label your credit card readers with instructions, because people should know how to use them intuitively.

There are two ways to fix this.

One, build some sort of affordance into credit card readers that only lets you put your card in one way, and makes it visually obvious what that way is. Since credit cards are basically featureless rectangles with no built-in directionality, this would be difficult.

Two, put magnetic strip readers on both sides, so that it doesn’t matter which way you put in your card. The existing affordance — a flat slot indicating where you put the card — is sufficient, and no further instruction is required, because it just works. I think this would be the best way to go, unless there’s some technical reason preventing it that I don’t know about.

The larger moral is that simple things we use everyday should “just work”, and if you’re constantly having to provide instructions on how to use something, that probably means that it’s annoying people.

Don’t annoy people. Practice good design.

Another canvas-based toy, in honor of all the snow we’ve been having around here lately: The Snowflakerator.

Lets you draw in 6-way radial symmetry. I got the idea from those folded paper snowflakes that everyone used to make as a kid.

I’m liking canvas, it’s easy to do some fun stuff with. And I really like it not being the black box on the page that Flash tends to be.

More of these to come, probably.

A couple of weeks ago, my former colleague Mike @ Meja Design released this cool visualization of the digits of PI mapped to colored dots:

This got me thinking about other transformations you could do over the same set of numbers. At the same time, I’ve been wanting to start playing with canvas, for possible future infographicky goodness. So I thought, what better way to get my feet wet with canvas than to visualize PI as a line chart! And just for fun, I put it on a circle too, since, y’know, PI. (I was going to make the lines nice and curvy, but it’s the weekend and bezier curve math was not being my brain’s friend, so straight lines for now.)

So, without further ado: the digits of PI visualized as a line chart, using canvas. (Also: I threw in excanvas, but didn’t actually bother to test it in IE, so if it doesn’t work, um… try a real browser, I guess? Cheers.)

Is it even possible to successfully apply the principles of open-source software to design? Or does really great design require a certain level of Steve Jobs-like tyranny, a sense that one vision is masterminding everything, or at least a single point of responsibility?

(By “design”, I’m referring to visual/experience/industrial/graphic/architectural/service/fashion design — all of the fields that deal primarily with creating some sort of effect or experience for a human being. I am not referring to things like the design of circuits or of hardware. Those fields are different.)

The relevant difference that I see is that really great software is usually quite modular. Software engineering principles like encapsulation and loose coupling mean that lots of people can work on something, each one taking a part, and still come out with something that integrates quite well and does what it is meant to do. This is probably what makes open-source projects work as well as they do.

On the other hand, really great design is incredibly integrated. If you look at a great experience, one of the striking points is the way in which every single aspect, from building architecture to package design to software interfaces, makes an integrated and coherent contribution to the experience. It has a personality — one personality, not a schizophrenic array of different voices all talking at once.

I wonder, given its coherent and integrated nature, whether great design is fundamentally incompatible with the open-source model. After all, “designed by committee” is a common insult, but there isn’t really an equivalent phrase relating to programming.

A fascinating thing I’ve been noticing lately (and even more since the tragic earthquake in Haiti) is the use of social gaming to encourage people to donate. Mainly I’m thinking of Zynga, which raised $1 million for the World Food Programme in only 2 days, by allowing people to purchase special virtual goods in games like Farmville and donating the proceeds from those products to the cause.

I think this is brilliant, because it combines the best features of both donating and purchasing. You know that the money you give is going to help others who need it; and you also get something directly in return. (In the case of Farmville, you get access to a special crop with particularly lucrative stats, and you also get a special flag so you can show off your generosity to your friends.) This works because the marginal cost of virtual goods is effectively zero, so none of that money is required to compensate the producers, assuming that the fixed costs have been covered.

While Zynga is very much a for-profit company, seeing the effectiveness of their charity drive got me thinking about what it would take to create a game that was specifically designed to encourage people to maximize donations to a charitable cause. I think it would tap into a lot of the same traits that I discussed in my post about Farmville’s psychological hooks, but in a way that ties in-game rewards to a specific real-life behavior: that of donating money.

Let’s take the example of Donors Choose. Since they focus on primary and secondary education, if I were creating a game for them I would base it around a simulation of a school. Like Zynga’s games, my game would be tapped into some social platform like Facebook, to make it easy for people to “visit” and share with their friends. (The ability to easily check out other people’s performance is crucial; the competition and “showing off” that result are the hook upon which much of the desired behavior hangs.)

Maybe you start out in a one-room schoolhouse, with 10 students. You are given a teacherlike avatar that you can customize to look like yourself, to create a sense of ownership, and your goal in the game is to make your school a success.

The main aspect of the game is this: as you give money to various projects through Donors Choose, you get more students in your school, and you also get points that you can spend on virtual goods related to different subject areas.

So, for example, if you donate $100 to a science project, you get 1000 points that you can spend on installing a virtual science lab in your virtual school and buying things like awesome robots, model rockets, telescopes, and so on. If you donate $100 to an English project, you can buy fancy bookcases, statues of Shakespeare, comfy chairs to read in, and so on. (All very cutely and appealingly drawn, of course.) Basically, every dollar that you donate allows you to make your virtual school more and more luxe. (Think Harvard + Hogwarts + a sci-fi novel.)

This makes it very easy to show off your generosity to others, just like Farmville’s special Haiti flag does. And since we know that looking good to other people is one of the main reasons people donate, this should tap into that urge to show off, to appear generous, to make yourself look good. (While benefiting real people along the way, of course.)

Second, your school gets graded in all of these different areas, which roll up into an overall grade for you, the teacher. You start out with an F, and as you enhance different areas of your school, your grade goes up. This allows you to measure yourself against your friends in the game, and creates a leveling system. Your grade is tied to what virtual goods you have access to, with cooler or better virtual goods reserved for those with a better grade. This creates a virtuous cycle, where donating money lets you level up and gain access to better goods, which can be acquired by donating more money, and repeat.

Third, to encourage stickiness and a high level of engagement, there are regular tasks that you can do to earn a small number of points, like grading papers and talking to kids. (Hey, it’s no weirder than people virtually plowing fields and milking goats!) The number of points you can earn from these should be kept fairly low, below the threshold needed to buy a lot of the really cool items. And if you don’t check in regularly, there should be some form of consequence; perhaps your students’ morale drops, and therefore your grade goes down. Creating the potential for loss triggers loss aversion, which is such a powerful instinctive force.

Fourth, each real-life classroom that you donate to can select and send you a special gift for your virtual school. These should be really cool premium items that aren’t available any other way. This creates a very direct relationship of mutual benefit: give money, and get this rare item in return. (You should also be able to post their thank-you letters and photos in a prominent place in your virtual school, for other people to read.)

This is just a start on what such a game would be, but I think it’s a really interesting approach. Rather than denying or bemoaning the various blind spots, biases, and quirks of the human brain, I think it’s interesting to design ways that we can exploit those quirks and biases to accomplish something good.