Saving the default image when one starts it for the first time
Locked
Saving the default image when one starts it for the first time
 
|
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; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: CAO: Compare Apples to Oranges |
Re: Saving the default image when one starts it for the first time
|
|
(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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim > Strange OpCodes: CAO: Compare Apples to Oranges > > > |
Re: Saving the default image when one starts it for the first time
|
|
In reply to this post by timrowledge
some thoughts - isn't the user likely to have the zipped version of the image/changes in case of DANG! moments? - couldn't the all-in-one have an extra copy
of the image/changes and a simple "Revert to factory defaults"
button to wipe away mistakes? On 5/17/18 5:20 PM, tim Rowledge 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; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: CAO: Compare Apples to Oranges |
Re: Saving the default image when one starts it for the first time
|
|
In reply to this post by Chris Muller-3
> On 17-05-2018, at 2:40 PM, Chris Muller <[hidden email]> wrote: > 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. I have to disagree there; I wouldn't consider it tedious nor meaningless. It's a single dialogue action and an educational moment. > 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 yet decades of experience of people with little experience trying out Smalltalk systems suggests otherwise to me. Think of it like opening a template document in a word processor. > 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. That would be a perfectly fine approach too. It does prevent the user choosing a name, but that may be positive or negative. It could be implemented in the image rather than us having to write shell equivalent scripts for several systems. Then again, we likley need to do that anyway to cater for 32/64 bit stuff. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- S p a c e d o u t . |
Re: Saving the default image when one starts it for the first time
|
|
>> On 17-05-2018, at 2:40 PM, Chris Muller <[hidden email]> wrote:
>> 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. > > I have to disagree there; I wouldn't consider it tedious nor meaningless. It's a single dialogue action and an educational moment. To get to the "Dang moment", you have to have a user who 1) launched Squeak already, 2) did something which caused them to want to "start over", 3) then answered "Yes" to the question, "do you want to save this image?", and then finally, 4) relaunched it only to find the system did exactly what they asked it to do. THAT is an educational moment. The moment when the user launches Squeak the very FIRST time, is when they're expecting to be dazzled by Squeak, not have Squeak expecting something from THEM -- to think up a "name" when they don't even know yet what it is they're supposed to be naming or why, because they don't have the context of the "dang moment" yet. The proposal would distract every new users' "first-kiss moment" (i.e., the one you never forget), to target these very rare "dang-moment" cases, and only the ones of those who didn't simply re-unzip ("clean install"), and only for the very tiny fraction of their (potential) life with Squeak when they're still "discovering", before getting their system properly installed for proper long-term use. >> 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 yet decades of experience of people with little experience trying out Smalltalk systems suggests otherwise to me. Think of it like opening a template document in a word processor. > >> 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. > > That would be a perfectly fine approach too. It does prevent the user choosing a name, but that may be positive or negative. Your proposal would require them to be able to choose a name as well, but if the user is ready to use multiple images, they've pretty much graduated from the All-In-One, and ready to move to a proper setup instead of the demo. The All-In-One did precisely what it's intended to, and nothing it isn't. > It could be implemented in the image rather than us having to write shell equivalent scripts for several systems. Here it is: if [ -f $TEMPIMAGE ]; then echo "Welcome to Squeak!" else cp $MASTERIMAGE $TEMPIMAGE spur $TEMPIMAGE Please don't put all new users through that question, and complexify the image to do it. Best, Chris > Then again, we likley need to do that anyway to cater for 32/64 bit stuff. > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Useful random insult:- S p a c e d o u t . > > > |
Re: Saving the default image when one starts it for the first time
|
|
The user experience I'd go for is something like this: - user downloads new Squeak release - runs Squeak - does something - saves image - quits - runs Squeak again - by default, sees her/his modifications - but there should be an option to "start clean" (using the release image) This would avoid the "please save the image in a different location" dialog, saving would just default to a location different from the release image (*) We had something almost like this for the OLPC Etoys release. The image was installed in /usr/local/share which is not writable by the user. Saving defaulted to a user directory. The VM startup script would check if there was an image in the user directory. If so it would run that, otherwise the system image. Something similar could work for Squeak. The main problem would be to have a VM mechanism for selecting an image you want to run on startup. - Bert - (*) That said, forcing the user to choose a location on first time startup would be okay too, and better than what we have now |
Re: Saving the default image when one starts it for the first time
|
|
> On 17-05-2018, at 5:25 PM, Bert Freudenberg <[hidden email]> wrote: > > The user experience I'd go for is something like this: > > - user downloads new Squeak release > - runs Squeak > - does something > - saves image One of the complications we have to face is that a lot of Mac users are getting used to the idea of *not* saving files, as the apps do so on a frequent basis. Does Windows do anything like that? > - quits > - runs Squeak again > - by default, sees her/his modifications No, I think if you just run Squeak you should get a default image (or preferably a copy in some manner). If you d-click on a particular image you get that image. That still seems to be the norm so far as I can see. It's like opening Word (shudder) or other apps - you get a default or a template chooser, But if you open a particular file, you get that file. > - but there should be an option to "start clean" (using the release image) > > This would avoid the "please save the image in a different location" dialog, saving would just default to a location different from the release image (*) > > We had something almost like this for the OLPC Etoys release. The image was installed in /usr/local/share which is not writable by the user. Saving defaulted to a user directory. The VM startup script would check if there was an image in the user directory. If so it would run that, otherwise the system image. > > Something similar could work for Squeak. The main problem would be to have a VM mechanism for selecting an image you want to run on startup. > > - Bert - > > (*) That said, forcing the user to choose a location on first time startup would be okay too, and better than what we have now > tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim ASCII to ASCII, DOS to DOS. |
Re: Saving the default image when one starts it for the first time
|
|
In reply to this post by Bert Freudenberg
One of the first thing I was told when I started in Smalltalk was to keep a backup of the base/clean image. Do we *really* need a dumb-proof mechanism for *THAT* ?!?!?! I mean is it *that* difficult a concept to grasp ?!?!?!?!?!?!?!?!?!?! ----------------- Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein) |
Re: Saving the default image when one starts it for the first time
|
|
Sure, backup etc is and was possible (manually copying files in the
file system). But why not have a script to handle this? These days an enhanced user experience useful for a wide audience is good thing to implement. --Hannes On 5/18/18, Benoit St-Jean via Squeak-dev <[hidden email]> wrote: > One of the first thing I was told when I started in Smalltalk was to keep a > backup of the base/clean image. Do we *really* need a dumb-proof mechanism > for *THAT* ?!?!?! > > I mean is it *that* difficult a concept to grasp ?!?!?!?!?!?!?!?!?!?! > > > ----------------- > Benoît St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) |
|
|
In reply to this post by Bert Freudenberg
On Friday 18 May 2018 05:55 AM, Bert Freudenberg wrote:
> We had something almost like this for the OLPC Etoys release. The image > was installed in /usr/local/share which is not writable by the user. > Saving defaulted to a user directory. The VM startup script would check > if there was an image in the user directory. If so it would run that, > otherwise the system image. +1. Images could be saved in $XDG_DESKTOP_DIR/squeak/. NetMorph generated a small random (readable) name for saving which also works out well. This is simple enough for beginners but could be overridden by advanced Squeakers. These days, most beginners prefer to open their files rather than start an app and then open the file within the app. > Something similar could work for Squeak. The main problem would be to > have a VM mechanism for selecting an image you want to run on startup. I would rather not reinvent the wheel and bloat the vm. xdg[1] already does most of the job for common desktops like GNOME/KDE etc. We could use xdg-utils[2] commands to pick up settings at launch time and use xdg-open to launch images. There is a one-time pain in generating mimetypes[3] for every image variant and the corresponding *.desktop spec for various vms (stack/cog/spur etc). [1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html [2] https://www.freedesktop.org/wiki/Software/xdg-utils/ [3] https://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec/ Regards .. Subbu |
Re: Saving the default image when one starts it for the first time
|
I think that most of the clean-up code in ReleaseBuilder should be enough for the average user to clean up the own image again. So, we just need to add some UI to "Reset this image to factory defaults" or something. The advanced user may not need such a mechanism. Best, Marcel
|
Re: Saving the default image when one starts it for the first time
|
|
In reply to this post by timrowledge
Like more the old approach of having .image .changes .sources and the right
VM in a folder On 17/05/2018, 18:20, "tim Rowledge" <[hidden email]> wrote: > 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. |
Re: Saving the default image when one starts it for the first time
|
|
In reply to this post by marcel.taeumel
> On 17-05-2018, at 11:47 PM, Marcel Taeumel <[hidden email]> wrote: > > I think that most of the clean-up code in ReleaseBuilder should be enough for the average user to clean up the own image again. So, we just need to add some UI to "Reset this image to factory defaults" or something. I'm not seeing how that would be possible for any meaningful amount of changes; sure, resetting various preferences can be done but that's a very long way from 'go back to default image'. We have been previously discussing how to deal with having 32 & 64 bit image and supporting VMs, along with the expanded world of v3 images etc. That is pretty much predicated on having an image path to use to work out which vm is needed. We surely ought to be able to decide on a default image when none is specified, copy it to a 'proper' place and then use the aforementioned logic to start the right vm with that image. That should work with likely cases - starting Squeak with no image specified via a command line starting Squeak by clicking on a desktop icon starting an image via commandline with a specified image starting by clicking on a image file, so long as you've set the filetype to executable association correctly maybe even just trying to execute an image could work - kinda like having !#/bin/sh/squeak-starter at the beginning of the image? Likely doesn't translate well though. Do many OS's have a commandline equivalent to 'run this file by looking up its filetype-> executable rule? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- When a thought crosses her mind, it's a long and lonely journey. |
|
|
In reply to this post by Chris Muller-3
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 experience. 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 intended. 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. fwiw, jrm On Fri, May 18, 2018 at 10:25 AM, Chris Muller <[hidden email]> wrote: (I see you created a separate thread for this at the same time I |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |