The Birth of a Book: Part 15

I was finally granted permission to start telling the world that I was writing a book. It was time for Interaction 14, a perfect time to toot my horn. On February 2nd, I submitted my revisions of all 8 chapters and the final figures. Then I headed to Amsterdam. I got to discuss the publishing process with Jeff Gothelf, who forewarned me about the issues I might face during production. The book was a great conversation topic, but I’m not sure how much good the publicity did. I didn’t realize it would take another 6 months, as long as it took me to write the book, to get it printed and on store shelves.

It was during the conference that I was informed that I had to recreate all of the screenshots in chapter 7. It has to be obvious that they are screenshots to avoid copyright issues. This became a real hassle. Before I started writing the book, the authoring guidelines I was given told me not to include my figures in my document. Rather, I should just put in the figure numbers and captions. That wasn’t a problem while I was writing, but when I had to go back in and change the figures, be it adding, removing, or just moving, I created a lot of errors. It’s really easy to get a figure labeled incorrectly when you never see it in context. There were multiple instances in which I had to renumber half the figures in a chapter. I wouldn’t catch my mistakes until I received proofs back from the typesetter. If I ever do this again, I’m going to insert placeholder figures in my manuscript.

In the middle of February, my editor dropped the bomb.

We also received a page count estimate back  from our typesetter and the manuscript is coming in at 176 pages, which is a bit under what we had proposed.  This is cause for concern as a low page count can affect sales etc.  We have several options here, such as choosing a different interior template, with a slightly lower page count, that may increase the page number, or adding content, maybe even another chapter.

I had thought I was done writing. I was happy to be done writing. I was ready to enjoy a little free time again. Instead, I had to write another 25 pages.

To be continued…

Read previous parts.

Interaction15 is coming

Interaction15 will be held in San Francisco this coming February 9th, 10th, and 11th. Their website just went live for early bird ticket sales. The first 100 tickets go for $949. After that, they’ll be $1,149. I also see that they won’t be able to fit all attendees in the main venue, so once they reach capacity, later ticket purchasers will end up watching the keynotes from across the street via video. I’m not sure how I feel about that arrangement.

That’s a significant increase in price over last year. The early bird tickets went for about $750. However, they make a point of saying that registration is one price for everything.

That’s the same price whether you want to come to just talks, talks & workshops, just workshops or you want to hang out in your hotel room the whole time.

That makes it sound like the cost includes workshops. However, they don’t explicitly list workshops in the breakdown.

Included with your ticket:

  • entry to all conference sessions & venues
  • lunch & snacks on all three days
  • entry to the opening & closing parties
  • other stuff that we’ll be announcing in due course

Once you take a look at the schedule, however, it becomes clear. They are interspersing the workshops with the talks. Each period, you can choose whether to attend two 45 minute talks or a 2 hour workshop. It’s an interesting idea.

Kickstarting

I’m loving Kickstarter. I’ve been completely satisfied with every project I’ve backed so far. Just today, I received delivery of Video Games: The Movie and Paul and Storm’s Ball Pit. I’m looking forward to Obduction, Last Life, and What Comes Next is the Future.

Most recently, I’ve backed SUNSET, a first-person video game thriller that finds you exploring a luxurious penthouse apartment against the backdrop of violent revolution in a fictional South American metropolis, and App: The Human Story, the story of the cultural phenomenon that has become the new art form of our generation. Check them out.

Help Bring Midwest UX 2015 to Pittsburgh

I’m co-chairing a team of people that are currently assembling a proposal to host Midwest UX 2015 in Pittsburgh. We just sent out the following request to the Pittsburgh Design Community. If you would like to see the conference come to Pittsburgh, we would like your help.

Do you think Pittsburgh has a strong and vibrant design community? Do you believe that Pittsburgh is a leader in the UX field? We want to know why. 

A team of UX professionals, led by Jack Moffett and Ryan Cummings, is in the process of assembling a bid to host Midwest UX 2015 in Pittsburgh. We are inviting Pittsburgh designers to stand up and proclaim their love for our city and community. We are collecting brief video statements to be featured in our proposal. Interested? Here are the details.

If you don’t have the time or means to shoot a quick video, but still want your voice to be heard, send us an email (midwestuxpgh@gmail.com) and answer the questions below. We have use for written statements too.

GUIDELINES

  • Your video should be no longer than 1 - 2  minutes in duration and must be submitted to the Midwest UX team no later than Friday, July 25th. 
  • Your video should answer the two following questions:
    Why is Pittsburgh a great place to practice design/UX?
    Why would you like to see Midwest UX come to Pittsburgh in 2015?
     
  • No profanity, please.
  • Submissions may be edited, and, depending on the volume of responses, not all videos will appear in our final submission.

HOW TO SUBMIT VIDEO

  1. Upload your video to DropBox, Vimeo, or a similar platform by which we can download it (We can’t easily download from YouTube). Digital files only—No DVD, VHS, or Betamax please.
  2.  Send us email (midwestuxpgh@gmail.com) with your name, title, company (optional), and the link to your video. 

TIPS FOR RECORDING

  1. Videos should be provided in MP4 format (also known as MPEG-4). Most digital video cameras, high quality smartphones, and other digital recording devices use this format, so don’t sweat it.
  2. Try and shoot in high definition (HD) video format with a 16:9 aspect ratio. The most common resolutions are 1280×720 pixels (720p) and 1920×1080 pixels (1080i/1080p).
  3. The preferred video codec is H.264. If you have no clue, don’t worry about it.
  4. When recording with a mobile or tablet device, shoot in landscape.
  5. Try to shoot in good lighting conditions. We want to see your face!
  6. Try to avoid bright light BEHIND you. Many cameras have auto functions that will create havoc in your picture when there is bright light behind you.
  7. Try to record in a space without loud or distracting noises.
  8. Record 10 seconds of silence before you begin. The editor will LOVE you for it.
If you’re not a videographer, that’s OK. We’re not overly concerned with your technical skills; we’d much rather see and hear your passion for design and the city. It’s the contents of the package we’re interested in here (that’s you!), not the fancy wrapping paper.

Thanks for your time,
The Midwest UX Pittsburgh Team

The Birth of a Book: Part 14

Over the Christmas holiday, I wrote the conclusion, acknowledgements, dedication, glossary, and references. I also got the GitHub repository up. It was time to finalize the cover. We also finalized the title of the book, going from the working title, “UX and Web Development: Better Results through Integration with Your Development Team,” to “Bridging UX and Web Development: Better Results through Team Integration.”

As I worked on the cover, I was also attempting to get somebody to write a foreword for the book. The point of a foreword, as far as I was concerned, was to lend credibility to my book by having a recognized member of the design community endorse it. And additional requirement was that it be somebody that I know personally and respect. The first person I asked never replied. The second person declined. My editor contacted a list of people that I had suggested might provide endorsements for the back cover, but none of them panned out either. That was a little disheartening, but I felt confident enough in the usefulness and quality of my writing that I wasn’t too concerned about it. Yes, I would have preferred to have the support of some “big name” UX professionals, but to tell the truth, I don’t mind not sharing the cover.

By the end of January, the cover design was done, front and back, and I had comments back from my technical reviewers on all the chapters. It was time to make revisions and learn some lessons… the hard way.

To be continued…

Read previous parts.

Documenting State

As I continue to refine my employment of OOCSS, I’m also improving the process by which I architect and document the UI. Until now, I’ve waited until implementation to think about the state classes I need and how they will be used. They have only been documented as comments in the HTML. States would be specified, but without any instruction as to how to enact them.

In the past two weeks, I’ve been working on a very detailed UI behavior specification for a complicated form (complicated behind the scenes to make it clear for the user). I figured out the various UI states that I plan to control with CSS and included state classes in my specification document. Now, I not only explain the behavior that is to occur, but provide the state class that can be added or removed to enact it. This is a significant step in improving collaboration with my development team on the CSS architecture. It also forces me to think more strategically about how I intend to implement the front end.

[1] Blog Post(s) About Parenthetical Plurals

Recently, I’ve been specifying a UI for configuring recurring events. I have a number of pet peeves when it comes to copywriting, and in this design, I had the opportunity to address one of them: parenthetical plurals. Take this form from Apple’s Calendar application, for example:

The “s” is conditional based on the number the user enters into the field. But this isn’t print—the form could be dynamic. When the value in the field changes, the software could do a quick evaluation to determine if it is greater than 1, and if so, add the “s”.

I’ve included this behavior in my UI specification. I’ll be interested to see if I get any push-back from the developers. Given the complexity of the form, the implementation of this little bit seems trivial.

Foursworn?

I started using Foursquare because I felt obligated to learn about it. Why had it become popular? What made it such a good mobile app? What lessons could I take away from this combination of geolocation, gamification, and social networking? I had fun with it. I enjoyed the badges, the witty copywriting, and earning the mayorship of my frequent haunts. I competed with friends in my office, especially when we went on business travel. I may have checked into the airport parking lot, people mover, security checkpoint, tram, terminal, and gate. Ahem. I also enjoyed free chips and salsa after checking in at Chili’s.

Recently, Foursquare launched a new app called Swarm. They started advertising it every time I checked in. I ignored it. I had read that it was just about finding out where your friends are, which isn’t what I used Foursquare for. Then, one day, Foursquare wouldn’t let me check in. It directed me to download Swarm. I contemplated deleting it, but I now have a few years of history in the application, and I like being able to find places I’ve been. So, I downloaded Swarm. After I used it to successfully check in a couple times, I deleted Foursquare.

Now, I find that they expect you to have and use both apps. If you want the free chips at Chili’s, you need Foursquare, but to check in, you need Swarm. This is idiotic. Why should I use two apps to do what I could do before in one? As I understand it, there are no longer badges to be earned or mayorships to steal. I seem to only get 1 point per check-in where I used to get bonuses for various things. It no longer seems fun. It no longer seems useful. I’ve been forgetting to check in places, because I’ve stopped caring. If you read through the reviews on Foursquare, you’ll find that a lot of people feel the same way.

I’m curious as to what they were trying to do. Was there a problem they were trying to solve? Why did they think dividing the functionality into two apps would be an improvement? Did they think their users were tired of badges and mayorships? Most importantly, I wonder what lessons they’ve learned.

Knobs

Physical knobs are wonderful things. They can be large enough to grab with you whole hand, like a door knob, or small enough to twist between thumb and forefinger, like a radio dial. They can be textured and made with materials to improve friction. They can give tactile feedback as they are turned. They can snap into position or stop turning when they reach the end of their range. They can fit an infinite range of values into a tiny circle. They are intuitive controls that don’t even require the user to look at them as they are used.

However, knobs do not translate well to virtual UIs. All of the tactile qualities are gone, and the twisting motion that is so intuitive to those of us with opposable thumbs becomes an awkward test of hand-eye coordination in two dimensions.

And so, we find another case where Apple’s skeuomorphic designs, while visually beautiful, are less usable than they should be. The latest version of GarageBand has an impressive collection of simulated instruments, all of which provide controls for adjusting the sound. Here, for example, is the control panel for a Bass Synthesizer.

As you can see, they are all knobs. Beautifully rendered, yes, with animation that is smooth as butter, but the first time I tried to turn one, it did not behave as I expected. I grabbed the knob on one side and tried to rotate it clockwise by dragging my mouse in a circle, effectively tracing the knob with the cursor. The knob turned just a little bit, but then stopped and finally reversed directions and turning counterclockwise until I stopped moving. With a little bit of experimentation, I figured out that to turn a knob, you should move your mouse straight up and down. Up will turn it clockwise, and down will turn it counterclockwise. Moving the mouse left and right has no effect.

I wasn’t the only one to have this problem. I got to observe my lead guitarist as he used the software for the first time. He did exactly the same thing I did. He never got the up/down movement, instead discovering that he could control it by swiping up and down on his Magic Mouse (the same action you would make on a scroll wheel). This turns out to be the most elegant method of controlling them, and I’m sure it’s what Apple had in mind.

Apple went to great lengths to design these panels, customizing them for each type of instrument. There are many different styles for different types of keyboards.

Tech Synth

Electric Piano

Vintage Clav

Yes, that vintage clavichord has rocker switches and scratches in the finish. But how easy is it to tell whether the treble filter is on or off? Keyboards aren’t the only instruments that got special treatment. Here’s a bass guitar.

Even instruments that wouldn’t have controls on them have been given the treatment, such as this upright concert bass.

The sheen on the dark-stained wood grain of the knobs and the little notches in them are exquisitely crafted, but I can think of more informative ways to show the settings.

Yes, it’s true that a knob can fit more data in a smaller space. For example, this pan knob takes up much less space than the slider beside it.

It also gives a numeric readout while in use, which the previously mentioned controls do not. But it doesn’t seem like these panels are cramped for space.

Knobs are inherently physical controls. There are better widgets for use on screen.