Interesting discussion. It appears you have not had the chance to work
with a good wrapper, or maybe you shun guis or something because there
appears to be a strong bias to your statements. I have been a
programmer AND user on both sides, gui and command line, so I am not
making things up.
> I'm not saying GUIs don't work. Just that they are generally a subset
> of what can be done with commands.
This is simply not true. Expose every function and every parameter and
there is nothing the gui can not do. Add some automation, and the gui
can actually do more.
> You are making some assumptions about scale and locality here. I have
> most of the world at my fingertips in the form of URLs.
Of course I am. I must make some assumptions or there is nothing to
talk about. Don't forget a gui can have a box where a URL is entered so
it can do everything you can by just typing in stuff plus anything else
that gets added.
> OK, but if I regularly work with 44 repositories, I'm likely to have
> their URLs in a file where a script can extract them a lot faster than
> you can navigate the world in a picklist.
Now you're making assumptions, that's OK though. Makes for a good
discussion. And you are right. Nothing works best 100% of the time.
Now think of the reverse of that. What if you wish to do something to
44 repositories once? Whats better typing them all in or clicking on
them. You can type, I'll click.
> Let's assume the list of choices won't fit on a screen...
See above reply.
> But it can only be a good design after you already now what I'm going
> to do. Until then you can only offer the bazillion choices.
Again, not true. With experience comes wisdom. Although you can never
predict a user 100% of the time, you can learn to be spot on 50% (or
better) of the time. And you seem to be forgetting a gui can do
anything text can do by offering a textbox. There's a bazillion right
there. You also have a bazillion at the command line. I think what you
are picturing is nothing like what I am planning. lol. At least I
would never use the same words to describe it as you do.
From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
Sent: Monday, September 10, 2012 4:29 PM
To: John Maher
Cc: David Chapman; Mark Phippard; users_at_subversion.apache.org
Subject: Re: general questions
On Mon, Sep 10, 2012 at 3:15 PM, John Maher <JohnM_at_rotair.com> wrote:
> I don't 100% agree. I've designed lots of guis. And there were times
> users discovered a feature I never intended. And I'm not talking
> a bug called a feature. While true that the programmer has a lot to
> think about (fortunately I am one), the gui can be designed in such a
> way to empower the user.
I'm not saying GUIs don't work. Just that they are generally a subset
of what can be done with commands.
> Simply presenting the choices in a list will
> speed use by avoiding typing in long paths and the occasional type.
You are making some assumptions about scale and locality here. I have
most of the world at my fingertips in the form of URLs.
> Having a multi-selectable list allows any command ease of application
> many targets with a loop you spoke of. I never have to think of every
> possibility the user can enter, just every possibility of a command I
> will execute. They are not the same.
OK, but if I regularly work with 44 repositories, I'm likely to have
their URLs in a file where a script can extract them a lot faster than
you can navigate the world in a picklist.
> You are right where a script is more suitable for a sequence on many
> things. My gui will never be able to compete with that. On a single
> operation on many things, if the gui can do it, it will win every
> I can out-click a very fast typer, probably not the fastest.
Let's assume the list of choices won't fit on a screen...
> And if it requires a bazillion mouse clicks, it is a poor design.
But it can only be a good design after you already now what I'm going
to do. Until then you can only offer the bazillion choices.
Received on 2012-09-11 14:24:23 CEST