Midwest UX 2014 & Me

Last week, I took my annual vacation to a log cabin down in wild, wonderful Wes Virginia. During that time, I was completely off the grid. There’s still no cell phone signal in the valley, and we don’t have a land line. Nor do we have cable or any type of internet connection. We can pick up a few radio and television stations via antenna. So, of course, everything happened last week.

Most notably for me, registration opened for Midwest UX 2014, and as part of that, they announced my full-day workshop, titled Bridging UX & Web Development. Yes, it’s named after my book and will be based on it. I’ll be leading the workshop on Thursday, October 23rd. We’ll work from 9:00 am to noon, break for lunch, resume at 2:00 and finish at 5:00. Here’s the really cool part: it’s only $200. I know! Don’t miss this opportunity to improve your CSS chops and learn how to contribute to your team’s production codebase.

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.