Hi everyone,
With Guille we are trying to improve the usability of the WorldMenu. The world menu is by large un-intuitive: - Users are not used to click on a background to open a menu - For those that "get it" they try to do it with right click (Of course, it looks like a context menu!) and that does not work Since some decades now the default way to display a menu in applications is to have a bar at the top of the windows. We should change that world menu by a menu bar like any application. That will lower the entrance barrier to new users, at the cost of having to move the cursor to the top to look for the menu... You can find here a PR that add the WorldMenu as a top bar to Pharo and reorganize it: https://github.com/pharo-project/pharo/pull/1470 See screen in the PR. It still have room for improvements but we think it's stable enough for integration in Pharo. Missing features: - What do we do when Pharo is not wide enough? - What to do when a window is dragged behind? - Make it parametrizable to allow users to build a bar with their own menu builder - Add shortcuts to open the menu windows like (maybe) - Update it when we change the font size (this is a general Pharo problem) Feedback is welcome. Related issue: https://pharo.fogbugz.com/f/cases/22038/Replace-World-Menu-by-Menu-bar Guille & Cyril -- Cyril Ferlicot https://ferlicot.fr |
Hi Guille & Cyril,
On 1 June 2018 at 14:22, Cyril Ferlicot D. <[hidden email]> wrote: > Hi everyone, > > With Guille we are trying to improve the usability of the WorldMenu. > > The world menu is by large un-intuitive: > - Users are not used to click on a background to open a menu > - For those that "get it" they try to do it with right click (Of > course, it looks like a context menu!) and that does not work > > Since some decades now the default way to display a menu in applications > is to have a bar at the top of the windows. We should change that world > menu by a menu bar like any application. That will lower the entrance > barrier to new users, at the cost of having to move the cursor to the > top to look for the menu... > > You can find here a PR that add the WorldMenu as a top bar to Pharo and > reorganize it: > > https://github.com/pharo-project/pharo/pull/1470 > > See screen in the PR. > > It still have room for improvements but we think it's stable enough for > integration in Pharo. > > Missing features: > - What do we do when Pharo is not wide enough? > - What to do when a window is dragged behind? > - Make it parametrizable to allow users to build a bar with their own > menu builder > - Add shortcuts to open the menu windows like (maybe) > - Update it when we change the font size (this is a general Pharo problem) > > Feedback is welcome. Thanks for this. Along with being able to maximise windows completely, making the task-bar distinct at the bottom, these are great changes. Instead of a menu bar at the top, which takes quite a bit of space, and as mentioned may not fit on a small screen (especially if applications add entries), how about a "Start" button in the task-bar that pops up the menu a-la Windows? I'm not tied to the name "Start", it could just be an earth icon, which would save space. (This is actually how I interpreted Cyril's original suggestion) Cheers, Alistair > Related issue: > https://pharo.fogbugz.com/f/cases/22038/Replace-World-Menu-by-Menu-bar > > Guille & Cyril > > -- > Cyril Ferlicot > https://ferlicot.fr > |
In reply to this post by CyrilFerlicot
Hi, I really love this idea. I've already added (hacked together) something similar for some of my projects so I am happy to see this is going into Pharo.
> - Make it parametrizable to allow users to build a bar with their own menu builder
I would love if it was possible to somewhere (Settings?) just specify a pragma that should be used for the construction of the menu... or perhaps even a list of pragmas. That way the existing mechanism can be simply reused and custom menus can be created just as easily. I think this should be very easy to add. I would really love to have this option also for the regular world menu, but I didn't find a way to easily achieve that. >
- What do we do when Pharo is not wide enough?
Hamburger menu? >
- What to do when a window is dragged behind?
Currently you cannot drag window above the top side (which I've learned only now :-D ), so the constraint would just move a bit lower? Also, is it (easily) possible to configure the position of the menu? Both top/down, as well as RTL and LTR direction (or right-aligned LTR) which I mentioned for the bottom menu in an earlier github discussion. Peter On Fri, Jun 1, 2018 at 2:22 PM, Cyril Ferlicot D. <[hidden email]> wrote: Hi everyone, |
In reply to this post by alistairgrant
>
- For those that "get it" they try to do it with right click (Of course, it looks like a context menu!) and that does not work I thought that this was due to be swapped for Pharo 7? Was that idea scraped? Peter On Fri, Jun 1, 2018 at 3:18 PM, Alistair Grant <[hidden email]> wrote: Hi Guille & Cyril, |
In reply to this post by alistairgrant
>Guille & Cyril wrote> > > Since some decades now the default way to display a menu in applications > > is to have a bar at the top of the windows. Alistair wrote >> Instead of a menu bar at the top, which takes quite a bit of space, >> and as mentioned may not fit on a small screen how about a "Start" >button in the task-bar that pops up the menu a-la Windows So this basically reduces to the two UI options: 1. Should Pharo look like an application (and have the menu at the top) 2. Should Pharo look like an OS itself (with a primary "Start" menu in the taskbar as on Windows) Maybe we should support both styles using a setting. Bye T. |
In reply to this post by alistairgrant
On 01/06/2018 15:18, Alistair Grant wrote:
> Hi Guille & Cyril, > > Thanks for this. Along with being able to maximise windows > completely, making the task-bar distinct at the bottom, these are > great changes. > Yes, I did not see the problem because I use backgrounds and it was visible :) > Instead of a menu bar at the top, which takes quite a bit of space, > and as mentioned may not fit on a small screen (especially if > applications add entries), how about a "Start" button in the task-bar > that pops up the menu a-la Windows? I'm not tied to the name "Start", > it could just be an earth icon, which would save space. (This is > actually how I interpreted Cyril's original suggestion) > Personally, I would like to have display strategies for the WorldMenu and the user could select the one he likes (because nobody will agree on UI). For example: - Menu bar strategy - World menu strategy - Start button strategy - Composite strategy to have multiple ones Now it is simple to do the two first, but I will probably not have the time to implement the "Start button" one. > Cheers, > Alistair > > > -- Cyril Ferlicot https://ferlicot.fr |
In reply to this post by Peter Uhnak
On 01/06/2018 15:25, Peter Uhnák wrote:
> Hi, > > I really love this idea. I've already added (hacked together) something > similar for some of my projects so I am happy to see this is going into > Pharo. > >> - Make it parametrizable to allow users to build a bar with their own menu builder > > I would love if it was possible to somewhere (Settings?) just specify a > pragma that should be used for the construction of the menu... or > perhaps even a list of pragmas. That way the existing mechanism can be > simply reused and custom menus can be created just as easily. > I think this should be very easy to add. > I don't know if it should be in the SettingBrowser since Pharo currently comes with only one menu (if someone know how to implement a new one it will be easy for him to find the option to change the pragma of the MenuBarMorph), but the pragma should be parametrizable in any case. > I would really love to have this option also for the regular world menu, > but I didn't find a way to easily achieve that. > >> - What do we do when Pharo is not wide enough? > > Hamburger menu? I'll rephrase, we have ideas to manage all those problems but how do we implement it? Currently there is no widget to do that and sadly we don't have enough time to create them :( > >> - What to do when a window is dragged behind? > > Currently you cannot drag window above the top side (which I've learned > only now :-D ), so the constraint would just move a bit lower? Yes, but for now when can detect a drop on the menu bar only if the cursor is over the MenubarMorph. If the user drop the window by dragging the bottom, the top of the windows will be under the MenubarMorph. > > Also, is it (easily) possible to configure the position of the menu? > Both top/down, as well as RTL and LTR direction (or right-aligned LTR) > which I mentioned for the bottom menu in an earlier github discussion. > For now I don't think so. I think it would be cool to integrate this first version then everyone can try to improve it. > Peter > > -- Cyril Ferlicot https://ferlicot.fr |
Administrator
|
In reply to this post by Peter Uhnak
Peter Uhnák wrote
> I really love this idea. I've already added (hacked together) something > similar for some of my projects so I am happy to see this is going into > Pharo. Were these projects where you were the only user? I'm very leery of this change. For experienced users, I struggle to see how "Navigate over to Xyz which takes up screen real estate" is better than "click wherever the cursor happens to be". Could the setting actually be between the current behavior and the new, and not variations on something new that many existing users may not want/benefit from? The new user argument makes some sense, but of all the difficulties I had learning Squeak/Pharo I for one never found the World Menu confusing as a new user. I guess we have to defer to people who deal more directly with newbies on that point… ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Cheers,
Sean |
But if we can have
- the old situation (world menu is click on background) + new task/open window widget - the new task/open window widget + optional 1st special 'start' button (and keep world menu is click on background) - the new task/open window widget + the new menu bar widget that would then cover all cases, no ? > On 1 Jun 2018, at 15:58, Sean P. DeNigris <[hidden email]> wrote: > > Peter Uhnák wrote >> I really love this idea. I've already added (hacked together) something >> similar for some of my projects so I am happy to see this is going into >> Pharo. > > Were these projects where you were the only user? I'm very leery of this > change. For experienced users, I struggle to see how "Navigate over to Xyz > which takes up screen real estate" is better than "click wherever the cursor > happens to be". Could the setting actually be between the current behavior > and the new, and not variations on something new that many existing users > may not want/benefit from? > > The new user argument makes some sense, but of all the difficulties I had > learning Squeak/Pharo I for one never found the World Menu confusing as a > new user. I guess we have to defer to people who deal more directly with > newbies on that point… > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > |
In reply to this post by CyrilFerlicot
Hi Cyril,
On Fri, Jun 01, 2018 at 03:48:54PM +0200, Cyril Ferlicot D. wrote: > On 01/06/2018 15:18, Alistair Grant wrote: > > Personally, I would like to have display strategies for the WorldMenu > and the user could select the one he likes (because nobody will agree on > UI). > For example: > - Menu bar strategy > - World menu strategy > - Start button strategy > - Composite strategy to have multiple ones > > Now it is simple to do the two first, but I will probably not have the > time to implement the "Start button" one. Fair enough. (I haven't had time to do much of anything recently) On Fri, Jun 01, 2018 at 03:56:14PM +0200, Cyril Ferlicot D. wrote: > On 01/06/2018 15:25, Peter Uhn??k wrote: > > > > Also, is it (easily) possible to configure the position of the menu? > > Both top/down, as well as RTL and LTR direction (or right-aligned LTR) > > which I mentioned for the bottom menu in an earlier github discussion. > > > > For now I don't think so. I think it would be cool to integrate this > first version then everyone can try to improve it. +1 (to integrating a first version and iterating) Cheers, Alistair |
Administrator
|
In reply to this post by Sven Van Caekenberghe-2
Sven Van Caekenberghe-2 wrote
> - the old situation (world menu is click on background) + new task/open > window widget If there's a "preserve the status quo" option (e.g. World Menu behavior unchanged and no toolbar), I'm happy! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Cheers,
Sean |
In reply to this post by alistairgrant
Hi, @Cyril I don't know if it should be in the SettingBrowser since Pharo currently Adding a new pragma is not a problem, you can use whatever name you want (see e.g. worldMenuExample pragma), but there is no way to tell Pharo to use this instead of the default one. I don't know if it should be in the SettingBrowser since Pharo currently comes with only one menu Oh, never mind. I just found out that this is already in place, in WorldState class>>desktopMenuPragmaKeyword:. I don't know how I managed to miss this in the past. So if the new menu bar just uses this (WorldState class>>discoveredMenuPragmaKeyword), or uses a similar mechanism (so the menus can differ, which would be also nice), then all is well. I'll rephrase, we have ideas to manage all those problems but how do we I don't know about menu morph, but the bottom menu can handle overflow, can that be used for the time-being? @Sean: Were these projects where you were the only user? No. For experienced users, I struggle to see how "Navigate over to Xyz which takes up screen real estate" is better than "click wherever the cursor happens to be" Pharo adds 25px margin on all sides of a full-screen window. This is enough to add menu to each side. So in fact Pharo already wastes 4x as much space to do what you want. Secondly, my menu doesn't match the world menu, it provides the most important/common options that user needs; so yes, it is faster, because it is one or two clicks instead of going through items that are not relevant to the user. Finally, even if I didn't consider full screen, very often I find myself having to move windows, just so I can expose a piece of desktop to click on. Please don't forget that some Pharo applications are meant for (non-programmer) end users, and not for (Pharo) developers. But don't see a problem with adding a checkbox to settings "Menu bar [x]". There is already such a setting for the bottom task bar ("Taskbar..."). Peter On Fri, Jun 1, 2018 at 4:27 PM, Alistair Grant <[hidden email]> wrote: Hi Cyril, |
On Fri, Jun 1, 2018 at 5:11 PM, Peter Uhnák <[hidden email]> wrote:
Well, actually we are right now doing this: open "self open" self new menuBarItems: WorldState new menuBuilder menuSpec items; open. So the menu bar uses the menuBuilder used by the system, which is hiding the pragma and everything from us :)
Well, one thing is to overflow like the bottom bar (growing so all items fit). But I'd like to have a solution (now for this iteration) where overflowing items are hidden and shown in a "..." button or a hamburguer button.
|
Administrator
|
In reply to this post by Peter Uhnak
Peter Uhnák wrote
> Pharo adds 25px margin on all sides of a full-screen window. Good point. I wonder why that's the case! Maybe as you later pointed out to keep some desktop available for clicking. Peter Uhnák wrote > it provides the most important/common options that user needs Ah! Good to know and interesting, but presumably very subjective. This would seem to point to the need for total individual customizability of the World Menu. Although it is currently flexible, I don't think we have that now. Peter Uhnák wrote > very often I find myself having to move windows, just so I can expose a > piece of desktop to click on. Why don't you use the 25px margin?! ha ha j/k Seriously though, thanks for the explanation it was very helpful. As long as the proposal can be turned on and off it sounds good. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Cheers,
Sean |
On Fri, Jun 1, 2018 at 6:46 PM, Sean P. DeNigris <[hidden email]> wrote: Peter Uhnák wrote According to the github issue discussion, this is the case. Peter Uhnák wrote For sure. But for an end-user application it is my responsibility to figure out the UI/UX. Although it is currently flexible, I don't think we have that now. The pragma collection can be filtered, but it is not used by the code, so it is all-or-nothing, not very flexible. I think this is for future iterations. Peter Uhnák wrote This applies to fullscreen only. It doesn't apply when you manually move a window to this space. And for fullscreen, I often have the margin disabled. So that's why. :) Peter |
Looks like Pharo 7 will be the most impressive release in all aspects of system:). About pragmas: I believe we should move to Commander with first class commands. It requires to create command classes for all menu items. For example "Save image":
It will bring reusable commands which activation can be extended 2018-06-01 20:23 GMT+03:00 Peter Uhnák <[hidden email]>:
|
Yes, Commander should drive a lot of these things. Very useful for scripting things as well and add new macros. Phil On Fri, Jun 1, 2018, 21:06 Denis Kudriashov <[hidden email]> wrote:
|
In reply to this post by Torsten Bergmann
On 6/1/18, Torsten Bergmann <[hidden email]> wrote:
> >>Guille & Cyril wrote> >> > Since some decades now the default way to display a menu in >> > applications >> > is to have a bar at the top of the windows. > > > Alistair wrote >>> Instead of a menu bar at the top, which takes quite a bit of space, >>> and as mentioned may not fit on a small screen how about a "Start" >>button in the task-bar that pops up the menu a-la Windows > > > So this basically reduces to the two UI options: > > 1. Should Pharo look like an application (and have the menu at the top) > > 2. Should Pharo look like an OS itself (with a primary "Start" menu in the > taskbar as on Windows) > > Maybe we should support both styles using a setting. > > Bye > T. > |
>
I believe we should move to Commander with first class commands.
How would that work when menu entries can be generated dynamically? Peter On Sat, Jun 2, 2018 at 1:32 PM, H. Hirzel <[hidden email]> wrote:
|
Hi Peter.
2018-06-02 19:17 GMT+03:00 Peter Uhnák <[hidden email]>:
Commands are responsible to build menu items for themselves. By default they build single item. But you can override method and generate multiple items. Look for example at ClySwitchQueryScopeCommand>>#fillContextMenu:using:
|
Free forum by Nabble | Edit this page |