This new commercial from Nissan has me impressed. Using “innovation” as their tagline, they provide an inspirational vision for a greener, better future. Notice how they balance ergonomics (the step in the rear wheel) with environmentalism.
The best designers I work with have an insatiable desire to design the right thing in the right way. They get frustrated by things they see as roadblocks to the success of their idea. Things, such as: unnecessary meetings, overt politics, uninformed opinions, malicious collaborators, and supposed technical limitations.
In my role at Adobe as a design manager one of my primary responsibilities is to remove roadblocks. The more I can do, to make it easier for the designers I work with to focus on doing what they do best, the better for them, the project teams they work with, and the greater XD team as a whole. This often requires me to do things I never imagined doing when I was a full-time designer - like attending on average 6-8 meetings a day; or filling increments of time between meetings with flurries of email glue; or spending as much time thinking about the informational needs of stakeholders as I used to spend defining a great experience design.
And, I love it. I love it because within the context of a large software company - team collaboration is necessary to make great designs possible. And within any good design team, there is a separation of role and responsibility. My role happens to be roadblock removal (along with creative direction, strategy planning, the occasional beer run, and well, a long list of other items that are too deep to explore this Sunday afternoon).
This is why Bob Sutton’s latest article in the HBR titled The Boss as a Human Shield, has me smiling. The article outlines, in short, a range of tactics managers can use to shield their employees from the unnecessary, distracting, and destructive. It also provides a few insightful warnings for when shielding might do more harm than good, or be a waste of time.
I highly recommend checking it out, it’s incredibly insightful and, if you are in a position of design management, immediately useful.
The Font Shop has some excellent, succinct, and free PDFs on a range of typographic topics.
Their latest is called “Meet Your Type,” and is sweet as it is short.
Why settle for casual flirtation when looking for a long-lasting relationship? Finding the perfect match is easy if you know the rules. Meet Your Type will help you overcome common obstacles, and keep your heart thumping for your one true love: typography.
HotGloo is a horribly named new web app that allows designers to create interactive, logic-based, wireframes. I haven’t signed up to use it yet - primarily because it doesn’t provide a 100% free trial - but have viewed its tutorials. Based on them, HotGloo seems interesting, but in my experience, and with an understanding of the minds of most designer personas, it may present a level of complexity that relegates it to relevancy with only a small subset of logically-minded interaction designers.
Here’s what I find interesting about HotGloo…
First, as a tool for creating interactive experiences, it is platform agnostic. In other words, it doesn’t output FXG/MXML, XAML, or HTML/CSS, which a developer then might use as the basis for final implementation. This allows HotGloo to focus on the needs of designers, instead of concerning itself with code output usable by developers. This isn’t a bad strategy because HotGloo doesn’t have a platform that it needs to necessarily support, and because developers are never be satisfied with generated code anyway; they all have their own way of writing and managing code.
Second, HotGloo provides a surprisingly deep level of logic. For example, HotGloo provides designers the ability to utilize the observer pattern. It also provides the notion of “stateful” widgets, and a set of common and useful UI elements such as dialogs, combo-boxes, etc. This is some cool and useful stuff. But as I previously mentioned, the level of logical complexity inherent in the app is appropriate for only a small sub-set of interaction designers.
Finally, I appreciate that HotGloo doesn’t clutter itself with tools to create rich visual designs. By not providing properties for deep visual design, HotGloo is able to focus its users on the wireframing phase of the greater application design and develop workflow. I love wireframing, and I love the fact that HotGloo maintains its focus on it.
If you’d like to take HotGloo for a spin, give them your credit card digits for a free 30 day trial. Otherwise, get a feel for their app via their detailed How To section.
I’ve used an iPad for over two months now. During that time I’ve used many apps across a broad range of categories, and designed and produced one. I’ve gained a fairly deep knowledge of the iPad (and iPhone) HIGs. As part of my day job, I typically have four to five conversations about products, features, and designs for the iPad, daily. In other words, I’m a power user who has in practice pushed my iPad to it’s limit, and in concept pushed ideas for interactions with my iPad to the extreme.
So, please take that into account when I say that while I agree that the iPad is a great device for “seeing” the web, it’s not a great device for deeply using it.
To clarify this statement, consider the following cases for web use:
1. Update status on Facebook
2. View photos on Facebook and Flicker
3. Read the NYTimes.com
4. Use Gmail to write a long email to mom
5. Comparison shop for a new washer/dryer
6. Research vacation rentals in Vienna
The first three cases - both incredibly common - require me to click a few buttons, and/or type in a few words. On my iPad, accomplishing these tasks via mobile Safari and the iPad keyboard is a breeze. Indeed, they are so easy, that when coupled with the iPad’s form factor, the experience of conducting them is better than on my laptop.
However, when I engage in the fourth task on my iPad, the experience of using the web begins to degrade. In this case, where I am typing a long email to mom, the iPad’s keyboard simply falls short. For me, typing more than a URL, or at most a string of 20 words, becomes unbearably arduous. For me, the lack of command keys destroys my typing workflow. I simply can’t live without the ability to very quickly copy, paste, and delete. And while this isn’t the fault of mobile safari, the experience of writing emails is a significant part of deep web usage that simply lacks on my iPad.
Finally, tasks five and six are just a complete waste of time on the iPad. For each of these cases, the ability to spawn, and then navigate across multiple new windows, is entirely necessary. On the iPad, such workflows are downright antagonizing. On the other hand, using Safari on my laptop, I’m able to open new URLs either in tabs, or in new windows, and easily navigate across them, again using command keys.
To link this all back to the title of this post - when Apple claims that the iPad is the best way to “see” the web, I don’t disagree with them. But when it comes to relatively common use cases that require typing, key commands, or the quick spawning and subsequent access of multiple browser windows - deeper web use cases - the iPad provides a poor user experience.
I’m really digging Graphic Birdwatching - a site dedicated to showcasing the amazing design work of women. Not only is the content on the site top-notch and absolutely inspiring, the organization behind the site is driven by a common cause to “connect and support female graphic designers everywhere”.
For in-depth coverage on the organization, its goals, and the women behind it, check out this interview of Ann-Kristina Simon by Eye Blog.
David Pogue has some damning things to say about Google’s App Inventor:
Truth is, Android App Inventor is only the latest in a long line of “programming for the rest of us” kits: HyperCard, Automator, Scratch and so on. Each, at its debut, was hailed as a breakthrough. Each promised the dawn of a new era. And not a single one wound up delivering the idiot-proof, drag-and-drop software-creation process they promised. It may well be that “programming for nonprogrammers” is simply an oxymoron.
I agree. That’s why I believe that the best we can do is to make “programming concepts” easier for non-programmers to understand. To put this another way, it’s my contention that - and it seems as if Pogue comes to this conclusion as well - it take a programmer to write an app of any use or quality. Non-programmers, when empowered to put programming concepts to use, can make some interesting stuff. But it takes a programmer to connect the dots and ensure that the program is top notch.
That all said - it’s great that Google has enough secure revenue to justify a product whose ultimate purpose is pedagogically philanthropic. My sincere hope is that Google’s App Inventor has a longer lifespan than Google Wave.
Sorry to post two NYTimes.com articles back to back, but they happen to both be relevant to design.
This article describes how GE’s lack of product usability coupled with poor product instructional design, and flavored with a dash of incompetence on the part of the hospital technicians, has led to numerous cases of over-irradiation. It’s sad. And in my opinion, the primary fault lies with GE.
Normally, the more radiation a CT scan uses, the better the image. But amid concerns that patients are getting more radiation than necessary, the medical community has embraced the idea of using only enough to obtain an image sufficient for diagnosis.
To do that, GE offers a feature on its CT scanner that can automatically adjust the dose according to a patient’s size and body part. It is, a GE manual says, “a technical innovation that significantly reduces radiation dose.”
At Cedars-Sinai and Glendale Adventist, technicians used the automatic feature — rather than a fixed, predetermined radiation level — for their brain perfusion scans.
But a surprise awaited them: when used with certain machine settings that govern image clarity, the automatic feature did not reduce the dose — it raised it.
When a company designs and builds a medical instrument/equipment whose function poses an inherent medical risk, that company is responsible for ensuring that the use of the instrument/equipment has been usability tested. In other words, the company should run end-users of the instrument/equipent thought usability studies, in the context of work, in order to ensure that the instrument/equipment is indeed usable, and to evidence areas where the instrument/equipment might cause it’s end-users to error.
I wouldn’t be surprised if GE had neglected to test their gear before unleashing into the hands of ill-trained technicians, who then nuked the brains of unsuspecting and frantic stroke victims.
This kind of thing roils me. It’s like the combination of a Don Norman debate, and a Norman Bate’s moment.
This NYTimes.com article on the foundation of Italy’s economic woes. Many of them stem from the effects of globalization on the practice of bespoke manufacturing. The article shine a light on the fact that in this day and age, even the highest level of luxury and quality are trumped by efficiency.
This quote shines:
In the eternal contest between the meticulously honed and the nationally franchised, Italy knows where it stands. As a matter of profit and loss, it doesn’t make sense to store wool in a spa and let it convalesce for six months, but the methods of Luciano Barbera were never destined for a get-rich-quick guide to manufacturing. His business will make sense only to customers, and for them, quality has a logic of its own.
Ethan Eismann is an Experience Design Manager at Adobe Systems. This blog is about Flash, Flex, AIR, Flash Catalyst, RIAs, design management, and design writ large.
