[squeak-dev] Saving the default image when one starts it for the first time

John-Reed Maffeo jrmaffeo at gmail.com
Sat May 19 02:23:15 UTC 2018

What is the "New User Experience" we are trying to support?  Who is the
"New User" we are trying to reach? The All-In-One distribution is really
cool for demonstrating the power of Squeak but it becomes problematic for
doing any kind of development work because the files are, well, like Tim
said.  I agree with Chris that we want AIO to be a "first kiss" kind of

My personal use cases for AIO are performing cross platform testing and the
occasional demonstration showing SameGame running on three different
platforms from the same launch point on the network. AIO is an APP Squeak
is a POWERTOOL (that can be used to create really neat apps).

For this particular issue, my suggestion is to have a special dialog when
the user *closes* the image and explain why it is good to save the image
with a new name when you are working with a new release.

I see Bob Arning's first comment below, I agree with that. The first thing
I do with a new image down load is unzip it and put the zip file in the new
folder. If I am downloading individual zipped artifacts I put the zipped
file in whatever folder I put it in.

My suggestion is to keep the AIO simple, for first time users. 1. A 32 bit
version that will run on most (all?) current, supported platforms. 2. A
readme.txt file with some notes about possible pit falls that might happen
(DANG! moments?) and how to recover 3. An in-image survey  that asks
questions about the users experience when saving/closing the image.

Do we have any idea about how many downloads are performed? Is it worth the
effort? Is the Squeak Beginners mailing list given prominent attention (do
we want to give it prominent attention or point them to one of the social
media sites for programmers (superuser stackoverflow ?). I forget sometimes
that we have millions of potential new users all over the planet that we
want to come play in our #World. Which point on the bell curve of potential
users do we want to aim for?

My concept for the AOI image is an easy to run multi-platform distribution,
for a first time user, with low to medium experience,  to expand their
experience with exposure to Smalltalk and provide them with a pathway to
the land of []. Once a new user is ready to worry about nuts and bolts of
doing actual, productive development using a standard installation (.image
.changes .sources and the right VM in a folder - Hi Edgar), they are ready
to do a clean install and start working with Squeak the way the Dogs

The people who are doing the heavy lifting can decide, however, I think
that there is more value in providing compelling content, stuff like: a
guided example of how to write a "Hello, World!" program 15 different ways,
how to download new projects (oh, OH, there are games out there!),
something from Fun Squeak every time they  launch a new session, or as
Easter Eggs as they explore the environment; just not every thing at once.



On Fri, May 18, 2018 at 10:25 AM, Chris Muller <asqueaker at gmail.com> wrote:

> (I see you created a separate thread for this at the same time I
> responded in the Meeting Notes thread, so I pasted my take from that
> thread below, for continuity in this thread, sorry!)
> New users' first experience upon launching Squeak should be an
> immediate commencement of their journey to discovery and wonderment,
> not a tedious and meaningless (to them) message that tasks
> them with some chore they couldn't possibly care about at that point.
> Many would bail right then and there.  Personally, I think most users
> that would use a system like this would know about files and folders
> and would simply re-unzip it, but if you feel strongly the system
> should hold their hand then lets actually hold it by handling it for
> the user *automatically*.   A tweak to the launcher scripts included
> in the All-In-One.  Simply change the script to make a copy of the
> "master" and then launch the copy.  If  the copy already exists (i.e.,
> from last time), launch it instead of copying it over.  Then, we
> simply include a "factory-reset" script which deletes the copy.  Done.
> On Thu, May 17, 2018 at 4:20 PM, tim Rowledge <tim at rowledge.org> wrote:
> > I've long tried to argue that the release images ought to start up in
> state where they insist on being saved under a new, user chosen name as the
> first (or nearly) action. This way the release image (and changes) could be
> locked, guaranteeing that there is a clean image on-disk for the inevitable
> "Dang!" moment. This seems to me to apply doubly for the all-in-one systems
> since those release images are buried so deep in directories that you have
> to look up to see the Mohorovičić discontinuity far above you.
> >
> > What I claim ought to happen is that the current and very excellent
> preferences wizard should be extended to open a file saver dialog and
> insist on the image being saved. We would need to do some directory path
> parsing to make sure that we actually offer a realistic directory and not
> the /Users/tim/Documents/Squeak/Squeak-5.0-All-in-One.app/
> Contents/Resources/Squeak5.0-15113.image path I see on my iMac; I'd posit
> that find the all-in-one part and chopping just before it might be adequate.
> >
> > I can see one situation where this might cause a problem that needs some
> thought; when using a script to prepare an image eg the VMMaker build
> scripts. I see the 'NukePreferenceWizardMorph.st' in the vmmaker build
> scripts which removed the pref wizard ok, but it still leaves the image
> being saved over the original. Strictly speaking this is very unlikely to
> be a serious issue with the vmmaker regime because we almost always load
> the images into the mv/image working directory, but it's a poor example to
> have around. Changing to make the 'NukePreferenceWizardMorph.st' save the
> image under the new name and then dropping the copy in
> buildspurtrunkvmmakerimage.sh might be nicer?
> >
> > Next question is whether anyone can think of serious problems with
> making this change?  And then, how to implement it cleanly?  I *think* it
> might work to over-ride #delete in PreferenceWizardMorph which is sent when
> the chance to configure is declined right up-front, or when the user clicks
> on 'Done'.
> >
> >
> > tim
> > --
> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > Strange OpCodes: CAO: Compare Apples to Oranges
> >
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180519/a85c04ed/attachment.html>

More information about the Squeak-dev mailing list