PythonEditor icon indicating copy to clipboard operation
PythonEditor copied to clipboard

Organisation of Blocks in Menus

Open nevilh opened this issue 8 years ago • 10 comments

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.

nevilh avatar Mar 06 '17 22:03 nevilh

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

jaustin avatar Mar 15 '17 12:03 jaustin

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. ;-)

ntoll avatar Mar 16 '17 11:03 ntoll

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?

jaustin avatar Mar 16 '17 11:03 jaustin

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.

ntoll avatar Mar 16 '17 11:03 ntoll

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 )

jaustin avatar Mar 16 '17 12:03 jaustin

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.

ntoll avatar Mar 16 '17 12:03 ntoll

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.

ntoll avatar Mar 16 '17 12:03 ntoll

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 [email protected] 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 .

jaustin avatar Mar 16 '17 12:03 jaustin

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.

nevilh avatar Mar 16 '17 16:03 nevilh

Here's the 'blocks' ordering image

jaustin avatar Mar 24 '17 15:03 jaustin