President and Co-founder of Humanized
Aza has over six years of professional interface design and consulting experience. He is the son of Jef Raskin, the inventor of the Macintosh project, and so has 22 years of informal interface design training. Aza gave his first talk on interface design at his local San Francisco chapter of SIGCHI at the age of 13, got hooked, and has been speaking ever since. By the age of 17, he was talking and consulting internationally; by age 19, he was coauthoring a physics textbook because he was too young to buy alcohol; and at age 21, he started drinking alcohol and co-founded Humanized. Aza has also done Dark Matter research at both Tokyo University and the University of Chicago, from where he graduated in math and physics. For recreation, he does Judo, speaks Japanese, and invents in his lab. He also enjoys playing the French Horn, which has taken him all over the world. Be warned: Aza is an incorrigible punster, so please do not incorrige.Presentations by Aza Raskin
Workshop #5: Design - Websites more User-centric
To err is human. We make mistakes. Our users make mistakes. It's a fact that our interfaces must handle gracefully. The first law of interface design is that "A computer shall not harm your work or, through inaction, allow your work to come to harm", yet the interfaces we design routinely ignore this idea. Is it possible to design interfaces that are so fault tolerant that no matter how many mistakes we make, that our work will never got lost?The Death of the Desktop
We are all familiar with the ubiquitous metaphor of the desktop on the computer. We take it for granted - that's the way computers work. But how much work do we get done on the desktop? None. Time spent in the desktop is entirely wasted in navigating to the application in which we can finally do our work.Designing for "Oh No!"
To err is human. We make mistakes. Our users make mistakes. It's a fact that our interfaces must handle gracefully. The first law of interface design is that "A computer shall not harm your work or, through inaction, allow your work to come to harm", yet the interfaces we design routinely ignore this idea. Is it possible to design interfaces that are so fault tolerant that no matter how many mistakes we make, that our work will never got lost?Books by Aza Raskin
by Markus Jakobsson, Steven Myers
-
Phishing is the practice of deceiving people into revealing sensitive data on a computer system. It is one of the fastest growing problems on the Internet, specifically through identity theft and money laundering.
This book looks at how and why phishing is a threat, and presents countermeasures. It serves to educate the reader on how phishing attacks have been mounting over the years, how to detect and prevent future ones and focuses on corporations who supply the resources used by these attackers. Subsequently the text deliberates on what action the government can take to respond to this situation and compares the adequate versus inadequate countermeasures. - Available At: http://www.amazon.com/Phishing-Countermeasures-Understanding..
Humanized Weblog
Humanized makes using your computer easy.
Monday, July 21, 2008
What would the web be like if you could tell it what you want to do as easily as you currently tell it where you want to go?
Mozilla Labs is starting to experiment with linguistic interfaces. That is, we’re playing around with interfaces where you type commands and stuff happens — in much the same way that you can type a location into the address bar in order to go somewhere.
I think this is cool because, for one thing, I think language-based interfaces are seriously under-explored compared to pointing-based interfaces. For another thing, I used to work on a project called Enso. Enso’s a language-based interface, where you type commands in and stuff happens. I think we got certain things right and certain things wrong in Enso’s UI design, so I want to take another crack at doing it better.
What makes a good linguistic UI?
Here’s my current theory.
- It’s easy to learn.
- It’s efficient.
- It’s expressive.
Those are the three “E”s. Let’s unpack ‘em a little.
“Easy to learn” should be self-explanatory. Even if a tool is super-efficient and incredibly powerful, if it’s too hard to learn, it’ll be relegated to the “experts only” ghetto. Yeah, that’s right, I’m talking about you, Unix shell. (ahem, Unix/Linux/Posix/BSD/etc.) The original language-based UI, the oldest UI still in common use, and the one which has given the whole concept of “type what you want to do” a bad name for the last thirty years, serves as an excellent counter-example. For a linguistic UI to be easy to learn, it should strive to avoid all of the following misfeatures of the shell: (more…)
Friday, July 18, 2008
In the concept video I recently did for laying out the interface paradigms for Firefox Mobile, I listed five guiding principals.
- Touch it with your finger
- Large targets are good
- Visual Momentum and Physics are compelling
- Typing is difficult
- Content is king
It’s these principals that inform the design of new features long after the original design as been coded, released, and iterated on. In discussions with the perspicacious Mike Beltzner, another design principal emerged.
6. Use modal overlays sparingly, if at all.
To be sure we are on the same page—I’m may be partaking in the dangerous hobby of coining new terminology—an overlay is simply a content area that sits in front of the content beneath it. The aspect that makes a modal overlay modal is that when it is up, the content “beneath” the overlay cannot be acted upon until the overlay is dismissed. Although a modal overlay may be visually transparent, it is never interaction transparent: you must always take action, like clicking “okay”, before continuing with your workflow. While I’m living dangerously, I’ll toss one more phrase into the mix: a state-forgetting modal overlay is an overlay whose state is reset every time it is summoned. That is, any work you do in the overlay is lost when you dismiss it. (more…)
Monday, July 14, 2008
Lately some of us at Mozilla Labs have been experimenting with graphical keyboard user interfaces in Firefox. Our current work-in-progress is something that we’re calling Ubiquity for the time being, though the name is by no means set in stone.
Ubiquity is heavily informed by Enso, a software product developed by me and my colleagues at Humanized from 2005-07. Aside from the benefits outlined in Alex Faaborg’s blog post entitled The Graphical Keyboard User Interface, this experiment is intended to solve few other problems, one of which I’ll address in this post.
Web applications, much the same as desktop applications, are a bit like isolated cities: it’s difficult for an end-user to arbitrarily share data and functionality between them. This is alleviated to some extent by creations like Firefox Add-ons that add toolbars or sidebars to Firefox’s UI, Bookmarklets, and Greasemonkey, but while all of these solutions are powerful, each comes with its own set of problems. The buttons and bars of many Firefox add-ons don’t scale well because of the valuable screen real-estate they consume; Bookmarklets are restricted in scope because they only have the access privileges of the website they’re running on; and Greasemonkey doesn’t prescribe any kind of interaction model, which makes it difficult to reuse the functionality of a script in a context other than the ones it was expressly designed for.
Wednesday, June 11, 2008
Firefox is coming to mobile. The innovation, usability, and extensibility that has propelled Firefox to 200 million users is set to do the same for Firefox in a mobile setting.
User experience is the most important aspect of having a compelling mobile product. Every bit of interaction and pixel of presentation counts when typing is laborious and screen sizes are minuscule. Many of the standard interaction models, like menus, always-present chrome, and having a cursor, don’t necessarily make sense on mobile. It’s a wickedly exciting opportunity but there are myriad challenges to getting it right.
One avenue for exploring this opportunity is through Mozilla Labs, which is about pushing the envelope towards better and brighter interaction horizons, as well as incorporating a winder community into the innovation process. This concept video explains one direction we are thinking in, and we’d love to inspire participation in thinking about other directions.
See the demo video and read the post on Aza’s blog.
Wednesday, May 28, 2008
One of the great things about the web is the relative ease with which one can set up a new service. In social bookmarking alone with have Del.icio.us, Digg, Facebook, Fark, Mister-Wong, Newsvine, Reddit, Technorati, Slashdot, and StumbleUpon, to name a few. That’s great for competition, and that’s great for users, but it’s not so good for bloggers and content creators.
What are you to do if you want readers to promote your content? Kevin Rose, of Digg, put it succinctly: “Encourage your visitors to submit their favorite stories directly to Digg [with a Digg badge].” Not everyone uses Digg. You have to decide on which bookmarking site, if any, to dedicate your precious screen real-estate. It’s a hard choice. If you choose poorly your reader won’t vote—it’s not a single click coupled and out-of-sight means out-of-mind—and your content losses its chance to make it big. You have to choose your horse wisely.
Read the rest of the post for a way to figure out which social bookmarking sites visitors use, on a per-visitor basis. JS library included.