Comment by miiiiiike

> Another example that kept turning up was that the ticket "1 phone number for a customer is not enough, support 2 phone numbers" is inevitably followed by "2 phone numbers is not enough, support 3 phone numbers"

Zero. One. Infinity.

https://en.m.wikipedia.org/wiki/Zero_one_infinity_rule

YAGNI, handle a singular case, and once you have multiple treat it like a list.

Change management, designing schemas for being amenable to change management, having systems that can migrate data with an understanding of what historical context in which that data got into the system (was it imported from a source with a nuance that was fine before you changed the form, but now makes less sense with the updated meaning and positioning of the field?)... all of this is what makes software hard, whether low-code or high-code!

One of the ironic things, to bring it back to Figma, is that giving designers and stakeholders Figma in all its glory becomes a justification for having engineers on the project, because you can't realize those exciting design visions with just Airtable and the like. Those engineers aren't useful because they can write code; they're useful because they'll (hopefully!) think through those change management and schema design considerations, building something that will be maintainable in the future. It's a good thing to have a design tool that incentivizes a level of foresight before launching a product that's meant to be best-in-class.

>> an object going through a number of states with state transitions was general and much better than the 15+ date columns

It amazes me that anyone would write a schema with a dozen date columns, but I've seen such things. Once you're dealing with a large database of something like that, it's tempting to just add one more column rather than pitch why you should refactor the whole thing.

I try to keep my schemas relational as possible. Actions and immutable records should obviously be stored in separate tables from the objects they reference. However, this does make the UX form design / CRUD process less amenable to simple solutions where forms are just generated right out of a schema.

Your phone number example highlights this. In general of course you want to store contacts in a separate table from customers. But that means you're probably going to need a separate contacts sub-form within your customer form, rather than just inline phone fields. Then form will need to be required or inlined for any new customer before the main customer form can be saved. Stuff like that.

Over the last 15 years or so I've built and refined my own form generator, really a DSL for designing forms that fit this type of thing. In its more basic use cases, each form lives as a row in a database, with each form_item linked to it in a separate table. The form runs a pre-fab query that expects N inputs that it binds to :variables (usually in WHERE or HAVING clauses) and then renders a pre-populated visual form with various input types like dropdowns, checkboxes, calendars, etc (based on those form_items, which can all be styled, required/not required, required based on other answers, etc). Each form_item has its own standard validation or custom validation function on both the client and server side. The form knows which table it wants to write to and which bound variable is the id field it's going to target for update. Sending it a blank id field renders the form with nothing populated and then does an insert instead of an update when it's submitted. It's very slim, about 500 LOC of Typescript and 700 LOC of PHP, including most standard kinds of validations on both ends. I've always toyed with the idea of releasing it it for people to use, but here's the rub: If you want to do anything involving writing to more than one table, you need to write a custom final function for those additional insert/updates.

So, it's a lovely system, but someone coming to it naively would run the risk of designing schemas that were not expressive enough, to try to keep the CRUD system happy. And I think this is just an inevitable problem with all low-code solutions: They don't handle multi-dimensional data the way you want a clean schema to handle it. (And neither do users).

While code may no be the leanest human-readable representation, scripting languages are a quite deep local minimum. There is a difference between hiding complexity and blocking you off from complexity. Scripting languages work because when you encounter a problem your library / framework can't fix, there is at least a basic procedural Turing complete language to fall back on.

No, I meant requirements.

Stated otherwise: "Sufficiently advanced requirements are indistinguishable from code".

Abstracted requirements define outcomes. Fine-grained requirements define code.

What did you learn about Figma that changed how you think about your work?

I advocate for learning as much as possible as well. It comes naturally with being self-taught. That said I think it’s also worth zooming out and giving things a look through a critical eye to ensure that the things we’re learning are necessary and worthwhile.

There are still a number of “old school” UI designers out there who’ve resisted trends and have staunchly stuck to a more traditional workflow, where they start out with a rough mockup made in e.g. Photoshop and then iterate the design alongside an engineer. It would be interesting to be in the room amidst a discussion between one of these traditionalists and a “new age” Figma-type UI designer.

I used Fireworks a lot, and what amazed me at Sketch when I found it, is that they figured out every single thing that bothered me in Fireworks and did it right. At that period, Figma was mostly copying all the tiny clever innovations done by Sketch.

Figma on desktop is an Electron app I believe. Figma chose to build a custom webGL rendering engine for their design canvas, so the core issue is that technical decision early on (probably allowed for some better performance and multiplayer back then). Figma is stuck with wanting to control their rendering and allow for non-product stuff like Figjam or the new Draw tools, but it will inherently hold them back from providing a really good design/dev handoff and always will hold designers back because it doesn't use CSS web rendering.

Thanks, I can’t wait to showcase it on here. It’s frustrating because I can only work on it on nights and weekends, and my 15 month old daughter doesn’t make that any easier.

I’m incredibly pumped for it, though. It’s almost entirely keyboard driven, kinda like Vim. I’m building this rich set of mnemonic commands to build/design UI components. It’s like Vim + Storybook + WebFlow.

Don't create every possible picture. Create a representative set.

Draw each screen at least once. If you have dark mode, you don't have to fully redraw each screen in dark mode, just enough to show how dark mode should look. If it has to work on desktop, you probably do have a completely different desktop version of each screen (from the default mobile) so draw that - but don't redraw every detail of a widget that's identical to mobile.

Testing every combination should be for the testing stage. It's good if you can foresee clashes (like the desktop version of this widget looks bad on this page in dark mode) in the design stage but it's not really an excuse to prolong the design so long that it lasts until you would have been finished with testing anyway.

Having a computer generate all the combinations for you in the design stage isn't that great unless you can pay individual attention to them - there's no point producing artefacts that nobody looks at.