Hello,

I thought that in Squeakland, the division between the _developer_ and
the _user_ is supposed to be blurred, if not completely gone.  I think
that the only benefit to putting the time into developing applications
like the ones that Brad was talking about was to exemplify the idea
that this line is blurred through familiar types of applications.  The
kinds of people who are going to be attracted to Squeak, no matter
what we do, are going to be the kinds of people who are comfortable
with this blurred line.  If we set a precedent for making easy the
exercising of the kind of power that Squeak allows through familiar
environments like email and office applications, I think that more of
these people will be able to quickly understand and experience the
paradigm that Squeak represents.

Derek, I think your Breaking Barriers speech (which I enjoyed reading
:) ) is right on point.  Although you remain safely dogmatic in your
distinction between "user" and "developer," however, I think that this
Barrier needs to be broken down as well.  I really believe that this
is in keeping with what Brad had in mind from the beginning.  I'm glad
that this conversation is taking place to further refine these themes.

Cheers,
Mike


On 2/2/07, Milan Zimmermann <milan.zimmermann at sympatico.ca> wrote:
> Hi Derek,
>
> I should mark this OT, or ask Ken to setup squeak-advocacy list. Anyway, I
> should say that I agree with much what you said, considering the difference
> how I'd describe a user vs. developer. A few comments on it inline...
>
> On 2007 February 1 05:38, Derek O'Connell wrote:
> > Regarding "attracting more developers": before appearing critical I'd
> > like to say that *I see* the potential in Squeak/Smalltalk but I'm not
> > sure it is immediately apparent to many others (meaning those yet to
> > encounter Squeak/Smalltalk). This is not to say I have any sort of
> > special insight or anything but because of years of relying on other
> > developers to one extent or another it is refreshing to work in an
> > environment where each new nugget of learning contributes to my
> > knowledge of the *total* environment. There's no technology barrier at
> > which point I have to re-tool to gain deeper control of the
> > environment (beyond the obvious topic of customising the VM but even
> > this would be transitory (do it then just use it)). My only regret is
> > that I didn't "discover" it years ago. I'm also grateful that
> > experienced developers continue to improve Squeak but... (you knew it
> > was coming :-) )...
> >
> > Squeak/Smalltalk has been around for years with I guess large numbers
> > of interested developers at one time or another but still has almost
> > *ZERO* mindshare in the general computer using population and, I would
> > also guess, close to zero in those that can or want to program. This,
> > IMHO, is not simply a pubilicity problem, it's a presentation problem.
> > Framed crudely: Squeak/Smalltalk *is* a great development environment
> > but a dire *user* environment.
> > Yes, Morphic is way cool but most user
> > oriented "applications" are mashed up with non-application elements
> > and many an answer to newbies questions begin with "Open up a
> > workspace, type "blah new openInWorld", right-click, select "DoIt"...
> > I mean, COME ON! What century are we in? I say this somewhat
> > tounge-in-cheek because if you have convinced a newbie to do this then
> > you can immediately claim that they have written and executed their
> > first Smalltalk program ("there, that wasn't hard was it?" LOL).
>
> By "user" I ment a person using a application, such as web browser or office
> suite, which is what started the debate. I probably was not clear even for
> myself but by developer I ment anyone using Squeak for developement or
> playing, or simply interacting with it. From this perspective, what you are
> complaining about (rightly!) is in the _developer_ scope, not _user_ scope. I
> could write much about Squeak (Morpic) UI feeling awfully inconsistent ,
> illogical and complicated (to me at least), so just one example: Line up 4
> (partly overlaping) elements:a Workspace window, a Morphic Project Window, a
> Pinned Menu and a Book Morph. Each of them behave completely differently in
> terms of a) how to bring them to front and b) how to pick them up and move.
> (thanks for the halo that is the only consistent interaction!) For new
> developers (ok, users, in your view) this must be a complete turn off. the
> complexity of menus is another thing. I am not sure there is a way to "fix"
> this, as it would require to define some UI rules first, I am thinking that
> using something like Tweak is probably the way out of it.
>
> >
> > So to get specific: should the focus be on attracting more developers
> > or more "casual" users, and are better development tools needed or
> > more end-user applications? In truth there is no correct answer and it
> > is a bit of a chicken-n-egg situation.
>
> yes i agree completely. What I am not sure about (but will have no problem to
> be wrong, and not discouraging ) is whether developing large scale end user
> applications that exist today (and have many man-years development invested
> in them), is a practical way to gain user base.
>
> Milan
> > Any answer depends on the state
> > of affairs at the time it is given. Today there are developers (I'm
> > not sure how many) but I argue that there are *no* casual users and
> > that end-user applications are needed.
> > If the question is "who cares
> > about casual users?" then I say that these, not developers, are future
> > life-blood of Squeak/Smalltalk development, they will generate the
> > demand that ensures Squeak/Smalltalk continues to exist and improve. I
> > could also question the role of developers without end-users and
> > postulate that if there were more end-users today then there would
> > also be jobs for Smalltalk developers... and everyone would be happy
> >
> > :-P
> >
> > A few final points:
> >
> > - I pay homage to EToys, Seaside,  Scratch, Sophie etc but none of
> > these are what I would class as In-Squeak user-based applications.
> > Croquet of course offers potential but I would say not for general
> > consumption until high speed comms and 3D hw acceleration become so
> > standard that suppliers/manufacturers list them in their basic specs
> > (if only people would not dream to buy machines without hw 3D!)
> >
> > - I recognise the wealth of code in the image but question the
> > accessibility of this to casual users or even wanna-be programmers. In
> > the case of the former presentation is very much key, for the latter
> > the amorphousness of Smalltalk interfaces lack the "sign-posts"
> > provided by well-documented API's in other environments.
> >
> > - Squeak is an ideal place to challenge peoples concepts of what a GUI
> > is and what they should be able to with it. A much better environment
> > for *any* sort of experimentation than say "Proce55ing". I have a few
> > ideas that I'd like to throw into the pot, depending on what direction
> > Brad takes this conversation.
> >
> > - To the hardcore Smalltalk developers: despite any apparent
> > criticisms above, I LOVE YOU! WE LOVE YOU! Carry on coding dudes! :-)
>
>