I'm sure I'll have more to say about the UI behind Splash-O-Matic 2600, my upcoming browser-based tool to make large, ready-to-run images for the Atari 2600, but right now I'm chuffed that I got an image "upload" feature working - except it all happens in the browser!
Here's the editor page:
and here it is running on an Atari Emulator -
The trick is using the createFileInput() feature from P5. I didn't get the (probably more performant) loadPixels() version working, but get() let me read from the pixels and take a guess if this square should be black or white.
I was worried this was going to be super-tough to add to my tool, but it turned out to be pretty easy. The trick was not to overthink it: in theory I could let the tool carefully scale and crop etc the uploaded image - but that would really complicate the UI. I decided to let the program just scale the original image to the width and height of the canvas, then read the pixels. (In atari-pixel-size chunks)
I've been thinking a lot lately about The Rise of Worse is Better. This is a good example of the "New Jersey approach" favoring simplicity above completeness - making the implementation simple really made the whole thing possible.
But thinking about the example from the essay - the "interface" for the PC loser-ing was "more complex" because the programmer had to do more checking. And the metaphor for me is, my "interface" is in some ways "more complex" because the user might have to scale/crop the image on their own. But, the UI itself reflects the simplicity of the interface! Which in turn means the user has to know less about my system - it's more transparent, easier to keep a mental model of what's going on.
No comments:
Post a Comment