codeman1044 wrote:

Semi support.
I like the idea of a larger preview window, but I'm not certain about the idea of all of the tabs in the same view. Scratch is supposed to be user-friendly and seeing all of those at once might overwhelm a newer and/or a younger user.

Za-Chary wrote:

The problem with these suggestions about revising the layout (particularly if it's optional) is that it could add a lot of complexity for not only the Scratch Team, but also to anyone trying to teach or learn the Scratch language. It's tough to teach Scratch if not everyone might not have the same editor layout, and it's not entirely fair to the Scratch Team to code a layout so that a small percentage of users is satisfied. This is similar to why “Set the editor to look like older versions of Scratch” is rejected.

Of course, you are not suggesting the editor to look like older versions of Scratch. Therefore, I can't confirm that your suggestion is rejected — but I would guess that the Scratch Team wouldn't add this anytime soon.

ResExsention wrote:

No. The older versions were basically the almost same layout, here, I'm thinking of a complete optional overhaul to something more standardized, so that when people move away (or come to) Scratch, they won't have to completely relearn how an engine UI works.

_nix wrote:

ResExsention wrote:

No. The older versions were basically the almost same layout, here, I'm thinking of a complete optional overhaul to something more standardized, so that when people move away (or come to) Scratch, they won't have to completely relearn how an engine UI works.

What about when someone is trying to teach Scratch, as Za-Chary mentioned? Suppose you're teaching a group of students, all fairly new to Scratch. If some users coincidentally discover the engine-style UI, they will probably have trouble following the rest of the class, because any photos or demos the teacher shows will be in the normal UI – which is totally different from the one the student is using!

Plus, having two different UI styles might make it more difficult to work together as a pair or group of students/users in person. Suppose one user swears by the engine-style UI mode, while the person working with them has never seen it before! If it's used, they might be overwhelmed and confused, and would certainly have trouble participating in the team. And if it's not used, well, the other user would probably face similar problems – they're used to the engine UI and like it much more than the normal mode. Who's in the wrong here? Well, nobody, really. It's a result of the circumstance – a problem inherent to having two very distinct modes in the editor.

When you're working alone, yes, I can see this editor being useful for someone who prefers that sort of editor appearance. (I wouldn't, but hey, opinions vary, and I've got years of experience working with Scratch's present editor, not those engine UIs which are all a bit overwhelming to me. ) The thing is, it would have a lot of impact on working in real-world settings, where there are other people also using or teaching Scratch around.

(PS: This is the kind of discussion I've had with regards to a dark mode for the Scratch editor, too – but it's considerably less significant there since that's just a color scheme change, rather than a whole UI overhaul. The same parts are in the same places, so it's generally easier to adapt to either mode.)

(Edit: formatting typo!)

ResExsention wrote:

P.S. The engine UI is not overwhelming. Maybe it gets a bit of time to get used to but I find it more streamlined and standardized than the current editor. Lol, just about every game engine uses some variant of the “big preview in the middle, properties and options on the sides”, so there is no relearning involved if you switch engines.

ResExsention wrote:

For team projects, I don't think your analogy of “both people have never seen the other UI” would fit in accurately. The original UI is still the default UI, and it would require some changes in the settings before the new engine UI can be used. This means, in almost every case, the person who uses the standardized UI will have at least some experience with the original UI, so I don't think this will be a problem. I don't think they would end up going “click here, then click there” anyway, they would both probably be accustomed to their respective settings, so they won't really have to deal down to the specifics of what buttons to press.

ResExsention wrote:

For classes, may I suggest putting the option of the UI layout to the teacher, so that the teacher can decide whether to teach the standardized UI or the original UI? This way, the class basically doesn't end up getting confused with the new layout.

_nix wrote:

ResExsention wrote:

P.S. The engine UI is not overwhelming. Maybe it gets a bit of time to get used to but I find it more streamlined and standardized than the current editor. Lol, just about every game engine uses some variant of the “big preview in the middle, properties and options on the sides”, so there is no relearning involved if you switch engines.

Having the costume and sound editors visible all the time is overwhelming because they take up a whole lot of screen real estate and divert your focus to something you're not using. Is it really useful, the majority of the time, for the costume and sound editors to be actively visible? I don't understand the reasoning for that.

_nix wrote:

ResExsention wrote:

For team projects, I don't think your analogy of “both people have never seen the other UI” would fit in accurately. The original UI is still the default UI, and it would require some changes in the settings before the new engine UI can be used. This means, in almost every case, the person who uses the standardized UI will have at least some experience with the original UI, so I don't think this will be a problem. I don't think they would end up going “click here, then click there” anyway, they would both probably be accustomed to their respective settings, so they won't really have to deal down to the specifics of what buttons to press.

That's fair, but I still disagree because I do find your editor suggestion to be a considerably more crowded experience. While the editors aren't so different that either would be unusable to someone inexperienced with it, it still seems like unnecessary friction – again, because I don't understand the advantage for having the costume and sound editors constantly visible.

_nix wrote:

ResExsention wrote:

For classes, may I suggest putting the option of the UI layout to the teacher, so that the teacher can decide whether to teach the standardized UI or the original UI? This way, the class basically doesn't end up getting confused with the new layout.

I see your reasoning, but it seems like a bit of a hack or workaround. As a rule, I believe it's preferable to avoid introducing more modes to a UI in general, and specifically preventing access to a mode because of its flaws in a collaborative environment makes it seem rather like these issues ought to be resolved, rather than to continue existing but be set aside by disabling access to them. Of course, if you fix those issues, you just end up.. right back at the normal editor we have today.

_nix wrote:

PS: You've likely noticed that in Scratch 3.0, the stage (“inspector” as you call it) is on the right side of the screen instead of the left. This is because Scratch 3.0 (and 1.4) adapt an idea of working left-to-right, like you read stories. Where you get blocks is on the left of the screen, then the workspace where you build scripts is in the middle, and the stage where you view the result is at the end of the screen. (The UI actually flips in languages that read LTR.) Your suggested UI seems to send away with this reasoning. I understand that this is so that users can get better experienced with more advanced game engine editors, but is that worth sacrificing the intuitive work-in-reading-direction idea of the editor in that mode?

_nix wrote:

PPS: Again, unless there is a clear advantage to the mode outside of being a transition between programming editors, I feel it doesn't fit in Scratch. It seems to me a similar argument to whether there should be an “advanced” mode, where (setting aside compatibility issues) list indexing would start at zero instead of one. Arguably, there are benefits to this type of indexing, but if the core reason is to make it a smoother introduction to more advanced programming languages, I feel that's not a benefit great enough on its own.

kritav wrote:

The problem with the editor is the amount of dead space, I don't know why they don't make use of the real estate…

ResExsention wrote:

About your analogy about reading the screen LTR. That's actually the default layout in most game engines. Basically, you start with a hierarchy, showing everything, allowing you to select which parts to modify, then you have the viewport, to see your creation, and then the inspector to allow the dev to make changes depending on what was seen in the viewport. I had actually considered the way that people would read the UI, and it seems to be fitting to the analogy of LTR. You have the inspector to make changes, and then see them in the preview. The costume and sound editors are on the right, so that when you come back around, you can make changes in the inspector before seeing it in the viewport. I don't see how I'm overhauling the way content is read, please forgive me.

ResExsention wrote:

Uh, I didn't suggest indexing at 0. I don't think it was in my suggestion at all.

ResExsention wrote:

I will have to concede there. You do have a point, but I still firmly believe that the students shouldn't have to completely relearn a game engine if they decide to pursue game development. Again, both editors essentially serve the same functions, and the engine layout may be hidden deep within the settings.

ResExsention wrote:

I don't think having the additional menus always visible would be considered clutter. Plus, since't they're quite off to the side, you hardly notice them, and when you need them, you save yourself a few clicks and do it all in a standardized environment. I believe it's quite useful. Shouldn't game engines let you take as many shortcuts as possible in terms of navigating the UI, so that you can make your game more efficiently without having to mess with tabbed windows?

Workspace  |  Stage
(Tabbed)   |  Sprites

Workspace  |  Stage    |  Costume Editor
(Blocks)   |  Sprites  |  Sound Editor

_nix wrote:

So, my understanding is that your idea would basically involve just making the sound and costume editors visible on the right-side of the screen. Is that correct?

_nix wrote:

That said, I'm a bit confused about how it would all… fit. kritav mentioned there's a lot of free space to fill up with more UI, but I just don't see it on my screen! Here's what my editor looks like:

Workspace | Stage | Costume Editor
(Blocks) | Sprites | Sound Editor

_nix wrote:

You might exclaim blasphemy and say I am cheating by making the stage view 120%, and you'd be right. But even at +0% (normal) zoom, the paint editor still takes up, say, 40% of the screen width (vs. the 50% in my screenshot). We'll say the sound editor is equal width because it can realistically be shrunk width-wise without worsening its UI.

_nix wrote:

So, 40% for the paint/sound editor column + (at least) 30% for the stage = 70% of the width encompassed by those two columns, leaving us (at most) 30% of the screen space for the code workspace. And.. that's what confuses me. It seems to me that your suggested UI implies that the width of the code workspace be cut to less than half its present size. If you want to increase the size of the stage (as you suggest), it'd end up taking more width, resulting in an even smaller code workspace. (Do remember that the width of the workspace includes the width of the block palette, too, which spans some 15% of the screen itself!)

_nix wrote:

The reason this confuses me is because, at least for me, the vast majority of time working on a project is spent in the code editor, defining the behavior and implementation for every object in the creation. While I certainly appreciate the ability to access the sound and paint editors at the click of a tab (and even more quickly, with your suggested UI), the amount of time I spend using them just pales in comparison. So, I do not understand why it would make sense to decrease the width of the block workspace, only to make space for elements of the editor which are not used nearly as frequently.

when green flag clicked
forever
  set y to ((50) * ([sin v] of ((1000) * (timer))))
end

_nix wrote:

-snip snip-

_nix wrote:

-snip snip-

ResExsention wrote:

Really? Userthemes exist now? Please tell me how I can use it with Scratch, please?

ResExsention wrote:

And, you forgot to mention that you actually have to run the script, the changes don't get reflected in real time. Plus, I must say that running scripts by themselves aren't very efficient sometimes, since scripts can depend on other scripts and so on. I think it would be better to just restart the whole project, this way you don't have any script dependency issues, and you can always return to the code editor if need be.

ResExsention wrote:

Again, the costume editor will just list the costumes for the selected sprite, you'll need to click a button, which will result in the paint editor replacing the viewport or code editor. Thus, you can actively see all the costumes for the selected sprite without having to tab out. This also allows for easier name reference when writing scripts, since sometimes costumes aren't named very well, so I have to constantly switch to the costume list. Same goes for sounds.

_nix wrote:

ResExsention wrote:

Really? Userthemes exist now? Please tell me how I can use it with Scratch, please?

Yeah! Well, sorta. Scratch 3.0's GUI is made totally out of HTML elements which are styled with CSS, so by using a browser extension (Stylus, available on Firefox/Chrome/Opera), we can create our own custom CSS to modify the editor's appearance to our tastes. This was one of the goals of Scratch 3.0's design, actually! So, to use my userstyle, you'll need to install Stylus, then, while in the Scratch editor, click the “write style for (this URL)” button in the extension popup. Then just paste the CSS code from here into the editor that shows up; save, and you should see it take affect!

(BTW, you'll want to actually fill out the “applies to” section riight below the editor according to this screenshot. The two important ones are “URLs matching the regexp”; they make the theme apply anywhere on the Scratch website.)

(PS, Scratch unfortunately has strict terms disallowing the sharing of JavaScript browser extensions on Scratch. I'm linking you Stylus and my userstyle both from my own confidence that they are perfectly safe and do not tamper with your ability to use Scratch or act maliciously at all, and that's relatively easy for me to guarantee, since userstyles are not made with JS and so can't do stuff on its behalf (without some ridiculous trickery). But yeah. Sharing around JS extensions will apparently (still) get you a warning from the ST with your posts deleted. PPS don't use or link to the similar browser extension, Stylish! Stylish is not Stylus. Stylish is a malicious extension that steals and collects your browser history!)

ResExsention wrote:

And, you forgot to mention that you actually have to run the script, the changes don't get reflected in real time. Plus, I must say that running scripts by themselves aren't very efficient sometimes, since scripts can depend on other scripts and so on. I think it would be better to just restart the whole project, this way you don't have any script dependency issues, and you can always return to the code editor if need be.

OK, that's a fair opinion, though I respectfully disagree. In the case of a complex algorithm-based project, sure, it may be better to restart the project, but in the vast majority of my games I find it much more useful to develop while I'm running the project. Different use cases I suppose!

ResExsention wrote:

Again, the costume editor will just list the costumes for the selected sprite, you'll need to click a button, which will result in the paint editor replacing the viewport or code editor. Thus, you can actively see all the costumes for the selected sprite without having to tab out. This also allows for easier name reference when writing scripts, since sometimes costumes aren't named very well, so I have to constantly switch to the costume list. Same goes for sounds.

Oh, gotcha! That's fair, yeah. I somehow didn't recognize that part of your post earlier. Again, to a degree I disagree, because I do find it useful to see how changes to a costume or sound are reflected in the context of the full project view, but hey, again, our use cases for Scratch, not to mention our development styles, are pretty different.

Thanks for the discussion about all this, too. I quite enjoy ranting about UIs, so it's nice to have a place where I can do it constructively! I'm probs not going to be around a whole ton to discuss more through the not-weekend, but I feel we've basically gotten to a clear point here. It's really just a misalignment of working styles. I feel what I was describing is more natural and fits Scratch better, buuuuut I'm biased because I'm way more used to it. They're just different methods of working, and different editor layouts fit them better.