| |||||||||||||
LinuxCon: Some advice from Uncle DirkLinuxCon: Some advice from Uncle DirkPosted Sep 23, 2009 23:40 UTC (Wed) by Baylink (subscriber, #755)Parent article: LinuxCon: Some advice from Uncle Dirk
> On the issue of design, Dirk made the claim that we have few real designers in our communities. Indeed, the processes in many communities seem to have the explicit goal of encouraging people interested in design to go elsewhere.
Indeed we do not.
"Designer" is what I've put on my business cards for most of the last 20 years. It's come up through three tracks; I do software design, graphics design, and the odd TV program here and there; design, like most other discplines, is the application (and thoughtful breaking) of rules.
The reason, I've learned, why designers are chased off in the FOSS environment is largely that design is *not* generally an implementation skill, and designers are not always skilled implementors: to take software as an example, I've worked over the years with half a dozen really excellent coders (which I am not) on various projects.
They were excellent coders, but if you left them to do the design themselves, you wouldn't get anything usable. Systems analysis and software design (two closely related, but slightly different fields) are both critical to a good end-product in the software business... but the only way you get them, generally, in FOSS, is if you *do* find that rare coder who can do both -- it tends to be a "Code or GTFO" sort of environment, except in very rare instances.
And that, I think, is the problem Dirk's alluding to.
He says we need "competence" to implement visions. But that's two pieces: turning the "vision" into a deliverable, and *then* delivering it.
FOSS tends to be weak on the first half -- because that's the half that says "it needs to be usable and workmanlike looking (if not pretty), *in addition* to working properly". And the people who are good at that part are *often* not superstar programmers. Which is all the meritocracy seems to select for, in many cases.
"Programming systems product", Fred Brooks called it. All four quadrants, to paraphrase the movie industry.
That's the part we're missing, and as long as lead coders on projects think that all the smart people *already* "work" for them, the problem will continue.
When you're big enough (or smart enough) to already have a bugzilla or trac, and accept (and triage) RFE tickets, you're either on your way to digging out of this hole, or you've done it. Lots of projects either don't accept RFEs at all, or ignore them.
Figuring out how to make sure that vision isn't tunnel- seems the important bit.
(Log in to post comments)
LinuxCon: Some advice from Uncle Dirk Posted Sep 23, 2009 23:43 UTC (Wed) by Baylink (subscriber, #755) [Link]
And I missed one important point, on the 80/20 issue:
The *fun* part, generally, is the design work; lots more people seem to find designing fun (whether or not they're actually any *good* at it), than find coding fun... so if you let a designer take the fun 80%, then you're *really* screwed.
Not sure if that part's fixable...
LinuxCon: Some advice from Uncle Dirk Posted Sep 24, 2009 18:47 UTC (Thu) by holstein (subscriber, #6122) [Link]
A variation on the bike-shed-color syndrom probably.
LinuxCon: Some advice from Uncle Dirk Posted Sep 24, 2009 1:38 UTC (Thu) by JesseW (guest, #41816) [Link] Interesting and thoughtful response, Baylink. There was one part I didn't follow, though.But that's two pieces: turning the "vision" into a deliverable, and *then* delivering it. / FOSS tends to be weak on the first half -- because that's the half that says "it needs to be usable and workmanlike looking (if not pretty), *in addition* to working properly". I don't fully understand what you mean here. You are saying that "turning the "vision" into a deliverable", which I gloss as "specifying it in detail", involves making sure the specification is "usable and workmanlike looking ... [and] working properly". Isn't that what the whole process of making anything is about? What else is there? Could you expand on what aspects of that are particular to the "turning the "vision" into a deliverable" part of the process?
LinuxCon: Some advice from Uncle Dirk Posted Sep 24, 2009 1:52 UTC (Thu) by Baylink (subscriber, #755) [Link]
Sure, though Fred Brooks, as I noted, did it better:
http://my.safaribooksonline.com/0201835959/ch01lev1sec1
Roughly, though, it's "avoiding the three-click problem": it's not always easy for some coders to get up out of the nap of the earth to 5000 feet, much less 30,000 feet, and make sure that they've actually completely specified the problem ... which is what is being complained about there.
FOSS development works, most of the time, we are told, without any direct financial incentive because the developers are scratching their itch.
The problem on point is that *they're not scratching everyone's itch*.
Figuring out how -- and how far -- to generalize, and then making sure that all happens, is the job of systems analysts and project managers. In my personal experience, the number of people who are really good at both is small. I'm a competent coder, but I don't *love* it. What I *love* is figuring out what people really need, and then specifying that so that someone can create it.
FOSS development caters to people who are good to great -- or at least *dedicated* -- coders, whether or not they're good designers (I've seen some really raunchy programs in FOSS; great code, but they're just not up to the task, as demonstrated by the opinions of their audiences)...
but it -- and by "it", I mean "lots of the people who run big FOSS projects" :-) -- doesn't tend to deal well at all with people who are really good analysts/designers, but aren't coding superstars.
Or, perhaps, my entire opinion here is colored by the unsurprising fact that they just don't agree with *my* view of The Way Things Ought To Be; unsurprising because I, clearly, don't agree with theirs. :-)
This is all my perception, of course, going back to when I could read all of Usenet in a day; it's leavened by 25 years in DP/IT, most of it as a designer/analyst, much of it writing my own code, and also by interacting with quite a number of FOSS projects to varying degrees of depth, including big modern things like WebGUI and Zimbra, and old projects like HylaFAX. I could be wrong. :-)
LinuxCon: Some advice from Uncle Dirk Posted Sep 24, 2009 1:59 UTC (Thu) by Baylink (subscriber, #755) [Link]
I find I wasn't quite clear enough before hitting post :-)
"usable and workmanlike looking" is the part I was suggesting is supplied by designer/analyst types, and often missing in FOSS projects, because it's not "essential to the base function".
A current example that's driving me insane is Knetworkmanager, as supplied with SuSE 11.0, which I run on my laptop. The Right Way to handle this stuff has been pretty obvious for some time -- supplied, embarassingly enough, by Windows XP... though it often can't keep the links *running* to save its life.
But KNM makes me jump though some non-obvious hoops to get anything done, having to know that I must choose "New Connection" in order to teach it about a network I've never been on before, and having to suffer through a popup menu that completely fills the screen of already learned networks when *none of them are in range*... and which is *in the way* of the other menu as I scroll up to do the thing I actually need to do.
That's the sort of three-click-problem items he was talking about, IMO.
And the simple fact of the matter is that while I could probably contribute to fixing them, the amount of time I have available to deal with the 30 or 40 such things that make it difficult for me to use SuSE/KDE3 on a daily basis limited to "I might hang a ticket, if I don't have to fight to find and sign up for your tracker". And what I *get*, in a lot of cases is "we look forward to your patch".
I've *read* "Smart Questions".
I submit that while I understand -- and even approve of -- the arguments it makes, *that's the difference we're talking about*. If you want Real People to *want* to use your stuff, then *someone* has to deal with those issues.
LinuxCon: Some advice from Uncle Dirk Posted Sep 24, 2009 4:42 UTC (Thu) by JesseW (guest, #41816) [Link] Thank you. I appreciate you taking the time to explain this; I've also noticed similar issues. Let me expand on my understanding of the alternative to to this problem, i.e. the process followed by projects that do pay attention to RFEs (Requests For Enhancements, for those following along at home). The maintainers of such projects consider their jobs to be designers/systems analysts, although with the job of selecting the good from what they are given, rather than being able to directly demand it of subordinates, as is done in traditional cathedral-style projects. The projects attract a number of coders who are willing and able to recognise itches when they read RFEs, even if they themselves hadn't felt the itch before. And finally, such projects have users who are aware, able and willing to send in their observations of the problems and rough-edges they encounter and receive courteous appreciation for doing so. Is this impossible? Hardly. Are there many, many projects that arn't like this? Certainly. While I agree that many FOSS projects don't recognise the value of suggestions without code, I'm still uncertain why you consider that having a badly structured interface doesn't screw up "the base function[ality]". I would be surprised to hear of a project that refused a patch fixing a interface wart on the grounds that "interfaces don't matter". There certainly can be really big and long arguments over whether a particular aspect of an interface is a wart or not, but that's quite different than refusing to fix a wart that everyone agrees is there. As for the examples you mention with Knetworkmanager -- those certainly sound like irritations that most folks using it would like to see gone -- likely including some developers. It is frustrating that the response to filing a description of the problem, or even a specification of how the problem could be resolved, implies that no-one but you is responsible for coding it -- it would be much better (and I've seen this) if the response was, "Thanks for clarifying the solution to this apparent problem; that will make it easier for whoever has the skill and time to implement it." But asking for a patch (from the original submitter or someone else) is a reasonable request -- the code needs to come from somewhere. Does this match up with what you've been trying to express?
LinuxCon: Some advice from Uncle Dirk Posted Sep 24, 2009 13:10 UTC (Thu) by Baylink (subscriber, #755) [Link]
> I'm still uncertain why you consider that having a badly structured interface doesn't screw up "the base function[ality]".
I consider that having a badly structured interfaces *does* screw up the base functionality; that was most of the point of my post. :-)
> I would be surprised to hear of a project that refused a patch fixing a interface wart on the grounds that "interfaces don't matter".
Most projects would accept *the patch*, it's *the bare report* that they're not interested in... and that was the *rest* of the point of my post.
LinuxCon: Some advice from Uncle Dirk Posted Sep 24, 2009 16:37 UTC (Thu) by JesseW (guest, #41816) [Link]
Well good, then we agree. Thanks for the discussion! ;-)
LinuxCon: Some advice from Uncle Dirk Posted Sep 24, 2009 9:33 UTC (Thu) by Frej (subscriber, #4165) [Link]
Or just copy the gnome gui. Considerable design resources went in to that.
Although the preferences dialog could use some work - the primary goal (selecting a wireless
LinuxCon: Some advice from Uncle Dirk Posted Sep 24, 2009 17:27 UTC (Thu) by wstephenson (subscriber, #14795) [Link]
knetworkmanager 0.7 for KDE 3, as shipped in openSUSE 11.0, was written by a kernel hacker, and I jumped in as a KDE developer late in the cycle to do the minimum cleanups needed to get it functional for release. While I am very grateful that Helmut wrote knm3, its UI could do better.
Please have a go of KDE 4 knetworkmanager, currently under development for openSUSE 11.2 and available for 11.1 via the Build Service, and let me know if you think we've improved matters.
LinuxCon: Some advice from Uncle Dirk Posted Sep 27, 2009 14:19 UTC (Sun) by Baylink (subscriber, #755) [Link]
Well, I'd love to, but can I *run* that on 11.0? Without installing KDE4 (which I'm still not using)? And if so, does that mean I have to grab the SRPM and build it myself?
(Thanks for this reply, BTW, and my apologies that my own was so delayed.)
LinuxCon: Some advice from Uncle Dirk Posted Oct 1, 2009 23:41 UTC (Thu) by jmm82 (guest, #59425) [Link]
"But KNM makes me jump though some non-obvious hoops to get anything done, having to know that I must choose "New Connection" in order to teach it about a network I've never been on before, and having to suffer through a popup menu that completely fills the screen of already learned networks when *none of them are in range*... and which is *in the way* of the other menu as I scroll up to do the thing I actually need to do."
Do they have a nm-applet for KDE.
NM in Gnome does not connect to a wireless network automatically unless you have already connected to the network before, but the only time you would have to add a new connection in order to make it appear in the list is for a hidden network. If a network is broadcasting an SSID it will show up in the list and you must click it the first time to connect, but it does not require creating a new connection. Granted it may be a bug in the kde interface.
how does Windows XP do it?
In all fairness it is a Gnome project, just as Amorak(I use Exile now, but it is different) does not run as well on Gnome, Network Manager does not run as well on KDE.
Good points though in your posting.
LinuxCon: Some advice from Uncle Dirk Posted Sep 24, 2009 8:12 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
Something I would like to try coding, when I have time, is a GUI creator which really separates code and design - where the GUI executable created would start a separate, text-only executable to handle everything not related to the UI, would send it all GUI events as lines of text into it's standard input, and receive events as lines of text out of the programme's standard output. Events would be as abstracted as feasible from the UI, somewhat based on Qt's signals.
That way a programmer would be able to write their stuff, doing a very sketchy GUI to support it, and people more interested in design would be able to do their own interfaces without having to get too deep into the code.
LinuxCon: Some advice from Uncle Dirk Posted Sep 24, 2009 9:21 UTC (Thu) by hppnq (guest, #14462) [Link] Something I would like to try coding, when I have time, is a GUI creator which really separates code and design I can recommend it! Years ago I wrote something that combined a markup language for the graphical stuff and a script language that could handle events, callbacks and other things of a more dynamical nature. It could do more or less what you describe, e.g., read or write text from a file descriptor and have an interpreter do something intelligent with it. (My problem is to find the time to clean it up and release it. I'm not sure the design was so great. ;-)
LinuxCon: Some advice from Uncle Dirk Posted Sep 24, 2009 10:25 UTC (Thu) by spaetz (subscriber, #32870) [Link]
ever used Glade in which the design could even be a separate .XML file from the binary?
LinuxCon: Some advice from Uncle Dirk Posted Sep 24, 2009 11:12 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
That doesn't quite do what I want, although I would almost certainly use Glade for the actual UI "drawing" in a first version to reduce coding effort and increase the chance of ever getting something working. AFAIK, Glade still requires you to write a lot of binding code yourself in C or python or whatever you are using.
I am thinking of something where all the basic communication between GUI components could be set up in a Qt-like signal-slot way, but without any real coding, and communication between the UI and the (pure console) main programme would also be done via signals from the UI to the programme's standard input, mapped to text strings - e.g.
'MySignal selected "some dropdown entry"',
where "MySignal" is a signal identifier shared between programme and UI - and something similar from the programme's standard output back to the UI (updating graphics would probably be one of the trickiest bits here).
LinuxCon: Some advice from Uncle Dirk Posted Sep 25, 2009 6:03 UTC (Fri) by magnus (subscriber, #34778) [Link]
Having the communication at that low level would mean that your non-GUI process would need to know lots of detail about the GUI side (which controls exists etc) so you wouldn't achieve any real separation between the two.
To make this separation work well, you would need to make your text-only process like a server that handles the application's state only, and the GUI process is the more active part that sends queries and requests to change the state.
For many applications a bit part of the code is in the GUI handling, and I don't think you can get away from that. What you could possibly do is move the GUI handling code to a scripting language like Javascript which many designers are familiar with.
LinuxCon: Some advice from Uncle Dirk Posted Sep 25, 2009 9:59 UTC (Fri) by anselm (subscriber, #2796) [Link] Congratulations. You just re-invented Tcl/Tk -- after ... what? 17 years? :^)
LinuxCon: Some advice from Uncle Dirk Posted Sep 25, 2009 10:10 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
Except that Tcl applications had to be written in Tcl, which might put off some developers :) (I do seem to remember that Tk could be coupled to other things, but I don't remember that taking off). But was a Tk GUI really that easy for a non-programmer to rip out and replace without changing the underlying application?
LinuxCon: Some advice from Uncle Dirk Posted Sep 25, 2009 13:58 UTC (Fri) by anselm (subscriber, #2796) [Link] The original idea behind Tcl/Tk was that the meat of an application would be written in a language like C, and its functionality be made available as Tcl commands. These Tcl commands could then be used to »script« the application, to allow automated testing, or -- in conjunction with Tk -- to create a GUI for the application. Hence the actual application code (in C, mostly) and the GUI code (in Tcl/Tk) would be neatly separated. This approach was (and presumably still is) used to great effect, for example, in various VLSI design applications. Tcl got much of its bad reputation because people would try to write big(gish) programs in Tcl itself rather than subscribe to the philosophy outlined above. It took the language some time to acquire the necessary properties to be really useful for larger applications, but by that time much of the damage was already done. Tcl/Tk did earn its inventor, John K. Ousterhout, an ACM Software System Award in 1997 (something that all the other X11 toolkits have yet to achieve), so it is officially a Good Idea. It is worth noting that when Tcl/Tk came out (early 1990s) it was running rings around its competitors such as OSF/Motif as far as ease of development was concerned. It can also be surmised that if, instead of inventing various other X11 toolkits from scratch, the community had poured the same amount of effort into improving Tcl/Tk (which already existed and worked quite well), we would all be much better off :^) For example, Gtk started out as the »GIMP toolkit«, but if the original developers of the GIMP had decided to come up with a better Tk canvas widget rather than implement a complete new X11 toolkit from the ground up, they could have saved themselves a whole amount of work, and the GIMP would be a better program even today. This is the NIH phenomenon at work.
LinuxCon: Some advice from Uncle Dirk Posted Sep 25, 2009 16:00 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
>The original idea behind Tcl/Tk was that the meat of an application would be written in a language like C, and its functionality be made available as Tcl commands.
Indeed, in my first proper job I worked on a scripting language for processing vector data which was based on Tcl.
>This is the NIH phenomenon at work.
LinuxCon: Some advice from Uncle Dirk Posted Sep 25, 2009 10:05 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
My personal suspicion is that the approach I am pushing will work well up to a certain point, but will not scale beyond that. It will depend how much can be achieved by connecting UI components with signals and slots (and how many clever solutions people can find to increase that). As a simplified example: the signal "File menu/open" would be connected to "File chooser dialogue/show", the different components would also be connected to one another ("Directory view/select directory" to "File view/change directory") and "File view/select" would be connected to "File chooser dialogue/hide" and to a text signal into the text process: "OpenFile <filename>". The question is how many uncomfortable details my simplified example simplifies away, but thinking back to Visual Basic 1 (the only one I ever used), I do think that it could work for some applications.
The other point I am hoping may hold is that many more complex applications are built around a single main central widget. For example in MS Word, that would be the editor widget. I hope that at least for some applications, it will be possible for the text controller process to hold some state about that widget (the visible size, the position of the scrollbars), to accept a few events like key pressed, mouse clicked, mouse dragged, scroll down, refresh rectangle and to send a few, like fill rectangle with bitmap, change vertical scroll range, place cursor, while still not knowing implementation details like what the widgets are called, exactly where the scrollbars are and what they look like and so on. (In other words, behave as if it were managing a full screen application like a DOS editor, rather than worrying about the full complexity of a GUI).
LinuxCon: Some advice from Uncle Dirk Posted Sep 24, 2009 13:34 UTC (Thu) by Baylink (subscriber, #755) [Link]
Yes!
This is probably the best design pattern of any for GUI interfaced software; ironically, it's a pretty good description of an AJAX web app: constrain the GUI/app interface to a nice texty 'telnet' channel.
Among other things, this not only makes replacing the interface easier, it *also* makes *scripting* the interface -- say for testing -- easier as well.
It's not as *easy*... but it's worth it.
LinuxCon: Some advice from Uncle Dirk Posted Sep 24, 2009 13:45 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
I will let you know if I ever actually get anything done then! (Although it will definitely not be any time soon, as I have too many other distractions in the real world just now :) )
LinuxCon: Some advice from Uncle Dirk Posted Sep 25, 2009 6:42 UTC (Fri) by eru (subscriber, #2753) [Link] This idea reminds me of a description of HUT Windows, an old (1980's) experimental window system from the Helsinki University of Technology (never used it, saw a demo once and read a booklet, which I might still have somewhere on paper). Another similar system might be AntiRight (http://www.nongnu.org/antiright/).
|
|||||||||||||