Im working on my next tutorial which will appear soon, but for now i’d thought I’d share a few thoughts and see what you all think. Ok once again there seems to be a big topic on everybody’s minds and this time it’s the Human Interface Guidelines. Scott has some insightful commentary on this. I believe early on when I first started learning Cocoa, I took a look at this document. As far as I can remember people have been chastising Apple for not following it. Right away some things didn’t make sense like the specific types of apps that brushed metal was supposed to be used on, etc. Personally I don’t think I’ll read the HIG again anytime soon. Why? Because if you really think out a solution and take into account the users perspective while following what should be common sense, you don’t really need the HIG. Remember when your designing an app, your designing a solution to a problem so you should try and make it simple. Right away when someone looks at your app it should be very apparent what the app does and give the user a good idea of how it works. If someone has to spend a good while looking around at your app to begin to figure out these things then your solution is already too complicated, they might not be able to use everything right away but they should get the gist of it. A big pitfall of some developers is throwing too much at your user. A good example is maybe your developing a simple image edit app. If your user is typically a amateur photographer and just wants to maybe crop and do some adjustments to the image quality, do you think they’ll really need a metadata inspector window constantly showing and taking screen real estate? Of course you can suffer from the exact opposite of this and throw too little at your user to the point where they are constantly opening up things. For example Im not pro photographer but, I presume Apple did some research and decided it was a good idea for pro photographers to have access to a bunch of panels for color correction, image adjustment, metadata, etc in Aperture. Another thing I tell myself when designing UI’s is “Don’t be like the Windows developers!” Now this is not to say that all windows UI designers are crap, it’s just there are so many Windows programs I look at and go “why did they do this?” and “wtf is the purpose of this?” and so on. One of my friends who goes to Iowa State University told me in one of his classes they covered this new Windows framework (who’s name escapes me at the moment, I think it’s the windows presentation framework or something like that) that can make all these magical UI effects. He was in a group and they were designing a UI which I believe was a login window or something like that. Should be simple right? Well they wanted to have a paper clip dance around the window and have other visuals. My friend (evidently being the only sane person in the group) didn’t like this idea. Around this time the teacher came by, now you think anybody who was sane would chastise the group for putting up such a dumb idea that wastes so much resources on something so simple. But the teacher thought it was a good idea. Now I should issue a disclaimer that not all teachers at ISU are like this thankfully. So in conclusion here are the basic points
- Identify what the problem is your solving
- Define everything you require to solve the problem
- Don’t throw everything at once to the user, define the common tasks your users will be performing on the app and design around that (but allow them to get to the more complicated parts easily if they need to get to them)
- Design everything around the basic purpose of your app
- Go for the simplest solution first (you’ll get more done faster and your users will love your app because they can get things done faster) even if it takes a little bit of trial and error to find what that is “the simplest solution is usually the most elusive” - Jonathan Ive (may not be exact quote, I can’t find my iMac movie)
- Don’t waste resources on things you really don’t need in your app.
3 comments:
Colin, I very much enjoy your articles, however it irks me (and others no doubt) that you don't understand the difference between "your" and "you're". Please, please, please take the time to proofread your posts and learn this important grammatical distinction - your blog will be a lot more credible and professional as a result.
Sorry about that. I realized that I need to go through and edit these articles much more carefully and I am starting to try and filter these articles better. I promise things will get better.
There was a great book on UI etc. "The Elements of friendly software design" by Paul Heckel. It has been out of print for 15 years at least, but what he summarised there is still valid and will be true as long as we are humans and computers are around:
1. Know your subject
2. Know you audience.
3. Maintain the user's interest.
4. Communicate visually.
5. Lever the user's knowledge.
6. Speak the user's language.
7. Communicate with metaphors.
8. Focus on user's attention.
9 Anticipate problems in the user's perception.
10. If you can't communicate it, don't do it.
11. Reduce the user's defensiveness.
12. Give the user control.
13. Support the problem-solving process.
14. Avoid frustrating the user.
15. Help the user cope.
16. Respond to user's actions.
17. Don't let the user focus on mechanics.
18. Help the user to crystallize his thoughts.
19. Involve the user.
20. Communicate in specifics, not generalities.
21. Orient the user in the world.
22. Structure the user's interface.
23. Make your product reliable.
24. Serve both the novice and the experienced user.
25. Develop and maintain user rapport.
26. Consider the first impression.
27. Build a model in the user's mind.
28. Make your design simple...
29. But not too simple.
30. You need vision.
Post a Comment