Mu: Versioning/auto updating on windows package

[dannystaple]

Discussions with Nicholas - suggestion is instead of a version number in a corner/about box - a "an update is available - get it?" dialog/pop up - based on pinging an endpoint for the latest release.

NEeds to be foolproof/unobtrusive.

[ZanderBrown]

Possibly use GitHub API (When we start using releases) or a JSON at the root of the website.
Simply download the JSON on launch compare strings, display the appropriate message.
Probably have an option to disable it.

[carlosperate]

Ideally we should start using the GitHub releases, so that would make using the GitHub API the preferred method.

From that point I would suggest to do the simplest thing possible, which is probably to open the releases page for the user to manually download the latest version.

To make it unobtrusive we should make this configurable (ON/OFF) from the settings file. To have it OFF by default would probably make the entire feature useless, as I doubt anybody is going to go through the settings documentation just to enable this feature. If we have it ON by default then we should pay a lot of attention to the way we indicate a new version is available.

I assume most schools will install Mu into a classroom and happily use that one version throughout the academic year without updating. In that case it would be really annoying if a window would open to tell you to upgrade every time the app is opened.

[carlosperate]

Just an idea:
We could do the check on Mu and if a new version is found we could very briefly and subtly highlight the help button.
Then on the help website we could have it check as well and dynamically add a message to the top of the page instructing the user how to upgrade?

[ntoll]

This needs thought. My brain-dump:

• We should check for updates by default (and I agree with Carlos, this should be configurable).
• In the event of an update it should remind you with a friendly pop-up that happens but once.
• From then on, if you click on the help button (which takes you to a versioned endpoint) you should see a warning in the help page saying "This version is out of date" etc... with instructions for how to update it.

Thoughts?

[carlosperate]

In the event of an update it should remind you with a friendly pop-up that happens but once.

Once per "new update" or once ever? If we do the "remind once per new update" then we are going to need to keep some type of record to know when to remind again or ignore.

From then on, if you click on the help button (which takes you to a versioned endpoint) you should see a warning in the help page saying "This version is out of date" etc... with instructions for how to update it.

I think we should be doing this at the very least, with whatever else we decide for the desktop app. I quite like the idea as it is relatively simple and we have quite a bit of control over it to change it if needed.

[ZanderBrown]

I know the idea is to keep things simple but as more and more gets added we seem to add another button to the toolbar & a couple of popup dialogues for good measure.

Maybe it's time to consider a status bar or, dare I say it, a menu.

[carlosperate]

I think that omitting a drop down menu bar is a very good way to ensure we don't add too many features and to keep things simple. The general idea of Mu is that it should be an introductory editor, if you need additional features perhaps it's time to move to more advanced tools.

This can also to be used to measure and evaluate if new functionality fits within Mu's goals. If it's an important feature that will be useful for the target audience and it needs it, then it should have its button, otherwise we might have to consider to not add it.

[ZanderBrown]

I'm not looking for additional features it's more that the original toolbar

Is becoming increasingly crowded:

And modal message dialogs are not always the correct way to inform the user and some start to become quite irritated at pressing 'ok' to everything

[ntoll]

I'm with @carlos regarding the toolbar as a warning signal for too many features. I'm also with @ZanderBrown in that the toolbar is perhaps, shall we say, "full"...

There are four sections to the toolbar: files, micro:bit, look/feel, other. I set myself the self imposed (and I admit arbitrary) max number of three buttons per section. We've now reached that limit:

files: New, Load, Save
micro:bit: Flash, Files, Repl
look/feel: Zoom-in, Zoom-out, Theme
other: Check, Help, Quit.

As Mu supports other Python modules the only section of buttons that should change is the "micro:bit" section that should include context specific buttons. For example, for a vanilla Python script they should probably be "Run", "Debug" and "Repl".

Hopefully you can see there's a method to this apparent madness.

The most important reason for buttons is more to do with literacy and children: many of our users will have underdeveloped reading skills and icons help with this problem. Please note, I don't mean our users are stupid. As a teacher in UK secondary schools I regularly taught kids with English as an additional language. I also taught a surprisingly large number of kids with dyslexic related issues as well as many who simply had special educational needs. Big bold and obvious images help kids to make sense of the textual aspects of the interface. In most of the schools I taught, I estimate over 50% of 11yo kids were impacted by one or more of these issues. It's for this reason that a limited set of visually informative buttons are so important.

Hope this makes sense. Remember Mu isn't for programmers... it's a first step.

[ZanderBrown]

I understand the madness I see the problem myself regularly however by using these big cartoon buttons we run the risk of making feel like they are being treated as if they are stupid (i know this is not the intention).

But we do have to consider that functions like Save As... have been requested multiple times but with the current system there is nowhere to place such a button. Such students generally navigate fine around the likes of Microsoft Office so maybe a slightly more detailed menu system could be adopted? Another possibility to help with English being a second language is to provide translations

[ntoll]

Apart from one rather brusque software developer, we have never had any feedback from a teacher or student that says the iconified buttons makes them feel like they're stupid. On the contrary, at PyCon UK I was actually congratulated by one teacher about the thought that has gone into Mu's user interface. None of the kids at the childrens' day at PyCon UK complained about the tooling (except for one boy on stage during the show and tell, who complained about Mu but it turned out to be the gestures API in MicroPython that was problematic). In fact we had them all set up within 5 minutes: a remarkable achievement when you consider that with other editors all sorts of things go wrong and much of previous year's PyCon UK have been spent reconfiguring editors, fixing things and re-explaining stuff. Not so this time: kids coded and forgot about the editor. That's a result. All the above is backed up from feedback from the Raspberry Pi Foundation education team whose suggestions were the basis of initial UI work in Mu.

"Save As" is a classic example of, "if you know you want 'save as' then you're too advanced for Mu". In that case we should provide an obvious next step with some suggested next editors - I'd love to hear your thoughts on what these may be - along with details of how to use uflash, microfs and, say, picocom to interact with the device. Perhaps we should consider a MegaMu editor that looks more "traditional" and caters to more advanced programmers (although there are plenty of editors that already fulfil this role). Some sort of progressive enhancement of the UI as the user starts to use the editor is an alternative way forward (although this would be difficult to get right and make Mu's code base very complicated).

Hope this makes sense. And please please please don't think dismissing your point of view. If you can show me evidence from teachers and kids that the UI is problematic then we should look into it and make changes as appropriate. Nevertheless, I believe the feedback we've had so far indicates we're on the right track.

Regarding English as an additional language - I spent a lot of time working with teaching colleagues in this respect when I was a teacher in London - the point is not to give information in a native language but to facilitate the practice and use of English. Teaching is done in English and, especially for computing, the subject matter is in English. I taught lots of very clever kids who were refugees from the Balkan war: they'd arrive with no English, but thanks to their own efforts and those of my EAL support teaching colleagues they'd soon pick it up and fly. It is for these learners with underdeveloped literacy skills that we give visual hints.

:-)

[ZanderBrown]

Feel free to ignore my suggestions. This is your project based on your experience & research and as such can do whatever you like with it :-)

MegaMu could definitely be a good idea as IDLE, PyCharm ext. are definitely big and scary for still relatively 'new' programmers. MegaMu could be an 'intermediate' step towards moving onto these editors. The sort of metaphor I'm thinking of is: learn to toddle in Mu, walk in MegaMu and then run in IDLE, PyCarm or whatever else.

A 'MegaMu' could add a menubar & status bar whilst retaining the main toolbar allowing users to mix and match between the two ways of doing things as they move on to the next stage of their programming experience

[ntoll]

@ZanderBrown please never think I'm ignoring suggestions. I _welcome_ constructive criticism, comment and ideas - it forces me to justify myself and without your prompting we wouldn't have got to the interesting proposition of "MegaMu".

In an ideal world, what would it look like? How would it function? How would it bridge the gap between Mu's simplicity and, say, Atom (randomly picking an editor at random)..?

:-)

[ZanderBrown]

Only a limited initial response but some slightly dodgy ui mockups:

Focused on the window:

Ignoring my bad art my initial ui thoughts are:

• Smaller toolbar buttons
• Menubar featuring the toolbars actions as well as additional features such as save as
• Statusbar showing shortened versions of many of the messages currently implemented as dialogs (a simple "Flashing.... Complete" instead of the explanations about flashing lights ext)
• Current cursor position information in status bar
• Probably some kind of "command pallet":

[ntoll]

Responses to your initial thoughts:

• Do we need icons in the toolbar. Perhaps we should be encouraging the use of menus?
• Simple menus++. Thoughts on naming? How about... File, Code, View, Help (relating to the four sections in the current Mu toolbar).
• +1 status bar
• +1 to lots of information in the status bar
• Not sure what you mean by "command pallet".

[ZanderBrown]

Command Pallet is a feature available in VSCode and I believe atom. Ubuntu has the similar "Heads Up Display"

The basic idea is a textbox which when you type into displays a filtered list of menu items. Useful as it allows keyboard-only operation without haveing to remember keyboard shortcuts.

Probably overkill with the limited options.

File Code View Help definitely seems like a good selection matching up nicely with Mu's sections (possibly label them as such in Mu?).

Maybe the toolbar should be optional (off by default?) with the appropriate option in View

[ZanderBrown]

MegaMu should have things like #164

[ZanderBrown]

So returning to the original point of this issue, now we are using releases https://api.github.com/repos/mu-editor/mu/releases becomes available.

Should make implementing such a feature easy. any suggestions on a update available interface?

I'll attempt to put something together over the next few days with at least a placeholder interface

[ntoll]

I'm playing devil's advocate here...

Mu displays its version in the toolbar of the window. Many teachers teach to a specific version of a piece of software. Most of them don't have any choice about how or when to upgrade their software, so I'm not sure how useful such a feature would be.

One thing we could (and will do) is update the help page with a "This version of Mu is out of date" banner across the top, for all help for old versions of Mu.

In the interests of not-making-work-for-ourselves, I'll close this issue. If, at a later date, lots of teachers and/or users want an "update available" feature we can revisit how we might do this within Mu.

Thanks for all the contributions folks!