spuzzdawg wrote: > I think that this is basically an argument in usability vs > flexibility.
One person's flexibility hinders another's usability. :) I think what's abundantly clear by this whole discussion is that there's a grave need for a recommended, introductory-level workflow--- and enough "glue" to make that workflow as simple as possible for a new user. A new user probably doesn't care initially about the gobs of cool stuff gEDA can potentially do, I bet they just want to get from schematic capture to fabricated board with as little effort as possible. Once they've completed that cycle once, if the experience is pleasant then they'll be motivated to try some of the more sophisticated workflows that gEDA's flexibility makes possible--- even if that means a higher investment in effort. If the initial experience is unpleasant, they won't come back and all that flexibility is wasted on them. I came to gEDA with no experience whatsoever, other than doing schematic "captures" with pencil and paper, and "fabrication" on a solderless breadboard. I'm three or four designs in now, but getting to where I was even competent with the tools hasn't been easy--- my first board run cost me $500 due to a footprint screwup that forced me to toss the whole lot in the bin. I don't like having to demand that level of effort from the new users that I recommend the tools to. A tool as powerful and important as gEDA needs an active user and contributor base, which is something I don't see reflected in the geda-user mailing list activity: the same few names come up over and over again. That's a bad sign. We can't grow a user base if we can't create a pleasant out-of-the-box experience that keeps the first-timers around for a second, third and successive designs. Even if their designs aren't substantial, and even if they don't require all the power that gEDA has to offer, we have to make sure that their efforts have a high probability of success if we're to keep them around to learn about all the better ways that gEDA can solve their problems. For the record, I don't think gEDA is *that* hard to use. By far the biggest obstacle to me to date has been a lack of clear direction on and support for an introductory-level workflow: a basic set of pre-existing symbols and footprints for some common parts, and end-to-end guidance on how to use them to get through to something you can submit to a board house. (In fact, it took me a while to even figure out HOW to submit to a board house). As it is now, most of my symbol and footprint library is basically junk because I totally didn't get the idea from the beginning about the kinds of information I need in my symbols vs. what I thought I needed. I'm not talking about a "heavy-vs.-light debate", I'm talking about "if you are going to do a heavy symbol, then do it like this...". I think the root of the Slashdot article poster's problem is gEDA's out-of-box experience, but we've let that discussion (de)evolve into the relative merits of flexibility vs. usability. I think we should go back to defining tasks that would improve the out-of-box experience without necessarily breaking gEDA's flexibility in situations where more than documentation is required to address the issue. Once we've worked down that list, we can decide at that point if the time we get back is best spent on abstract discussions or more tasks. :) b.g. -- Bill Gatliff [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
