Since the bus driver does not necessarily open the back doors at every stop, there is a button next to the doors on the outside of the bus that will open the door. The button looks like this:

What most people don’t understand is that you have to hold down the button until the door opens.

On the style of bus I take, there is a pressure sensor built in to the step inside the bus leading down to the back door, which opens the door when you step down on it (which also isn’t great user experience, but that’s another story). I assume that when the buttons were installed, they were configured so that they would work the same way as the pressure sensor in the step. While it makes sense that you would need to keep standing on the step for a moment to open the door, that’s not a great user experience for a button.

Few people understand that they need to hold down the button to open the doors. Over the course of my 10 block bus ride, I usually see many people frantically pressing the button repeatedly, as though it were an unresponsive elevator button. It’s a perfectly reasonable response, considering how much the bus button looks like an elevator button.

Sadly, the bad design works in my favor. When people fail to open the doors from outside, the bus is able to leave a bit faster. Still, I feel a little guilty about benefiting from bad user experience.

Until MUNI posts instructions next to the button, I’ve resolved not to worry about it. If the bus isn’t crowded and I’m standing within a step of the door, I’ll open it for someone who wants to get on, but I won’t go out of my way to make a packed bus even more packed. If there’s anything San Francisco buses don’t need, it’s more confused riders.

She took matters into her own hands and created a new conference for game developers in her area with the secret agenda to “get as many women on stage as I possibly could.” Her not-so-secret agenda included other aims like making the conference affordable, not including any panels and ensuring the conference took place on a weekend (so attendees didn’t have to take time off work).

I love this initiative, but what really stands out to me is hearing that finally, someone other than me is willing to admit that they can’t stand panels at conferences!

I hate panels. Kill them with fire.

Before I anger many conference organizers, let me clarify. I have no problem with a well-planned talk presented by multiple people. I do hate the style of panel in which four or five very accomplished individuals sit on a stage and make up answers to predictable questions.

I hate sitting through 15 minutes of introductions that are unnecessary if you read the panel description. I hate how vague the topics always are. I hate watching one panelist hog every question. I hate that half the time is typically spent on audience questions, which are usually self-aggrandizing at worst and boring at best. Like Courtney Stanton, I hate having my time wasted watching strangers agree with each other.

Most of all, I hate the lost potential of panels. You could increase the impact of the presentation by an order of magnitude if you tell those interesting panelists, “Talk to us at length about something you’re passionate about.” Given the choice, would you attend the talk where the presenter did or didn’t plan what she wanted to say? I’ll gladly attend a deep dive talk or a workshop on any topic before I attend a panel.

Tempted to host a panel? Here’s what you can do instead:

• Divide your panel into 10 minute lightning presentations.

• If you want to address a problem as a group and crowdsource solutions, don’t bother with the panel. Set ground rules, open the mic from the beginning, and only take questions and answers from the audience.

• Save money and invite one presenter for a deep dive talk.

• Still really want to interview people on stage? Interview one person at a time.

Conference organizers, please step up your game. Don’t pat yourself on the back because you gathered five of the best minds in your industry and asked them each their background story and what they do in their spare time.

Recently while filling out a bank form online, I had the option to receive emailed statements rather than dead trees in the mail. The checkbox looked like this:

Receive email statements

I preferred the dead trees, so I left the box unchecked and clicked “submit.” The page came back with an error and pointed out that checkbox actually looked like this:

Receive email statements *

Of course, I wasn’t being given the option to receive emailed statements, but rather the bank needed me to acknowledge that I would receive emailed statements, despite my preference.

It doesn’t make sense when you think about it. A checkbox field is always a required field, whether or not it has a little red asterisk. It only returns true or false; it can’t return null. It doesn’t make sense to give the user an error saying they didn’t give an answer for the checkbox, because not checking it is an answer.

My grievance is not that the bank was forcing me into emailed statements (though I am miffed about it). Rather, it annoys me that requiredness is not consistent among field types. Making any other kind of field required means that the user must give some answer. Making a checkbox required means that the user must give a particular answer.

I realize that using a checkbox is the normal way for a user to agree to some stipulation, but usually there’s an explanation such as, “Please indicate that you have read our terms and conditions by checking the box.” In this example, the box was mixed in with other input fields, and I don’t think that the red asterisk was sufficient to replace that instruction.

It would be great if browsers were more consistent about what required input means. In the meantime, if you must use a “required” checkbox, don’t expect your users to understand that from a red asterisk alone.

Kareen Troussard, a student in Paris, said the episode might have saved her. “I want to major in computer science,” she said in an e-mail, “and Vassar doesn’t even know how to use a computer on the biggest day of our lives.”

I know it’s just a quip, but it unfairly blames the computer science department for a mistake in the admissions office. The quote stems from three common misconceptions:

Misconception #1: The computer science department is responsible for all of the college’s electronic activities.
Reality: Very few, if any, college computer science departments are also responsible for IT at the school.  Teaching computer science and maintaining a system are very different jobs, and Vassar has an entire Computing and Information Services department to handle their IT. (Even Vassar students don’t understand this distinction. The CS department had to put a sign on the door saying saying visitors looking for IT help were in the wrong building.)

Misconception #2: Learning computer science is the same as learning to use a computer.
Reality: Writing software and using software require vastly different skill sets. Computer science students learn about math, logic, algorithms, and programming languages, not how to use Microsoft Word or admissions software. You can’t assume that a “good computer scientist” is “good with computers,” or vice versa. (As I’ve blogged before, this is one of the misconceptions that keeps people away from studying CS.)

Misconception #3: The mistake arose from someone not knowing how to “use a computer.”
Reality:  Someone “used a computer” very successfully to send an admissions decision to 76 applicants. However, they neglected to update the text that the candidates would see. The culprit is forgetful, not technically-impaired. Moreover, using “You’re accepted” in filler text rather than, “This is a test,” was just asking for trouble.

While I certainly came upon cases in school when it seemed like “Vassar didn’t even know how to use a computer,” I hate this vague accusation that my department is somehow responsible for the error. Vassar students and faculty are amazing people, and studying computer science with them was a blast. Even though a Vassar website was at fault, I’d hate to think a student passed over studying computer science there because of it. Go ahead and blame the institution, but leave my department out of it.

Well, I haven’t been. Senioritis has gotten the best of me. It’s been very difficult to bring myself to work my thesis and Japanese assignments knowing that in 11 days it will all average out to a grade on my transcript that’s mostly predetermined by now. It doesn’t help that I have already secured my post-graduation job. I felt weak and unmotivated yesterday as I struggled to write and prepare my thesis presentation. I needed a boost, but didn’t know where to get it.

I eventually realized that I wanted a couple more features in my research project’s map application for presentation purposes. Boom, I opened my IDE! Boom, I code got banged out! Once I had a task closer to doing what I love, I was suddenly able to focus and be productive. 

While I don’t agree with everything he says, I love motivational speaker Marcus Buckingham‘s adage that your strengths aren’t what you’re good at, but instead “your strengths are those activities that make you feel strong.” Writing code is one of my strengths because when I develop a clever function or overcome a tricky bug, I feel like I can do absolutely anything.

Once I finished writing the extra functions for my presentation, I had a renewed drive to be productive which helped me get through writing the rest of the presentation. From now on I’ll keep my side-projects in mind for when I need an extra burst of productivity.

Don’t even think about doing it in a coffee shop. Quiet, clean room. Absolutely no environmental hustle and bustle, none.  Oh, and when I say “quiet, clean room?” Assume I mean “quiet, clean room with no weird crap in the background.”

Two years ago I interviewed for a lead instructor position at a kids’ tech summer camp. Since I was still finishing my spring semester in college in New York and the job would be back home in the Bay Area, we did the interview on Skype. However, living in a dorm with a roommate and lots of friends who came when they pleased meant that my living space wasn’t going to cut it as an interview location. (The dorm room also violated the “no weird crap in the background” advice.)

I considered academic buildings and dorm parlors, but since I couldn’t reserve them, I still ran the risk of interruptions. When I mentioned my dilemma to my advisor, she suggested I reserve a study space room in the college library. Not only did that space let me have an uninterrupted block of time, but it also had bright lighting, a well-maintained internet connection, and the added bonus of shelves of books for my backdrop.

Libraries are a great option for non-college students, too, but make sure your local library’s study rooms are well lit and offer internet and electricity before you reserve one.

I can’t guarantee that the interview location will make or break your application, but it worked for me – I got the job!

A notable article on hacking oneself a standing desk made the rounds of Hacker News and Lifehacker this week. Tonight, I needed the energy for one last push to get some work done and stop slacking off. Lacking the motivation to actually put my desk chair atop my desk, I pulled some cardboard boxes out of my closet and made do. It’s a little rickety, but it gets the job done, and I got my work done.