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.
-
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.
While I agree with your premise in principle, I disagree in practice. Most non-trivial applications are the work of teams. Often, time is simply not allocated to make nice GUI's and/or there are multiple people working on said GUI at the same time, which can result in a sort of "tug of war" as different people use their own idea of what is good looking. This is really the failing of the project manager, and not the programmers themselves. Left to their own devices, a programmer will probably create something pleasing, however, they will also take an eternity to do it. Part of a project managers job is to say "Yes, that's done.. now do something else". Also keep in mind that many programmers have the GUI thrust upon them, and they have no choice in how it is designed or laid out. Finally, the GUI tends to be at the bottom of the list of priorities, since it's "just cosmetic". That means that when deadlines loom and the project needs to be shoved out the door (and what projects aren't shoved out the door before we'd rather them be) then low priority tasks sometimes don't get done.
-
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.
GUI is over-rated( From a Programmer ) Functionality is over-rated ( From an Artist) Thus what is really needed is a HYBRID man, in one hand he has a paint platter in the other hand he has a traditional Hex-Calculator, Skins are an example that such a creature does not exist and can not be bred or created. Regardz Colin
-
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.
You're assuming something that is totally false, but which is assumed by many people (including managers) - that UI design is easy. I mean, you just put controls in a dialog, right? Good UI design is a skill that must be learned, but unfortunately, as Erik said above, many people view UI as unimportant; something to be given to either the new guy or whoever has a little spare time. (Heck, I once had a manager tell me after a long project that my work "was only UI" as if it didn't matter in the end.) IMHO the layout of one's code (spacing, comments, variable/function naming) is much more indicative of a programmer's competence. 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... you have to wonder how the programmer thinks. I'd wager that that UI was written by the same person that wrote the underlying code, and he made the UI match the underlying implementation. It's clear to him, so it's fine, right? Whoever made that UI is just bad at UI and didn't put any thought into it. It doesn't mean his code is bad, nor that he couldn't make better UIs in the future. A good UI designer has learned how to think like a user and design the UI for the user, not "whatever works," and not something for himself. This is something that managers think comes naturally, but that is far from the reality. --Mike-- http://home.inreach.com/mdunn/ The Signature, back by popular demand: Buffy. Pajamas.
-
You're assuming something that is totally false, but which is assumed by many people (including managers) - that UI design is easy. I mean, you just put controls in a dialog, right? Good UI design is a skill that must be learned, but unfortunately, as Erik said above, many people view UI as unimportant; something to be given to either the new guy or whoever has a little spare time. (Heck, I once had a manager tell me after a long project that my work "was only UI" as if it didn't matter in the end.) IMHO the layout of one's code (spacing, comments, variable/function naming) is much more indicative of a programmer's competence. 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... you have to wonder how the programmer thinks. I'd wager that that UI was written by the same person that wrote the underlying code, and he made the UI match the underlying implementation. It's clear to him, so it's fine, right? Whoever made that UI is just bad at UI and didn't put any thought into it. It doesn't mean his code is bad, nor that he couldn't make better UIs in the future. A good UI designer has learned how to think like a user and design the UI for the user, not "whatever works," and not something for himself. This is something that managers think comes naturally, but that is far from the reality. --Mike-- http://home.inreach.com/mdunn/ The Signature, back by popular demand: Buffy. Pajamas.
> You're assuming something that is totally false, but which is assumed > by many people (including managers) - that UI design is easy. I don't read this from Jim's text. He assumes that UI design is as easy or as difficult as programming in general. UI design and programming require, to a large extend, the same skill set, of which "being able to organise" is one of the most important. For both disciplines one must understand and analyse the user's problem and, unless the problem at hand is trivial, design a proper modular solution. One can make use of best practices, but no solid "mathematical" theory how to do this exists. The UI designer / programmer has to rely on common sense and feeling for good modularity, which can come from talent and/or experience. So I fully agree with Jim: a good UI designer will be a good programmer, and vice versa. Sito Dekker
-
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!