World menu versus docking bar
Locked
World menu versus docking bar
 
|
Awhile ago we added a docking bar, because the world menu is often harder for newcomers to find at first than we tend to want to think. We put some key use cases there, most key of which is Help, which is probably more important to newcomers than experienced users.
I noticed that the help... entry in the world menu contained some stuff that was very questionably help-related, moved it out to the docking bar. I pretty much emptied out the help... item on the world menu, so I removed but Chris pointed out that not everyone uses the docking bar and put it right back, suggesting that we find a way to generate the same menu in both contexts (which I think is a great idea, and will investigate today.)
The question in my mind though, is: where do we stop with that? What do people think: should there be any separation of concerns between the world menu and the docking bar? (My thought was, some things made more sense on the docking bar than the cluttered world menu, but if not everyone uses the docking bar... yeah.) Or are the world menu and the docking bar best serving the user as two different views into the exact same functionality?
From an implementation perspective, I much prefer the canvas-ish style of what's in the docking bar presently. The data-driven style of the world menu, while very terse, makes my eyes glaze over. I'm tempted to rip into it and and refactor it to use a canvas-ish API (making the two more compatible,) but I'm liable to introduce regressions that way, and we're fairly locked down at present, no?
Anyway, I was hoping to get a feel for what people think about this stuff.
|
Re: World menu versus docking bar
|
|
I think it'd be great to give the world menu a make-over.. Having
separate menus for the docking bar and world could be "richer".. Maybe the docking bar could be just a sub-set of the world menu, because there are a lot of things that are not on the docking bar, right? I think it's great when we can simplify (e.g., try to improve the system by removal, not addition) the system while at the same time striving to make it more conventional for newcomers. The challenge is to do it in a way that increases, or at least matches, existing functionality and usability.. For example, right now I'm able to navigate the world menu with the keyboard; I wouldn't want to lose that.. :) Thanks, Chris On Sun, Mar 28, 2010 at 11:06 AM, Casey Ransberger <[hidden email]> wrote: > Awhile ago we added a docking bar, because the world menu is often harder > for newcomers to find at first than we tend to want to think. We put some > key use cases there, most key of which is Help, which is probably more > important to newcomers than experienced users. > I noticed that the help... entry in the world menu contained some stuff that > was very questionably help-related, moved it out to the docking bar. I > pretty much emptied out the help... item on the world menu, so I removed but > Chris pointed out that not everyone uses the docking bar and put it right > back, suggesting that we find a way to generate the same menu in both > contexts (which I think is a great idea, and will investigate today.) > The question in my mind though, is: where do we stop with that? What do > people think: should there be any separation of concerns between the world > menu and the docking bar? (My thought was, some things made more sense on > the docking bar than the cluttered world menu, but if not everyone uses the > docking bar... yeah.) Or are the world menu and the docking bar best serving > the user as two different views into the exact same functionality? > From an implementation perspective, I much prefer the canvas-ish style of > what's in the docking bar presently. The data-driven style of the world > menu, while very terse, makes my eyes glaze over. I'm tempted to rip into it > and and refactor it to use a canvas-ish API (making the two more > compatible,) but I'm liable to introduce regressions that way, and we're > fairly locked down at present, no? > Anyway, I was hoping to get a feel for what people think about this stuff. > > > |
Re: World menu versus docking bar
|
|
Totally. One thing I really would like to see, is a world menu with less at the top level. I like to Squeak on a very small screen. I have an Eee 1005HAB, which is the spitting image of a DynaBook. It's a bit like an XO but with a conventional display, conventional networking, enough muscle to do serious development, and a keyboard big enough for my grown-up hands.
The top level world menu, presently, barely fits vertically. I'd like to do a couple of things with it. I'd like e.g. help to contain the same stuff as what's in the docking bar help menu, and accomplish that via the same code path (Chris I think you're dead on here.) I'd also like to move some things off of the top level.
One thought I had (people, please shoot me down if this is ridiculous to you, I'm not sure I've sold myself on it) is: If the docking bar is enabled, don't show the menus that appear on the docking bar in the world menu. If the docking bar is disabled, the world menu can show it's contents. Yay? Nay? Keep in mind this refers to a hypothetical world menu that shared an implementation style with the docking bar.
I've been messing with the world menu since I first started playing with Squeak, and having had a look at how the new docking bar is implemented (I *really* like the implementation better) I would quite like to spend some time rethinking the design of the world menu; I'm not sure I'd want to put the effort in if I was the only person who'd ever use the code though, so I'd like to get a sense of what people think about it.
On Sun, Mar 28, 2010 at 6:30 PM, Chris Muller <[hidden email]> wrote: I think it'd be great to give the world menu a make-over.. Having |
Re: World menu versus docking bar
|
|
> One thought I had (people, please shoot me down if this is ridiculous to
> you, I'm not sure I've sold myself on it) is: If the docking bar is enabled, > don't show the menus that appear on the docking bar in the world menu. If > the docking bar is disabled, the world menu can show it's contents. Yay? > Nay? Keep in mind this refers to a hypothetical world menu that shared an > implementation style with the docking bar. If your goal is to have a smaller World menu, I would tend to answer to base it on the #simpleMenus setting rather than the presence of Docking Bar. The World Menu provides a more-consistent UI than the docking-bar, more consistent with with Squeak's overall "object-oriented" UI, because we all know that clicking on an object, whether it is the "World" object or a smaller object, presents a menu for that object. Up until recently, I had viewed the Docking Bar as primarily a divergence from the OO UI to help newcomers used to a "global-command-menu" to be more comfortable. Thanks' to Andreas' value-adding search bar and clock, it looks to now be useful for experienced developers too. However, for accessing global behavior, the docking bar still also requires more energy to use than the world menu, primarily due to the up-front fine-motor pointing gesture required, and that the keyboard cannot be used to invoke it like it can with the world menu (via ESC key). I wouldn't want accessibility to things I can get from the World menu to suddenly require this fine-motor gesture every time.. Regards, Chris > I've been messing with the world menu since I first started playing with > Squeak, and having had a look at how the new docking bar is implemented (I > *really* like the implementation better) I would quite like to spend some > time rethinking the design of the world menu; I'm not sure I'd want to put > the effort in if I was the only person who'd ever use the code though, so > I'd like to get a sense of what people think about it. > > On Sun, Mar 28, 2010 at 6:30 PM, Chris Muller <[hidden email]> wrote: >> >> I think it'd be great to give the world menu a make-over.. Having >> separate menus for the docking bar and world could be "richer".. >> Maybe the docking bar could be just a sub-set of the world menu, >> because there are a lot of things that are not on the docking bar, >> right? >> >> I think it's great when we can simplify (e.g., try to improve the >> system by removal, not addition) the system while at the same time >> striving to make it more conventional for newcomers. The challenge is >> to do it in a way that increases, or at least matches, existing >> functionality and usability.. For example, right now I'm able to >> navigate the world menu with the keyboard; I wouldn't want to lose >> that.. :) >> >> Thanks, >> Chris >> >> >> On Sun, Mar 28, 2010 at 11:06 AM, Casey Ransberger >> <[hidden email]> wrote: >> > Awhile ago we added a docking bar, because the world menu is often >> > harder >> > for newcomers to find at first than we tend to want to think. We put >> > some >> > key use cases there, most key of which is Help, which is probably more >> > important to newcomers than experienced users. >> > I noticed that the help... entry in the world menu contained some stuff >> > that >> > was very questionably help-related, moved it out to the docking bar. I >> > pretty much emptied out the help... item on the world menu, so I removed >> > but >> > Chris pointed out that not everyone uses the docking bar and put it >> > right >> > back, suggesting that we find a way to generate the same menu in both >> > contexts (which I think is a great idea, and will investigate today.) >> > The question in my mind though, is: where do we stop with that? What do >> > people think: should there be any separation of concerns between the >> > world >> > menu and the docking bar? (My thought was, some things made more sense >> > on >> > the docking bar than the cluttered world menu, but if not everyone uses >> > the >> > docking bar... yeah.) Or are the world menu and the docking bar best >> > serving >> > the user as two different views into the exact same functionality? >> > From an implementation perspective, I much prefer the canvas-ish style >> > of >> > what's in the docking bar presently. The data-driven style of the world >> > menu, while very terse, makes my eyes glaze over. I'm tempted to rip >> > into it >> > and and refactor it to use a canvas-ish API (making the two more >> > compatible,) but I'm liable to introduce regressions that way, and we're >> > fairly locked down at present, no? >> > Anyway, I was hoping to get a feel for what people think about this >> > stuff. >> > >> > >> > >> > > > > > |
Re: World menu versus docking bar
|
|
Hi,
> However, for accessing global behavior, the docking bar still also > requires more energy to use than the world menu, primarily due to the > up-front fine-motor pointing gesture required, and that the keyboard > cannot be used to invoke it like it can with the world menu (via ESC > key). I wouldn't want accessibility to things I can get from the > World menu to suddenly require this fine-motor gesture every time.. You can invoke the menus in the docking bar by ctrl+<n>, where n is the index of the menu, and then locate your menu item by typing. e.g. to open a workspace hit ctrl+3 (to open the tools menu) and then type 'wo' (which selects the workspace menu item) and finally hit enter to open it. The search bar also could be accessed by such a keystroke (e.g. ctrl+9), but that's not yet implemented. Balázs |
Re: World menu versus docking bar
|
|
On 3/29/2010 2:42 PM, Balázs Kósi wrote:
> You can invoke the menus in the docking bar by ctrl+<n>, where n is the > index of the menu, and then locate your menu item by typing. > e.g. to open a workspace hit ctrl+3 (to open the tools menu) and then type > 'wo' (which selects the workspace menu item) and finally hit enter to open it. > The search bar also could be accessed by such a keystroke (e.g. ctrl+9), > but that's not yet implemented. I didn't even know that. So Ctrl-3 "b" <enter> fires up a browser? That's cool! Can I ask you to update the keyboard shortcut help accordingly? Thanks, - Andreas |
Re: World menu versus docking bar
|
|
In reply to this post by Balázs Kósi
Neat!
On Mon, Mar 29, 2010 at 2:42 PM, Balázs Kósi <[hidden email]> wrote: Hi, |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |