Tuesday, December 05, 2017

Some Thoughts on Drag and Drop Block Programming

I’ve toyed with drag and drop or block based programming for a bunch of years now. I even keep a list of block programming platforms. But this year I am really using them a lot with students. It’s been a real learning experience for me and my students. I’m using AppInventor with my mobile application programming students and code.org’s AppLab with my APCS Principles students. Now the AP class is using AppLab with JavaScript now but we started with the blocks and the interface is still very much drag and drop related.

I’m thinking about this in two ways. One as for my own projects and one as a teaching tool. I’m old school – started programming with punch cards and FORTRAN – so I confess that I am still most comfortable doing my own programming in traditional languages (mostly in C# these days with some Visual basic depending on my mood0. For for students things are different.

First the good. In many ways my mobile apps students are doing more advanced things than my Honors Programming students (C# there). For example connecting to Amazon’s API is a snap in AppInventor. Setting up things like nested code is also very easy. Syntax problems are pretty much not an issue. So we are covering a lot of concepts. That’s all great. I wonder how it will translate for learning text based languages. My AP students all have previous (to applab) experience with text based languages so they are not a control group for me.

One the down side, debugging block based code is different for me. I’m used to traditional debuggers and I haven’t figured out how (or if) that can be done in AppInventor. So of course I go old school with taking code out or adding messages in different places. Error messages in AppInventor are an area where I am facing a learning curve. The idiom is different and I’m teaching myself so it can be slow at times. Next time I teach this it will be better though as my students are showing me a lot of bugs learning opportunities. Still I have had the AppInventor emulator crash with no usable error message and that is a problem. I want to see if I can get some cheap devices to use next year. I think that will make some things better.

UI formatting is an other area I am struggling with. I think this is both a lack of experience and practice with the tool combined with different limitations on a mobile device screen. I am less than happy with my UI for my Windows Phone app which I wrote in C# and Visual Studio which suggests I need help with small screen UI design anyway.

In any case the students in my mobile app class are learning a lot (I think) and enjoying the course (I think) which are good indicators of success. I’m pretty happy with that. I’ll use AppInventor for future sections of Mobile App Programming.

I still feel like blocks are best for small apps and for beginners. Yes, I know people make some pretty sophisticated programs with them but I struggle to wrap my head about that being as easy as text based languages. Maybe 45 years of experience writing text based code is a learning disability for me. Or maybe I just need the right teacher? I’m taking blame here and trying not to blame the tools.

Today block programming languages seem to be mostly designed as teaching tools and they are good at that. I think a lot more has to be done to really make them usable as general purpose languages for more complicated large projects. I do think they can get there even if the path isn’t obvious to me.

8 comments:

Brian Gray said...

There are a couple of other block programming languages that you might want to look at: thunkable.com and gpblocks.org.

Thunkable is similar to AppInventor, but can be used on iOS and Android. I have played with it and like it, but I have not used it with students yet.

GP Blocks is a program that runs on a computer - Windows, MacOS, and Linux. (There is a web-based option, too, but I have not used it.) It is Scratch on steroids, and without the training wheels. My intro-level classes used GP Blocks for the fall term. We have used Scratch in the past, but were able to do far more (and teach more advanced topics and techniques) in GP Blocks than we could with Scratch. The primary author of the program (John Maloney) has been very helpful in tweaking the program to suit a high school lab environment.

There are many example programs in the downloadable package, and an active support discussion forum.

Mike Zamansky said...

I think you know my feelings on this. Some good tools but frequently used in the wrong place and as a crutch to excuse teachers not knowing content.

I'll add one that I like that I don't think you mentioned - codesters.com. They grew out of a tutoring company in NY. I like the tool because it's DnD of Python blocks - when you drop a block, it becomes the Python code.

I also like them because they really listen to and work with teachers.

cooltech.blogspot.com said...

Just in time for consideration during this, Computer Science Week.

Ed Robinson said...

Maybe using a mix of languages would be best.

Snap! programming has a good visualization of lists and lists of lists. You could be teaching a text based language, and then just briefly switch over to Snap! to get across the concept of lists and lists of lists, without the syntax of that particular language.

Snap! also has a visual step debugger, which would be useful for teaching loops.

Garth said...

For any student continuing in CS after high school they have to see a line code language before they graduate. I do not think there is a big difference in the coding skills learned between DnD and line code but the concepts of syntax, IDE management, and the simple skill of typing correctly are something I feel a student needs from high school if they are going to continue on. A kid could walk into a CSCI 135 Java/Python course and survive but they would be burning some midnight oil for quite a while if all they knew was DnD. For those that do not go on in CS DnD is just fine. The concepts behind CS and programming are not (or at least should not be) based on language type but on thought process.

Of course I am like Alfred, I find debugging DnD a royal pain. I also cannot see as much code on the screen with DnD as I like. Those icons take up so much room! I want something like a 40 inch monitor.

Mike Zamansky said...

Garth -- that assumes that there's a smooth transfer from DnD to text for the non CS student.

That non CS student could be asked to or could leverage CS and programming to their advantage in either their future course of job experiences but, at least at this time, would involve text based programming -- writing a Google doc/spreadsheet macro (JS) or a Python script to analyze data for a research project or to generate visuals as two examples.

Would that non CS kid be able to seamlessly on their own move to the text based environments that they could leverage to tremendous advantage? They might have the mental tools from CS using DnD but will they get best benefit out of them without being able to use them in practical environments?

Garth said...

Mike - The thing I am thinking about is that they would have a structure to build on if all they saw was the DnD. Often the option for non CS kids is DnD or nothing. They do not want to take a line code course. DnD is much better than the nothing. I think there is a bit of an issue carrying over the DnD to line code, the transition is still real iffy. I personally do not teach any course that is a full semester of a DnD language. I make sure they see a true line language, even if it is as simple as Small Basic. Any kid that takes a second semester will see Python and a little VB (just so they can see a language that uses forms and VS).

Another thread to this discussion is the teacher side. To my knowledge Montana has one CS teacher with a CS degree. All the others (me included) started with another field and ended up in CS/programming. (I am willing to bet this is a trend nation wide.) I know quite a few teachers who's introduction to teaching programming started with the principal walking into their room in the late spring and asking them to teach programming in the fall. Those teachers almost have to start with teaching DnD, there is a lot of low level curricular materials available that will not bury them in the first year. I attended a week long Python curriculum PD this summer. Three quarters of the class had little or no programming experience. At the end of the week they still were clueless. They had no foundation to build on. They thought programming was just learning syntax. I think if they had started with a DnD they would understand that programming is 80% planning the code and 20% typing the code. A problem with a DnD teacher is they often do not seem to want to progress beyond DnD. It is easy, the kids are having fun, the class is easy to manage so why learn something as ugly and boring as line code?

Unknown said...

I am a fourth year teacher, teaching Exploring Computer Science (ECS) for the first time this year and decided to do it with Python, specifically because I wanted students to have experience with a text based language before taking Java. However, having taught nine weeks of Python, which is all we have time for in the ECS course. I am thinking that I should step back and use a block based language such as Scratch as recommended in the course when I teach it next year.

Teaching the base concepts of selection, loops, variables, and lists seem like it would be easier to do it without having to worry about syntax errors. Students get to focus on the concepts and not the syntax. You do raise a good point about debugging using messages instead of a debugger, so that will be something to keep in mind.

As someone coming to teaching after having programmed for many years, I had forgotten how difficult it was to learn some of those base programming constructs. Thanks for sharing your experiences.