In this screenshot, I’ve circled a bit of directed interaction. There’s a highlight around “0.5” and a pop-up editor that allows the user to change the value. This new feature is made possible by Swift Playground markup.

Like all Swift playgrounds, this page uses live code, some of which you see and other parts of which are hidden, either by placement in Sources or by using playground markup. The code is marked up to disable edits except in this one place. Here’s what the key part of the underlying code looks like:

filter.setValue(/*#-editable-code*/1.0/*#-end-editable-code*/, forKey: "inputAmount")
imageView.image = UIImage(ciImage: filter.outputImage!)

Yes, those are in-line comments adding markup in the  setValue call. It’s kind of ugly and it relies on the old-style C /* */ comment delimiters that allow the markup to be inserted in-place.

From a coding viewpoint, it’s ugly as sin. From a user experience viewpoint, it ensures that users can explore exactly one setting to better understand the Core Image vibrancy filter.

This is no way, at least at this time, to use markup to limit values to legal parameters. For example, Core Image may not like negative numbers or numbers above 1.0. You could work around that by using a separate variable and adding clamping code, e.g.

var inputAmount = make this editable
inputAmount = clamp(inputAmount, 0.0, 1.0)
filter.setValue(inputAmount, forKey: "inputAmount")

But if you do that, you’re drawing attention away from the CI code you’re demonstrating and focusing it on user interaction instead. No one’s going to use this pattern in real code, while they may very well use the pattern in the screenshot. (Which, if you think about it is the real point of this.)

I’ve gone ahead and filed a radar (26996963) about the issue, asking for enhanced markup that allows input qualities for editable playground sections.

I probably should file another one asking for “Auto Run” markup, so these kind of examples will re-execute on each edit, just like they do on OS X.