Le samedi 28 mai 2011 à 19:06 -0400, Paul Davis a écrit : > this is a cart vs. horse problem. > > i think you're absolutely correct that functionally, this is identical > to a notebook. but there's function, and there's design. > > this design calls for an alignment of UI elements that isn't possible > to accomplish with the current widget set (how would you get that More > combo/menubar/button into the tab list?). is the design wrong to > attempt that? if its wrong, why? if its right, how to accomodate the > design if the current widgets don't. > > in most of what you've written here, you seem to put the widget set > first, and you seem to be suggesting that UI design should work with > the constraints that flow from the widget set, because that will > result in good UIs. the other position is that good UI design should > come first, and then the widget set and specific widgets need to be > modified to accomodate the design(s). Of course design should decide how widgets behave, and which widgets exist, and not the reverse. But I also believe the thought that "damn, it doesn't exist in our toolkit, is it really worth adding a new widget?" is a fundamentally sane reaction, because it ensures we keep a our UI patterns as consistent as possible. Adding a widget always comes with the risk that people might misuse it all over the desktop: that shouldn't be done without good reasons!
> in this case, that would imply a rather complicated change (or maybe > its simple) to the notebook widget. so there are 4 choices: > > * possibly complex and far-reaching changes to existing widgets - > no new widgets, but the design can be supported > * new widgets - creates ambiguity in the widget set, but the design > can be supported > * modify the design so that it can implemented with existing widgets > * reject design because the widget set can't support it > > my feeling on this is that it depends a lot on the quality of the > design and the resistance on the part of the designer to modifying it > so that the design can be implemented using the existing widget set. Indeed, if a mockup can't be achieved with what GTK currently offers, we must first ensure the designer was aware of it, and check with him whether he thinks a new widget should be added, or an existing widget should be modified. I guess sometimes, when designing a UI, you imagine things that can't be implemented exactly how they are drawn, but wouldn't mind adapting them a little. In the case of the notebook-like ( Notes | Edit ) buttons, IMHO the design issue is that introducing buttons that behave like notebooks but don't look like them can make the UI less predictable. If current notebooks aren't good, maybe they also could be visually changed so that all programs benefit from it. (Technically though, implementing these buttons so that they look like the mockup isn't hard: create a notebook with hidden tabs, and switch pages when clicking on these two buttons.) To sum up, I don't think it really is Benjamin's "problem", but more of a design question. Designers who draw mockups requiring a change in the toolkit should simply be asked for confirmation, and be part of the coding/review process if changes are implemented. Regards _______________________________________________ usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
