[squeak-dev] Separate documentation (was: Default preferences)

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Sat Nov 27 22:56:53 UTC 2021


Hi Timothy,


> then I will gladly generate a PreferencesHelp


Your contributions for documentation on Squeak are very welcome, but IMHO separate help documents that mirror the structure of the subject are not the most efficient way to go. What I think could help us better would be:


  *   A short summary of preferences that are relevant for different user groups, such as newbies, developers, or core developers - our current general-purpose summary is the preference wizard, but it might benefit from some minor refinements. Hypothetically, we could model different user roles here with a small drop-down menu or something like this - but this should be discussed beforehand on the list.
  *   Better categories for all the existing preferences - for example, some preferences are in the Morphic category which IMHO would belong to 'tools' instead. The current inconsistent spelling is also slightly distracting.
  *   A list of preferences that we should deprecate - beware, there is already deleteUnusedPrefs.cs on the list.
  *   Maybe some improved helpStrings of the preference items themselves.

You can see all existing preferences in the preference browser if you select the "--all--" category. If you really need this, you can query them via "Preferences allPreferences".

But IMHO separate help documents should be used with caution - in my experience, they are looked up significantly rarer than help content that is integrated right into the domain (method comments, class comments, tooltips, maybe help buttons). Interactivity is a great strength of Squeak and Morphic. We should not impair it by introducing additional spatial or semantic distances [1]. Plus, separate content tends to get out of sync. Interactive tutorials that guide you through a tool when you open it the first time would be very cool if you would like to engage more in this field.

Anyway, this is just my personal view, and I'm happy whenever you can present me an opposite one. :-)

Best,
Christoph



________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von gettimothy via Squeak-dev <squeak-dev at lists.squeakfoundation.org>
Gesendet: Samstag, 27. November 2021 22:51 Uhr
An: squeak-dev at lists.squeakfoundation.org
Cc: squeak-dev at lists.squeakfoundation.org
Betreff: Re: [squeak-dev] Default preferences

Not to interrupt,


but if an output of all preferences (along with method category and 'target' if such thing exist)  then I will gladly generate a PreferencesHelp.


It may help you kind folks offload these decisions to  more experienced users while reducing the amount of preferences to be considered for  release purposes.



Just post a Doit for me and I will git-r-done.


Cordially


tty


---- On Sat, 27 Nov 2021 15:16:45 -0500 mail at jaromir.net wrote ----

Could be just me, but I always hide flaps - would it be something for the PreferenceWizardMorph? Or hiding some menus - like Projects?

Also, the last 'page' offering extra packages - would it be possible to include Inbox Talk?

Thanks,


^[^ Jaromir
--

Sent from Squeak Inbox Talk

On 2021-11-23T09:44:29+01:00, marcel.taeumel at hpi.de<mailto:marcel.taeumel at hpi.de> wrote:

> Hi all --
>
> There is no need to change the default values for the preferences that are in the PreferenceWizardMorph. Let's focus on whether some interesting preferences are missing from that morph and on the values for preferences not in that morph.
>
> Best,
> Marcel
> Am 23.11.2021 00:13:44 schrieb tim Rowledge <tim at rowledge.org>:
> >> 1. Windowing
> >> Personally, the first thing I do in every new image is to enable these prefs:
> >> "mouse over for keyboard focus", "open tools attached to mouse cursor", "windows' contents are always active".
> >> Do I belong to a minority of Squeakers or could we satisfy a majority of Squeakers by turning on these prefs by default?
>
> Well *I* wouldn't be happy with them but then I immediately load my prefs file anyway so maybe I wouldn't even notice.
>
> > For myself I'd add "Embed a Transcript in a Workspace" because I use and move both around the screen all the time; and frankly, since my first encounter with Squeak I always wondered why I have to open two tools, one of which has a totally nuts name, in order to be able to print "Hello" ;)
>
> But a Transcript is fundamentally different to a Workspace; the former is for the system to tell you what is going on, not for scribbling notes.
>
>
> >> 4. Editing
> >> - Auto enclose brackets -> #beforeSpaces (see [1], pending. Inserting a bracket pair () right before a character just feels pretty useless to me.)
> >> - Enclose selection with brackets -> true
>
> Again, very not OK for me.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Hackers have kernel knowledge.
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211123/cba9e528/attachment.html>
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211127/e13ecdb4/attachment.html>


More information about the Squeak-dev mailing list