160 likes | 254 Views
Applying Existing Guidance to Mobile Phones . Tyler Lemke CMPT 480 November 28 th , 2012. Why is this important?. Smartphones have exploded in recent years (100 million+ owners in US) Used similar to PC’s, yet have widely different interfaces and capabilities
E N D
Applying Existing Guidance to Mobile Phones Tyler Lemke CMPT 480 November 28th, 2012
Why is this important? • Smartphones have exploded in recent years (100 million+ owners in US) • Used similar to PC’s, yet have widely different interfaces and capabilities • Better to address now than later • Manufacturers of software/hardware are beneficiaries
Examining Smartphones-Hardware • Hardware design can vary hugely, focused on what is common • Had to establish common features between cellphones • Hardware accessories were not examined (docks, keyboards, etc)
Examining Smartphones-Software • Focused on iOS and Android • Heavy focus on information from the iOS and Android official guidance • User created applications create further issues
Implementation • Analysis showed that most existing guidance could be revised or supplemented • Focus was on the guidance mentioned in the analysis • New guidance was recommended only as necessary • Otherwise, put guidance under two categories: Not applicable or Applicable with modification
Hardware Guidance • Based on ISO-IEC 29136 • Vast majority of hardware guidance proved to still be applicable • Physical Controls (Power Button, volume, etc) translate very well (Section 5.4) • Any guidance on connectors was also applicable with no modifications needed (Section 5.7) • Surprisingly, keyboard guidance also translated very well to phones (Section 6.2)
Software Guidance • Based on ISO-IEC 9241-171 and ISO 9241-20 • Software guidance was not as applicable as the hardware • General Guidance (Names, Labels, Icons) were still applicable (Section 8.1) • Customization was an issue, needs a lot of modification to be applicable • Keyboard Customization as an example (9.3)
Evaluating New Guidance • Focus was on use cases • Good use cases had a main success scenario, consisting of steps • Also had “extensions” which are scenarios where the interaction differs from main success • Structure was devised by Martin Fowler, can view at http://en.wikipedia.org/wiki/Use_case
Evaluation Cont. • Ended with about 30-40 use cases • Split between hardware and software • Each use case has a “story”, reason for it to be done. • These stories are from perspectives of the manufacturers, they will be ones following guidance in most cases
Evaluation Cont. • Coming up with use cases difficult proved difficult • Challenge is fore seeing a real world situation where they might occur • Must also have some uses cases where failure happens, else results will not be valid
End Results-Hardware • General Guidance works as is, with little modification (5.4) • Stability can be left out (5.4.1) • Guidance on Power Controls (5.5) remains applicable • All guidance on connectors and interfaces (eg. Audio Ports) is applicable • Surprisingly, keyboard guidance (6.2) is still applicable
End Results-Hardware Cont. • Touch screen are of guidance requires modification (6.3) • This includes guidance on using haptic feedback, how to separate navigation/activation • By far the area needing most modification
End Results-Software • General Software Guidance (8.1) remains fully applicable • User preference settings (8.2) need modification to work • Issue is with manufacturer lock down (Apple) • Hardware also present issues
End Results-Software Cont. • Biggest problem area of software was input (9.0) • Touch screen makes cause for changing this • Customization on input also problematic for reasons discussed • Guidance on text/font remains relevant, but modification is needed • Research into screen size, DPI should be done
End Results Cont. • As mentioned, unless use cases are valid, results don’t mean much • Different people = different use cases = different results • Any further work in this area means much more evaluation
Project Conclusion • As it stands, project is a starting point • Further work needs to be done in revising guidance, can base a lot off of existing guidance • As revisions are made, new use cases will be needed • If more work is done, can serve as official guidance for hardware/software manufacturers