> Hi all, > > I did a complete redesign of the dialog. > > teaser: > > "How does the interaction architect that designs the dialog for > a certain printer model stay in control of good UI, without > being at the mercy of an algorithm or of the developer? > Here is how it works:" > > read all about it:
I've said it before on your blog, and I'll say it again: The drop-down for printer selection WILL NOT WORK! Please take a look at real school and corporate networks. It is not at all unlikely to find machines with access to dozens and dozens computers, and not that unlikely to find computers with access to hundreds of printers. The printer list MUST be a proper list with sorting and searching capabilities, or it is will be a huge pain in the ass to use for anyone except the home and small office people. The current GTK+ print dialog gets this wrong, too, but at least it isn't so bad as to use a drop-down, a UI element that behaves abysmally when there are too many choices. The tags that look like links but aren't are still funny looking, too. There has to be a better way to do that which doesn't trample established UI expectations. The example preview widget is useless in so many cases. Anyone doing booklet printing or many other kinds of professional publishing drafting needs to be able to see side-by-side pages. Now, that's my comments and the minor things wrong with the design. There's more to it than that, though. The whole approach is just wrong. The idea of letting the printer manufacturers decide _anything_ about the UI is just terrifying. Look at the common printer drivers around. There is a recent story up about a printer driver written by some retard who didn't understand the Linux/UNIX security model so just made everything run as root. Those are the kinds of developers that printer manufacturers hire. We don't need those people deciding what tags and option sets to stuff into the UI, and we ESPECIALLY don't need a printer dialog that makes those horrible choices the sole option for configuring printing of a document. Instead of just stuffing a bunch of tags into the UI, why not come up with an actual user-study-based idea of what 90% of users need to do, come up with a solid (and tested) UI for them, and then add in an easy way to access the extra tags/options for users that need the extra printer control? Let some actual UI designers figure out how to deal with the WHOLE printing config process, and not just come up with a framework for UI that the printer manufacturers stuff with arbitrary crap? I mean, two different printers could have the exact same option under two quite differently named tags. You go from requiring that a user learn on printer dialog to the user requiring to learn a printer dialog for each printer he uses. I've read the design process for the dialog design, and I know that the project is based on the promise that manufacturers will be working on good design and not using tags as pure marketing vehicles and such, but let's be honest - that's NOT how things have ever worked out in the past with similar agreements, and it's not how things will work out in the future. Hardware manufacturers get specs and software designs wrong constantly, and they rarely bother fixing those mistakes, even in newer models. The printing dialog must have a solid and complete design from the start that includes all common features and settings, and only rely on printer manufacturers for the hardware-specific stuff. -- Sean Middleditch <[EMAIL PROTECTED]> _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
