I spent 5 years in the 90s creating a WYSIWYG tool with Visual Basic 6 , and VB6 was a life saver.
I think retool is a fantastic, modern-day re-incarnation of that.
However, I think when the UX is important -- that is, a rich, pixel-perfect design combined with robust facilities to define custom app logic, a principles-first approach has to be taken.
We've taken one stab at this, to say that logic should be defined in a spreadsheet specifically tailored for the app-building purpose, and I think only time will tell if this approach is right. [1]
100% Agreed! Defining logic in JS is quite clunky for these sorts of tools.
I'm biased[1], but for this reason we took the approach of creating a spreadsheet from scratch for the sole purpose of creating logic for apps (both internal tools & customer facing UX).
Would be curious to get the everyone's input on our spreadsheet-driven approach -- thoughts?
It's also in somewhat bad taste to appear to be making a positive contribution to the discussion of someone else's work while actually promoting your own, and you've done that twice in this thread.
(I hesitated to say something about this because Retool is a YC co and we moderate less in such cases (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...) but this principle is the same everywhere and I've made similar comments in many non-YC-related threads.)
To op, for tools like Figma, what do you think the future holds? In what dimension will they evolve? How can they help you be more effective? Will they help you express your ideas in ever higher fidelity over time? [1]
[1] Biased questions, but genuinely curious about the op's answers given his deep expertise in the field (as the founder of https://mintdata.com)
Great question. Figma is leaps and bounds closer to giving designers tools that work like code, but it still has a long way to go. My wish list design tool is something that has the creative flexibility of design canvas, but the power of clean, performant code. Truthfully I think it'll require evolution both in the design tools space, but also the HTML and CSS specs.
For instance, in Figma we've only had a reliable way of adding something simple like button padding (where you can create a reusable button that will expand as you type a longer label) for a year. There have been plugins that did it before that, but they weren't reliable. This is crazy when you consider you've had the ability to add padding to a box in CSS for decades. At the same time, try doing a complex layout in HTML/CSS, which requires you to learn about flexbox, floats, position, and/or CSS grid. Compare that to the ability to just draw a box, move, scale, and rotate it in a design tool.
So I see design tools and browser tools converging over time to allow designers, engineers, even product managers a layer of abstraction over interfaces that feels much more intuitive, with less duplication. Right now, I have components in Figma that mirror components we use in React, though this is usually manual effort which is also a bit crazy. I don't really count WYSIWYG editors as having figured this out yet, since they produce garbage code in my experience.
Good questions. For future versions of this I may try to get guests to answer more questions about challenges in their profession to spark interesting ideas for entrepreneurs trying to build solutions.
You can imagine a version of the world where designers structure their designs in a way that can easily export to e.g. a vue component, and along with the base structural layout they define different UI states it can be in, with animation timelines. Designers should be able to specify every aesthetic variable, and developers just program the business logic to fill content tags and toggle designer-defined states.
I agree that it's trainable, but to create a good icon a first timer can spend several hours. Several hours in which they could be doing work that they have trained for.
If one intents to be a sole developer then yes, they have to improve in all fields, but when one is in a team one has to let some things go, and let people better than them on that field do them.
Design isn't about drawing pictograms, so nice strawman. The type of design thinking implied in the comment is more about knowing –or at least have the faintest idea about what a visually cohesive system is and could look like. There's no such thing as a "sole developer" in software development because your code is inherently tied to function and that function tied to its design. The more you value that concept the more you "train" your understanding of modern graphic design.
We [1] used to think the same thing a few years back, but then figured out empirically that virtualization (above the React layer) will let you view/scroll through virtually unlimited-size datasets (until you hit the browser's memory limit per tab).
So, at this point, I would say canvas is not required to render large grids in modern browsers (even though Google Sheets does this for likely legacy reasons)
That’s very interesting, but to be perfectly honest it’s almost the exact opposite of how I’d tend to think of things whilst building or manipulating a model. I don’t want to offend anyone, but it feels baroque, like something bolted-on, and it kind of breaks the whole “spreadsheet extruded into arbitrary dimensions” (cube) metaphor.
(Such as how in the accursed Excel, at least up to the last version I was blighted with having to use, one couldn’t take a cell of a Pivot table as the input to another formula elsewhere.)
Just watched the video. I think it is a different approach. The spreadsheets in the video seem row-oriented. It goes more in the direction of a relational database. CubeWeaver is multidimensional, so you don't need a group by function. You can group by a dimension just by creating a new worksheet with less dimensions and copying the data from the original worksheet using a formula. You can also group by an attribute using the JOIN function.
It lets you define your dashboard logic in a spreadsheet & then drag/drop the dashboard UI and publish it for end-user consumption.