Category Archives: Nadyne

software

how much engineering effort is lost to DST every year?

5 Comments

I haven’t yet met anyone who really likes Daylight Savings Time (DST).  Every spring, everyone complains about losing an hour of sleep.  Then you walk through your home and get annoyed by the clocks that aren’t updated automatically.  You get even more annoyed when you have a clock that should’ve been updated automatically but wasn’t, or it somehow got updated incorrectly.

Anyone who has colleagues, family, or friends overseas knows that DST is more complicated than that.  Other countries might or might not participate in DST, and the dates on which they change their time are not the same.1  When you’re trying to book a meeting or make a telephone call, there’s a few weeks every spring and autumn where you double-check to make sure that you’re not doing it at the wrong time.

DST is a massively complex beast.  In the US, it wasn’t until 2007 that the dates for the time change were standardized across the country2.  Before that, states and localities could opt out of DST, although you should note that Arizona and Hawaii still don’t observe it.3

“That doesn’t sound too bad,” you’re thinking to yourself right now.  There’s not a lot of error conditions to be had here.  You could get the date itself wrong, but it’s now standard enough that this isn’t too likely.  You could get the time zone wrong, which is probably most likely to be a concern if you’re close to a time zone boundary or if you’re in one of the places that doesn’t observe it.  Both of these are probably not going to require a lot of engineering effort.

And it’s not, so long as you’re only dealing with the US. But now pause and consider: as of this writing, there are 196 countries in the world4.  Each of these countries potentially has their own dates for recognizing DST.  For the countries which observe DST, the dates on which they do so might or might not be standardized, or might be standardized but get moved around if a local government decides to make a small tweak that year.  Localities within these countries also can choose not to observe it.  Don’t forget that the northern hemisphere is observing DST in one direction, and the southern hemisphere is observing it in the other direction.  While you’re at it, realize that “Pacific time” isn’t just the name of a time zone in the US.  Wikipedia has a huge page about daylight saving time by country, which gives you an idea of the complexity of this issue.5

All of this is complex enough when we’re thinking about a single clock that needs to update.  Let’s add in another layer of complexity: client/server.  Your computer has its own internal clock, and it updates against a time server somewhere.  That cell phone in your pocket has at least two time sources.  It’s got its own internal clock, and it’s also getting the time from the nearest cell towers.  Your mail application gets its time from the local computer, and it’s also communicating with the mail server and getting items there that are timestamped.  The examples here are all but endless.

In software engineering, we talk about “edge cases”.  An edge case is a problem that occurs when you’re at the outside the usual operating parameters.  DST is a rat’s nest of edge cases.  You can come up with a dozen of them without even trying hard.  Anyone who’s worked on an application that deals with this has a horror story about the year Venezuela changed their dates for DST at the last minute, or somehow one server didn’t get the latest code, or a million other edge cases.

I have to wonder: how much engineering time gets wasted on DST every year?  Just think of all of the tech companies that have to deal with this: any company that makes a mail or calendar application (IBM, Microsoft, Apple, VMware, …), every mobile phone provider (AT&T, Verizon, T-Mobile, …).  Maybe the tech industry could come together to abolish DST and succeed where so many others have failed.

  1. In 2001, when I moved from Sydney to Silicon Valley, I was in Sydney for their “fall behind” time change, got on an airplane, and was then in the Valley for our “spring ahead” change.  Between that and jet lag, I was in my own personal time zone for at least a couple of days.  Nadyne Standard Time? ↩
  2. Second Sunday in March, first Sunday in November, in case you’re interested. ↩
  3. To confuse matters further, the Navajo Nation in Arizona does observe DST. ↩
  4. The UN recognizes 193, but that doesn’t include the Vatican, Kosovo, or Taiwan. ↩
  5. According to that page, Russia has now stopped observing DST, which I have to believe caused some software engineers a couple of sleepless nights in coding that update. ↩
user experience, VMware

summer internship opportunities for user experience researchers and designers

1 Comment

I mentioned earlier that summer intern season is coming, and that my team has intern openings.  The job openings are listed on our website:

  • user experience research intern — This position reports to me, and is on a project where I really want to see some awesome research.  Read the job description carefully, because there’s some discussion in there of what the project is about, and a great candidate will be able to tell me how they’d go about executing on this project.
  • user experience designer intern — We’ve got several openings, so there are several different summer projects where we’d like an awesome intern to come in.  Here, a great candidate will have a good portfolio and will be able to tell us how they think that they would apply their design skills to the types of problems that we see at VMware.

Interested?  Email me with your cover letter, resume, and portfolio (required for design candidates, not required but still useful for research candidates).

We’ve got other jobs available as well, not just summer interns.  We’re especially interested in hearing from senior interaction designers, such as for this opening.

Nadyne

my conspiracy theory about password expiration

I’m completely and utterly convinced that corporate password reset policies are somehow tied to vacations.  There’s just no other explanation for the fact that, every freakin’ time I go on vacation, my password expires just before, during, or just after my vacation.

So my theory is this.  The system scans my calendar and looks for all-day events that are marked either “busy” or “out of office”.  If it finds one of those, and if that all-day event spans 4 or more days, then it sets my password expiration date to happen somewhere during that time.  I think it might be a random number in the range vacation±3 days.

Which is to say: I leave for vacation on Saturday, and my password expires on Thursday.

user experience

the difference between good user research and great user research

This morning, my team discussed the benefits and drawbacks of large-scale A/B testing.  Websites like Google and Amazon often use A/B testing where they randomly show some of their users a new version of a webpage, and measure whether the outcomes are different: a better click-through rate, for example.  There’s a lot be learned in this kind of testing.  It’s a powerful method for websites to learn about how design changes, both major and minor, can impact how users complete their task.

However, it doesn’t give you a complete picture.  It tells you what happened, but it doesn’t tell you why it happened.  One of the differences between good user research and great user research is in what you learn and how you can apply that information in the future.

In good user research, you learn that something happened.  Maybe you’ve learned that a user is completely blocked from finishing a task.  Maybe you’ve learned that users can complete their task 20% faster.  Maybe you’ve learned that, while they’re not doing anything faster, their satisfaction ratings are higher than usual.  Each and every one of these findings is important.

Each and every one of those findings can be made better if you know the reason behind it.  Sometimes it’s reasonably obvious, but oftentimes it’s not1.  When you know the reason why a change has improved or degraded the user’s experience, you have a better opportunity to innovate in the future.  You only have data.  You don’t have insight.

Good user research allows you to react.  It allows you to evolve your designs.  With good user research, you will make improvements.  Your application will be better.

Great user research allows you to learn more about your users.  It gives you insight into how they think and what they’re trying to accomplish.  It allows you to make intuitive leaps and to truly innovate.  With great user research, your greater understanding of your users will allow you to make improvements to your whole business, not just your application.  Your business will be better.

  1. And sometimes you think that the answer is obvious, but it turns out that the obvious answer isn’t the correct answer. ↩
Q&A, user experience

Q&A: what are the best courses to take in a user experience curriculum?

Last week, I spoke at a networking breakfast at the University of Michigan’s School of Information.  One of the questions that I was asked there was from someone who is in her first year of the program.  She wanted to know what UX courses were the most useful.

Your user experience coursework is the table stakes.  They’re necessary, but not sufficient, to be a good UX professional.  I won’t point to any of those courses as more or less useful.  Instead, it’s about what you get out of those courses: clear and concise communication, the ability to give constructive design criticism, the ability to take feedback (which won’t always be constructive criticism, but you still have to take it), the ability to juggle a changing schedule, the ability to handle multiple projects and deadlines.  An individual course isn’t make or break — and curricula change all the time, so a course that was useful to me when I got my degrees might not even be offered any longer.  Rather, the gestalt of what you learn during the process of getting your degrees is what will make you a great UX professional.

In many respects, the course that I use the most out of my three degrees is public speaking.  A lot of what I spend my time on isn’t really user experience work.  Instead, it’s communicating about user experience.  I communicate with my UX peers, program management, and application teams to understand what their research questions are.  I formulate a research plan, and then have to communicate that research plan to the stakeholders: why I’ve elected to do this kind of research, what results we can expect to get from this research.  Then there’s actually conducting the research, which isn’t so much about the tools that are used to collect the data (Morae, Excel, Camtasia, etc), but rather how my communication with the research participants as I collect that data.  A good user researcher guides, but does not bias, the participant as the researcher collects data to answer their questions.  After I’ve conducted the research, analyzed the results, and formulated my recommendations, my job is next to communicate the results and recommendations.  And throughout the software development lifecycle, aside from specific research that I have conducted, it’s my job to continue to communicate about previous user research that might be applicable to a given question, as well as general principles of good user experience.

Another unexpectedly useful course, this one from my undergrad, was a course called “statistics and society”.  It was about consuming data.  That course taught me a lot about how to think about data.  How does the method for collection impact the results?  How does the presentation of the data impact its analysis?  Neither this course nor my public speaking courses were required for my degrees, but I think that the skills that I learned in those courses are ones that help me be a great researcher.  I’m able to apply those skills very broadly, and they help me every single day.

Your UX coursework is the beginning.  If you don’t have good UX skills, you’re not going to get very far.  But your UX skills are not enough.  To grow in UX, you need to be great at more than just user experience.

development, Nadyne

cool girls code

1 Comment

Cool girls code.  It’s one of the awesome t-shirts that VMware is handing out at college recruitment fairs right now.  It can be hard to get credibility as a female software engineer, and that pink shirt is a reminder to all my fellow women in tech that we’re not alone, and that it’s pretty damn cool to be a female software engineer.

Given that I’m out and actively trying to recruit more women to join my immensely geeky company, you can imagine my disappointment when I saw that Violet Blue has, yet again, made an idiotic statement about women in technology.  Actually, she made an idiotic statement about a specific woman in technology.  She attended Macworld 2012, and led off her column with an extended commentary on what she called “the saddest booth babe in the world”.  She even included a picture, which she has since removed, of the woman sitting in a chair looking tired.

The problem, of course, is that the woman in question actually isn’t a booth babe.  The woman is an employee of a small iOS company, not a model paid to draw in foot traffic by showing skin.

It’s hard enough being a woman in tech without some uneducated blowhard, who happens to try to style herself as all about female empowerment, come along and bash a woman in tech by assuming that she’s a booth babe.  I would expect that someone who likes to pretend that she’s a tech blogger would actually know that not all women at a trade show are booth babes.  I’d even like go out on a limb and imagine that this so-called tech blogger could even imagine that a good-looking woman can also work in tech.  It’s especially galling when that very selfsame uneducated blowhard is the one who was bitching last WWDC when some guy asked what she does, instead of assuming that Violet is a developer.  (This is, of course, ignoring the fact that Violet is not actually a developer.  Tech blogger, perhaps, but not a developer.)  At the time, she decided to play the dumb-chick card and pretend that she knows utterly nothing about computers, and then upbraided the guy in her column for falling for her little gambit.

So let me get this straight: it’s bad for a guy to believe you when you say that you don’t know anything about tech, but it’s totally okay for you to call a woman a “booth babe” and complain about her hunched shoulders and “breasts that were packaged air-tight in a tight, branded t-shirt” and not even bother to talk to her?  At least the WWDC guy was trying to make conversation, and believed you when you said that you were a model in town.  Violet Blue couldn’t even be bothered to either (a) go talk to the woman, (b) go look up the development company and see whether she works there, or even (c) not start off a column with such a ridiculous anecdote that had pretty much nothing to do with the rest of her column or the event itself.

I’ve worked Macworld before as a vendor.  It’s freakin’ exhausting.  You’re tired.  Your feet are sore, because you’re standing on a thin layer of carpet over concrete.  You’re quite possibly hung over, a result of having a bit too much fun at the Macworld Blast party the night before.  Your voice is cracking because you’ve been talking too much, answering questions about your application.  That’s the perspective when you’re working in one of the big booths, where you’ve got several of your colleagues around to help out.  But this woman was at one of the teensy developer kiosks, which means that she was probably either alone or maybe had another person there.  That’s also the perspective from someone who just has to drive to San Francisco from Mountain View, so there’s no concerns about jet lag or uncomfortable hotel beds or being in an unfamiliar city and not knowing anyone.

The original picture, which Violet Blue has (of course) yanked, is one that I recognize and identify with.  I’m quite sure that I’ve been seen in that exact same pose at some point in my life at Macworld.  I hope that no-one out there has such an unflattering picture of me, although I wouldn’t be surprised if it were out there.  I’m lucky in that, as far as I know, no-one has chosen to post such an unflattering picture and description of me to a major tech blog.  It’s bad enough to be exhausted at Macworld, I can’t imagine what it’s like to be exhausted and publicly ridiculed there.

As if the original article weren’t bad enough, not to mention the edits done to the article so that it doesn’t look quite so appalling, is Violet’s response.  You see, she got called on her idiocy pretty early.  People who weren’t even at the show took a look at the picture that she posted and figured out that the woman isn’t a booth babe.  Violet, instead of putting her big girl panties on and owning up to her idiocy, instead doubled down:

It’s really reaching to brand me a misogynist because I put the woman in a social category based on the environment she was in. I was not the only one to do so. It was not obvious that the woman in the booth was not a booth babe

It was pretty obvious that she wasn’t a booth babe.  Let me count the ways:

  1. She wasn’t dressed as a booth babe.  She was in pants, a long-sleeved t-shirt, and a short-sleeved t-shirt over that.  Now that I think about it, this is an exact description of what I wore today.  The woman in the booth wasn’t displaying cleavage, she wasn’t wearing platform heels, she didn’t have a skirt cut up to her hip.  There was no skin showing.  Her t-shirt might have been a bit tight, although honestly every t-shirt looks tight when you’re tired and thus not sitting up straight.  But it certainly wasn’t booth-babe tight.  It was just normal.
  2. She wasn’t at a booth that would have gotten a booth babe.  Yes, there were some booth babes at Macworld, but it’s not every booth that gets a babe.  The natural habitat for a booth babe is one of the big flashy booths that are crawling with company representatives, and it’s the booth babe’s job to get people to come to the booth and talk to one of those representatives.  This woman was at one of the little developer kiosks.  They barely have space for two people to be at the booth at the same time.  They certainly don’t have the space for a booth babe, and I bet they don’t have the budget for it either.
  3. Booth babes are never left in the booth alone.  Booth babes are there to get conference attendees into the booth, but then it’s someone else’s job to actually talk to them.
  4. Speaking with her would have made it clear that she wasn’t a booth babe.  Usually, a booth babe can perhaps answer some very high-level questions about the product(s) at hand, like how much it costs and when it will be released.  That’s it: they generally can’t answer deeper questions, and since they’re trying to get lots of people to come to the booth, they’re mostly interested in handing you off to someone else so that they can continue to do the job that they’re there for.

But wait, there’s more!  Then Violet outdoes herself with this:

If you want to know how I really feel about booth babes (though I’m sure you won’t because the drive-by is always better) – get some context for booth babes in my column by reading this:

The CES Booth Babe Problem

http://www.zdnet.com/blog/violetblue/the-ces-2012-booth-babe-problem/963

And you will see that Ms. Szurmai-Palotai is exactly the kind of “booth babe” I am referring to – women devs, women hackers. Not the kind some of you seem to instantly think I mean.

This is completely and utterly ridiculous.  There’s only one definition of booth babe, and Violet’s own CES article is talking about exactly that kind of booth babe: a scantily-clad woman who doesn’t know anything about the technology at hand, but is only there to drive traffic.  No-one has ever seriously tried to refer to “women devs, women hackers” as booth babes.  The term is a pejorative, and we all know it.  Don’t try to pretend that it’s neutral or even positive.

Amusingly, Violet tries to blame the backlash on an “attack” from Daring Fireball, and paints anyone who has criticised her as being a fanboy.  Not so: she had already been called on her idiocy quite some time before Daring Fireball linked to it.  And Daring Fireball’s commentary cannot, in any way, be construed as an attack:

But as Shawn King points out in the comments under the photo, the woman in question doesn’t look anything at all like a “booth babe” — she simply looks like a developer who happens to be a woman manning her booth. And according to subsequent comments by Tim Breen, that’s exactly what she is

Violet says in her comment that she should have been given a chance to do something:

A simple correction would have sufficed, and then you could have seen what I did with it.

The simple correction came swiftly.  And we saw what you did with it, Violet: you did absolutely nothing.  You let your nasty little column stay exactly like that for a day.  It was only after apparently you’d gotten enough comments calling you on your idiocy that you finally edited the column to note that the woman is a developer, and you replaced the original photo of the “sad booth babe” with one of a lineup of iPhone cases.

Strangely enough, Violet’s column about booth babes at CES does get one thing exactly right:

Present an inappropriate female stereotype and – no surprise – you’ll create an environment of inappropriate and stereotypical behavior.

It’s not the booth babes, it’s the reductive booth babe mentality that’s the real problem here.

Yes, it is the reductive booth babe mentality that’s the real problem here.  Now, Violet, take some responsibility for being part of the problem instead of part of the solution.

Q&A, user experience, VMware

Q&A: how can I find user experience jobs in the Bay Area?

I’m spending today at the University of Michigan, participating in some campus recruiting.  The morning started off with a networking breakfast with the School of Information, which was great: lots of people who are interested in UX jobs at VMware.  We’re hiring for both summer internships and full-time positions, so this kind of thing is exactly what we need to do to get great hires.

During my talk, I took a lot of questions from the students about working at VMware, what UX is like here, and so on.  Which is great: it gives me fodder for future blog posts.  I’m going to quickly answer one of the questions that I got during that session: how to find UX jobs in the Bay Area.

Working in UX in the Bay Area is truly awesome.  There’s so many tech companies, and lots of them are hiring.  Finding UX jobs can be somewhat of a challenge within tech, because UX jobs can get lost in the general tech hiring that happens.  One great resource for finding UX jobs is BayCHI.  Paid members have access to their Job Bank.  Lots of employers post their UX openings there.  It’s mostly Bay Area, although there are jobs posted elsewhere in California and the US there too.  Many of the jobs are for interaction designers, but researchers and visual designers aren’t left out in the cold.

It’s awesome to see one list of UX opportunities in one place.  It gives you an idea of where the job market is going and what skills are in demand.  For me, although I’m not looking for a job, I still glance over them to make sure that I’m growing my skills in the right ways.  I don’t want my career to stall.  I want to keep improving and moving my career in the right direction.

If you’re in the Bay Area, going to the BayCHI meetings is a great way to network with your fellow UX professionals.  They’re held directly across the street from VMware campus, so it’s pretty easy for me to pop over.  I watch to see what the monthly topic is, and go to the ones that I find interesting.  Most BayCHI talks are excellent, and the networking is icing on the cake.

UX folks: what other resources do you point college students towards if they’re looking for a job?  Other than your own company’s career page, of course.

development

lessons from a long career

At every geek company that I’ve worked for, most people send out a good-bye email to their team when they’re moving on.  Today, one of my colleagues from my previous team posted a going-away mail from someone else who’d been on that team since the dawn of time.  He included lessons from a long career at Microsoft.  I have to admit that this is my favorite lesson:

6. At some point, you will have to resolve a bug by saying, “If the user does something that dumb, they get what they deserve.”

There are nine other pieces of wisdom on that list, so you should go check it out.  #7 on that list is one of the absolute rules of the universe, second only to gravity.

user experience, VMware

giving back more than we take

This morning, Paul Maritz sent mail to all of VMware talking about where we’re going in 2012.  There’s a lot in it, and I really like seeing this kind of honesty and transparency from my CEO.  In it, he added a core VMware value: giving more than we take.

In my year-plus at VMware, I’ve been doing a lot of that.  I’ve spent a lot of time mentoring others on my team to help them improve their research skills.  I also created VMware’s first internal user experience conference, vUE.  I’ve also just started a series of UX tech talks (which probably deserves a post of its own), the first of which happens at the end of this month.

My goal is to help my organization exemplify user experience excellence for the whole company.  In short, I’m doing two things: modelling user research excellence for my team, and helping our user experience team come together to share expertise and identify areas where we can collaborate and build a better VMware-wide user experience.  As a side effect of these efforts, I want to create a community for our user experience professionals across the company.  This is also part of giving back: I want to build a lasting user experience community where awesome user experience people want to work.

There was a lot for me to like in Paul’s memo.  This particular piece resonated with me because I feel like I’m ahead of the curve.  It’s awesome to see our CEO recognize the importance of efforts like mine.