On Fri, Jan 24, 2020 at 3:29 PM Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:

> > 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.
>

For example of menu overflowing vertical space: WorldMenu/ new morph.../
from alphabetical list/

Many of the sub menus there will overflow vertical space, unless you have a
very tall screen.

Best,
Karl




> 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/de7bc302/attachment-0001.html>