chac@aratar.UUCP (Chuck Clanton) (02/24/89)
i am wondering if anyone reading this newsgroup has an interest in programmers and programming. in particular, i have been thinking about the following problem. most of the recent toolkits for bitmapped workstations seem to have the design philosophy that interactive components, widgets, should have an extremely high degree of customizability. hence, one often finds 20 to 40 parameters that can be set. the code for such widgets is extremely difficult to understand, and the interactions among those parameters is extremely difficult to document and understand. if you have programmers who are willing to build whatever widgets that the interface designers want, i wonder if this is the right design philosophy. an alternative is the "inheritance by editor" slogan-idea. that is, if a programmer has a very simple table widget that has 5 rows and 2 columns, that programmer can quickly build one that has 6 rows and 3 columns. it may take less time for the programmer to build a new widget in the new format than it would take a non-programmer to figure out how to set up all the combinations of height, width, column number, column order, number rows, number items per row, etc of the parameterizable widget. clearly this has the makings of a religious issue currently, and clearly if you do not have programmers to devote to this kind of work, you need the parameterizable widgets. however, i wonder what kind of data, or lacking data, experience people have in comparing these two paradigms. if there is empirical data, then perhaps some answers are possible. certainly, the simpler widget is more likely to be bug free, and the inherited code is much simpler. of course, the well-used settings of the parameterizable widget are likely to be bug free as well, though the lesser used ones or unusual combinations may not work as expected. further, debugging the parameterizable widget may be much more difficult. also, obviously, i have chosen an extreme case, and intermediate positions are defensible. one point made by rob pike is that he prefers to make design choices carefully, then not provide customizability but rather defend ones choices or become convinced that one is wrong and change them. this is not an unattractive view. further, many of the people building highly parameterized widgets are doing so explicitly because they do not want to make interface design decisions. but if an interface designer is available during the programming process, perhaps these decisions can profitably be made. i would be very interested in hearing what others think about this issue. especially but not exclusively if you have any data or experience that bears on it.
klee@daisy.UUCP (Ken Lee) (02/28/89)
In article <339@aratar.UUCP> chac@aratar.UUCP (Chuck Clanton) writes: >most of the recent toolkits for bitmapped workstations seem to have >the design philosophy that interactive components, widgets, should >have an extremely high degree of customizability. hence, one often >finds 20 to 40 parameters that can be set. the code for such widgets >is extremely difficult to understand, and the interactions among >those parameters is extremely difficult to document and understand. Actually, it's really not that bad. The vast majority of these parameters are the same for all "widgets" in the application, so need only be set once. Most of the time, they're set in a configuration file that can be edited after compile time, giving the end user the final say. For example, you generally want all your push buttons to have the same colors, same shape, same size, and same feedback mechanism. The colors probably also apply to most other widgets in your user interface. Just set them once and don't worry about it. On the other hand, too many choices is often an excuse for no policy. If you're designing multiple applications (or an application in a multiple application environment), you'll probably find most of these parameters fixed by your style guide. If you don't have a style guide, and care about consistency, you probably should write one. The Macintosh style guide is one reason the Macintosh user interface is so popular today. Modern user interface style specifications, such as Open Look, specify most of these parameters and have few left for the programmer and end user. Some programmers think this removes creative options from their work, but I think there are still pleanty of difficult decisions to make, such as user models and functional representations. Ken Lee -- klee@daisy.uucp Daisy Systems Corp., Interactive Graphics Tools Dept.