[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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 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@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user