iPad Application Design → permalink
The iPad is not just “a big iPhone.”
Technologically speaking, it is very similar. The way you interact with it, however, is different. The applications don’t feel like mobile apps. They are robust, full featured and intuitive.
Make Your User Interface Intuitive By Encouraging Experimentation
The design industry is plagued with the misconception that product manuals are evil. These designers believe that your product should be intuitive enough to use without a manual.
While there is a certain truth to this, there are many viable reasons for product manuals to be used. There needs to be a certain level of competency that can be achieved without the manual.
A manual is never an excuse for poor design.
Your product should be designed to encourage people to experiment. That’s how people learn how your product works, and it is also how they discover advanced functionality.
Dear HTML, CSS, and JavaScript: Flash is more flexible → permalink
Nate Klaiber is spot on. I had this same conversation with Jason at ThunderTech a while ago. As much of a proponent I am for web standards, it’s not the technology that’s to blame.
One of the key issues in this space is the lack of a good IDE for developing media rich websites without Flash. That’s what makes Flash so attractive to designers, the ease of creating these multimedia based websites. Dreamweaver doesn’t come close.
Over the last few years we’ve seen major Flash studios, like Fantasy-Interactive, make the move to web standards.
Even though HTML/CSS/JS is far more semantic, more accessible and more flexible, we don’t possess the tools to build a really top-notch IDE.
The bigger question is… should we bother building such an IDE? I’m not so sure. It’s the transparency of the markup that makes HTML/CSS/JS so accessible. Abstracting that markup in an IDE would probably bring along the same issue’s that plagues Flash today.
“I agree” checkbox syndrome
The “I agree” checkbox has become an interface standard on registration forms. “I agree to the terms and conditions.” While it’s purpose is generally understood by the consumer, it is a key source of frustration for people registering for accounts.
eBay's Registration, as an example
Why it’s overlooked:
- Checkboxes are small, particularly ones which aren’t grouped in a fieldset;
- They are typically at the bottom of a form – Out of sight out of mind;
- They are placed in close proximity to a larger button which takes the focus.
Memory Eternal, Pauline Nelson
Late last week, our dear friend Pauline Nelson passed away after a battle with cancer. Pauline was not just my client, she was my friend and a mentor to me for nearly 10 years.
Back in 2001, while a music major in college, I started doing some freelance work on the web. Pauline, an independent jeweler in the Los Angeles area, became my first client. Not only was she my first client, but she stayed with me for 9 more years until her passing last week.
How to analyze a usability study
Most of the value you gain from a usability testing session comes from the analysis after the session is complete. I have been involved in a few sessions recently where no formal analysis has been conducted. I believe this is a mistake.
Traditionally, the analysis portion of a usability session takes quite a long time. The end results is usually what I call a “Dead Document.”
“Dead Documents” are reports that have value, but negatively impact productivity. This is usually because it takes too long to create the document, or there isn’t enough time to consume it.
I have developed a quick and dirty system for analyzing the data. It requires only a few hours to create and only a few minutes to consume.
Technical Stories in Agile Software Development
I just read this interesting post on technical stories by Jack Milunsky. In the article he addresses the question of “Should technical stories appear on the product backlog for a Scrum project?” For billable client projects, a related question exists of “Are technical stores billable to the client?”
The answer to both of these questions is yes. Technical stories represent efforts necessary to improve the infrastructure of a system. While they do not add value to the system through the addition of new or refined functionality, they do directly add value to the system in other ways.
Who’s Attending Codemash 2010?
The Codemash Conference is not just about great content, but it’s about great people. Last year I met some great new friends and even did a fair amount of business with them.
I’ll be podcasting, blogging and networking all week. If you are around, make sure to hunt me down.
Are you attending?
If you are attending, post in the comments so we can find each other this week.
Design Last Design
Agility comes from your ability to rapidly gather feedback about the software you are building, and to react quickly. This is especially true during your initial build phase.
Interface First Design
I’ve always been a supporter of Interface First Design. To your customer, the interface is the product. The customers needs are all defined by the way they interact with your product. This is why we have always encouraged designing the interface before writing any code. This keeps developers from over-engineering features and ensures the customer gets what they expect from you.
However, I often find myself over-designing. I waste a lot of time designing things that will be deleted in future iterations.
Introducing Design Last Design (DLD)
Recently, I’ve been experimenting with what I call “Design Last Design.” Essentially this means we sketch out a user interface in the beginning, as we always have, but we don’t pretty it up. We build the whole application in greyscale with standard fonts, and boxes, but nothing pretty. Near the end of the project, we wrap it all up with graphic design. The interactions are all still designed up front, but the graphic design is laid on at the end. We don’t waste time on graphical details which are not yet important.
Search
Popular Posts
- 50 Tips To A User Friendly Website
- My Favorite Pomodoro Timers
- How to build a Gantt Chart with the Google Charts API
- Why Flash is Mostly Bad
- Sharing the Grid
- 10 Tips to Better Google Wave Conversations
- The difference between User Research and Usability Testing?
- How to Label Submit Buttons
- Our New Development Process
- Paper Prototyping vs. Balsamiq Mockups
Latest Comments
- Nate Klaiber → “ The design industry is plagued with the misconception that product manuals are evil. These designers believe that your product should be intuitive enough to use without a manual. While there is a certain truth to this, there are many viable reasons for product manuals to be used. There needs to be a certain…”
- Joe Fiorini → “ The design industry is plagued with the misconception that product manuals are evil. These designers believe that your product should be intuitive enough to use without a manual. While there is a certain truth to this, there are many viable reasons for product manuals to be used. There needs to be a certain…”
- Roger F Carver → “ The Google Charts API is an excellent way to add high quality charting to your web application. We first started working with the API as part of the Simpli5 dashboard development, and were quite impressed with its functionality and ease of use. Wrapper classes were developed and added to our Sandstone Application Framework to make…”
- Nate Klaiber → “ The “I agree” checkbox has become an interface standard on registration forms. “I agree to the terms and conditions.” While it’s purpose is generally understood by the consumer, it is a key source of frustration for people registering for accounts. eBay's Registration, as an example Why it’s overlooked: Checkboxes are small, particularly ones which aren’t grouped…”
- Josh Walsh → “ Most of the value you gain from a usability testing session comes from the analysis after the session is complete. I have been involved in a few sessions recently where no formal analysis has been conducted. I believe this is a mistake. Traditionally, the analysis portion of a usability session takes quite a long…”