Design Thoughts on Decker

Decker is a Hypercard inspired took for making interactive utilitizes, art, and games. However, I think it fall shorts of that goal in a lot of places for me. One particular problem it has is constantly obfuscating the art for the code.

Let's walk through a few of Decker's work flows.

The Various Work Flows of Decker

A screenshot of decker with the tool bars out — Decker presents itself as a blank canvas upon which you can draw on.

A screenshot of decker with and draw on it — You can draw directly on cards. However, these drawing are not interactive, more set dressing. This is the first form of seperating art from logic in decker.

A screenshot of decker with and drawn on it with a button to the right. — In decker interactive elements are called Widgets. Later, I'll bring up Decker's prototypes. In this screenshot, I've added a button to the card. However, this card cannot be directly edit. There is no interaction with it aside from place it.

A screenshot of decker's widget drop down menu. — In order to edit a button you have to go to the widgets drop down menu, then to properties which will open a modal. This model lets you configure the name, text present, keyboard shortcut, and style of the button. Additionally you can script the button.

screenshot of decker's code editor. A button is visible, however it is only a outline of it with the code name for it. — However, the scripting view blocks the whole card. Turning on x-ray mode doesn't actually show the card, but outlines of the widgets. This means you can't actually see what it is your scripting just a high-level outline of it.

Screenshot of decker with the file menu open and the prototype option highlighted — This problem is compounded further by the nature of editing prototypes. To build a prototype, you need to navigate more menus, mess with a popup, then open the prototype editor. At this point you are now two degree seperated from the card.

Prototypes behave similiar to cards. You can draw it, add widgets, and script them. However, just like the card the code editor blocks the view of the prototype. So now you are three degrees removed from what you are working on.

I find this to be for to much indirection for crafting interactive experiences with. Even with more traditional IDEs, I can typically view my code in my text editor, my drawings in Krita, and my world in something like Godot's editor. With decker each mode is isolated by blocking the previous one.

The prototype modal for adding new contraptions. — This problem is compounded further by the nature of editing prototypes. To build a prototype, you need to navigate more menus, mess with a popup, then open the prototype editor. At this point you are now two degree seperated from the card.

Prototypes behave similiar to cards. You can draw it, add widgets, and script them. However, just like the card the code editor blocks the view of the prototype. So now you are three degrees removed from what you are working on.

I find this to be for to much indirection for crafting interactive experiences with. Even with more traditional IDEs, I can typically view my code in my text editor, my drawings in Krita, and my world in something like Godot's editor. With decker each mode is isolated by blocking the previous one.

The mindset of the developer vs Ideal of Decker

Decker's home page states the following:

Anyone can use Decker to create E-Zines, organize their notes, give presentations, build adventure games, or even just doodle some 1-bit pixel art. The holistic "ditherpunk" aesthetic is cozy, a bit nostalgic, and provides fun and distinctive creative constraints. As a prototyping tool, Decker encourages embracing a sketchy, imperfect approach.

However, this seems to be contradicted from my first impression. While attempting to use Decker for Dec(k) Month, I ran into a bug with the card field. I was very roughly sketching out ideas just messing about, and this issue ended my attempt at Dec(k) Month.

When I presented this issue to the developer, I was greated with a much unwelcomed lecture about softare design patterns:

As a general design note, I do not recommend directly exposing internal widgets of contraptions and banging on them from the outside; this is very brittle and makes it difficult to revise the design of the contraption or maintain internal constraints.

This mindset to me feels like it flies in the face of what a tool for "embracing a sketchy, imperfect approach". The result is that I have found myself unable to push past this design friction in Decker. It leaves me with a constant sense that Decker is not for me and never will be. That the way I want to sketch and be imperfect is not what Decker intends.

Changes

I'd personal make it so building prototypes provide a sort of live view into the current card. Additionally, I'd allow the visual presnetation of your cord to be visible while editing the script. In general, I would avoid blocking the users view of the card and what they are working on. I consider continous visual feedback of what's being developed vital to creative work.

Another change to Decker's approach is I'd remove as much of the modal popups, dialogues, drop downs, and menus needed to style and edit interactive elements. It makes Decker feel more like an intergrated development enviroment that a sketchpad. This is a similiar problem I have with Bitsy. The more menus I have to go through, the more "doorways" I have to pass through which means more context switching which means more risk to my flow state.