search

jmoenig / Snap

a visual programming language inspired by Scratch
http://snap.berkeley.edu
GNU Affero General Public License v3.0
1.51k stars 745 forks source link

LOVE the find-blocks / open-project / save-project, we want people to find them though #444

Closed ddgarcia closed 7 years ago

ddgarcia commented 10 years ago

Nobody will ever know about open/save project unless we change the menu for "Open..." to "Open... ^-O" and "Save" to "Save ^-S", easy changes. (I would also propose a "Find Blocks... ^-F" menu item, but there doesn't seem to be a menu that is appropriate for it. the first is for files, the second is for clouds, the third is for configs)

xtitter commented 10 years ago

On chrome in windows, the browser is grabbing all the ctrl keys for its own purposes -- so, I can't ctrl-F into the find palette in anyway.

jmoenig commented 10 years ago

I fixed that in today's release. Try flushing your cache and let me know if you still can't use cmd-key combinations in Chrome. The only browser that doesn't catch them all is currently Safari...

xtitter commented 10 years ago

Comfirmed it works on Chrome/Windows when shift-reload'ed. Excellent!

jmoenig commented 10 years ago

Thanks for checking and confirming that Chrome on Windows no longer overrides Snap's keyboard combinations with its own ones, Nate!

cycomachead commented 10 years ago

(I would also propose a "Find Blocks... ^-F" menu item, but there doesn't seem to be a menu that is appropriate for it. the first is for files, the second is for clouds, the third is for configs)

This is absolutely necessary if we want people to discover this feature on their own. The menus are becoming a bigger issue... We need something like the "Edit" menu in Desktop apps which has undo, find, cut copy paste (when Snap! has it...)

ddgarcia commented 10 years ago

Actually, since we support undrop, paste, and find -- it makes sense that there be an "Edit" menu. I wouldn't argue for a menu if there were just 'find' but now that we have those three I think it's appropriate.

It also makes me think that we might want to have a "startup tip" that can be permanently removed by a "don't show this again" checkbox alongside an "ok" which closes the modal dialog. It would list the tips that we all know are useful, one at at time (randomly?) that would include:

"Did you know you can 'undo' a drop? Choose Edit->undrop (or right-click on the script window and choose undrop)."

"Did you know you can search for available blocks via Edit->Find, or ^-F (control-F), or right-click on the left palette and choose 'Find...'"

"Did you know there are three ways to save files? You can save your project to the cloud, or to the browser, or to an XML file"

"Did you know that you can share the files you have in the cloud to share with others? In the open dialog box, select a project and click the 'share' button"

etc etc

dan

On Tue, May 20, 2014 at 10:35:35PM -0700, Michael Ball wrote:

(I would also propose a "Find Blocks... ^-F" menu item, but there doesn't seem to be a menu that is appropriate for it. the first is for files, the second is for clouds, the third is for configs)

This is absolutely necessary if we want people to discover this feature on their own. The menus are becoming a bigger issue... We need something like the "Edit" menu in Desktop apps which has undo, find, cut copy paste (when Snap! has it...)

Reply to this email directly or view it on GitHub:

https://github.com/jmoenig/Snap--Build-Your-Own-Blocks/issues/444#issuecomment-43713931

Dan Garcia, Ph.D. 777 Soda Hall, 510.517.4041 ddgarcia@cs.berkeley.edu Senior Lecturer SOE UC Berkeley, EECS dept cs.berkeley.edu/~ddgarcia

jmoenig commented 10 years ago

Hmmm.

At some point somebody is going to come up with needing to search for a certain costume, a particular sprite, a passage in an imported sound, a script in the scripting pane or block editor, a help screen, a line in a menu, etc.

I'm afraid that the the bottom line of this is: "Whatever the user doesn't find in the menus that pop up if you left-click on a button that's located at the very top of the window isn't self-discoverable",. Likewise if the bottom line is: "every feature that isn't anchored in a left-clickable button" is not self-discoverable.

Snap does have different "edit" operations for different parts of the IDE:

For the Scripting pane there is

for the Palette there is:

for the stage we have:

for blocks in the scripting pane you can

for blocks in the palette you can

for block prototypes in the block editor, you can

for the currently selected sprite / stage, you can....

and so on.

My point is, there a so many editing features that it makes sense offering them contextually and through direct interaction rather can at some central place. Bullet-lists are for marketing departments ("our product supports JSON XML PDF DOC *CSV" etc...).

Can't we just advise our users to "explore" (which includes "right-click a lot, and thou shalt discover all you need")?

brianharvey commented 10 years ago

If we're going to do "Did you know..." (which I don't advocate; it's too much reminiscent of the paper clip) some of them should be about real features (as opposed to UI features): "Did you know you can put a list inside a list?" "Did you know you can build your own blocks?" "Did you know you can put a block inside a list?" Etc.

brianharvey commented 10 years ago

@jmoenig I don't think that's quite fair. We have a lot of menu operations that are unique to Snap!, or at least unique to blocks languages. But some things are pretty much universal to all software these days, and it wouldn't be opening Pandora's box for us to have a _standard_ (as much as possible) Edit menu.

jmoenig commented 10 years ago

Also, the Berkeley-hosted Snap website itself - not just the web-app - could provide a lot more - searchable(!) - information :-)

brianharvey commented 10 years ago

Oh, I like that idea! We could then even write (or make as an exercise) a search _block_ that scrapes the web site. :-)

jmoenig commented 10 years ago

Oooh, a search block is such a cool idea!! That reminds me of my proposal to actually add one that finds - err - blocks...

cycomachead commented 10 years ago

Lot's going on here...

1) Too many tips is definitely bad, but we should definitely have some ways of graphically introducing users to more of Snap!. (Perhaps it's optional, or instead of just help, there's 'Tips' or we just make help more useful or something...), Anyway, this is a new issue.

2) Websites, yeah... s.b.e needs some love. But separate issue as well, and some of that discussion is happening elsewhere.

--- I don't think another block would solve that issue. (I'm not really sure that was a serious comment, right?)

Snap does have different "edit" operations for different parts of the IDE:

Yeah, there are different functions which can be applied to different parts, but that doesn't mean they should be attached to menus.

As long as a user is working with blocks, (in the scripting area, or while building a block), s/he may want to find a block. Why should the find button only exist in the context of the palette? Sure, the view exists from the palette, but my mouse won't be over the palette when I want to find a block.

(The same is true for many of the other things, like adding a comment, or help).

There are two issues here:

nathan commented 10 years ago

I like Apple's guidelines on context menus:

You can think of a contextual menu as a shortcut to a small set of commands that make sense in the context of the current task.

i.e., they offer a convenient shortcut, but the full list of commands (even those that don't apply in the current context) should be enumerated elsewhere. (For Mac apps this means in the menu bar).

cycomachead commented 10 years ago

Yeah. I think that's a good guide, and essentially the point I was trying to make.

The other related issue to discoverability is that there's no way to find out when new features exist.

Michael Ball From my iPhone http://michaelballphoto.com

On May 21, 2014, at 10:36 AM, Nathan Dinsmore notifications@github.com wrote:

I like Apple's guidelines on contextual menus:

You can think of a contextual menu as a shortcut to a small set of commands that make sense in the context of the current task.

i.e., they offer a convenient shortcut, but the full list of commands (even those that don't apply in the current context) should be enumerated elsewhere. (For Mac apps this means in the menu bar).

— Reply to this email directly or view it on GitHub.

khotchkiss13 commented 10 years ago

Sorry for my lack of participation the last week. I am done with finals, so I can devote quite a bit more time to Snap! now. @jmoenig I love the version that is currently live for the searchbar. it is very fast, responsive, and it works very well. I think that adding toggles and buttons would not be difficult, and it is something that I could most likely implement pretty quickly. As for the menus, I think that adding at least one more option is the least we could do to try to simplify Snap! a little more (See issue #421 ). I agree that there should be some way to be able to show users that Search exists other than asking them to hit cmd-f or right clock the pallete. Whether this should be in a tutorial or on the web page, or in a menu, I don't know. I know that there is part of the Snap! dev team working on a tutorial, so they may be able to add a part about searching. Again, I really like this version ,and I believe that it can be very useful to all users of Snap! Thanks!

marwahaha commented 10 years ago

Why can't the search bar be permanently visible?

cycomachead commented 10 years ago

Why can't the search bar be permanently visible?

@marwahaha It's a UI element that isn't necessary most of the time which adds unnecessary complexity. I do somewhat agree with this, but it is super hard to find search otherwise.

cycomachead commented 7 years ago

Aside from the edit menu, the original issue of displaying keyboard shortcuts has now been resolved. :)