Author Archives: Lou Franco

End Your Day with a Plan for Tomorrow

I keep a physical daily journal in an A5 Dot Grid book. At the end of each day I draw a template for the next day and try to fill in as much as possible. For example: on January 18, I drew this for the 19th.

The red checklist at the top is three things that I must get done that day (The Big 3). This is reserved for my most important tasks. If I can’t commit to three, it’s ok, I can use one or two, but never more than three.

Then, below that are my time blocks for the morning and work-day. If I have meetings, I’ll put them in, and then I try to find a couple of big blocks to work on my Big 3. It’s ok for this to be a little blank the night before, but sometime in the morning it will be mostly filled in.

Under that I’ll keep a running list of tasks and notes for the day as a bullet journal.

This technique is a result of refinement over time derived from a combination of Free to Focus and Deep Work, both highly recommended.

I have a variant of this that I do at the end of the week that I’ll post about soon. One element of the weekly plan is to collect my WINS from the week before, so at the end of each day, I try to pick out one or two things I did that will bring me joy later when I reflect on them.

Icon-Last Development

I am about to release an update to Sprint-o-Mat. I decided to change the text-based UI to something more visual.

The point of Sprint-o-Mat is to guide you during programmed workouts. In my training, I do workouts like this:

Warm up for 15 minutes at a slow place
Repeat 4 times
1. Sprint 1/2 mile at my 5k pace
2. Rest 1/2 mile at a slow pace
Cool down for 10 minutes at a slow pace

Sprint-o-Mat lets you define these runs and then guides you during them with haptics and a read-out. The current version’s running UI looks like this:

I had a few problems with this. First, this is hard to read while running. Second, it doesn’t emphasize the most important information. Finally, there were actually two screens like this that you toggled between with a tap (the UI was not opinionated enough).

So, I changed it to this (just a single screen):

In this view, the outer oval tells you about your overall pace (the white dot is a pace setter) and the inner oval tells you about this particular segment. The center shows those two paces (overall and segment). If you want more info, the corners have details.

Based on this new UI, I changed my icon from:

To:

Once you use the app, this icon is a much better visual cue to it. It also evokes a track, which is a good symbol for sprinting. The original icon evoked sprinting more directly, but it has very little to do with the app otherwise.

This progression from app design back to icon is the opposite of how I did it for Fast-o-Mat.

Vague Tutorials Would Help with Coding Interviews

I think tutorials should be vaguer because “A [vague tutorial] would get the reader playing instead of reading and help them practice composing code instead of copying it.”

In a typical tutorial, all of the code is inline with the text, which tries to explain it line-by-line. In a vague tutorial, you’d get just enough information to write the code yourself. Some code would be given as a scaffold with blanks you fill in.

This is very much like how coding interviews work, so doing a series of vague tutorials would be good training for them.

This means that the sites that are doing training for coding interview (e.g. TopCoder and HackerRank) are to some extent vague tutorial writers. It’s interesting that they also gamify their sites (mostly via ranking), which gets at the theme of many of my posts, although I think gamification is not as good as playability.

In my last job hunt, I knew my target employers gave very hard data-structure/algorithmic style coding interviews, so I spent weeks on TopCoder (most failing) before I applied. The main things I got out of it was deciphering specifications under time pressure and iterative development. Both of these skills are invaluable when doing a coding interview, because unfortunately, tech job interviews are mostly auditions.

AR Opens up Playability Possibilities

Yesterday, I pointed out that Pokémon Go was a playable workout app, where playable means that the game design ideas are driving the app, as opposed to gamification, where it’s slapped on.

I was thinking more about this and realized how many apps may be turned into games via AR. Again, not with badges, but by making playing the point of the app.

Not just for workout apps, which I think will drive lots of AR games.

But for something really different: consider an app that wanted to help you to eat healthier by guiding you while grocery shopping.

We all know what that app would look like: a list of grocery items, maybe color coded with “healthiness”. You tap tap tap when you buy eggplant, spinach, and blueberries (“You got an anti-oxidant badge!”). You lose points when you scan that box of mini-donuts.

The AR version has zombies in the cookie aisle.

Interestingly, the produce section seems to have no zombies—better scavenge there. Cookie boxes emit a piercing sound when they are in your cart, drawing the dead towards you. Leave them behind to draw them away.

An art appreciation app could help me get more out of a museum by telling me a little about what I might see and then making a ad-hoc quiz show as I take in the art. Or putting me in a pub quiz later based on what I looked at.

AR could turn a tour guide app into a spy hunt game. Follow that lady in the black trench coat and see what she’s up to—she’s boarding the boat to the Statue of Liberty! It’s practically the plot of North by Northwest.

These would be games, which are fun, not gamification.

Pokémon Go is Playable, Apple Workouts is Gamified

Let’s say you are trying to develop an app where the goal is to get the user to walk more outside.

Pokémon Go does this by building an AR world where it is fun to go outside and find pokémon, and then it makes you walk in order to hatch them. It makes you go to new destinations to progress in the game. Walking is a byproduct that is not particularly rewarded outside of the game goals you achieve. For example, you aren’t given a badge just for walking a lot.

In Apple Workouts, I walk if I want to. I can tell the app or not. It tries to encourage me with alerts and badges (and filling my rings). It’s using positive reinforcement and the elements of games, but walking is not a game. They have layered on points, levels, badges, and competition.

This is what I mean about the difference between playability and gamification. I don’t think that Pokémon Go was actually trying to make a workout app. The walking mechanic is just what is available to an AR game—it’s the equivalent to the walking/running you have to do in any side-scroller.

Like Pokémon Go, the playable version of a thing is unlikely to resemble that thing at all. The gamified version is recognizable for what it is.

Playable, not Gamified

In Playing a Book, I said:

You don’t read a programming book, you play one. I mean play, like playing a game. In a game, you progress through levels by learning and applying skills. At the end of the level, you play against a boss that you have to beat to progress.

I want to clarify that I don’t mean “Gamification”. I don’t want a book to seem like a game—I want it to literally be a game.

In a gamified book, you would just write the book as normal and then give the user a badge when they complete a chapter. Or maybe you’d assign points to various things.

The distinction I am trying to draw is that playability is something you start with to drive your design. Gamification is something you slap on at the end.

Icon-first Development

I’m currently working on an app to help me with intermittent fasting. I developed it icon-first.

My apps mostly exist to drive my own learning. Right now, I am trying to learn SwiftUI and visual design.

To do the latter, I’ve been reading Designing Visual Interfaces, which came highly recommended from Amy Hoy. The first chapter teaches techniques for simplification, and so I decided to not think about the UI at all at first, but to find some kind of unifying metaphor by trying to design an icon that meant “intermittent fasting” to me.

In intermittent fasting, you try to eat in a defined time window each day, commonly eight hours (so, fasting sixteen hours). Many people just pick a time window and use it every day (e.g. 10-6), but that doesn’t work for me—I want to decide each day what woks best for my schedule.

So, with that vague idea, I started sketching

To get loose, I just drew a circle. Then, a pie chart that showed the feeding window as a third of the whole. Then, I tried a ring. Eventually, I just had a vertical stripe, then a horizontal one. I realized the essence was “thirds”—8 is a one-third of 24. I also had the idea that I could hide an “F” in the design (for Fast-o-Mat, the name of the app). I don’t like icons that have a word or letter in them, but a hidden letter in the design is fine with me.

At this point, I thought I could go into Pixelmator and refine. There have been many iterations. This one imagines showing seven days of history in a vertical stack.

I really like how the “F” is hidden in this one. The problem was that when I went to make this UI, I didn’t like using it. Seven days is way too cumbersome when you mostly just want to deal with today (and maybe yesterday and tomorrow).

Also, a phone is tall and narrow, so this design overemphasizes the week over the day when you render it in portrait. It’s hard to edit the today-bar, because it’s too narrow.

So, I worked on my UI and eventually settled on only showing three days (yesterday, today, and tomorrow). I went back to the icon and made this:

This does not have as recognizable an “F” in it, but that’s not the priority, so I am ok with that. Each vertical bar is a day and its position shows the part of the day you are feeding. The Today bar is bigger than the other days, because that’s the most important. On a phone, this whole things is stretched vertically, so there’s plenty of tap space on the parts of the bar you might need to interact with.

I am still working on refining the UI. I’ll follow-up when that is closer with thoughts on how that evolved.

Working through the icon helped me focus on simplicity. Designing Visual Interfaces talks about designs being instantly recognizable and impossible to use incorrectly. A lot of this comes from reducing the number of elements.

The second chapter is about visual perception, using things like contrast and size to allow the user to group elements into layers and order them.

Using the constraint of designing an icon first helped me focus on those aspects of design.

Programming Tutorials Should be Vaguer

The basic template for programming tutorials is:

An introduction with a motivating example
Step-by-step how-to style instructions with code
Conclusion

But, if the way to learn programming is to write programs, this template breaks down at step 2. At the end of the tutorial, you have working code, but since your brain was engaged in reading and typing (or copying), it’s hard to absorb the information. I know that when I have “done” tutorials, I didn’t really learn the material in a way where I could do it on my own later.

So, perhaps tutorials shouldn’t give you all of the code, but instead provide enough information for you to write it yourself.

For example, here’s a code sample from a tutorial I wrote about GameplayKit:

enum GameOutcome: String {
    case win
    case reset
}

Instead of showing this, I could have written: “Declare a string-based enum named GameOutcome with two cases: win and reset.” There could have been a button that revealed the code.

Another way would be to use Steve McConnell’s coding technique from Code Complete. He suggests writing the comments first and then writing the code beneath (and between the comment lines), so like this:

// GameOutcome is an enum of the possible final states: win and reset.
// It needs to be a String-based enum because we use the
// raw value in GameplayKit methods that take an AnyObject.

This really only works for very simple code (I know because I tried to write the above example for more complex samples and couldn’t). A tutorial like this would get the reader playing instead of reading and help them practice composing code instead of copying it.

New Article in the Swift Companion: Methods

Yesterday, I wrote that books should get you to write code, not just read it. I’ve been working on a companion to Apple’s Swift Programming Language book that helps you do that by offering exercises for each chapter.

I just published the companion to the Methods chapter on App-o-Mat. If you want to start from the beginning, go to the outline of Section 1. If you understand the content of the corresponding chapter, the exercises are meant to be very easy. If you are having trouble with them, it would be a good idea to review the chapter again before moving on.

Learn Programming by Writing Programs

Most programming books and tutorials show you code and explain it. What they should be doing is describing code they want you to write.

Here are some examples:

Project Euler presents one numerical programming problem at a time. You must provide the correct answer (a number) before you can see the next one.
Apple’s Swift playground books on iPad also make you write code. Your programs move a robot around a board, and it knows if you achieved the goal they specified.
The Unwrap app by Paul Hudson. It combines video and written lessons with challenges of various types including writing Swift code. Each lesson is very small.
freeCodeCamp breaks down learning web development into tiny coding challenges that are auto-checked by the site.
Cryptopals teaches you how to write cryptography and code that attacks it with lessons you check against the expected output.

The big advantage of this style is each level can be very focussed on using just one new skill. In this talk by Kathy Sierra (and in her book Badass) she covers the research behind skill acquisition. One big idea is that you need to break skills down into tiny sub-skills. The reason is so you can master part of a skill, rather than half-master a full skill, which is hard to improve later.

She also says that learners need feedback, which these systems do by verifying your work automatically (or by having an expected output you can check).

In contrast, most programming tutorials are quite long and don’t make you create your own programs (so can’t really provide feedback).

If all you do is read or type in the code in the tutorial, you aren’t practicing a core skill of programming, which is to write code on your own to match a specification.