1214 new menu bar

[kotarCreative]

Add more color. Move menu bar to be within workspace. This is a precursor to creating a playground that only appears at runtime.

[kotarCreative]

[dethe]

Is this in a state where you're ready for it to be reviewed? I wasn't sure.

[kotarCreative]

newest iteration with hidden playground

[kotarCreative]

[kotarCreative]

I dont think its ready for review yet. Im just going to keep this branch for the complete redesign

[dethe]

Sounds good, just wanted to check.

[CelticMinstrel]

Why are undo and redo so different?

[kotarCreative]

they are just placeholders for now. I have yet to find matching icons.

[CelticMinstrel]

You could simply take one of them and flip it horizontally.

[kotarCreative]

[dethe]

Spent some time with this tonight, here are some impressions to start more discussion:

1. The layout feels quite clean.
2. Can the panels be resized by the user? That is a bit buggy in the master branch, but has been requested consistently since the project began.
3. The image buttons are OK, but should have some kind of text representation (at least on hover, although that isn't great on mobile). Even knowing the system I had to just guess and explore to find things.
4. I hit the Uncaught TypeError: Cannot read property 'querySelectorAll' of nullfindAll bug you mentioned, I'll see what I can figure out about it.
5. This may just be me, but I find the purple a bit garish and too much.
6. Because so much of scripts depend on the window size, we should probably not run the script until the transitionEnd has fired. I think that would fix the problem with the waterbear offscreen. [Update: I tried this and it worked, see PR https://github.com/kotarCreative/waterbear/pull/2
7. While it is nice to have the entire screen for running programs, it does eliminate the ability to tweak values while the script is running to see what happens. We could deal with this the way Scratch does, by giving blocks a checkbox that, if checked, puts a control box into the running view for changing the value of that variable. There are other ways around this, and it won't really be an option on mobile anyway, but I wanted to mention it for completeness.
8. When playing the script full width, we should hide the title bar or make it more subtle.

Overall this works well and is quite cool. It would be nice to get all the pieces (menus, script view, playground) to be stand-alone enough that we could reconfigure them at will in various ways. I think this gets us a little closer to that ideal.

[dethe]

To give some context for my last comment, in Tynker the blocks menu can disappear altogether so there are just free-floating blocks, and the script is likewise just floating over a background image:

[kotarCreative]

So i was just reviewing your comments and I agree with most of them.

Point 2: They cannot be resized currently. I removed the splitters that were originally implemented because frankly they looked really ugly and they did not work once I started to separate out the different sections of the program. I agree resizing would be good for each individual cell though. Point 3: I dont like the images that much either. The only problem with text representations is that they take up a lot of space and can impede the script blocks. I may have to look at relocating the menu or giving the user the option of moving it so that size is no longer an issue. Point 4: still not fixed Point 5: I agree. I was just a temp colour that I never got around to changing. I changed it now to a softer colour. Let me know what you think. Point 6: we fixed this so :+1: Point 7: this was more of a temporary solution for me because we dont have the debugger implemented. It might make sense to just have the playground as its own resizable cell or even as a popout window for the desktop user. I doubt mobile will have the debugger so this implementation could work for mobile still. Point 8: This can be fixed if I can simplify the cells further. There is still extraneous wb-vboxs and such in some places.

Overall Im glad that you actually seem to appreciate the update lol.

[dethe]

Point 2: They cannot be resized currently. I removed the splitters that were originally implemented because frankly they looked really ugly and they did not work once I started to separate out the different sections of the program. I agree resizing would be good for each individual cell though.

I agree it was ugly and didn't work very well. If we can improve on it that's great.

[dethe]

Point 3: I dont like the images that much either. The only problem with text representations is that they take up a lot of space and can impede the script blocks. I may have to look at relocating the menu or giving the user the option of moving it so that size is no longer an issue.

A floating pane for the menu would be interesting. Not clear to me why Run, File, Undo, Redo,Examples take up more room than the images. I don't think we even need Undo and Redo to be featured so prominently now that the normal hot keys work (as well as undo/redo works at all, which isn't great).

[dethe]

Point 4: still not fixed

I created issue #1285 so I will remember to dig into that.

[dethe]

Point 5: I agree. I was just a temp colour that I never got around to changing. I changed it now to a softer colour. Let me know what you think.

Better, but my problem wasn't so much with the purple as with the big block of solid colour. I think we can use the space better.

[dethe]

Point 7: this was more of a temporary solution for me because we dont have the debugger implemented. It might make sense to just have the playground as its own resizable cell or even as a popout window for the desktop user. I doubt mobile will have the debugger so this implementation could work for mobile still.

Hmm, I wonder if there are hard and fast reasons not to have the debugger on mobile (i.e., on phones, we should certainly have it on tablets).

In any case I certainly see value in having the playground free to be resized, repositioned, etc.

[dethe]

Overall Im glad that you actually seem to appreciate the update lol.

I'm very glad to have someone else thinking about the UI and how to make it better, and testing those ideas out. One of the downsides to a visual language is that it cannot live outside of an IDE, you can't just use your favourite text editor to write WB code. The existing IDE has had sporadic work to improve it, especially when I had designers helping out, but it originated in a quick hack to be the simplest possible thing I could get working before demoing at JSConf and didn't evolve much from that for a really long time.

So it's not ugly because I want it to be, just because I end up getting stuck a the "making it run" level and rarely get to the "make it fun to use" or "teach with it" levels.

Thanks for tackling this!

[CelticMinstrel]

I don't think we even need Undo and Redo to be featured so prominently now that the normal hot keys work (as well as undo/redo works at all, which isn't great).

I don't think it's a good design to have important features only accessible by hotkey. Even though I personally would usually use the hotkey over a menuitem.

[dethe]

@CelticMinstrel I'm not arguing the only access to undo/redo should be hotkeys, but that if they are one menu level deep (as they are on most desktop software) that would not be a terrible thing. This brings up a good point though: part of discoverability is a way to discover shortcuts. Which means that menu items with shortcuts should have the shortcuts visible on them. How to do this cross-platform will be interesting.

[CelticMinstrel]

Ah, yeah, I wouldn't have any problem with them being placed under a menu rather than at the toplevel.

Regarding cross-platform shortcuts, isn't it simply Cmd on OSX, Ctrl everywhere else? Though also you might want to omit the shortcuts altogether on platforms without a keyboard, like iOS, where keyboard shortcuts don't make sense.

[dethe]

Well, the trick is reliably detecting what platform we're running on, but yes, Cmd on OS X and Ctrl elsewhere.

[alexjsmac]

Yeah I agree that the running box opening to the width of the screen automatically is a bit obtrusive. How about collapsing the first two boxes so that the default is to see the current blocks box and the running box side by side?

As for the icons, how about just a play button for run, like in most IDEs, and a red square for stop?

Overall I really like the makeover!

[kotarCreative]

The side by side layout is a great idea actually. I will try and get that running.

[kotarCreative]

Ok I implemented the change you suggested Alex. However now if you click the start button after the script is running it stops it without adjusting the window which is obviously wrong.

[alexjsmac]

Yeah that's nicer! And I guess if it'll be something like that there should also be a stop button with the others (or just move it?).

[kotarCreative]

i was thinking i would just make the run and stop the same button and just change the icon depending what state it is in.

[CelticMinstrel]

That makes sense to me. (Unless you wanted a pause button, I guess.)

[ghost]

This looks a lot nicer and is a much better use of space! I like the idea of the run and stop button being in the same place since it was my first instinct to click the same spot to try and stop the program. I'm not super crazy about the placement of the menu bar, though I don't know where a better spot would be. To me it seems to clutter the workspace a bit, but that's getting a little nit-picky.