Re: I have a problem

[Milan Bouchet-Valat <nalimilan club fr>]

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