On Mon, Sep 10, 2012 at 3:15 PM, John Maher <jo...@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 about
> 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 to
> 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 time.
> 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.
--
Les Mikesell
lesmikes...@gmail.com
