Usability and look-and-feel (was Re: [squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean))

2009/6/29 Hernán Morales Durand <[hidden email]>:
> Dear Ian,

Hello Hernán!

>                  I really understand your position, because I hated
> the Squeak UI for almost one year, until I started to read about Color
> Theory and Cognitive Pshychology and understand some things about it.
> However, each soul has to convince by himself or do something about
> it.

There are many superficial people in this crazy world. They don't get
pass the current look-and-feel. It is unfortunate enough because they
cannot see the true beauty behind Smalltalk. The look-and-feel is not
so important to me since it's necessary to create a custom UI for our
application to be deployed, and localization, deployment facilities,
maintenance related stuff, etc. comes on top of my list. But, still,
it's good to be able to talk about these issues and understand what
the problems are.

> Color Theory and Cognitive Psychology

Squeak UI is really colourful. Bright colours are stimulating and
would be favourable to any child's development. It is however very
difficult to spend 8, 10, or more hours a day, everyday, either on a
personal project or a professional front, with such a colour scheme.

Moreover, the colours are not necessarily clearly identifying each
window or graphical component; I feel lucky that it doesn't pop up the
same tool with different colour each time. The lack of coherence in
the colour scheme makes it exhausting and serve no other purpose than
aesthetics, usability completely left aside. The lack of coherence in
the general look-and-feel is also disturbing and annoying.

Usability comes second in the list of complains from my acquaintances,
which I tried to Squeak-e-vangelize. The first obstacle is obviously
no edit-compile-cycle but we ain't gonna get it (it makes no sense at
all in Squeak). Sincerely, I think, people can get over the fact there
is no edit-compile-cycle. Then, they hit themselves to a bunch of
separated windows in contrast to an IDE, which traditionally provides
everything integrated through panes and top menus in categories.
Newcomers (or even not so new) should easily find features without
having to dig into obscure menus or, sometimes, even code. Menus are a
big mess. They're sometimes huge and the lack of organization is
problematic. The programmers not so familiar with Squeak definitively
have to understand the principle behind the workspace, transcript,
class browser, saving an image, etc. Nonetheless, the sense of being
lost in this new but exciting environment would not repulse them if
only they could find familiar elements.

>  Let me put my feelings into the words of Schoenberg, he once said :
> "Art is not for everyone; and if it is for everyone, it is not Art.".
> And I believe pretty much the same here : "Smalltalk is not for
> everyone; and if it is for everyone, then it is not Smalltalk".

It is perfectly fine if Smalltalk is not for everyone. Though, wasn't
it the initial spirit of it? Anyway, while it might not be for
everyone, it shouldn't make our own community split up and flock away.
Right? I've got the feeling the Squeak community has created a very
comfortable niche for itself and sort of forgot about the essentials.
A reality check once in a while is always good.

> Cheers,
>
> Hernán


Best regards,
Ian.

--
http://mecenia.blogspot.com/

> Usability comes second in the list of complains from my acquaintances,
> which I tried to Squeak-e-vangelize. The first obstacle is obviously
> no edit-compile-cycle but we ain't gonna get it (it makes no sense at
> all in Squeak).

At this point I'm just puzzled. Why would people so deeply in love with
the edit-compile-cycle they find it hard to live without it even
consider Smalltalk (or Lisp, for that matter) in the first place ? I'm
lost. Maybe you should start by selecting a bit more carefully the
people you want to Squeak-e-vangelize (half-kidding here, no offense
intended).


> the programmers not so familiar with Squeak definitively
> have to understand the principle behind the workspace, transcript,
> class browser, saving an image, etc. Nonetheless, the sense of being
> lost in this new but exciting environment would not repulse them if
> only they could find familiar elements.

Or, at the contrary: let them experience a big shock that wipes out
their preconceived ideas about programming. Trying to help them avoid
that shock may actually make thing more difficult for them in the long
term. They have to grok that Smalltalk *is* different.


Stef

> There are many superficial people in this crazy world. They don't get
> pass the current look-and-feel. It is unfortunate enough because they
> cannot see the true beauty behind Smalltalk.

It is not superficial to look at Squeak and run away screaming as soon
as you see it, in fact it's the exact reaction of the vast majority of
developers who open up an image for the first time and it's quite a
normal reaction.  It looks and feels like an ugly toy rather than a
serious development environment and it's Squeak's fault, not the
developers.

If it looks like a toy, then it shouldn't pretend to be otherwise.  If
it's going to claim itself a serious platform that real work can be done
on, then it needs to look and behave that way.  The Pharo guys
understand this, but I don't think Squeak ever will.

Progress and backwards compatibility are fundamentally opposing forces,
those insisting on backwards compatibility are the ones preventing
progress.  Those insisting on the monolithic image of unmaintained
packages are preventing progress.  The Pharo guys had the right idea,
break from the community containing those people so those things can be
dropped and some progress can actually made instead of the yearly
endless "future of Squeak" posts that always seem lead to doing nothing.

My money's Goran's first scenario: Pharo continuing to steal developer
mind share and Squeak slowly stagnating and dying off.

Ramon Leon
http://onsmalltalk.com

> Progress and backwards compatibility are fundamentally opposing forces,
> those insisting on backwards compatibility are the ones preventing
> progress.

Because they are opposing forces, we need to balance them. What you say
could be completed with: those insisting in progress are the ones
preventing actual software to be implemented.

What is the point of progress if you can't harvest it ? Don't you see
the drawbacks of a permanently moving target ?

Stef

Em 29-06-2009 16:03, Stéphane Rollandin escreveu: While I was working at the Secretaria de Estado da Educação de São Paulo
that was the way some people found to prevent any action to be
effective: if something is not excellent/optimum, then it is not worth
to be considered. And in this search for excellence they didn't have
even reasonable/average solutions.

I cannot figure how Pharo will deal with the problem of neglecting
backwards compatibility let's say 5 years from now. Will they deploy
only excellent software???? Nothing will get obsolete???? They'll rise
funds to pay people to fix things every time something gets broken by a
new non-backwards compatible image???? Will people be forced to work
with paleolithic images????

About l&f, squeak-dev has a nice one and professional enough.

2009/6/29 Stéphane Rollandin <[hidden email]>:
> At this point I'm just puzzled. Why would people so deeply in love with the
> edit-compile-cycle they find it hard to live without it even consider
> Smalltalk (or Lisp, for that matter) in the first place ? I'm lost. Maybe
> you should start by selecting a bit more carefully the people you want to
> Squeak-e-vangelize (half-kidding here, no offense intended).

No offence taken. The problem is different. People don't like changes,
people are scared of changes. And going from edit-compile-cycle to
such a different approach, as in Squeak, it's a monstrously big drop.

Please, make no misunderstanding on my intention, it's not about
entirely remodelling Squeak to fit another paradigm. My primary idea
is to make the transition easier with some familiar elements and a
better organization. The rest can be pretty much as we do... let's
just not scare people off at first sight.

> Or, at the contrary: let them experience a big shock that wipes out their
> preconceived ideas about programming. Trying to help them avoid that shock
> may actually make thing more difficult for them in the long term. They have
> to grok that Smalltalk *is* different.

30 years of big shock have proved not to work.
Thank you for trying, come back in your next life.
We cannot perpetuate recipes, which does not work.

2009/6/29 Ramon Leon <[hidden email]>:
> It is not superficial to look at Squeak and run away screaming as soon as
> you see it, in fact it's the exact reaction of the vast majority of
> developers who open up an image for the first time and it's quite a normal
> reaction.  It looks and feels like an ugly toy rather than a serious
> development environment and it's Squeak's fault, not the developers.

Exactly my point. Squeak's fault. Our fault as a community. The sooner
we understand it, the sooner we can improve the situation.

> If it looks like a toy, then it shouldn't pretend to be otherwise.  If it's
> going to claim itself a serious platform that real work can be done on, then
> it needs to look and behave that way.  The Pharo guys understand this, but I
> don't think Squeak ever will.

Amen. The first sentence alone summarize well the idea.

> Progress and backwards compatibility are fundamentally opposing forces,
> those insisting on backwards compatibility are the ones preventing progress.
>  Those insisting on the monolithic image of unmaintained packages are
> preventing progress.  The Pharo guys had the right idea, break from the
> community containing those people so those things can be dropped and some
> progress can actually made instead of the yearly endless "future of Squeak"
> posts that always seem lead to doing nothing.

The most pressing problem about backward compatibility resides in the
fact that the community does not seem to understand with exactitude
what the backward compatibility needs are. The years have passed and
proposed change are tossed away because it might break compatibility.
It becomes an easy excuse.

Paradoxically, many changes have been brought to Squeak over the years
without much deep-thinking, resulting in a mess and making the
compatibility issue even greater. Are we really supposed to forever
support faulty code and defective designs?

The Squeak community wants backward compatibility, so it be. However,
it has to be defined in a comprehensive and accurate manner, and no
less. I don't want to be served meaningless excuses. Backward
compatibility becomes meaningless when it is used broadly and at any
moment on a system that never had a defined API, except, perhaps,
Smalltalk-80 as a standard.

As Stéphane said, it's important to find the balance in opposing
forces. We cannot entirely ditch the backward compatibility in favour
of progress and, yet, we cannot entirely stick to backward
compatibility because it will hinder progress.

> My money's Goran's first scenario: Pharo continuing to steal developer mind
> share and Squeak slowly stagnating and dying off.

Don't be blasphemous. :)

> Ramon Leon
> http://onsmalltalk.com
>
>

Best regards,
Ian.

--
http://mecenia.blogspot.com/

>> Or, at the contrary: let them experience a big shock that wipes out their
>> preconceived ideas about programming. Trying to help them avoid that shock
>> may actually make thing more difficult for them in the long term. They have
>> to grok that Smalltalk *is* different.
>
> 30 years of big shock have proved not to work.
> Thank you for trying, come back in your next life.

Death is the ultimate big shock, indeed.

Stef

2009/6/29 Stéphane Rollandin <[hidden email]>:
>> 30 years of big shock have proved not to work.
>> Thank you for trying, come back in your next life.
>
> Death is the ultimate big shock, indeed.

Hehe! Let's not kill Squeak before its time, all right? =)

Ian.
--
http://mecenia.blogspot.com/

  > The most pressing problem about backward compatibility resides in the
> fact that the community does not seem to understand with exactitude
> what the backward compatibility needs are. The years have passed and
> proposed change are tossed away because it might break compatibility.
> It becomes an easy excuse.

No, I don't think that's true. Maybe I'm too much on the defensive side
but I definitely remember several occurences of me having to raise
concerns about proposed changes, just for the sake of protecting my own
work. So I don't feel the community at large is over-valorizing backward
compatibility and really tossing away all propositions.

Unfortunately it's not that simple; my feeling is that several more or
less informal groups have different visions about Squeak and actually
fight to impose them. Pharo is one such group having divorced from the
community because it was tired to fight.

One path out of this confusion would be to have a debate about
articulating those different visions, compare them and see what can be
done about their differences. I did try, in my clumsy way, to start such
a debate, years ago, but it did not work.

That was in 2004, almost 5 years ago:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-December/086611.html

... and reading today what I wrote almost 5 years ago, I see that I
don't need to change a word: it's still pretty much the same situation.


> The Squeak community wants backward compatibility, so it be. However,
> it has to be defined in a comprehensive and accurate manner, and no
> less. I don't want to be served meaningless excuses. Backward
> compatibility becomes meaningless when it is used broadly and at any
> moment on a system that never had a defined API, except, perhaps,
> Smalltalk-80 as a standard.

agreed.


Stef

Stéphane Rollandin wrote:
>> Progress and backwards compatibility are fundamentally opposing
>> forces, those insisting on backwards compatibility are the ones
>> preventing progress.
>
> Because they are opposing forces, we need to balance them. What you say
> could be completed with: those insisting in progress are the ones
> preventing actual software to be implemented.

Yes, and in Squeak, they are completely unbalanced, those wanting things
to stay the same have won out over any major progress.  The eToys thing
is a perfect example, it should have been ripped out a long time ago,
the eToy community already forked.  The Squeak version is dead, and
should have been removed but illogical resistance to change prevented it.

> What is the point of progress if you can't harvest it ? Don't you see
> the drawbacks of a permanently moving target ?
>
> Stef

If you can't break compatibility, there is no progress, there is only
stagnation.  The whole point of a version is to be able to break
compatibility with previous versions, to make breaking changes, to
correct mistakes of the past and make progress.  Harvesting is the wrong
approach, it only works for small changes.  You don't harvest big
rewrites, you upgrade to a new image and reload your code fix whatever
your unit tests determine is now broken.

The idea of an ever evolving monolithic image that is continually
patched into being current is just dead or dying.  What works today is a
small core image and loadable packages with unit tests so images can be
rebuilt anytime, especially between versions.  Unmaintained packages
*should* die.

No one is forced to upgrade to the new version, if someone wants
compatibility, they shouldn't upgrade.  If they want the latest and
greatest, then porting their code to newer versions and fixing what they
broke is the price they pay, it must be that way necessarily.  Otherwise
there is no point in having new versions.

The drawbacks of a moving target are much less severe than the drawbacks
of a stagnant and dying community which will be the end results of a
attitude of not allowing breaking changes and progress.  People keep
forking Squeak because the Squeak community is utterly directionless and
resistant to change because that's the nature of any organization led by
a committee elected by diverse groups of people who don't share a common
goal.

Pharo is what Squeak should have been, a place for people who actually
do the work to build what they want and not be held back by those who
don't and just have strong opinions and don't want things to ever
change.  The people actually doing the work should be the only people
with any final say about what does or doesn't get done and what
direction things should go.  The only way to challenge the removal of
old, bad, or dead code should be to volunteer to step up and maintain it.

--
Ramon Leon
Chief Technical Officer
Alliance Reservations Network
IM Identities: gnaritas@aol, gnaritas2002@yahoo, ramon.leon@gmail
Work: 602.889.5547
Fax: 602.224.9896

2009/6/29 Stéphane Rollandin <[hidden email]>:

Stéphane,

There are definitively merits in favour of backward compatibility.
Changes should probably be brought at a slower pace: small changes in
minor versions, bigger changes to be expected in major versions.
Hardly any news here. Migration tools to help maintainers should be
considered. It's possible to make progress and change coexist, we have
to figure out what will work in the Squeak community.

How hard would it be to implement migration tool(s) in Squeak? Anyone? Ideas?

> ... and reading today what I wrote almost 5 years ago, I see that I don't
> need to change a word: it's still pretty much the same situation.

Yes. And it will come back as long as the situation is not resolved.


What kind of maintenance do you have to do on your projects when
changes are brought? What packages are your projects based on? You
have to open up a little bit if you hope the community to find a
suitable solution.

Ian.

--
http://mecenia.blogspot.com/

Hi!

Ramon Leon wrote... ah what the heck - just read his post - I agree with
100% of what he wrote. Perfectly phrased. :)

Now... at the end Ramon writes:
 > The people actually doing the work should be the only people
> with any final say about what does or doesn't get done and what
> direction things should go.  The only way to challenge the removal of
> old, bad, or dead code should be to volunteer to step up and maintain it.

This opens up an idea... I know that Steph got totally frustrated on
squeak-dev when he eventually "gave up" and started Pharo.
I even wrote to him privately the other day that the "trick" is to have
a selective ear. But that is not easy.

The key problem is that it can be very hard to separate "doers" from
"talkers" on squeak-dev. Lots of people post, lots of people have
opinions - BUT... only a subset of the people with strong opinions
actually contribute with code.

Ok, so sure, this may be elitist thinking and it may be a *really bad*
idea - but since we are throwing ideas on the wall to see what sticks
here goes:

Perhaps there should be a list for only people with "commit bit"? When
decisions are to be made then that list is used so that developers can
ask the others for opinions etc and only active committers have ability
to post. The list should be public though.

Crazy? Perhaps. But an idea. Because my perception is that the subset of
active committers very often tend to AGREE on the course of action.

regards, Göran

On Mon, 2009-06-29 at 13:29 -0700, Ramon Leon wrote: I didn't want to participate at all in this thread but reading your post
I feel the need to fully agree.

over and out,

Norbert

2009/6/29 Göran Krampe <[hidden email]>:
I agree that developers (or committers) should gain some sort of
immunity from critics by anyone else, who is not committing.
But making separate list will not help i think. We already have many of them.

And the last thing. Folklore says: the only people who doesn't making
mistakes is one who doesn't doing anything.
So, let the people try & fail, learn on mistakes and do better things.
Lets move to ANY direction, just don't stay as an idols.

> regards, Göran
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

On 6/29/09 6:44 PM, "Igor Stasenko" <[hidden email]> wrote:

> Lets move to ANY direction, just don't stay as an idols.

+10

Edgar

It's not so crazy -- Squeak can be a bit penalized in that there is no
such thing as a "patch mailing list".  From my experience, on a patch ML
fast-talkers usually run out of arguments fast...

Paolo

2009/6/29 Ramon Leon <[hidden email]>:
Well said!
Thank you, Ramon for expressing a perfect and clear vision of current
situation in a perfect english.
I sharing the same. And can sign under every of your word.
I hope some day i will learn how to express my thoughts in similar fashion. :)

> --
> Ramon Leon
> Chief Technical Officer
> Alliance Reservations Network
> IM Identities: gnaritas@aol, gnaritas2002@yahoo, ramon.leon@gmail
> Work: 602.889.5547
> Fax: 602.224.9896
>
>



--
Best regards,
Igor Stasenko AKA sig.

2009/6/29 Igor Stasenko <[hidden email]>:
> I agree that developers (or committers) should gain some sort of
> immunity from critics by anyone else, who is not committing.
> But making separate list will not help i think. We already have many of them.

Those who are not criticized are not working with anyone else. The
moment the community cannot openly criticize Squeak is the moment
Squeak becomes a dictatorship. Squeak is already living in a bubble
and it's not necessary to create another one. The Squeak Oversight
Board has to listen to those critics and decide what to do with them.
Not every critics are meaningless... because what? The person who has
submitted the critic did not contribute? I'll tell you what... to
critic is to contribute. Those who choose to shut up don't do anything
for Squeak.

Now, the community can rightfully expect the critic to go beyond "it's
not good", "I don't like this or that" and so on. It's important to
voice our opinions, ideas, etc. and, more importantly, the reasons
behind them. If someone does not pour efforts into doing actual
contribution, we can at least expect those to make an effort to
express properly their idea. Talking is one step toward common
understanding. Anyway, regardless of the critics, those who actively
contribute to Squeak should have a meaningful voice.

Ian.

--
http://mecenia.blogspot.com/

2009/6/30 Ian Trudel <[hidden email]>:
There are different sorts of critic:
- i looked at your code and your code stinks. Rewrite it here and there.
- i don't like your idea. Don't ever think implementing it.

got my point?

> Ian.
>
> --
> http://mecenia.blogspot.com/
>
>



--
Best regards,
Igor Stasenko AKA sig.

> What kind of maintenance do you have to do on your projects when
> changes are brought? What packages are your projects based on? You
> have to open up a little bit if you hope the community to find a
> suitable solution.

Sure, if it can help if I describe the way I work, I will do so. But
it's not really easy. Let me think about it, so that my rambling can be
somewhat useful.

Stef