Summary:
In the final chapter of Steve Krug's book on usability, "Don't Make Me Think", Krug concedes to the inevitable: That in the business of web design, you will likely be made to alter a website by decree of a superior who has no business making web design decisions (and it will show). The two main complaints Krug says he receives from web developers are that their boss is either asking them to collect unnecessary data from users, or to add needless "flash" and "pizazz" to otherwise informational websites. Krug attempts to explain to the hypothetical boss in these scenarios why these suggestions are, frankly, bad ideas. Not one to "beat around the bush," Krug says of collecting unnecessary personal data: "Usability professionals have a technical term for this practice. It's what we call 'a very bad idea.'" He explains that not only will users feel offended, but it could also actually lead to less data being collected, as users will feel compelled to either leave the site altogether or lie their way through the forms. As for the ubiquitous boss charge to "add sizzle", Krug explains the types of site that do well with flashy media: entertainment, full-branding, and portfolio sites. If the site being developed isn't on this list, Krug explains, then its main purpose is most likely informational, and needless pizazz will simply get in the way of information and offend the user, possibly leading to them no longer choosing to use the site. He then closes his book by stating that, though the book has focused on the rules and standards of strong usability design, it does not mean that the rules can't (or shouldn't) be bent when beneficial. He ultimately states that, as long as a wild decision has a purpose, and is thoroughly tested and results are positive, then the sky is the limit.
Links:
http://www.webdesignerdepot.com/2009/06/10-web-design-rules-that-you-can-break/
A site listing 10 common web design rules, and how to effectively break them.
http://www.noupe.com/design/breaking-the-rules-how-to-effectively-break-the-rules-of-good-web-design.html
A gallery of more websites breaking the rules in a successful manner.
http://www.moiremarketing.com/blog/want-your-website-get-noticed-break-rules
Blog post that hails effective rule breaking as the best way to get your website noticed.
Wednesday, March 9, 2011
Project 3 - Smartphone Application Design - Project Statement
Project Statement
“Überschlafen – Polyphasic Sleep Scheduler”
by Alex Brewer and Matthew Barrow
We will create an Android-native app designed to help users adopt a Polyphasic sleep cycle. “Überschlafen”, from the German for “Super sleeping”, represents the ultimate in Polyphasic sleep: The Uberman Sleep Schedule.
The Uberman schedule represents the most extreme and controversial implementation of polyphasic sleep, positing that REM sleep - the most beneficial, restorative mode of sleep - can be best achieved through a series of six 30-minute “naps” spread over the course of a 24-hour day (The idea being to achieve a total of three hours of REM sleep, as opposed to the roughly one-and-a-half to two hours gained from a traditional eight-hour sleep pattern. Proponents of the plan consider non-REM sleep to be wasteful and of little benefit). While true observational research validating these claims is scarce, anecdotal evidence is becoming more widespread touting the merits of this seemingly unnatural, non-Circadian sleep schedule.
Of course, the implementation of this schedule is not without its caveats. Most notable among them are the effects of heavy sleep deprivation resulting from missing a scheduled sleep period. In a world that moves at a pace such as ours, can anyone, regardless of their devotion, afford to watch the clock with such meticulousness? And what of the slow integration necessary to get to the point where one’s mind feels comfortable sleeping only three (separated) hours a day?
It is these issues that Überschlafen will attempt to resolve. Upon first opening the app, the user will be greeted by optional readings describing the Uberman schedule (and polyphasic sleep in general), carefully noting the risks involved. Should the user wish to continue, they will be asked to choose their gradual course plan, with options to define ideal sleep periods, as well as to opt out of the “ramp up” entirely.
The app’s main focus will be a broken circle revolving around a central time-display and countdown timer, with differently colored areas representing conscious and sleep periods. The app will alert the user when a scheduled sleep period is approaching. At this point, the user will have the option of playing sleep-aiding white noise (nature sounds, binaural rhythms, or digital pink noise) or a stored music file (via integration with the OS native media player). Upon completion of the sleep period, the app will sound an alarm (or, once again, a selected music file) which will require the completion of a simple puzzle or math problem to reset, ensuring the user’s complete return to consciousness.
In keeping with the theme of slumber, the app will utilize a monochromatic palette consisting of dark blues and grays. Branding based on the “Uberman” aspect will possibly be incorporated through relevant imagery (Friedrich Nietzsche, Leonardo’s “Vitruvian Man”).
Wednesday, March 2, 2011
Week 7 Reading
Summary:
This week's reading is courtesy of Apple's iOS reference library. "Human Interface Guidelines" introduces some guiding principles to help designers create an app that will provide the best user experience by utilizing the technology available to the iPhone and iPad's proprietary operating system. It begins by stating that great iOS apps "embrace the platform", namely, utilizing the visual style as well as the functionality the operating system is used for. This can include taking advantage of swipes and other touch-centric interaction methods. It continues by stating that clear definitions are essential to strong app design, stressing the importance of first deciding what features you intend to deliver, and who to market them to. Next, it states that a great user experience is "rooted in your attention to detail". Following this guideline means that all aspects of the app should be designed with the user experience in mind, down to the smallest detail. It then espouses the acquired wisdom that people "expect to find iOS technologies in the apps they use". Technologies like VoiceOver, it states, are expected by users to automatically be in every app they use, but actually may take work on the part of the designers and programmers to implement. The reference concludes by stating that all apps must include custom artwork of some sort, even if it's simply for the icon used in the App Store and on the home screen. It suggests reading further guidelines to know exactly what the requirements for artwork are.
Links:
http://appdevmanual.com/
A site selling a book about iPhone app design, including a supplementary blog about the subject.
http://www.smashingmagazine.com/2009/08/11/how-to-create-your-first-iphone-application/
A helpful step-by-step guide to creating an iPhone application, from conception to marketing the finished product.
http://www.webmonkey.com/2008/07/how_to_write_an_iphone_app/
Programmer-centric article that briefly explains what is necessary to create an app and have it accepted to the App Store.
This week's reading is courtesy of Apple's iOS reference library. "Human Interface Guidelines" introduces some guiding principles to help designers create an app that will provide the best user experience by utilizing the technology available to the iPhone and iPad's proprietary operating system. It begins by stating that great iOS apps "embrace the platform", namely, utilizing the visual style as well as the functionality the operating system is used for. This can include taking advantage of swipes and other touch-centric interaction methods. It continues by stating that clear definitions are essential to strong app design, stressing the importance of first deciding what features you intend to deliver, and who to market them to. Next, it states that a great user experience is "rooted in your attention to detail". Following this guideline means that all aspects of the app should be designed with the user experience in mind, down to the smallest detail. It then espouses the acquired wisdom that people "expect to find iOS technologies in the apps they use". Technologies like VoiceOver, it states, are expected by users to automatically be in every app they use, but actually may take work on the part of the designers and programmers to implement. The reference concludes by stating that all apps must include custom artwork of some sort, even if it's simply for the icon used in the App Store and on the home screen. It suggests reading further guidelines to know exactly what the requirements for artwork are.
Links:
http://appdevmanual.com/
A site selling a book about iPhone app design, including a supplementary blog about the subject.
http://www.smashingmagazine.com/2009/08/11/how-to-create-your-first-iphone-application/
A helpful step-by-step guide to creating an iPhone application, from conception to marketing the finished product.
http://www.webmonkey.com/2008/07/how_to_write_an_iphone_app/
Programmer-centric article that briefly explains what is necessary to create an app and have it accepted to the App Store.
Thursday, February 24, 2011
Week 6 Reading
Summary:
This week's reading begins by likening usability to common courtesy. Explaining that all users have a certain "reservoir" of goodwill, Krug explains the ways in which it is often depleted by poor usability design (Hiding useful information, demanding strict adherence to a standard from the users, asking for unnecessary information, being intentionally misleading, putting flashy imagery and animation before content, and having an amateurish-looking site), while also explaining that the reservoir is idiosyncratic and situational. While mistakes can deplete it, it can be refilled by doing things like putting important information first, saving the user as many steps as possible, making it easy to recover from errors, and, failing all of that, apologizing for any shortcomings in the site's design, avoidable or not. He then discusses how important designing for accessibility for those with disabilities is to the web, despite many designers' hesitance to do so, typically out of fear of compromising overall design or general laziness. In addition to accessibility being a law in this country, he states it's simply the right thing to do to enrich the lives of others. In the event of the failure of those reasons to force the designer to take another look at accessibility standards, Krug explains how making pages accessible makes them better overall, even to users without disability (For example, ordering things in a hierarchal sense of importance is almost essential for screen-readers, but greatly benefits those who can see as well, as all users scan for information, disability or no). He recommends CSS as the answer to obstacles that would, in the past, make accessible design difficult, and gives tips that can instantly be affected to the HTML of a page to make it more accessible.
Links:
http://www.webnauts.net/accessibility-testing.html
A short article that details reason why designers should attempt to test accessibility with actual users, as opposed to automated tools.
http://wave.webaim.org/
Useful tool that examines and tests any webpage for wide accessibility, with helpful embedded icons and reports.
http://www.w3.org/WAI/quicktips/
A few more tips for making accessible sites.
This week's reading begins by likening usability to common courtesy. Explaining that all users have a certain "reservoir" of goodwill, Krug explains the ways in which it is often depleted by poor usability design (Hiding useful information, demanding strict adherence to a standard from the users, asking for unnecessary information, being intentionally misleading, putting flashy imagery and animation before content, and having an amateurish-looking site), while also explaining that the reservoir is idiosyncratic and situational. While mistakes can deplete it, it can be refilled by doing things like putting important information first, saving the user as many steps as possible, making it easy to recover from errors, and, failing all of that, apologizing for any shortcomings in the site's design, avoidable or not. He then discusses how important designing for accessibility for those with disabilities is to the web, despite many designers' hesitance to do so, typically out of fear of compromising overall design or general laziness. In addition to accessibility being a law in this country, he states it's simply the right thing to do to enrich the lives of others. In the event of the failure of those reasons to force the designer to take another look at accessibility standards, Krug explains how making pages accessible makes them better overall, even to users without disability (For example, ordering things in a hierarchal sense of importance is almost essential for screen-readers, but greatly benefits those who can see as well, as all users scan for information, disability or no). He recommends CSS as the answer to obstacles that would, in the past, make accessible design difficult, and gives tips that can instantly be affected to the HTML of a page to make it more accessible.
Links:
http://www.webnauts.net/accessibility-testing.html
A short article that details reason why designers should attempt to test accessibility with actual users, as opposed to automated tools.
http://wave.webaim.org/
Useful tool that examines and tests any webpage for wide accessibility, with helpful embedded icons and reports.
http://www.w3.org/WAI/quicktips/
A few more tips for making accessible sites.
Thursday, February 17, 2011
Week 5 Reading
Summary:
In this week's reading, Krug discusses many of the problems that web teams face, and explains that the majority of them stem from personal and professional opinions, strongly held and immovable. For example, a developer may believe that average users like a high degree of interactivity, as that is what they personally enjoy and is their professional expertise, while a designer may believe an aesthetically-pleasing site is more essential for the same reasons. He also dispels the myth that there is an "average user", explaining that all web users seem to browse sites uniquely and idiosyncratically. He concludes that the best way to avoid these issues is to focus more on what elements are best for the specific site, and to confirm them through testing.
Testing, he explains, is vital to successful web design and development. Contrary to commonly held beliefs, he says, testing doesn't have to be expensive or time-consuming. He recommends testing early in the process more than later, and doing so with anyone who agrees to participate, finding the attempt to seek "ideal users" to be futile. Three or four people, also, seems to be the best number for testing at each step of the process. He lays out the simple test taking process, stating that you should allow the user to browse the site and ask them to think aloud as they do so, voicing their problems as they occur. You should then take this information and set about to fixing major problems, while keeping in mind the effect changes will make to the site as a whole.
Links:
http://www.useit.com/alertbox/20000319.html
A site that contrarily suggests five users as the "magic number", with explanations why.
http://www.webpagecontent.com/arc_archive/124/5/
A reference of recommended testing procedures.
http://www.uiaccess.com/accessucd/ut_checklist.html
Summarized testing checklist from the book "Just Ask: Integrating Accessibility Throughout Design".
In this week's reading, Krug discusses many of the problems that web teams face, and explains that the majority of them stem from personal and professional opinions, strongly held and immovable. For example, a developer may believe that average users like a high degree of interactivity, as that is what they personally enjoy and is their professional expertise, while a designer may believe an aesthetically-pleasing site is more essential for the same reasons. He also dispels the myth that there is an "average user", explaining that all web users seem to browse sites uniquely and idiosyncratically. He concludes that the best way to avoid these issues is to focus more on what elements are best for the specific site, and to confirm them through testing.
Testing, he explains, is vital to successful web design and development. Contrary to commonly held beliefs, he says, testing doesn't have to be expensive or time-consuming. He recommends testing early in the process more than later, and doing so with anyone who agrees to participate, finding the attempt to seek "ideal users" to be futile. Three or four people, also, seems to be the best number for testing at each step of the process. He lays out the simple test taking process, stating that you should allow the user to browse the site and ask them to think aloud as they do so, voicing their problems as they occur. You should then take this information and set about to fixing major problems, while keeping in mind the effect changes will make to the site as a whole.
Links:
http://www.useit.com/alertbox/20000319.html
A site that contrarily suggests five users as the "magic number", with explanations why.
http://www.webpagecontent.com/arc_archive/124/5/
A reference of recommended testing procedures.
http://www.uiaccess.com/accessucd/ut_checklist.html
Summarized testing checklist from the book "Just Ask: Integrating Accessibility Throughout Design".
Subscribe to:
Posts (Atom)