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. John -----Original Message----- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: Monday, September 10, 2012 4:29 PM To: John Maher Cc: David Chapman; Mark Phippard; users@subversion.apache.org Subject: Re: general questions 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