I would very much like to one day leaf through the introduction of a book or article about women and minorities in science/tech/maths without feeling like I am reading myself in the report of a formal psychological study of how victims are affected by psychological abuse. For starters I would like it to not be an accurate comparison.

This collection of papers, picked up out of curiosity from the “new” shelf of the academic library just outside my office, is an honest and up-to-date (2007) look at the issues facing women and minorities getting into scientific fields, the issues facing them once they get there, and the cultural and educational biases that keep them from wanting to get into a field where they will face these problems, every step of the way from grade school to corporate research or academic tenure. Sadly, unlike slightly older works where the numbers indicated more women and minority students in every major scientific field save Computer Science, it is obvious that in the past few years these groups are quitting the fields or abandoning the education required to enter them. Why? Standard “geek male” and other unhelpful stereotypes are still going strong, discrimination is still evident, cultural and biological parenting issues discourage women from high-commitment fields particularly in countries without adequate labor laws, glass ceilings hover. The book is chock full of references to recent National Science Foundation research on the matter, and none of it is heartening.

What is heartening is a very thorough “what to do about it” section full of ideas that sound obvious from the inside. Suggestions regarding early school programs, more educational focus on collaborative and hands-on work and other changes to teaching style, attempts to change the surrounding cultural issues and the like sit side-by-side with commentary on fixing overt and covert discrimination and other problems not unique to the sciences. Interviews with female and minority students are quoted extensively. Where possible, suggested changes are backed up with evidence for programs that have worked and best corporate practices found in the real world.  As a career software engineer with an interest in science before starting grade school, I don’t disagree with a word of it.

The work is, of course, a costly library textbook for its small size, targeted for academic institutions. Since these institutions are often part of the problem, perhaps someone who needs to see it will still find it useful. For my part, I will give it a shout-out as the best work I’ve yet seen on the subject. Maybe someday when I am old I will be able to take some time sabbatical-style and write about how we fixed this. I can dream.

I understand that you are in the business of making money by guessing from the minimal information I provide you through my profiles at various social networking sites which of your customer’s advertisements I am most likely to take the time to investigate.

To this end, I actually endeavor to provide you with more than the bare minimum of profile information. Nothing interesting, nothing personal; networking sites for work get to know about my work life and my work-acknowledged hobbies. When I say I care about “environmental issues” and “hiking”, I expect at least the occasional ad for fair trade hippie decor and recycled doodads and camping gear. When I admit I am a software engineer, I am unsurprised by certification training programs, domain hosting, and other networking sites targeted toward computer professionals. Absolutely nothing on any work-related profile belies any traditionally feminine hobbies or interests whatsoever.

This is intentional. I provide this information because I am interested in knowing about new and different websites for fair trade hippie decor, recycled doodads, and any click-stuff-on-the-web charity whatnot I may support. I provide this information to outweigh the massive assumptions made every time I am forced to enter “M or F” or type in my obviously female legal name. I provide this information to outweigh the equally massive assumptions made when that gender tag is correlated with a birth date indicating I am not only a legal adult but pushing thirty.

It never works. No matter how much mainstream, ad-targetable, genderblind information I provide, more than half of the targeted ads I see are for weight loss (usually in terms of dress sizes or low calorie stereotypical craving snacks), snake oil anti-aging secrets and stretch mark removal. Today, facebook tried to give me a $10 off coupon at diapers.com and “acne care in a chocolate”. I complained in my status message on the selfsame site about the general trend and within a few minutes my office was full of male co-workers surprised and appalled by the discrepancy between my experience and the ads they normally see that appear to be far more solidly based on their interests. (They were followed immediately by the few elderly female scientists in my department, clucking knowingly and annoyed at the same.) The personal manner of delivery makes the problem at once obvious to the mistargeted user and completely invisible to everyone else.

I see a very simple solution to avoid the ire of increasing numbers of folks online, a very simple option M or F or ‘I’m not telling’ or ‘don’t use this information for ad-targeting’ and the same on ages. But the traditional sales force doesn’t want that, I’m sure. It would break everything they know in marketing, to think we want to be approached as people. And so, every now and then, I click on the fair trade hippie decor and have a look around in the confidence that every business in the chain knows where I came from, and therefore what worked. And I rail at the source and bring the issue to the attention of people, who by the very purpose of the medium, never would have noticed.

What information do you knowingly provide the ubiquitous internet ad machine, ultimately conceived by the traditional sales force and implemented by human programmers in all their own demographic glory? What do you receive for your witting and unwitting efforts? Despite the commentary of my scientist friends, is it as bad on the other side of the gender lines? I’m not sure if “yes” or “no” on that one is the more acceptable result.

*

This being an attempt at a usefully academic blog entry, I shall not disparage the character of LyX with my customary coarse phrasing. My complaints are legitimate enough to stand on their own. The installation itself is bloated and overwrought — LyX installs MikTex as its underlying processor, which, as far as I can tell, scours the internet looking for plugins in order to install half a *nix kernel teetering atop one’s Windows environment. I already have Cygwin, I do not need this. The real issue, however, is trying to use the thing. LyX uses its own wrapper file type which imports sample .tex files just fine but worried me regarding saving them. While the underlying TeX code is available for viewing, the simple inclusion of .sty template files is hidden in a menu of document settings in order to access the otherwise visible but untouchable document preamble. Error messages in compilation are confusing and unhelpful. The unforgivable aggravation it inflicted on me, however, was that I could find no way to cut-and-paste into the document itself. That’s right, no paste. I’m sure the option is available somehow, but if I couldn’t figure it out myself in ten minutes, that sort of fails the software all on its own. I didn’t get halfway through retyping my paper’s abstract while tabbing back and forth to the browser window containing the proposal before closing and uninstalling LyX.

This brings me to Texmaker. Texmaker also works with MikTex or any other LaTeX processing engine, but it seems that in this world nothing is standalone. The one other thing I’ve found bundled to it is GhostScript, which serves as a utility for viewing PostScript versions of your formatted document and can handily open any other PostScript files you may have need of viewing on their way to a printer. Texmaker, as its name implies, handles raw .tex files and nothing else. Included template files go right in the main file, which you can access directly. Errors regarding missing templates are clear and thus easily fixed. A document outline sits in a small window to the left of a simple text-editor interface for easy navigation. Autocompletion hints based on your included template files appear when backslashed commands are begun. Word-like formatting options hover in a toolbar over your editor along with shortcuts for the mathematical and scientific special formatting that encourages LaTeX use in the first place. Output viewing options from PostScript (through Quick Build) to Dvi to PDF to converted HTML are available and obvious. Texmaker may actually get me to grudgingly like working with this system. Considering how little I want to work on the paper requiring me to wrangle LaTeX in the first place, that is high praise indeed.

I spent about a year as an intern and two as a full-time programmer for a small, independent developer — an increasingly rare entity as the industry consolidates under buyouts from big-name publishers. We had about fifty employees in two floors of the same building, and everyone knew everyone else. This included a few designers, very little management, fifteen or twenty artists of various stripes, and some of the most brilliant programmers I have ever known. In fact, fresh out of college and thrown in with these people, my confidence in my own programming abilities suddenly sank to a low I hadn’t known since I started coding at the age of ten. The learning curve was steep, and I think I am both a stronger person and a better programmer for sticking to it for even the first few months.

As every glamorous teaser article about the industry will imply, we had a ping-pong table, a pool table, a lobby with a comfortable futon and chairs facing a gargantuan television hooked up to every kind of console imaginable. We had catered lunch and bagels and donuts each once a week. We had a beer fridge stocked from a manager’s discretionary funds. No one cared that my hair was blue, that several people eschewed shoes, or that half the company didn’t show up until 10am, as long as we made our deadlines.

Our daily schedules depended highly on product schedules, which were in turn based on arbitrary commercial ship dates dictated by publishers and the holiday market. Think of any semester of a class with but one big final project and stretch that over twenty people and two years. Early in a project, everyone would have collaborative fun with a design, play with new technologies we wanted to incorporate, and build the basic structure at an unhurried pace. Far less than a standard eight hours after showing up, most of the team would kick back and begin playing hours’ worth of other games, competitively or collaboratively, until late into the night. There were ping-pong tournaments and Monkey Ball ones. Early in a project is the life in the gaming industry that fans get sold on. Slowly, over the course of a year or two, the work begins to catch up. There’s no point in being the one person with the nose to the grindstone, everyone thinks, because twenty-odd other people are going to make the crunch just as bad at the end. It might as well be enjoyed before it all falls down and eats your life again. Thus is the adolescent fallacy of an entire industry. And the more complicated games get, the more that is expected of the graphics, the physics, the sheer length of a story arc before a publisher will accept a game and a reviewer will praise it and a consumer will be swayed to plunk down their money, the more time and effort is required of the same people. Thus the looming “crunch” worsens. When I left the gaming industry, it was generally assumed that at small companies with good working conditions, “crunch” would take a month of one’s time before a beta release, another three or more before final shipment, and some time after that for those few adapting international editions and patching. By “take months of one’s time” I mean “require sixty, seventy, then eighty or more hours of high-stress work a week at jobs that are exempt from overtime pay in most of the United States”.

Speaking of the pay, it’s significantly less than the market value of average programmers for jobs that require exceptional ones. A first year game programmer’s hourly pay, if they start work to fill in during a crunch as typically happens, could be close to minimum wage. I still miss the beer fridge. I don’t miss the free breakfasts and lunches; for my first year, the pizza and barbecue leftovers stretched my food budget enough to keep me fed, if not healthy. It was, even during crunch, a good deal of fun. I felt a deep sense of camaraderie with my fellow developers and an overwhelming sense of personal and group accomplishment each time a title went out the door with our names scrolling in the credits. I am to this day very glad I followed my childhood dream and managed to get into gaming, and that I did it directly out of college, when I was still used to working all night on a project I loved for no pay. I still turn down the occasional solicitation for gaming work now; there’s too much I want out of life I can’t have working there, and for something that requires a resident doctor’s stress and hours, the end result is hollow.

I understand that the industry is improving in terms of crunch hours and pay, though the average burnout time is still about five years. This improvement is a direct result of many lawsuit settlements, the most famous of which have been against EA. It is happening very slowly, one company at a time, and I advise the undeterred prospective game developer to shop very carefully for a studio that will not take all of your enthusiasm and time and give nothing in return. I advise aspiring programmers to get a proper Computer Science degree, one which can be tailored to gaming-related skills (graphics most especially), but will still look good on paper if you ever tire of making games and want to fall back on a more stable career in computing. Look for jobs at developers you may never have heard of through the dodgily-named Gamasutra website. Hunt down an internship and get your foot in the door; find a roommate and live on leftovers. Be willing to travel across the country if there isn’t a studio near you, and prepare to get one or two titles under your belt at a small studio before the big names will pay your job applications any attention. Get involved with the International Game Developers’ Association and follow their advocacy group for Quality of Life. And if it ever stops being enough fun to feel worth it, walk away secure in the knowledge that a CS degree and the skillset of a game developer will get you attention anywhere you ever want a programming job again.

It can be a grand adventure. I regret nothing except starting out unaware of what I was in for. It doesn’t change my decision to never, ever go back.

And so we come to the title, which proclaims “for the rest of us.” What does a single software engineer do when presented with a interface design and implementation problem without the resources of a dedicated team at, say, Google, or Microsoft, or Apple? The following are the basic tenets I have learned over the years that have saved me a significant amount of time and stress in the long run, and have worked out well enough that my grand prize keeps being more interface work.

1. Internal consistency.
Even when you are building a small section of a larger software package with an existent bad interface, consistency is of utmost importance. Name your menu headers consistently with the rest of the program, use the same cancel and ok buttons in the same placement, use the same wording for your errors and dialogs, use the same colour scheme, and so on and so forth. This is boring, obvious, and important. Oddly enough, I’ve found internal consistency most important when adding to a bad interface that can’t be completely overhauled, because once users learn to navigate an unintuitive interface, they can work much more efficiently within that framework than if you change it, even to something better, for a single page.

2. External consistency.
Remember the examples above of companies who have dedicated teams for designing aspects of user interface design? I have had Microsoft and Google employees describe to me the eye-tracking technology they use to monitor how testers examine a new interface and use it, streamlining their products to match these use cases. You don’t have to have those resources to learn from those who do. Take a closer look at your operating system, common applications, big-name web pages. Follow their conventions and you are not only piggy-backing on big-name research, you are piggy-backing on the user expectations that have developed from familiarity with this other software. There are degrees of theft that become outright copyright violation or more nebulous “look and feel” lawsuits, but following an expected style can save a lot of time designing around niggling little issues, and can also reduce the number of user errors that occur when expectations are violated (see Charles Miller’s Firefox “bug” report).

3. Clearly provide only and all relevant information, grouped effectively.
This condenses several points more long-winded lists of design principles make: avoid clutter and reliance on color, know your widgets, group things effectively. An airplane flight simulator may require half a screen of fancy graphical knobs and indicators and buttons and switches, but very little else does. Hide infrequently-used options behind menu headers, grouped and labeled intuitively; go back to external consistency and look at a web browser or operating system for obvious, tested examples. Do you need a button or checkbox for every single option on the screen at once? Will a drop-down suffice and save you precious screen real estate? Can you make reasonable, intuitive tabs? The initial screen as presented to the user should flow directly into what they have to choose first or what they will do the most often. Hide what isn’t relevant and then make it very easy to make things appear as needed. Color is mentioned here as a matter of clarity: some users are colorblind, you may have no control over the color of operating system components that may show up in your application, and a basic interface that pukes up a rainbow on the user, even for most widgets in a paint program, is confusing and unpleasant.

4. Paper first.
In fact, several pieces of paper. This is another big-name design team trick. Before you write a line of code for anything more complicated than a confirmation/cancel dialog box, get out a notebook or a few printer header pages from the trash or anything on which you can draw some reasonably-sized “screenshots”. Draw out the whole first screen or form or relevant interface entity. Annotate each way that flows into the next screen or form. Draw the next one, and so on. Throw away pages, start over from scratch if you have to, chances are you will make significant changes in layout and flow for any reasonably complicated interface at this stage. This is right and good because you haven’t wasted your time writing any code or finding non-copyrighted widget graphics on the internet that would wind up unused. This is especially true and especially useful if you can show your “screenshots” to someone else.

5. Get user input early.
Doing an upgrade or redesign? Find yourself a user of the old system (and more is always better) and ask them what annoys them about it. Old product or new, sit your poor hapless test user down in front of the earliest prototype you have, send them screenshots of it, anything to get a modicum of testing done early by someone who will actually have to deal with the thing. Don’t have a real user? Drag anyone not writing code relevant to your interface over and have them look at it. Shove it in the faces of your roommates or significant others; if you’re a programmer, I assure you they’re used to this sort of behaviour. You may have to explain what something will eventually do, or what an icon is intended to look like in more polished stages of design, but it is likely that amidst the general griping and confusion you will get important insights on things that would be orders of magnitude more work to change later.

6. Have more than one way to do most things.
Your early user input and internal and external consistency should give you a good idea of what needs redundancy. “Users” is plural, and people have different ways they prefer to work, and in some cases different hardware and different needs. Best Practices state that most basic operations in a graphical user interface should be accessible completely by keyboard, or by keyboard and mouse. I’ve written an interface for software that was required to run on a small touchscreen as well as a standard PC, so we went farther and brought up graphical keyboards larger than the built-in Windows accessibility feature. Most graphical interfaces don’t require this degree of special effort, but there should at least be hotkey and mouse-based ways to do most things.

7. Anticipate user error.
Admit it. You have accidentally deleted things, sent email to “all”, printed the wrong page, mistyped a password, any number of every day interface errors. Getting user input early and adjusting for common failures can make them less frequent. But they’re still going to happen. Make user choices reversible when possible. Confirm when you can’t. Catch the errors you can, and explain the issue to the user effectively.

I am by no means a full-time professional interface designer. Fortunately for me, I am also no longer a full-time professional interface implementer, because decoupled from the design process, that is probably the second most boring job I have ever done, just behind folding t-shirts for an aquarium gift shop in high school. But while very little code has a dedicated team scuplting its user interface, every piece of software has UI somewhere, if only for installation or reporting, and some poor programmer has to write it and some poor user has to deal with it. And just a few simple things can make it easier on the rest of us.

(source: American Institute of Physics Statistical Research Center) (pdf)

There is a bulletin board that hangs on the lobby wall of the Physics building I work in. Amidst the job postings and conference posters and other standard university bulletin board components, there is a single graph that never fails to catch my attention. It’s not the best graph; the percentage axis is confusing and the data is a few years old, but I am aware of the real trends it is trying to represent. I believe the information is meant to be heartening. Except I’m on the red line, the only one that has been consistently declining for nearly as long as I have been alive, and I would rather have more women to work with than a career of affirmative action.

The declining numbers of women in my field of Computer Science has been a known issue that educators, industry members, and concerned geeks like the community of linuxchix have been trying to sort out since the early 1990s. The only Women’s Studies course I ever stomached in my loathing of second-wave feminism focused on “Women in Information Technology” and I was the only IT major in the class. I did a few months of library research and conducted interviews of all the female students I could find who had stuck with Computer Science or Information Systems degrees or dropped from them. I wrote a fifteen-page paper about the issues I found, mostly the same issues anyone discusses regarding women in science — confrontational and condescending attitudes from certain men in the field, self-doubt or social fallout from being assertive, actual or perceived ineptitudes at math self-traced back to early school expectations, unappealing perceptions of “geeky” people, and so on and so on. I finished my degree resigned at being one of two female students in all of my population-forty upper-level classes save Database Design (no math), and stepped out into the working world with no more of a clue than I had when I’d been made fun of at age twelve for being a geek and a tomboy.

The poster taunts me and my firsthand knowledge that its three-year-old data is still valid. All of the other sciences are improving. Where are we going wrong?