Re: gEDA-user: Power users us normal users, a conflict?
Hello: First of all, a aclaration for Stephan Boettcher: I'm not refering how power users to a CLI users, power users is a user that have a great knowledge of using the tools, all the tools including makefiles, bash, gEDA... I'm a CLI users and, certainly, I'm not a power user. El 08/04/11 21:16, John Doty escribió: On Apr 8, 2011, at 1:22 AM, Stephan Boettcher wrote: I do not see a conflict between GUI and make, the first ist a good way to make features of the second discoverable. Only if each individual tool is *simple*. Complex menus make features *less* discoverable. Besides, if your use case doesn't correspond *exactly* to the necessarily limited imagination > of the developer of a "feature", then that "feature" is just more fog, hiding the real "feature" > you want, or wasting your time by making it difficult to discover that the "feature" > is missing. In other words, GUI scales just as badly as a discovery tool as it does as an automation tool. > Therefore, adding capability should either involve: 1. More independent tools in the kit, or 2. *Less* GUI. Or a better GUI. Really, I'm thinking that we are talking the same but in different approaches: I'm talking about don't scare new users with a *seems too dificult and too ugly CLI tool* and you are talking that do less GUI because GUI block the users in his way to convert in power-users. Both are talking about the users, and the how work be done. John wants to make sure that the make-power is not compromised for the sake of the integrated GUI. But that should not discourage development in that area. But the design practices are incompatible. GUI is sensibly designed from the top down >(from appearance), while a flexible toolkit needs to be designed from the bottom up (build fundamental capabilities first, compose "features" from them). A Makefile often does much more sophisticated things than merely orchestrate a series of virtual button pushes. Then we need a different aproaches: let's look to other project, for example, rkward: http://rkward.sourceforge.net/ Rkward is a GUI for R app/language, but is console oriented, you have a console, you have a editor for writing scripts and you have several menus to do tipical actions. New users (like me) use these menus and can do some work quickly, but there are a new feature that give users a extra point: the menu actions are translate to code and you can view it before and after of doing the action. Rkward have a command log view where user can look to see code actions. This is a example of how GUI helps the user without become a ballast. In gEDA world we have KJWaves in a similar approaching, and I know for a project in a city nearest to me, ESpice (for Español Spice), where they build a GUI around Ngspice, and is console oriented: http://espice.ugr.es/images/screenshots/screen2-big.jpg http://espice.ugr.es/index2.html Is not the correct way? Couldn't we have a tool thinking in new, and novice, users that helps them without scare? Is the answer is no, then I add: we need too much more documentation (and, yes, we need too much more documentation in any way). gEDA and especially PCB suffer a lot from lack of discoverability. PCB is more complex, so the scaling problem is more evident. It suffers from the > related problem of being a grab-bag of GUI features without a solid foundation of clean, > well-factored capabilities. gschem and gnetlist could be better too, but they're already > unusually good by this measure. I can't talk about PCB, but gschem is a good tool, not really difficult to do the work with it from scratch. I do not believe that a GUI frontend to gaf, pcb, spice is the way to go. That prevents dicoverability. My productivity with proprietary tools always got a boost as soon as I learned how to call the components individually. This was not always easy to discover. I have the same experience. It relates to my main point here: GUI does not scale well for the automation of complex jobs. I don't have the experience, but because I start calling each tool individually (gEDA user from begin). However, I can see that you say, I can view it in each users that without a GUI they can't do nothing. But, I can see that you are a power users (I read the list, you can't hide it to me), I'm only a normal user, almost a novice and I say that took the needs of the novices too, offer them the greats tools that gaf, pcb and free spice tools are, but offer them too the help (and a big one is this list) in the shape of *interfaces* easy to use without these interfaces be a *big begin problem*. And,hey! We are talking about free software, we don't have our hands enchained with the need of profits, we can *invent a new way*. (I hope that I could transmit some of my idea, language is a terrible frustation to me, I can't do all good that I want with english, sorry too much about). Best regards. Salud y Re
Re: gEDA-user: Power users us normal users, a conflict?
On Apr 8, 2011, at 1:22 AM, Stephan Boettcher wrote: > > I do not see a conflict between GUI and make, the first ist a good way > to make features of the second discoverable. Only if each individual tool is *simple*. Complex menus make features *less* discoverable. Besides, if your use case doesn't correspond *exactly* to the necessarily limited imagination of the developer of a "feature", then that "feature" is just more fog, hiding the real "feature" you want, or wasting your time by making it difficult to discover that the "feature" is missing. In other words, GUI scales just as badly as a discovery tool as it does as an automation tool. Therefore, adding capability should either involve: 1. More independent tools in the kit, or 2. *Less* GUI. > John wants to make sure > that the make-power is not compromised for the sake of the integrated > GUI. But that should not discourage development in that area. But the design practices are incompatible. GUI is sensibly designed from the top down (from appearance), while a flexible toolkit needs to be designed from the bottom up (build fundamental capabilities first, compose "features" from them). A Makefile often does much more sophisticated things than merely orchestrate a series of virtual button pushes. > > gEDA and especially PCB suffer a lot from lack of discoverability. PCB is more complex, so the scaling problem is more evident. It suffers from the related problem of being a grab-bag of GUI features without a solid foundation of clean, well-factored capabilities. gschem and gnetlist could be better too, but they're already unusually good by this measure. > > I do not believe that a GUI frontend to gaf, pcb, spice is the way to > go. That prevents dicoverability. My productivity with proprietary > tools always got a boost as soon as I learned how to call the components > individually. This was not always easy to discover. I have the same experience. It relates to my main point here: GUI does not scale well for the automation of complex jobs. --- John Doty Noqsi Aerospace, Ltd. This message contains technical discussion involving difficult issues. No personal disrespect or malice is intended. If you perceive such, your perception is simply wrong. I'm a busy person, and in my business "go along to get along" causes mission failures and sometimes kills people, so I tend to be a bit blunt. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Power users us normal users, a conflict?
Rubén Gómez Antolí writes: > Hi again: > > El 08/04/11 01:30, Peter Clifton escribió: >> On Thu, 2011-04-07 at 16:00 -0600, John Doty wrote: >>> On Apr 7, 2011, at 3:06 PM, Rubén Gómez Antolí wrote: You are right but, what about the users? >>> >>> I *am* a user. > > I'm too. Both of you now pushed some users aside somehow, one calling the GUI users _consumers_, the other calling CLI users _power users_. I do not see a conflict between GUI and make, the first ist a good way to make features of the second discoverable. John wants to make sure that the make-power is not compromised for the sake of the integrated GUI. But that should not discourage development in that area. >>> gEDA is software that caters to the needs of users. But >>> it's not for passive *consumers* of software. There are plenty of >>> other tools for them. I sincerely hope that gEDA's power and >>> productivity are never abridged to make it more palatable to >>> consumers. > > John, I'm not attack the powerful of gEDA, I'm really agree with the > multiple pieces of powerful software that compounds it, and I love too > the posibilty of use makefiles, but... > > I tell you a short history: I have a friend, he is really good in > electronics and yes, he uses other comercial apps (and he's testing > Qucs). I try to come him with us, but, stop, if I tell him to need to > learn Bash, Makefiles, Gnuplot and other "esotheric" languages... ¡oh, > wait! He only wants to do some electronics work. He cannot be really good, when we stays in the GUI forever. At least not efficiently. An expert in any field needs to use learn the tools of his trade, or hire personel that does. None of the languages you quoted are esotheric. Users of commercial tools learn more esotheric scripting languages to achieve what open tools can partly achieve with these non-esotheric tools. These non-esotheric tools are useful for all kinds of productivity boost besides eda. > Who is wrong? Possibly anyone, then, what about do a easy curve of > learning? Why we have to lost a potentially users which should > contribute in some way to gEDA? For a leak of a good interface* to do > in a easy way the work? I say no. Try to tell him about doing some > makefiles and, definitively all lost, we and they. gEDA and especially PCB suffer a lot from lack of discoverability. There a powerful features in PCB that are inaccessible from the GUI, and those features that are accessible do not provide hints how to access them from scripts. And AFAIK there is still no complete list of all actions available. I do not believe that a GUI frontend to gaf, pcb, spice is the way to go. That prevents dicoverability. My productivity with proprietary tools always got a boost as soon as I learned how to call the components individually. This was not always easy to discover. gschem modes, like emacs modes may be a good way forward. If you target simulation, provide a menu that highlights spice attributes, and spice components, with descriptive names. Just make sure you can switch to different modes on the same schematic, to use what is left of multi-target capabilities in gschem. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Power users us normal users, a conflict? [WAS: Re: zview/ngscope]
Hi again: El 08/04/11 01:30, Peter Clifton escribió: On Thu, 2011-04-07 at 16:00 -0600, John Doty wrote: On Apr 7, 2011, at 3:06 PM, Rubén Gómez Antolí wrote: You are right but, what about the users? I *am* a user. I'm too. gEDA is software that caters to the needs of users. But it's not for passive *consumers* of software. There are plenty of other tools for them. I sincerely hope that gEDA's power and productivity are never abridged to make it more palatable to consumers. John, I'm not attack the powerful of gEDA, I'm really agree with the multiple pieces of powerful software that compounds it, and I love too the posibilty of use makefiles, but... I tell you a short history: I have a friend, he is really good in electronics and yes, he uses other comercial apps (and he's testing Qucs). I try to come him with us, but, stop, if I tell him to need to learn Bash, Makefiles, Gnuplot and other "esotheric" languages... ¡oh, wait! He only wants to do some electronics work. Who is wrong? Possibly anyone, then, what about do a easy curve of learning? Why we have to lost a potentially users which should contribute in some way to gEDA? For a leak of a good interface* to do in a easy way the work? I say no. Try to tell him about doing some makefiles and, definitively all lost, we and they. Perhaps, we need to invent *some artifact* that can do that the users, step by step, go the way to convert himself into power users, but, is necessary not to send them away, do not? *(Looks that I say interface, not necesary a GUI, perhaps it helps) Could I remind people to change the subject line when things start straying from the original subject at hand please. Is good the new subject? :^) Whilst I'm here (and no - the subject isn't right for it, is it ;)), I will just second John's statement that gEDA + Makefiles is a very powerful thing. Really, I'm too. I've just been collating some documentation for my thesis, and have been enjoying the ability to type a single "make" command, and regenerate my 70+ page PDF schematic after having made minor edits to the colour scheme file. Combine this with LyX / LaTeX, and the pdfpages package, and you can do some very nice things. I'm doing a project combining R + Latex, and, yes, I'm in the way to use makefiles, really is powerful, is "easy" to do, but is no easy for someone that only knows WYSIWG, looks strange, looks difficult. Need to send them to the hell? No, give them the oportunity of do the way. I'm all for adding more GUI integration and giving people the option of using a GUI as well, but gEDA's strength is that the command line flows work really well too. I think in the same way. Russell Dill wrote: > > eh, I think spice is always going to be one of those things that takes > some learning. An IBIS tool would be a much better match for GUI > integration. Of course, these people that think that the tools not requiring some learning don't go too far. > > For me, the most non-intuitive things were the naming of the '0' net > and the use of the tran command in ngspice, past that, everything was > pretty intuitive. One of the problems is the howto is more of a > manual: > > http://www.geda.seul.org/wiki/geda:csygas > > A tutorial with an example design would be of enormous help. A nice > example might be an unterminated vs terminated transmission line. > We have a big a problem with doc, really, we need too much tutorials, too much manuals, too much examples and, yes, we need books of electronics written with gEDA and others free tools in mind. I think that in this list there are many opinions, in some cases, differents oppinions but, all wants that gEDA become a better tool (a better tool than be now, and it is so good) and become a attracting tool for normal and power users, not a tool that scare posible new users. Best regards. Salud y Revolución. Lobo. -- Libertad es poder elegir en cualquier momento. Ahora yo elijo GNU/Linux, para no atar mis manos con las cadenas del soft propietario. - Desde El Ejido, en Almería, usuario registrado Linux #294013 http://www.counter.li.org ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
