Re: I have a problem
- From: Matthias Clasen <matthias clasen gmail com>
- To: Benjamin Otte <otte gnome org>
- Cc: usability gnome org, gtk-devel-list gnome org
- Subject: Re: I have a problem
- Date: Tue, 31 May 2011 09:56:59 -0400
On Mon, May 30, 2011 at 11:02 AM, Benjamin Otte <otte gnome org> wrote:
> That said, let me get into how I think this whole interaction between
> designers and developers should work inside GTK. I envision the design
> process for new widgets or interactions to go something like this:
> 1) GNOME designers come up with an idea
> 2) GTK developers implement the idea
> 3) application developers and designers (both inside GNOME and ISVs)
> use it in their applications
> There's maybe a "1.5) GNOME ships a prototype application to test
> things" in between.
> (Of course, this is not a top-down approach. Ideally the application
> developers provide feedback about how they think GTK should work to
> the GTK developers and the GTK developers
I think this is a bit backwards.
Your afterthought of 1.5 is very essential, and is exactly what is
happening in the contacts app now. We cannot go straight from design
to toolkit, having a prototype and using it in a number of apps for a
while is important for weeding out the good ideas from the bad.
(Designers are only humans too, after all, and come up with plenty of
ideas that don't work out, just like the rest of us). Going from
design/mockup straight into the toolkit is a recipe for the kind of
issues we've had with e.g. the switch.
And I don't think "GTK+ developers implement the idea" is scalable at
all. If creating new widgets is too hard for average application
developers, we need to make it easier. Of course, there is a big
difference between a prototype that matches the mockup and a widget
that meets the quality standards of GTK+, and this is where I see GTK+
developers come in: reviewing the prototype, making sure it matches
the API conventions of GTK+ and is properly bindable, flippable,
accessible, themable, etc...
One thing that seems clear is that we can't have the toolkit become
just a collection of UI paradigms of the past. It needs to keep
evolving.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]