Open nevilh opened 7 years ago
I agree with trying to create as much similarity as possible. I think it 'Microbit' was at the top, too, it might also help things like #37 as it increases the chance someone finds those constructs
While I understand your points, I disagree for the following reasons:
MicroPython and PXT are fundamentally different platforms that are organised in completely different ways. Such diversity is to be celebrated! My personal experience as a secondary head of music is that children are used to coping with different ways of doing things - be that playing a piano vs singing in a choir (both involve reading music, but they're very different musical activities) or using PXT or Python with a micro:bit (both involve programming but they are very different activities).
Furthermore, the current organisation of the blocks reflects the underlying Python APIs. The Python APIs are the result of a LOT OF THOUGHT and testing with kids and teachers. The sole purpose of the Python blocks is to facilitate the next step to text based programming with Python and so we want to encourage a mental model that fits the Python APIs that we already have.
Copying PXT's organisation of blocks is, IMHO, a step in the wrong direction and going to put Python at a disadvantage. It'll completely negate the reasons we built the blocks in the way that we did (to familiarise learners with the Python API and Pythonic way of thinking).
To continue the musical analogy, you're suggesting the equivalent of writing Piano music in four parts labelled Soprano, Alto, Tenor and Bass. ;-)
I'd understood this to be more 'order the categories more similarly to pxt' rather than change the apis. I thibk blocks mapping to APIs is right. @nevilh what were you thinking?
So, the categories remain the same but put in a different order? In which case, I'd suggest alphabetical order is the most beginner friendly order we could choose.
Well, looking back at @nevilh's original issue, I think he's arguing something different to me, actually.
As people start searching the blocks from the top, typically, then I think the ordering by frequency of use/utility is actually really sensible.
There's already a precedent that sorting some things out of order is 'right' because 'Loops, Logic,..etc' aren't with the rest of the blocks. And 'Lists' appears underneath 'Text'!
Thinking about what Nevil has said, and the existing APIs, perhaps there's a different grouping that makes sense
I've been trying to see if I can group things as, say "Input, Output, Utility, Variables" but that doesn't quite work because Pins and Radio are 'IO' not 'I or O'
Here's a strawman:
==============
Micro:bit
==============
Input
---------------
Acceleromater
Buttons
Compass
=============
Output
-----------
Display
Music
Neopixel
Speech
=============
Pins
=============
Radio
============
Logic
Loops
Math
Text
Lists
Images
===========
Variables
===========
Breaking things down like this might also help solve some of the things that mean people ask for 'Simple' and 'Advanced' mode (see #23 )
So this is a classic case where I'd want help from a UX person. I know several really great UX people so I think the best route forward is to ask them for some advice about how to move forward on this. The UX people I know have a great knack of taking the guesswork out of this sort of thing, testing assumptions and getting feedback from users. I'm sure they'll be able to give pointers.
I don't think WE (you, me, other experienced programmers) should decide on the order. It should be arrived at after some careful investigation, testing and validation in terms of UX.
Right, but that's where looking at the MS block editor and PXT can help, because BBC had UX designers work on those aspects for original deployment.
But if you've got some UX designers available to help, great!
On 16 March 2017 at 12:38, Nicholas Tollervey notifications@github.com wrote:
I don't think WE (you, me, other experienced programmers) should decide on the order. It should be arrived at after some careful investigation, testing and validation in terms of UX.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bbcmicrobit/PythonEditor/issues/34#issuecomment-287044314, or mute the thread https://github.com/notifications/unsubscribe-auth/AAI-qeBzk6bKbr_oaJQKyEEvldfcDExTks5rmS04gaJpZM4MUwWO .
It was about making it as easy as possible for students to move back and forwards between the different versions of Block (Regular Block, PXT Block & Python Block). Also it might make it easier for teachers who have worksheets based on Regular Block to re-use them (with minor modifications) with Python Block. For instance the Kitroniks Inventor's Kit Manual describes the Blocks as found in 'Regular Block' with the Blocks colour coded to help the students locate the menu of the same colour where to find them. Maybe getting some input from UX designers, as you say, is the thing to do.
Here's the 'blocks' ordering
I notice the Blocks Menus are organised in alphabetic order. Whilst there is a logic to them being in that order, since most students will graduate from the regular BLOCK or PXT BLOCK to Python Block I think it would help the student if the menus items were (as near as possible) in the same order with the same names and each menu item contained (as near as possible) the same Blocks as BLOCK/PXT BLOCK.