2016-04-02 Pen up and down, smoke test and UI considerations

Yesterday was an interesting day for Logeox. First of all, I added the pen up/pen down feature. It was quite easy under the hood: just add a Boolean field to the Turtle object, and generate getters and setters (I still honestly don’t know why). Then, in the goForward method, use lineTo or moveTo depending on the pen state.

What was more difficult, though, was making a reasonable UI for this feature. Currently there are just two buttons – unimaginatively labelled “Pen down” and “Pen up” – which change the state accordingly. The point is, this is extremely bad UI. What I probably should have done is a single button, toggling the state. (Interestingly, there is a widget for that, called ToggleButton. It has one drawback, though: it is a text button and not an image button, and I wanted to replace all my text buttons with image buttons. Google says there exist some ways to overcome this problem. There may be no such need, though – read on!)

Since the buttons carry no indication of the current pen state (currently at least), I thought that I needed some way for the user to immediately see whether the pen is down or up. My idea for that was to make the turtle color lighter if the pen is up. While I was at it, I also substituted newly generated pngs for the turtle. Somehow Android Studio changed my nice, black triangle into a gray mess when it imported the image. I decided that I was going to replace the bitmaps in the res folder manually, and so I did. (This is not scalable (pun intended), but I just created a big bitmap, rescaled it manually using ImageMagick four times and put the results into the folders corresponding to various screen densities. If it weren’t a one-shot job, I’d have scripted that, of course.) Then, I had to find a way to make it more or less gray programmatically, and this way I learned about LightingColorFilter. Nice.

And then everything suddenly stood on its head: I decided that all the basic functionality is in place, and handed my phone to my daughter. (Spoiler alert: I was very wrong.)

First of all, rotating the phone crashes the app. No wonder: the horizontal layout lacks the pen up/pen down buttons. No point in adding them, though – they won’t make it to the final version anyway.

Perhaps more embarassingly, there is no way to actually clear the screen other than manually killing the app. It would be funny if it weren’t so annoying.

But watching my dear little user revealed to me yet another thing: Steering the turtle with buttons may not be the right way at all. Why should I even want to have a button toggling the pen state when I can accomplish that by tapping the turtle itself? Why should going forward be launched with a button and not by tapping ahead of the turtle? And by analogy, turning can be done by tapping near the turtle’s side. And when I manage to do this, I won’t need separate horizontal layout at all. That’s good. (OTOH, the short time when rotating the phone actually worked reminded me of the problem of saving the drawing instead of resetting the blank canvas when it happens. That will need some more research.)

Another thing that dawned upon me – this time while watching my wife playing around with the current state of the app – was that I have to do something reasonable when the turtle goes offscreen. (As I wrote some time ago, I have some ideas – I just need to actually implement something.) Currently it is all too easy to lose it and practically never be able to find it again.

And that’s it for now. (I’ll save the rant about the design of the code structure – or rather, the lack of such design – for another time. I guess I’ll have to reread something on software design… I’ll also save the considerations concerning the default turning angle – actually, these will most probably have their own post, since it seems that there are some interesting choices there.)

CategoryEnglish, CategoryBlog, CategoryMakeYourselfKnown