On Sun, May 29, 2011 at 1:06 AM, Paul Davis <[email protected]> wrote: > On Sat, May 28, 2011 at 5:01 PM, Benjamin Otte <[email protected]> wrote: > > 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. > Just as a FYI: In this particular case, GtkNotebook supports action widgets, which would solve this particular problem. See http://blogs.gnome.org/johannes/2009/11/09/gtknotebook-action-widgets/ for an intro from when they were added.
> 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). > First of all, I would expect that I am biased towards the widget set, that comes from being one of the developers. ;) 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 When doing this thing though, we have to keep in mind the target audience for GTK. And we have to keep in mind UI design principles. Because the API of GTK is a user interface. And just like end users for GNOME, the "end users" of GTK - the developers writing applications - will look at what we give them and think about how to best use it to achieve their goals. Of course, they will not read the documentation, but infer something and then do what works. An example for this is the notification area. It was introduced in 2002/2003[1][2] and led a happy life until in 2005, when GTK introduced GtkStatusIcon. Suddenly, popping up an icon in the notification area became a trivial thing to do. Everybody saw it and thought "Hey, my application could make use of that, too." and off they went. And now notification areas look like system trays on windows and are definitely not the thing we envisioned them to be. In fact, it goes so far that doing notifications in the shell is basically impossible. And I think a large part of the reason for the misuse is that we made it too freaking easy to use. Had it been a separate library, people would have used it a lot less. Just imagine if notification bubbles were as easy as a simple call to gtk_notification_show()... And of course, every time we support a new way to do things, there's a nontrivial cost involved in it. Apart from having to support it for at least this stable series, people will make use of it, find issues with it and demand new features.That means someone needs to take care of bugfixing, enhancements and so on. And when one day we decide to get rid of it, people will complain that their application is designed around this UI element we provided to them and expect us to have an easy upgrade path for them. Another thing that is quite important for me is to get people to do the right thing by default[4]. So when some non-GNOME developer decides to write an application with GTK, I want him to accidentally do the right thing. For example, if we decide applications should use Chrome-like overlays for status information it's probably a bad idea that we have a GtkStatusBar[5] aptly named for it, but doing the wrong thing. Same thing for toggles: Can we make it possible that developers decide between switch, checkboxes, radio buttons and toggle buttons correctly? Without reading any docs? Fwiw, getting this right not only helps make developers happy, it also helps designers - both because the apps are beautiful by default and because you have to file less UI bugs. ;) Benjamin 1: http://library.gnome.org/misc/release-notes/2.2/index.html 2: http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.1.html 3: http://developer.gnome.org/gtk/stable/GtkStatusIcon.html 4: http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html 5: http://developer.gnome.org/gtk/stable/GtkStatusbar.html _______________________________________________ usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
