[ale] Different kinds of developers [was: Re: Programming language groups in ATL]

[aaron]

Thoughtful an insightful points, Daniel.  Thanks!

I think the comments also call attention to the fact that
weaknesses in UI development and usability considerations
are among the larger issues keeping Linux / OSS software
from enjoying faster adoption.

Looking back on my own forays into software product
development I  would estimate that at least 70% of both
the coding and the creative energy was devoted to the
user interface concerns, and that was despite being
restricted to using a fairly limited set of GUI gadgets

>From an OS or system API standpoint, the GUI tool set
being offered is a tough trade off between providing a
consistent user experience and allowing creative flexibility
for new and inventive approaches. It would be amazing
if the broader Linux community could generate (and find
some actual agreement upon) a set of interface "Style
Guidelines" for OSS UI developers to reference.  Even
a few simple rules of thumb can greatly improve the user
experience, like the Amiga Style Guide example of
 "providing informative feedback to the user within
five (5) seconds of any program launch or other GUI
Gadget, Menu or Icon interaction".

I think distros like Ubuntu are bringing some needed
focus to improving the Linux user experience through
a more consistent environment, but there is a lot of
room for futher improvement.

peace
aaron



On Tuesday 24 June 2008 10:48, Daniel Kahn Gillmor wrote:
> On Tue 2008-06-24 09:40:25 -0400, Chris Fowler wrote:
> 
> > There is a lot of text on the Internet on the difference between a
> > Windows programmer and a UNIX programmer.  I have one generalization
> > that I think fits the most.
> >
> > The UNIX programmer will write a program to work on the CLI first.
> > Then that programmer will develop a GUI that executes the CLI
> > program.  We see this often in Linux.
> >
> > The Windows programmer will design the GUI first.  There will be
> > forms and buttons with no code behind them.  After the design is
> > mostly done that same programmer will start writing the real code
> > that does real work.
> 
> Another way to see this difference for a program addressing a given
> problem domain is whether the developer is more interested in
> providing:
> 
>  0) programmatically-accessible conceptual primitives associated with
>     the problem domain, or
> 
>  1) an intuitive interface for humans to do the most common tasks
>     related to the problem domain.
> 
> This is not necessarily a UNIX/Windows divide, but unfortunately it
> often breaks down that way.  
> 
> The sad part for humans who use computers (and they're the point of
> these machines, are they not?) is that for a healthy computing
> infrastructure, we need both things fleshed out, and they are *very*
> different tasks.
> 
> Without developers providing good, flexible, powerful primitives
> (that's type 0), there will be no basis on which to advance new
> operations that may very well become "common tasks" for users in the
> future.  This leads to stagnation and concept lock-in.
> 
> But without developers providing good, intuitive interfaces for common
> tasks (that's type 1), most users will never get to experience working
> in the problem domain.  Proper use of conceptual primitives requires
> significant mental investment in understanding the entire problem
> domain, which few people are likely to muster.  There are just too
> many problem domains out there for folks to really understand the
> nuances of all of them.  
> 
> And GUIs built directly from the CLI (instead of from the expected
> user's point of view) are often hideous monstrosities [0], unusable by
> all but the folks who already understood the conceptual primitives in
> the first place.
> 
> Without a critical mass of users, even the underlying conceptual
> primitives will never get the level of testing, engagement, and
> feedback necessary for a healthy toolset.  This constant engagement is
> doubly necessary now that all computing is essentially networked,
> since the subtly-shifting network seems to cause bitrot in abandoned
> programs.
> 
> Most folks on this list probably agree that it's a bad deal for the
> users of Microsoft that MS doesn't provide (or encourage their sphere
> of programmers to provide) programmable conceptual primitives, a
> functional command line, etc.  We can see the stagnation, bugginess,
> and lock-in that comes from that decision.
> 
> But the UNIX and free software world needs to step up and acknowledge
> and encourage the work of strong user interface designers.  It is to
> our shame (and our platform's detriment -- not to mention our users')
> that we only have a few good examples of human-centered design.
> 
> So please don't say that starting from the human-facing UI (even with
> "no code") is not "real work".  It may not even involve a computer
> (i've seen good UI developers work entirely on paper and whiteboard),
> but it is real work.  It's complicated and difficult, possibly even
> moreso than conceptual primitive work, because humans are complicated
> and difficult subsystems to interact with.  And a good human-centered
> UI will often encourage a re-assessment of the conceptual primitives
> themselves, because there may be features or optimizations within the
> problem domain that only become relevant when you're placing your work
> directly in front of a bipedal primate.
> 
> FWIW, i'm a dyed-in-the-wool type 0 programmer, who struggles mightily
> not to let down my users because of my personal predilections.  I fail
> most of the time.
> 
> Regards,
> 
>         --dkg
> 
> 
> [0] a GUI designed after the CLI: this is just the first that came to
>     mind, and i don't mean to pick on xcdroast especially:
> 
>       http://www.xcdroast.org/xcdr098/sshot7.html
>   
>     if you understand this interface (even without the "advanced write
>     parameters"), you already know way more about writable optical
>     media than probably 99.9% of humanity.  And even if you know what
>     "fixate" means in this context, what happens if i make sure "do
>     not fixate after write" is checked, and then click the "Fixate
>     CD-R/RW only" button?  This is not a UI geared for wide-scale
>     adoption or general usability.
>