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 usability.gov’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.
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 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
- 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.