Radical notion: UI design and programmer competence
-
Here's an idea that will surely piss a few people off: I hold that the ability to design a decent, basic UI is a fundamental indicator of one's skill as a programmer in general. Why? Because a user interface is all about communication: exposing a program's features in a logical, usable fashion. It is exactly analogous to what is required when designing the interface for a class, DLL, etc: you want to expose the object's capabilities in such a way that client programmers can quickly and easily see what the class's capabilities are, and how to exploit them. A lot of programmers forget that source code is really a communications medium - and the primary target of the communication is another programmer, rather than the compiler. When you look at some of the real dismal failures in UI design - I'm looking at the Advanced Fax Settings dialog for Aptiva Communications Center, at http://www.iarchitect.com/visual.htm - you have to wonder how the programmer thinks. Is his/her code as messy and unclear as this dialog is? I ask, how could it not be? Error messages are another indicator. Frequently error messages contain the wrong information, or provide information that is useless to the user, or are simply incomprehensible. Perhaps this inicates that the programmer is simply lazy (this will show up in code); does not understand the purpose of the error message (again, this inability will reflect itself in code), or does not know how to communicate an idea (ditto). This is not to say that we all have to be user interface experts, anymore than it means that we all have to become device driver experts. There is certainly room for specialization in this business. But if a person can't lay out a simple, meaningful dialog box, or write a decent error message, I have to wonder about his/her ability to write comprehensible code that does the job it is supposed to do. OK, you have the coconut.
As someone who did a masters thesis on UI design and has spent 10+ years trying to get it right in the real world, I have very strong opinions on UI. UI is the hardest kind of programming you will ever do. Designing a UI for a complex app that is going to be used by many people to meet many different needs is harder than hell to get right. You are caught in a no-win situation, damned if you do, damned if you don't. I feel VERY strongly that to do it correctly each project MUST have two people dedicated to the UI. One is a person, not necessarily a programmer, preferrably a good support person, intimately familiar with the customer base, knows their needs, knows how they want to interact with the app, etc. The 2nd would be a programmer given TOTAL responsibility for the UI. That is, he/she would have the authority and responsibility to change any part of the UI produced by any other programmer that did not conform to a standard look and feel. These two people would work together, meeting regularly thoughout the developement process, dedicated to getting the UI "right". I also feel that having a programmer "design" the interface is like having a carpenter or a plumber design your house. Just because you know how to use the tools does not mean you know how a family wants use their living space. Stan Shannon "If the wheel had never been reinvented, our cars would be rolling around on logs."
-
As someone who did a masters thesis on UI design and has spent 10+ years trying to get it right in the real world, I have very strong opinions on UI. UI is the hardest kind of programming you will ever do. Designing a UI for a complex app that is going to be used by many people to meet many different needs is harder than hell to get right. You are caught in a no-win situation, damned if you do, damned if you don't. I feel VERY strongly that to do it correctly each project MUST have two people dedicated to the UI. One is a person, not necessarily a programmer, preferrably a good support person, intimately familiar with the customer base, knows their needs, knows how they want to interact with the app, etc. The 2nd would be a programmer given TOTAL responsibility for the UI. That is, he/she would have the authority and responsibility to change any part of the UI produced by any other programmer that did not conform to a standard look and feel. These two people would work together, meeting regularly thoughout the developement process, dedicated to getting the UI "right". I also feel that having a programmer "design" the interface is like having a carpenter or a plumber design your house. Just because you know how to use the tools does not mean you know how a family wants use their living space. Stan Shannon "If the wheel had never been reinvented, our cars would be rolling around on logs."
but in real world most of the times, the project cannot afford these two extra guys (if not for a large project atleast for a medium sized project).
-
Here's an idea that will surely piss a few people off: I hold that the ability to design a decent, basic UI is a fundamental indicator of one's skill as a programmer in general. Why? Because a user interface is all about communication: exposing a program's features in a logical, usable fashion. It is exactly analogous to what is required when designing the interface for a class, DLL, etc: you want to expose the object's capabilities in such a way that client programmers can quickly and easily see what the class's capabilities are, and how to exploit them. A lot of programmers forget that source code is really a communications medium - and the primary target of the communication is another programmer, rather than the compiler. When you look at some of the real dismal failures in UI design - I'm looking at the Advanced Fax Settings dialog for Aptiva Communications Center, at http://www.iarchitect.com/visual.htm - you have to wonder how the programmer thinks. Is his/her code as messy and unclear as this dialog is? I ask, how could it not be? Error messages are another indicator. Frequently error messages contain the wrong information, or provide information that is useless to the user, or are simply incomprehensible. Perhaps this inicates that the programmer is simply lazy (this will show up in code); does not understand the purpose of the error message (again, this inability will reflect itself in code), or does not know how to communicate an idea (ditto). This is not to say that we all have to be user interface experts, anymore than it means that we all have to become device driver experts. There is certainly room for specialization in this business. But if a person can't lay out a simple, meaningful dialog box, or write a decent error message, I have to wonder about his/her ability to write comprehensible code that does the job it is supposed to do. OK, you have the coconut.
Out of all the books a programmer will need read to become proficient he/she can afford to pick up at least one design book. It will not make them an expert but it will make a difference.
-
Out of all the books a programmer will need read to become proficient he/she can afford to pick up at least one design book. It will not make them an expert but it will make a difference.
hi Can you suggest me some books particularly on UI design. Thanks Cheers Kannan
-
hi Can you suggest me some books particularly on UI design. Thanks Cheers Kannan
I suggest you go the the Information Architects website - www.iarchitect.com, and check out their Hall of Fame and Hall of Shame for UI design. There is a lot of practical UI info here. They also have a list of recommended books.
-
Here's an idea that will surely piss a few people off: I hold that the ability to design a decent, basic UI is a fundamental indicator of one's skill as a programmer in general. Why? Because a user interface is all about communication: exposing a program's features in a logical, usable fashion. It is exactly analogous to what is required when designing the interface for a class, DLL, etc: you want to expose the object's capabilities in such a way that client programmers can quickly and easily see what the class's capabilities are, and how to exploit them. A lot of programmers forget that source code is really a communications medium - and the primary target of the communication is another programmer, rather than the compiler. When you look at some of the real dismal failures in UI design - I'm looking at the Advanced Fax Settings dialog for Aptiva Communications Center, at http://www.iarchitect.com/visual.htm - you have to wonder how the programmer thinks. Is his/her code as messy and unclear as this dialog is? I ask, how could it not be? Error messages are another indicator. Frequently error messages contain the wrong information, or provide information that is useless to the user, or are simply incomprehensible. Perhaps this inicates that the programmer is simply lazy (this will show up in code); does not understand the purpose of the error message (again, this inability will reflect itself in code), or does not know how to communicate an idea (ditto). This is not to say that we all have to be user interface experts, anymore than it means that we all have to become device driver experts. There is certainly room for specialization in this business. But if a person can't lay out a simple, meaningful dialog box, or write a decent error message, I have to wonder about his/her ability to write comprehensible code that does the job it is supposed to do. OK, you have the coconut.
A few quick points... (and BTW, I found many observations earlier on this thread quite on target). I differ slightly on the premise. I think the primary purpose of source code is not communication but formulation (including implementation and presentation) of an idea. The idea of a single pair (usability expert + programmer) is right on, so long as they themselves get along well :) Two main trouble points: (i) There are equally valid options in expressing the same idea (Tree with children on LHS or Horizontal Tabs on Top). People can get driven into corners defending their own positions, when, unfortunately, both are *right* and the manager-in-charge can't either make up his mind or take a stance! The trouble only compounds if you are suggesting a third party control. "Not Invented Here!" I have known/been told of $100/hr managers and programmers (the hourly rate is just an example) debate fulltime for two weeks on whether to license a $300 outside control (one time charge, no royalties) or not--just because it would come from outside, and not any other applicable reason (such as library dependencies, bug likelihood, standards orientation etc.). (ii) Nonprogrammers (say usability experts, managers, focus-group end-users) often do not appreciate the scale of internal changes involved due to only a small change in UI. The hard limits of what is at all possible are easier to tell. The soft limits due to the comparative magnitudes of alternative proposoals are both hard to project in advance and tough to communicate. And the team can't wait doing useful work either! It's a funny situtation. And then, usability experts often see something on the latest products on MS platform and think it should be possible easily. (Example: Dockable windows as in MSDev and CSplitter of MFC.) I think discussions certainly help. UI design *is* hard because, like all other interfaces, it involves having to draw a line somewhere :) Your project today is your great-grandchildrens' "ancestor clock."
-
hi Can you suggest me some books particularly on UI design. Thanks Cheers Kannan
I agree with Jim. AskTog: Design Section is another great site I have not seen anyone recommend yet. MS has a Windows UI guidelines book available at msdn. It discusses the standard Windows interface in detail, right down to the difference between a soft and hard edge and when to use which. I am currently reading The Design of Everyday Things. It is not specificly about computer UI design but about UI design in general.
-
Here's an idea that will surely piss a few people off: I hold that the ability to design a decent, basic UI is a fundamental indicator of one's skill as a programmer in general. Why? Because a user interface is all about communication: exposing a program's features in a logical, usable fashion. It is exactly analogous to what is required when designing the interface for a class, DLL, etc: you want to expose the object's capabilities in such a way that client programmers can quickly and easily see what the class's capabilities are, and how to exploit them. A lot of programmers forget that source code is really a communications medium - and the primary target of the communication is another programmer, rather than the compiler. When you look at some of the real dismal failures in UI design - I'm looking at the Advanced Fax Settings dialog for Aptiva Communications Center, at http://www.iarchitect.com/visual.htm - you have to wonder how the programmer thinks. Is his/her code as messy and unclear as this dialog is? I ask, how could it not be? Error messages are another indicator. Frequently error messages contain the wrong information, or provide information that is useless to the user, or are simply incomprehensible. Perhaps this inicates that the programmer is simply lazy (this will show up in code); does not understand the purpose of the error message (again, this inability will reflect itself in code), or does not know how to communicate an idea (ditto). This is not to say that we all have to be user interface experts, anymore than it means that we all have to become device driver experts. There is certainly room for specialization in this business. But if a person can't lay out a simple, meaningful dialog box, or write a decent error message, I have to wonder about his/her ability to write comprehensible code that does the job it is supposed to do. OK, you have the coconut.
Because a user interface is all about communication: exposing a program's features in a logical, usable fashion. It is exactly analogous to what is required when designing the interface for a class, DLL, etc OK, so we can hope that the people that wrote STL don't do user interfaces then... Stephen Kellett
-
Here's an idea that will surely piss a few people off: I hold that the ability to design a decent, basic UI is a fundamental indicator of one's skill as a programmer in general. Why? Because a user interface is all about communication: exposing a program's features in a logical, usable fashion. It is exactly analogous to what is required when designing the interface for a class, DLL, etc: you want to expose the object's capabilities in such a way that client programmers can quickly and easily see what the class's capabilities are, and how to exploit them. A lot of programmers forget that source code is really a communications medium - and the primary target of the communication is another programmer, rather than the compiler. When you look at some of the real dismal failures in UI design - I'm looking at the Advanced Fax Settings dialog for Aptiva Communications Center, at http://www.iarchitect.com/visual.htm - you have to wonder how the programmer thinks. Is his/her code as messy and unclear as this dialog is? I ask, how could it not be? Error messages are another indicator. Frequently error messages contain the wrong information, or provide information that is useless to the user, or are simply incomprehensible. Perhaps this inicates that the programmer is simply lazy (this will show up in code); does not understand the purpose of the error message (again, this inability will reflect itself in code), or does not know how to communicate an idea (ditto). This is not to say that we all have to be user interface experts, anymore than it means that we all have to become device driver experts. There is certainly room for specialization in this business. But if a person can't lay out a simple, meaningful dialog box, or write a decent error message, I have to wonder about his/her ability to write comprehensible code that does the job it is supposed to do. OK, you have the coconut.
*MANY* times, user interface *design* is handled by managers who depend on focus groups and sales staff who have NO EARTHLY CLUE about why the Windows interface was even implemented. Programmers in big companies are USUALLY just grunts who write the code they're told to write, and free-thinking coders are ridiculed and scorned by upper management with political agendas that have NOTHING to do with the usability of the product. Of course, there are programmers like you have described, but I think most of the more experienced people would stand up and shout from the rooftops in no uncertain terms about interface ideas that suck.
-
Here's an idea that will surely piss a few people off: I hold that the ability to design a decent, basic UI is a fundamental indicator of one's skill as a programmer in general. Why? Because a user interface is all about communication: exposing a program's features in a logical, usable fashion. It is exactly analogous to what is required when designing the interface for a class, DLL, etc: you want to expose the object's capabilities in such a way that client programmers can quickly and easily see what the class's capabilities are, and how to exploit them. A lot of programmers forget that source code is really a communications medium - and the primary target of the communication is another programmer, rather than the compiler. When you look at some of the real dismal failures in UI design - I'm looking at the Advanced Fax Settings dialog for Aptiva Communications Center, at http://www.iarchitect.com/visual.htm - you have to wonder how the programmer thinks. Is his/her code as messy and unclear as this dialog is? I ask, how could it not be? Error messages are another indicator. Frequently error messages contain the wrong information, or provide information that is useless to the user, or are simply incomprehensible. Perhaps this inicates that the programmer is simply lazy (this will show up in code); does not understand the purpose of the error message (again, this inability will reflect itself in code), or does not know how to communicate an idea (ditto). This is not to say that we all have to be user interface experts, anymore than it means that we all have to become device driver experts. There is certainly room for specialization in this business. But if a person can't lay out a simple, meaningful dialog box, or write a decent error message, I have to wonder about his/her ability to write comprehensible code that does the job it is supposed to do. OK, you have the coconut.
One more thing I'd like to add - someone decides they want the program to sport a new overall look "because it looks cool", with no thought at all as to how relevant the "new look" is to the scope of the program being written. The most over-used "look" I've seen is from Outlook. It seems that EVERYONE wants their program to look like Outlook. Pfft!