> Also like what we did with button labels, shortening them to the first letter when their extent gets too small.


This is indeed an improvement in terms of design, but it does not actually help you to find the right button.


> wherever we currently put a separator break, ---------- , what if it could be a "grayed out" label for that section of menu items which would, whenever the World height was too small, collapse that section into into a cascading menu, and ungray the label..?


Interesting idea :) I never struggled in a situation where a menu was too high, but in this case, it clearly sounds like an improvement to me. In order to give meaning names to these "automatical categories", we would need to revise or current menu design. However personally, I absolutely favor type-to-search in case of any menu that has more than 6 items :).

> Shift+red-click a menu item, you can edit it.  Shift+blue-click it, and you can use the red halo to remove it, or the green-halo to tear it off as a button and place it anywhere, such as the DockingBar.  We just need to make it _remember_ these actions, and put the removed ones under "more..." for retrieval.  Squeak's live configuration is allows the user to do it without having to context-switch.

But users cannot change the default contents of any kind of menu permanently without modifying the underlying code.

> > Plus, this kind of modularity impair universally comprehensible and reproducibly tutorials or screenshots.
> I hope you won't limit your imagination based on that.  No, close your eyes and let it run wild, imagine the most amazing and intuitive UI ever (something like in Minority Report).  Worry NOTHING about the implementation, ONLY the vision, as a user, and what you would want.  THEN make the tutorials and screenshots about THAT!

Well, of course, you're absolutely right :-) Provided that we provide a convenient command search function for all of these commands.

> Have you noticed how many modern consumer products no longer come with owners manuals, just "quick start" cards?  Integrated documentation seems to be a thing...  :)

I come from a generation that never consults an owner manual for an application until physical coercion is applied :) Intuitivity first, always, ever, of course! That's the way I learned Squeak until now, so we are not on a bad path.
However, a quick start guide sounds interesting, too :) This would also be a nice project for Squeak: If the user opens the MCBrowser the first time, for example, a decent pop-up could lead him or her to the most popular few buttons of the dialog and guide him or her how to make their first commit. Also see TipOfTheDay<https://github.com/LinqLover/Squeak-TipOfTheDay> for this more ideas.

Best,
Christoph

________________________________
Von: Chris Muller <ma.chris.m at gmail.com>
Gesendet: Donnerstag, 23. Januar 2020 22:36 Uhr
An: Thiede, Christoph
Cc: The general-purpose Squeak developers list; ralphpboland at gmail.com
Betreff: Re: [squeak-dev] variable assignments button


> It wasn't really meant as a proposal as much as an "example" of how we do it with our object oriented UI.  Since that is already available on the Class menu (also as Cmd+a on that pane, which is how I usually access it), we will have to decide whether we want to lengthen the already-long text menu, as you alluded to below..

In your previous message, you convinced me that it would be a better user experience to select the subject first and the operation second.

Great!  :)

This workflow is not supported by <cmd>a.

Very true.  The MC Browser also forces me into the "operation first, subject second" workflow.  I definitely prefer your Inbox submission for the workflow dimension, but..

But yes, the current text morph menu is way too long.

.. yep.  :)  On small screens, some menus end up taller than the screen.

Maybe we should clean it up at some time (for example, by extracting all find/"* with it" items into one submenu ... just an idea).

> Maybe the button row could morph itself automatically into one of those based on size and number of truncated labels..  :)   Another idea, ability to select which functions one wants at each place...   :-o   :)

Ah, that sounds a bit like MS (Office) Ribbons :) They are indeed a good example of how to keep a UI quite clear.

Also like what we did with button labels, shortening them to the first letter when their extent gets too small.  I ended up liking that, and could imagine something similar with menus, wherever we currently put a separator break, ---------- , what if it could be a "grayed out" label for that section of menu items which would, whenever the World height was too small, collapse that section into into a cascading menu, and ungray the label..?

Free configurability of each menu and button bar is a cool thing, but when I think at Visual Studio, for example, there were so many command lists to be adjusted that I actually never managed to adjust any of them.

"Command lists?"  It sounds like they buried it into some tab on a modal "Preferences" panel?  The Squeak way is "live" configuration.  Shift+red-click a menu item, you can edit it.  Shift+blue-click it, and you can use the red halo to remove it, or the green-halo to tear it off as a button and place it anywhere, such as the DockingBar.  We just need to make it _remember_ these actions, and put the removed ones under "more..." for retrieval.  Squeak's live configuration is allows the user to do it without having to context-switch.

Plus, this kind of modularity impair universally comprehensible and reproducibly tutorials or screenshots.

I hope you won't limit your imagination based on that.  No, close your eyes and let it run wild, imagine the most amazing and intuitive UI ever (something like in Minority Report).  Worry NOTHING about the implementation, ONLY the vision, as a user, and what you would want.  THEN make the tutorials and screenshots about THAT!  Maybe it'd even be a self-teaching, user-guiding UI, like in video games, so you wouldn't even need them.  Have you noticed how many modern consumer products no longer come with owners manuals, just "quick start" cards?  Integrated documentation seems to be a thing...  :)

Best,
  Chris

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