Tkinter or wxpython?

Chris Mellon arkanes at gmail.com
Tue Aug 7 09:42:43 EDT 2007


On 06 Aug 2007 15:25:51 -0700, Paul Rubin
<"http://phr.cx"@nospam.invalid> wrote:
> "Chris Mellon" <arkanes at gmail.com> writes:
> > You repeatedly have used the word "slickness" as a pejorative. I find
> > that offensive and it's insulting to users. When I write applications,
> > I want the interface to be as smooth and trouble free as possible,
>
> It's a perjorative when it's done for its own sake and doesn't really
> help the user.  This happens a lot.  When it helps the user, as it
> sometimes does, then it's not perjorative.
>

To me, "slick" means well lubricated and smooth. It means that there
are no rough spots in your interaction. I use the term "flash" for
cosmetic features.

> > As a matter of time spent in development, I do not find that
> > non-trivial UIs are significantly easier to develop using web
> > interfaces.
>
> That's possibly true, but a lot of the time, trivial interfaces are
> enough.  Look at Google search, one of the most complex apps ever
> built (tens or hundreds of MLOC, massive distributed crawler
> infrastructure, 100's of PhD's figuring out the algorithms, etc.) but
> its interface is simple HTML that you would probably call trivial.  It
> is quite possibly the most popular application in the world.
>

When you start talking about trivializing the interface, what you're
actually talking about is trivializing the *process*. The UI is just a
mechanism for interaction. If you have complex interactions, then you
need complex UI (or your users have to do a lot of manual steps).

Search is a good example of trivial interaction. It's not really the
common case, though - in a regular web browser there's a half dozen
minimal points of interaction, and some of them are fairly
complicated. In terms of man-hours spent, raw data entry is one of the
largest cases of human-computer interaction and it's a significantly
more complex interface than search.

As you point out, the complexity of the interaction is only loosely
coupled to the complexity of the application itself, and the art of
designing simple interactions with complex systems is one of the
hallmarks of good design. Apple is generally quite good at this. Note
even so that simple interactions can have or require rather
complicated UI metaphors. Drag and drop is a very visceral, intuitive
interface (it's the second thing my 4 year old figured out how to do,
button clicking was the first) but it's quite complicated to
implement.

I rather suspect that Google has rather more complicated internal
administrative and reporting interfaces for the search engine, too.

> > As a matter of respect for the user, I'm not going to tell them to use
> > a trivial UI if a non-trivial one will save them time, learning
> > effort, or frustration. In order to make this decision, I like to work
> > with the people actually using it and watch them at work. To see what
> > kind of extra steps they have to take and where I can save them time
> > or inaccuracy or frustration.
>
> Right.  Obviously this has to be decided according to the specific
> needs of the application.  A lot of times, trivial interfaces are
> easier to learn than nontrivial ones, precisely because they are
> trivial so there is less to learn.  Again look at Google search for an
> example.
>
> Also, at least for in-house applications, while the user's time counts
> (since their time costs your customer money), your development time
> and deployment effort also costs money that comes from exactly the
> same place, so you have to take into consideration the number of
> users, amount of time they will spend using the program, just how much
> of that time (if any) a fancier interface will save, etc.

Business constraints are always there in software development. You
don't get enough testing, you don't have access to representative test
data, you don't have direct user feedback. And of course the guy
signing the checks, who often isn't the guy using the application, may
decide that an hour of your time isn't worth 100 hours aggravation
from his minimum wage data entry folks. But *I* care about that 100
hours and to the greatest extent possible within my ability and
contract, I will minimize that burden on them.



More information about the Python-list mailing list