cutting.io

Conway: Life and Death v1.1

2024-09-02T03:12:00Z

I noticed my game of life app, Conway, had a couple of cosmetic bugs on newer versions of macOS so I spent a couple of hours fixing them up. While I was at it I couldn’t resist the urge to tinker and added an option for cells to leave trails, which I think makes the app very pretty!

I originally wrote the app as a tribute to John Conway. It’s no longer available on the Mac App Store but you can download it as a zipped app instead. (Warning: the binary has not been notarized so you’ll need to proceed at your own risk by following Apple’s instructions for running unnotarized softare.)

Adding trails was an interesting technical diversion.

Each cell in the universe is stored as an unsigned 8-bit integer in a texture, meaning it can have 256 different values. The original version of Conway used 0 for “dead”, and 1, 2, or 3 for “alive”. Each alive value was assigned a different colour, but were equivalent for the purposes of running the simulation.

This meant I still had 252 other values I could use for each cell, which just happens to divide nicely by 3, the number of colours each theme supports. I invented a new “zombie” state for each colour which is defined as dead for the purposes of simulation, but acts as a countdown from fully alive to fully dead.

Cell value	Definition
0	dead
1–84	zombie
85	alive
86–169	zombie
170	alive
171–254	zombie
255	alive

When each generation is updated, the zombie cells decrement until they reach fully dead. To show the fading trails, zombie cells are rendered as a blend between the background colour and their assigned alive colour depending upon how dead they are.

Zeds dev diary 20240813

2024-08-13T12:19:00Z

Zed’s new modal editor really simplifies a lot because there’s virtually no need for @FocusState any more.

I also applied extra polish this afternoon in the way of better VoiceOver descriptions and support for other accessibility features like reduced motion and increased contrast. Dynamic Type and dark mode are, of course, well supported.

Zed’s footer is now opaque; avoiding transparency over the scroll view results in fewer animation glitches when showing/hiding the keyboard.

In short, I think the UX feels pretty good now!

To concentrate on getting this app done, I’ve ditched the iPad-specific feature of showing all three lists on the screen at once. I expect to come back to this in a future version.

Next step is to dogfood the app for a few days to find the rough edges.

Zeds dev diary 20240812

2024-08-12T01:00:00Z

I’ve clarified the tabs on iPhone and added task separators. The iPad version of Zeds now shows all lists on the screen at once, and supports drag’n’drop both between lists and as a way to export/import text. But drag’n’drop, focus state, text fields and lists are giving me grief!

`draggable` & `dropDestination`

The new draggable and dropDestination APIs are powerful but limited, as with much of SwiftUI. For instance, there doesn’t appear to be a straightforward way to detect when a drag is in progress unless I fall back to the older onDrag API (which doesn’t play nicely with the new API). This is a problem because my tasks have tap gestures to activate editing which should be ignored during a drag.

`@FocusState`

My current UX has inline editing of multiline text fields in lists. This means editing focus can easily change as the user moves between text fields.

Unfortunately, it’s difficult to use a view model as a source of truth for focus because SwiftUI manages this closer to the view level with @FocusState (which can’t be used outside View types). Furthermore, focus state only works for views that are currently on screen so it can’t be used to record which task is currently being edited if that view is scrolled off-screen.

Any logic that needs to know whether a task is being edited thus relies on copying state between views and view models as they change with onChange. This is possible but error-prone and ultimately results in no single source of truth.

`ScrollView`

There is an unavoidable animation glitch if a scroll view or List has a safeAreaInset view at the bottom when the keyboard is dismissed. The workaround I’ve gone with is to not use the safeAreaInset directly, but calculate the amount of space needed with various reader proxies and pad the scroll view content itself.

Next steps

I have spent hours working around many bugs like these. My views are brittle, with surprising code that tries to balance all the hacks needed to make it fit together. My intention now is to significantly modify the UX to avoid the hacks. A modal editor for tasks rather than inline editing will help me avoid focus state issues and multiline text fields in lists.

Zeds dev diary 20240804

2024-08-04T05:53:00Z

I’m learning some new SwiftUI APIs by writing a “do it later” iPhone app called Zeds (ok fine… it’s a to do app, and yeah, that name is meant to sound like snoring but doesn’t work for US readers).

The premise is to boil everything down into just three lists: things to do later, things to do now, and things I’ve done. These lists are laid out next to each other in space from left to right.

Only one list is visible on the iPhone screen at a time and tasks are moved between them by swiping left or right. A stylised tab bar at the bottom lets you switch between the lists. Essentially it’s Kanban with nice gestures. I asked some beta testers to try this out with no help except for some initial built-in tasks acting as a user manual.

Although it all seemed clear and simple to me, no design ever survives first contact with the user. :)

My testers initially found the app confusing:

on launch there appeared to be only one list
it wasn’t clear what each tab icon represented, or even what the tab bar did
the instructional tasks looked like a large block of help text rather than sample items in a list

This confusion stemmed from some of my design choices:

no labels on the tab icons and no title on each list
- the principle was to minimise the amount of text in the UI to focus on the user’s text in the lists
replace the standard iOS tab bar with a minimal tab switch
show the to do list without indicating there are other lists either side of it
- the tab bar is meant to convey this but doesn’t
remove separators and other visual indicators of the list rows
- the list looks “cleaner” but is less obvious for new users

Next steps to consider:

labels on lists
fewer, simpler instructional tasks
an initial animation to indicate the lists positions in space
a more “direct” way of switching lists than the stylised tab bar
separators or otherwise distinguished list rows

Sierpiński gaskets in Swift

2024-07-26T03:29:00Z

I played the Chaos Game today to make a Sierpiński gasket (aka Sierpiński triangle). You can read the code below or download the Swift Playground to experiment with it yourself.

Just plot some points using this simple algorithm to see a ghostly fractal triangle appear from nothing:

Set your “current” position to any of the three corners of the big triangle
Plot a dot at your current position
Pick any of the three corners
Find the midpoint of your current position and that corner
Set your current position to that midpoint
Goto 2

I’ve been fascinated with fractals since my Dad took me to a lecture given by the legendary Benoit Mandelbrot at UNSW (or maybe it was USYD?) back when I was a kid in the late 80s. I remember writing BASIC programs for my Apple IIc and leaving them running overnight to make just one fuzzy postcard from some hidden nook of the Mandelbrot set.

But for maximal simplicity versus awe, you can’t beat Sierpiński gaskets. So easy!

The easiest way I know to plot points these days is on a SwiftUI Canvas. You’ll need to wait for all the points to plot before you can see the image so don’t make numDots too big.

Making the canvas redraw as it plots each point is left as an exercise to the reader. ;)

import SwiftUI
import PlaygroundSupport

let numDots = 1000
let dotWidth: CGFloat = 1
let dotColour: Color = .blue

let points: [CGPoint] = [
    .init(x: 0, y: 1),
    .init(x: 1, y: 1),
    .init(x: 0.5, y: 0)
]

let canvas = Canvas { context, size in
    // 1.
    var current = points.randomElement()!
    
    for _ in 0..<numDots {
        
        // 2.
        context.fill(dot(for: current, canvasSize: size), with: .color(dotColour))
        
        // 3.
        let selection = points.randomElement()!
        
        // 4.
        let midpoint = CGPoint(
            x: selection.x + (current.x - selection.x) / 2.0,
            y: selection.y + (current.y - selection.y) / 2.0
        )

        // 5.
        current = midpoint
    }
}
.frame(width: 200, height: 200)

func dot(for point: CGPoint, canvasSize: CGSize) -> Path {
    .init { path in
        path.addRect(
            .init(
                x: point.x * (canvasSize.width - dotWidth),
                y: point.y * (canvasSize.height - dotWidth),
                width: dotWidth,
                height: dotWidth
            )
        )
    }
}

PlaygroundPage.current.setLiveView(canvas)