Mu: Remove the buttons and use OS level, file menus.

[carlsmith]

Currently, we have huge, round buttons that take up a lot of vertical space. There's not enough space to have a button for every menu item, so we have shortlist of common ones, and are left with no way to select any other options, as there are no menus.

On OS X, users will expect all of the options to be available in menus in the main OS X menu bar. Most flavours of Linux have similar menus, and presumably Windows still does this too.

Obviously, Mu is aimed at children, but I don't think it should look childish. Kids only like toys as substitutes for the real thing when they can't have the real thing, and even then, they like toys to be a realistic as possible. I think Mu should be a simple tool for beginners, but still have the look and feel of a proper, minimal editor.

[ntoll]

Hi @carlsmith,

Thanks for your feedback.

We have based our UI design on feedback from teachers, children and beginner programmers. Put simply, they say that they want only a small number of buttons for only the essential tasks they need. This was sourced mainly from the feedback the Raspberry Pi Foundation's education team had garnered over the past year or two.

If you want all the other menus, you shouldn't use Mu. If you know why you want the other menus you definitely shouldn't use Mu. If you want bells and whistles, go use another editor. If, however, you want to teach Python to kids, you should definitely use Mu: feedback has been very positive so far in terms of the beginner user's experience. But you don't sound like you're a beginner, so you're probably not the target audience.

Regarding the actual look. Again, this was based upon feedback from users: big bold buttons containing icons that make it obvious what each one does (for those for whom English is an unknown or for people with underdeveloped literacy skills - such as children). We also make sure we label them to make the application work with screen readers. We use the Python blue and yellow colour scheme since this is a Python editor.

Mu _is_ a simple tool for beginners. I'm trying to work out what you mean by "proper, minimal editor". If you know of research from real teachers, children and beginner programmers that contradicts our own extensive UX/UI research, please point me to it. If your idea of minimalism is "vim" then, I'm afraid, you're way off the mark because of the steep learning curve. If you're thinking something more like sublimetext then you're also very wide of the mark - while it's minimalist in terms of look (unfortunately, there's very little to tell you what you can do, which isn't helpful for our target audience) it's too complicated in terms of the features that are available to the programmer.

Mu is for the very first steps into programming. Once you can toddle, you should probably toddle off to use another editor.

I hope this makes sense.

[carlsmith]

The only thing suitable for children around here is your ability to address criticism.

You made a number of points that are incorrect, but it would be an obvious waste of time to explain why.

I thought it was just your editor that treats users like they're stupid, but that's apparently your whole world view.

[ntoll]

@carlsmith _sigh_,

I've been nothing but respectful and merely asked for evidence. If the best you can do is say "you're wrong and I can't be bothered to explain why" in a snide sort of a way then I don't really have anything to go on to improve the project.

For the record, the editor doesn't treat users like they're stupid. On the contrary, it only assumes they're motivated beginners. All the features are directly based on user feedback from many experienced teachers, various kids and adult beginner programmers. Upon what else are we supposed to base such design decisions? As experienced programmers it's certainly dangerous and rather arrogant to think we know what's best for beginner programmers. While our experience as developers may inform our decisions, I believe putting our target users concerns and suggestions at the centre of our development is essential.

The sole purpose of Mu is to get people _started_ with programming - once they have momentum they should switch to another editor. The world has plenty of excellent editors and IDEs so people can find the one that best works with them. It certainly isn't likely to be Mu.

To be quite clear, the Mu philosophy is:

• Less is More ~ Mu has only the most essential features, so users are not intimidated by a baffling interface.
• Path of Least Resistance ~ Whatever the task, there is always only one obvious way to do it with Mu.
• Keep it Simple ~ It's quick and easy to learn Mu; complexity impedes a novice programmer's first steps.
• Have fun ~ Learning should inspire fun; Mu helps learners quickly create and test working code.

As you'll see, nowhere on this list is "treat users as idiots", and this list was compiled / distilled from the feedback of new / beginner programmers. We always make a point of saying that we welcome feedback too and act on such feedback when it is actionable and helps our target users!

Finally, please remember that Mu is an open-source project created entirely by volunteers. We love feedback, both good and bad, from anyone no matter who they are. However, we also have a code of conduct and contributing guidelines (see CONTRIBUTING in the root of the repository) that emphasises the need for a friendly atmosphere and engagement with respect. As volunteers, it's not fun to be on the receiving end of toxic commentary.

Your tone of writing and "I'm right, you're wrong and it's a waste of time to explain to you why" attitude flies in the face of this. While you are most welcome, such an attitude is not. Please, in future, any comments, feedback and contributions you may have for this project (which we will gladly welcome, evaluate and respond to) will be better received if made in the spirit of robust yet respectful engagement.

Thanks for listening and taking the time to engage with Mu.

[tjguk]

On 13/07/2016 22:48, Carl Smith wrote:

The only thing suitable for children around here is your ability to
address criticism.

You made a number of points that are incorrect, but it would be an
obvious waste of time to explain why.

I thought it was just your editor that treats users like they're stupid,
but that's apparently your whole world view.

Carl -- this response is wrong on so many levels.

Even if this were a paid-for support service -- which it's not -- and
even if Nicholas' response were as inane as you suggest -- which it
wasn't -- your's would have been an inappropriate response.

It's the kind of response you should write into an email to get it off
your chest... and then delete the email.

You're entirely entitled to your own views & opinions on the best kind
of editors for children. Or anything else. But Nicholas explained the
background to the thinking around Mu and invited you to come forward
with something substantive to back up your criticisms of that thinking.

All you've done is to respond spitefully. Please don't.

Please _do_ come forward with constructive criticism, framed civilly,
and be prepared for it to be considered respectfully and, perhaps,
rejected as not matching the particular ideas behind Mu.

[carlsmith]

I offered constructive criticism, which I was willing to get into, based on my own experience teaching Python and developing IDEs for beginners, but I was essentially ridiculed for it.

If your idea of minimalism is "vim" then, I'm afraid, you're way off the mark because of the steep learning curve. If you're thinking something more like sublimetext then you're also very wide of the mark - while it's minimalist in terms of look...

Comments like that imply that I'm an idiot that thinks Vim is a minimalist editor that's well suited to teaching programming to children. Only an idiot would think that. To then go on and reinforce the point, ranting about Sublime, just made it even more annoying. It's a rant about something that was never said or thought in the first place, that also implies that I'm stupid.

Mu is for the very first steps into programming. Once you can toddle, you should probably toddle off to use another editor.

That comment is also rude. It was either a snide way of saying f-off, or the author really needs to work on their people skills.

You both assume I don't understand the goals of the project, even though the goals are easy to understand. Have you considered that I might just disagree with some of your conclusions? They seem wrong to me, and I was hoping to discuss it, before contributing to your project.

In my experience, anyone with the literacy skills required to learn a programming language, already possesses the literacy skills required to use a drop down menu. Speaking English as a second language doesn't matter. They are already learning Python. If they can understand English words like continue or return, they can understand other words like save or open. Even if you do decide you need icons, you don't need them to be huge and rendered in primary colours.

I've found that kids prefer to feel like they are using tools that grown ups use, not dumbed down ones with pictures of farm animals. If you tell them "here's an editor - not a real one - a toy one for kids", you'll see the enthusiasm drain instantly. And you don't have to say that, as kids can see for themselves.

[ntoll]

@carlsmith to address each comment in turn:

Idiocy: I am not implying you're an idiot. I never would and it's _never_ my intention to offend; if that's how you read this passage, there's not really much I can do except bring to your attention that I am not implying you're an idiot. My intention was to enumerate all the various ways in which people may think of simple or minimal editors in such a way that you can see why I might have a problem with different concepts of minimalism. I was trying to be helpful, not offensive and engage with your original post.

Toddling: This is a metaphor - but it appears you've mis-read it. Once again, I'm not implying you're an idiot, but I believe the metaphor needs explaining if you believe I'm being rude. I use words like "first steps" and "toddling" as a way to show how developers go from crawling -> toddling -> walking -> running etc... to place where I see the editor in the development of skill. Put simply, it's meant to help you get from crawling to walking. Furthermore, in such a process learners use their current skill level to get to the next level (hence toddling off to find a new editor). As far as I can tell this is a common metaphor. Not sure what more I can usefully say about this except that, once again, I was trying to explain the context in which I see the editor.

Assuming you don't understand: not the case at all. I was delighted you were making your points and was looking forward to debating such things. It turns out that my attempts to politely engage with you failed. There's not a lot I can do about that. I've have been, and will continue to remain, respectful and polite. Any implication of ridicule or offence comes from what I hope you see as your catastrophic misreading of my replies.

Another thing you need to know is that the code for Mu is written to be as simple as possible - the intention is that more advanced learners (i.e. older teenagers) can use Mu to play with, modify and break in interesting and educational ways. As a result they are likely to read the issues and conversations relating to this repository.

Your replies containing foul language, attacks on my character and a generally rude attitude are toxic and do not help the aims of this project: we try to be a friendly place where people can build a code editor together.

I'm at a loss as to what more I can do to help you engage in a positive way to this end. This is demoralising and upsetting. I sincerely hope that, if you decide to reply, you make a significant change to your tone, attitude and assume, like Wikipedia, "good faith" on the part of people taking part in this project.

[samaaron]

For what it's worth, my experience developing Sonic Pi has suggested that for education apps, it has always been beneficial to listen to educators over developers. There are many, many fabulously powerful environments for programmers to use - but very few focussed purely on educational contexts.

I have said _no_ to so many, many, many ideas (often good and reasonable from a developer perspective) and continue to do the same.

Sonic Pi has a very specific design philosophy which covers both the language and the GUI -

If a feature is not simple enough for a 10 year old to use it doesn't go in

Also, we place heavy emphasis on making everything cross platform - which means ignoring the house style of individual operating systems.

I think Mu has made some fab decisions in this area :-)

[carlsmith]

Assuming someone is a casual end-user who doesn't get your goals, then lecturing them on Vim and Sublime is simply not a positive way to engage new contributors. I'm sorry, but you should accept some responsibility for the friction. I was genuinely trying to help.

Just for the record, telling someone "if you don't like x, you can toddle off and do y" is a common metaphor, you're right, but, at least in the UK, it means exactly what I said it means.

Anyway, it seems to have all been a genuine misunderstanding. It's not really important, and I'm sure teenage boys have seen much worse language on the Web.

If a feature is not simple enough for a 10 year old to use it doesn't go in.

It's a good rule of thumb, but drop down menus surely meet your criterion. If a person can't use a simple menu, they can't program. Many programs have complex menus, full of submenus and items with with unintuitive names, but menus are not intrinsically complex. If teachers are saying otherwise, I have to assume they've conflated the problems with typical menus with menus themselves. I remain convinced that an ordinary ten year old could confidently use a drop down menu designed for ordinary ten year olds.

The larger point is that kids prefer real things over toys, so editors for kids should actually just be simple, minimal editors, like Mu could be with a more minimal UI.

I hope you realise that I wasn't flaming your repo. If you look at my account, you can see that I don't normally get into negative personal exchanges in GitHub Issues - that's what Facebook is for.

Best wishes with your projects.

[willingc]

As a reminder, profanity is not acceptable on a project that may have students as contributors, now or in the future. The CONTRIBUTORS.rst file mentions that this project and its contributors respect the Python Community Code of Conduct

[carlsmith]

Fair play. I'll remove it now.

[ZanderBrown]

While the buttons should stay so that we have a familiar cross-platform environment I think for the likes of OSX & Ubuntu Unity we should provide a menubar.