World Usability Day 2010 – Part Two

World Usability Day logo

If you haven’t read Part One of this post, find it here.

I apologize. I failed at the whole not taking as long to get this post up. It’s been 90% done for several weeks just waiting for me to go back and finalize it – taunting me the whole while.

So, picking up where we left off there are three presentations remaining starting with a surprisingly interesting one from a government employee.

Government on the Move

When I saw that there was someone from our state government there it was not necessarily surprising considering how close we were to the Capital Building and my knowledge of’s existence, but I wasn’t sure if I’d be sleeping by the end.

As it turns out, Chuck Baird was an entertaining speaker and even started out joking about the bad rap speakers from the government get. He shared with us about how usability came to his attention and grew from there as well as the ways that the state had started to look at usability in their development.

While anyone can tell you that there is a lot work to be done on the state’s site, Baird was able to share about the Mi Drive site, MDOT’s twitter account and the mobile version of the state’s site.

Best Practices for Mobile Application Design

This presentation, by Jason Withrow of Washtenaw Community Colleg and Usable Development, LLC, mostly discussed the basics of how to think of and work in the mobile space.

Withrow started with the range of mobile devices – screen sizes, software, supported devices, storage and microbrowsers. All of these elements can vary across a wide range. For example the average cellphone has a screen size of 100-320 pixels while an iPhone is 480 in width and PDAs can range from 320-640 pixels.

From there he moved on to specific design constraints focusing mostly on hardware like the keyboards on mobile devices, touchscreens and potential bandwidth (both connection speed & data use).

For the sake of space I’m going to breakdown the main best of practice points into an outline.

Low-end device implementation
– best done in (x)html + css with either a handheld stylesheet, .mobl address or m.domain address.
– functionality should be focused on the key task the app is meant to do
– same amount of bandwidth is consumed when elements are hidden but not removed from mobile visibility/functionality.

High-end device implementation
– Option 1: (x)html +css combined with javascript using a css media query based on device characteristics
– Option 2: write the app in a programming language supported by the device.

– Streamline task completion: keep a consistent theme in mpbile design and focus on doing 1-2 things well
– Design for preferences and patterns: remember the users frequent selections & most recent actions
– Design for single-hand use: can the user operate it with one finger? Limit the need for keyboard & multi-touch.
– Keep Fitt’s law in mind: size is critical, it needs to be big enough to acquire easily without clutter to hit accidentally around it
– Use mobility to your advantage: incorporate the users geographic location in consideration

– transition between portrait/landscape modes requires bigger adjustments than on PDA/smartphones
– drop & drag is possible

Creating Beautiful Android & Apple Mobile Applications Easily

When we first saw this topic on the docket, we really weren’t sure if we’d get anything out of it because when it comes to coding… well, that’s what the devs are for (and we appreciate it greatly). I am so glad we decided to stay anyway.

Nick Kwiatkowski (@quetwo) started out with a few stats to keep in mind –

– 4.6 billion cellular subscriptions worldwide
– 3.5 billion are capable of text messaging
– 257 million data plan holders within the USA (over 1 billion world wide)

It is not all HTML5 and people are expecting an app but the fragmentation of mobile devices makes very few things compatible across the board. Because of this creating apps for use across the board can be very expensive in development hours.

Adobe has published an application framework that allows developers to create applications that run across mac, windows and linux

AIR is either compatible or soon to be compatible for iPhone, Android, Windows & blackberry and allows you to re-use code to create an app over multiple platforms. This is not a miracle tool. The toolsets will never be as powerful as an app targeted at a specific device and the context (phone vs desktop vs other) does need to be considered before sharing the code blindly.

I’m including my notes from the talk, but if you really want to get a good grasp of how this works I suggest going to Kwiatkowski’s blog for his notes, powerpoint, etc.

Start by selecting your chosen device in Device Central

Create a new document in Photoshop
– since it is exported from device central it is already set to the correct specifications
– make sure each element is on it’s own layer because the prototype will lose it’s taxonomy
– elements should also be divided into folders
– Do not rasterize labels and fonts, this breaks accessibility

Adobe Catalyst
– create a new project from a psd.
– It will import with an options screen (choose a color other than white so people don’t take it as something being wrong)
– Ctrl/enter will run the project in internet explorer
– Use shift to select multiple
– With a click change to types of functionality (Photoshop box -> text box)
– Specify as needed (parts, repeated elements, etc.)
– Create multiple views in the pages/states sections
– Create interactions from the data list

Now into Adobe Flash Builder (can also use Flash Professional)
– rt click on project explorer, Flex mobile AIR project
– list target platforms, blank to import project in progress
– multiple Photoshop files for real life re-orientation
– App id usually domain name backwards
– Automatically imports code with the catalyst final design file
– Debug file for errors
– Can export to code or the internet
– Professional is a little more advanced with iPhone

There you go. I hope you’ve enjoyed this overview even if it has taken me far too long to post it.

World Usability Day 2010 – Part One

World Usability Day logo

It has a taken a couple of weeks to get to writing this, but back on Nov. 11th @caitlinpotts and I had the opportunity to head out to Lansing for the day and soak in some mobile devices information at World Usability Day (#wud2010). I’ve realized in pulling together my notes that this would be awfully long as one post, so this’ll be a two parter.

We started off our day with a quick stop at Panera bread for breakfast and coffee before heading over to the Kellogg Center on Michigan State’s campus. Once there we met up with our friend Mike (@UXmikebeasley) and settled in for the day.

On to the presentations…

Talking Points

While our first speaker’s topic had absolutely nothing to do with the mobile apps we’re currently considering at work, Mark Newman of the University of Michigan gave a fascinating presentation.

‘I can get where I need to be and if I get lost I can find my way out.”
-Talking Points Test Participant

Talking Points is a research project they’re working on to use smartphone technology with gesture-based interactions to help visually impaired people learn about their surroundings.

Basically, the project uses GPS outside and, eventually, wi-fi tri-lateration inside to provide visually impaired people with information on their surroundings with community gathered GPS/wi-fi tags. These tags would be for paths, areas, points of interest, path intersections/decision points and functional elements like entrances or restrooms.

The goal of this project is to not only foster spatial awareness in navigation, but also comfort, security, exploration, improvisation and the discovery of new resources (aka independence). You can find out more information on the project at

The Art of Mobile User Experience Research

The second presentation was by Kris Mihalic (@suikris) from Nokia. He started out talking about the division in understanding humans that occurs in the technological workplace between market research and UX research.

Market research tends to focus on opinions and quantitative data gathered from focus groups, surveys and ideation sessions while UX research is usually more interested in behaviors and qualitative analyzing behaviors and anthropological studies for insights into why people do what they do. UX is also usually closer to product & design than market research.

There are three pillars that Mihalic focused on for Mobile UX – speed, flexibility and context.

Speed refers to all of the things involved in having a high speed of execution including fast prototyping, recruiting and delivering results, which includes involving stakeholders early.

One quick prototyping method that I’ve not used but sounded fun was sharpie movies, which is sketching in sharpie then compiling it into a movie. Being imbedded with a development team, his suggestion to become BFFs with the developers to gain their investment in prototyping was amusing. Cookies are generally a great form of bribery ;)

Flexibility referred in large part to platforms (focus on the important ones), interaction and hardware. He specifically mentioned being prepared and informed about the situation you’re working in and making sure that your stakeholders understand the constraints of what you are and are not able to do.

The last pillar of context stressed the timing within the development cycle, use vs. research, support/vendors and being contextually aware of your team, business, users and research partners. One suggestion he made was using video diaries from testers which put the device into a real life context and also powerful with stakeholders.

Milahic’s last point was that the greatest return on investment (ROI) of UX research is to take the information gathered and optimize your product’s ‘sweet spot’. You can’t do everything, but optimize that which you do well.

Building Mobile Experiences

The next presentation was by Frank Bentley of Motorola Mobility. He had some great visual examples that I unfortunately do not have to share with you, but there are some great points event without them.

The first and very important point is that while there is a good bit of similarity phones and computers, especially smartphones, but they are used very differently.

This point is so important because it goes back to the context that Mihalic mentioned and that testing in a lab alone won’t give you the whole story. You get the basic data from lab tests, but it doesn’t answer the question of how it’s really used and misses all of the creative ways that people use their devices in real life.

Because of the shortfalls of lab testing, their goal is to have a functional prototype that they can put out for field evaluations with beta testers in 1-2 weeks.

With these prototypes he emphasized building only what you need (!!!!!), focus on the experience instead of the technology and make sure that your prototype is sturdy enough to survive testing

He also emphasized the importance of recruiting according to your goals for testing and that the device needs to be their primary device to truly understand the context and how they are used. With the recruiting, it is best to recruit a diverse testing population so that similarities are less likely to be coincidental.

Lastly, the first prototype doesn’t need to be complete or fancy. The faster that a prototype exists – even if it doesn’t have all the polish – the sooner you can get real feedback to see if the project is going in the right direction.

That’s it for World Usability Day – Part One. Keep watch for Part Two. I promise it won’t take as long to get out as this first one did. I failed at that one… but Part Two is now up!

Say What? Learning to Speak Dev

When I started my current job back in February one of the first things I noticed was that I didn’t speak the language. It wasn’t that I was a stranger to acronyms – the Boy Scouts are quite fond of them – but these were new and strange letter combinations accompanied by words I was not accustomed to hearing. So I decided to start a little dictionary and felt this would be a great place to share it.


This is actually the model of software development we work off of, so it’ll get more detail than Waterfall. It was actually developed as a reaction to the Waterfall model and is based on the Agile Manifesto. Instead of trying to approach the entire project as one large piece of work it is divided into smaller chunks of work. The larger project is put into the format of a vision and these smaller pieces are put through the entire requirements/design/coding/testing gamut in a boxed period of time called an iteration. Sometimes these smaller pieces of work can be released on their own, whereas other times they are released as a whole when the vision is concluded.

This method has something of a cyclic nature. More like a rapid than a waterfall. Instead of each section being completed then not touched again as it goes the process things like testing and design are incorporated all the way through so that problems can be discovered and addressed early and quickly.

Command Line

Plain text interface is where interactions with the computer occur through written lines of text – no graphics. This term was not entirely new as I used to play in DOS as a child, but it disappeared from my vocabulary until I began working with Linux loving developers.


When most girls talk about committing they’re referring to marriage, but here to commit is to add completed code work back into the main project’s code base. While this is a common occurrence it can occasionally lead to being hosed. Thank goodness for the ability to revert to a previous state.

GUI (Graphic User Interface)

Pronounced ‘gooey’, this always makes me think of warm chocolate chip cookies. In reality, it’s what you’re used to seeing on the screen of your computer if you’re not a Linux user. Unlike command line which is totally text based, GUI uses a graphical interface to let you communicate with your computer.

HCI (Human Computer Interaction)

This is actually the field of work which preceded User Experience Design and studies the interaction between, you guessed it, humans and computers.


Basically, you’re out of luck. If something is ‘hosed’ it is completely and utterly broken down. Good luck if you need anything from it in the near future. The term does exist in Urban Dictionary if you’d like further examples.

IA (Information Architecture)

The underlying structure and organization of a website. This has close ties to library science and shares a lot of similarities since its all about organizing information so that it can be found and understood.


In the greater world and according to Webster’s this is usually used in relation to something like a speech impediment, but here is it is more closely tied to the verb ‘impede’ which is ‘to interfere with or slow the progress of’ so an impediment is anything that gets in the way of work being completed.


A measurement used to represent a pre-determined period of time during which work is done and reviewed. The goal is to have a working piece of software at the close of a sprint.

NUI (Natural User Interface)

The most recent development in interfaces, this is supposed to mimic the natural world closely enough so that it becomes intuitive. Examples of this can be seen in the various touch screens out there which allow you to interact with them via ‘gestures’ like ‘dragging’ something across the face of an iPad or iPhone.


So this particular entry is a bit of a joke for my co-workers. I’ve long been familiar with this typeface, but due to it’s recent rise in importance it was felt this should be included in this list. To the developers delight it is the bane of Lisa’s existence and has become and ongoing source of joking and pranking in the office. If you ask the devs, it is all that is right and glorious in the world even if there are occasionally consequences to this sentiment.


Originally this stood for ‘personal home page’ when it appeared on the scene in 1995 and is a general scripting language. In essence it’s a way to write web pages that do things. Now that I know it exists I see it pop up all over the place, but it seems to garner mixed responses around here. It may not be PHP’s fault though. It could just be getting a bad rap due to some old code the guys have to clean up.


Is not only a snake after all. It is another programming language that is supposed to be highly readable and has caused much excitement amongst the guys I work with. It was originally developed in the 80s and has had updates in 2000 and 2008. Apparently it makes you fly as well.


According to Wikipedia, it ‘is an iterative, incremental framework for project management and agile software development.’ Basically it’s a development team who have a Product Owner to represent the stakeholder and a ScrumMaster to maintain the processes. In our office those two roles are mostly combined.

The biggest thing (to me) with scrum is the three forms of review incorporated in it. Daily Scrum is within the team every morning reviewing the previous days work, plans for the current day and work impediments. Scrum review is presenting work completed in a sprint to the company at large. Then there’s the retrospective that is again within the team.


A model of software design that is sequential starting with requirements and ending with installation and maintenance. Each piece of the process is completed in its entirety before moving onto the next one.


Letting the code out in the great wild world. A release is when all the project work is done tested and shared with those who use the program it was intended for. In terms of software there is usually a ‘beta’ release which goes out to some folks who are will to test it to see how it functions beyond our walls and then, assuming all remains well, a general release which includes anyone else with the software.

In other words, whenever you get a notification to update your web browser (like Firefox or Chrome) or an app on your iPhone/iPod touch that means that the folks who are working on the software for that product have put out a new release for it.

Retrospective (Retro)

A regularly held meeting (usually at the end of a sprint) where the team discusses what was good, bad and needs to change since the last retro. At the close of the retro items are starred and assigned to be completed as well as there being a review of the previous retro’s stars to see if all of that work was completed.

UX (User Experience)

I have tried to find a simple explanation for my job and failed, but I will come back with a better description in a post just on this subject. My friend Zach says that UX is about ending suffering in regards to technology. I usually describe it as that I work with the development team to make sure that the things we make can be used by actual people.

UI (User Interface)

Tied in with the field of HCI, the user interface is the place where the actual interaction between human and computer occur.


The overall goal of the current development project which contains the key points of what is to be achieved by the completion of the project.

War Room

This is a communal work area, also sometimes known as a Bull Pen, which is common practice in Agile to increase face to face communication. Communication, of course, can include many varied and entertaining things. In our case it is a communal cubicle and we do call it the War Room. It even has its own twitter feed – @InTheWarRoom – which documents some of these entertaining communiques.

I’ve hit that point now where I don’t even realize how much I’ve learned by immersion so I’m sure there are terms I’ve missed. Feel free to include terms that probably should have been included in the comments below (or ask about ones you’re curious about).