Software Review: Using LaTeX on Windows – LyX and Texmaker

I spent five years earning a Computer Science degree deftly avoiding formatting anything for LaTeX  and was immensely proud of myself for dodging that. I was also immensely proud of myself for getting through five years of a Computer Science degree without horrifically math-intensive graphics courses and promptly landed myself in the end of the gaming industry where horrifically math-intensive graphics grunt work is done. That alone ought to have taught me not to gloat over such things.  Now, another six years later, I have a conference proceedings paper to write, one which is required to be formatted via LaTeX using various template pages for the publisher and the conference itself. What follows is my formative experience in the world of LaTeX in a Windows environment.

*

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.

Once Upon a Time: Solicited Advice for Aspiring Game Programmers

It has been over three years since I washed my hands of the gaming industry. Still, a few months into each completely unrelated programming job, word gets around that I have a sordid past as a game developer. Geeks with long-standing dreams start to tell me about their home-brew projects and cajole me in search of help and support. They ask, wide-eyed, how I got into gaming in the first place, what it’s really like, and why I could possibly have left. Lately, older co-workers are asking me on behalf of their collegiate offspring, each with childhood dreams of making a living making games. I always dread these conversations. I worry that my nostalgic reminiscence will build up someone’s dreams and then I’ll crush them.

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.

User Interface Design for the Rest of Us

Most of my career as a software engineer has dealt with user interfaces in some capacity. As this includes designing and implementing one-person configuration software at a forty-person company, leading the graphical redesign for sections of a very large project at a two-thousand-person company, and back again, I suspect at least small forays into UI work are nearly ubiquitous for programmers. The problem with this, of course, is that programmers are not normal users. And the programmer who writes an interface is the least normal user for it, because that programmer knows the precise location and appearance of any widget they expect to be there and what it should do, and their expectations of functionality are skewed as well. Many companies, especially for large projects, manage to reduce this problem by having dedicated designers, artists, and programmers to handle their own area of expertise. Depending on whom you work for and what you’re working on, it may well just be you, lone cowboy developer, and a list of requirements.

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.