The future of design tools
getmotion.io
getmotion.io
No-code tools for apps & websites:
- Webflow
- Glide
- SquareSpace
- Dreamweaver [1]
- Visly
- Hadron
- Modulz [2]
- Interplay [3]
- Haiku [4]
- Zeplin
- Zeroheight [5]
- InVision DSM [5]
--
[2] Modulz' product doesn't exist yet, but they've built hype. Caveat emptor.
[3] Just like Modulz, but from what I've seen there's more execution and less hype.
[4] My company: we pivoted our original "designer/developer connector" into an animation tool — we're launching our new collaboration tool soon.
[5] Sort-of; designer-focus
"Lazy work" does not mean "lazy person." And "joke" would be better stated as "this article reads suspiciously as astroturfing."
But I see how the blunt call-out of lazy work and tip-toeing around the astroturfing vibes—i.e. the way I worded my comment—could read as a personal attack, and I agree that's not a productive way to approach discourse.
I missed the edit window, but I would amend the first line: s/author/article and s/a joke/intentionally misleading.
Per Hanlon's razor, my first hypothesis is the former but we shouldn't rule out the latter. Proactively question good faith but don't proactively doubt it.
Calling out the article as misleading mitigates the damage it causes and thus exactly "contributes to understanding the topic."
For the better part of...15 years? I've been using various inspectors and dev tools. Like a chump.
There is also counter-examples: KiCad is an EDA tool which is very, very close to the commercial ones.
But it's a great point, we could look at the counter-examples - good Open Source tools not aimed at developers - to maybe find out why they exist and how to do it.
Browsers come to mind, Android in some regards. But hopefully we can find something else than ad-delivery infrastructure.
GIMP? Inkscape? Blender? Libre Office? Firefox?? Chrome??
I'm actually not sure what you're suggesting. There are no great open source projects outside those written for development? That's clearly false.
Libre Office is simply copying features from MS Office, and is rarely used in commercial settings anyway.
Chrome is open source (well, Chromium, Chrome is not), but it is basically 100% developed by a commercial company which does not generally accept community contributions.
I don't know enough about GIMP, Inkscape and Blender to give an opinion on how well they can be held up as examples of Open Source community tools that can replace commercial tools.
Edit: actually, thinking more about this, Firefox and other browsers are much more a tool for web development than a tool for users directly - the functionality that users use is much smaller in terms of implementation than the functionality that web developers use (the layout and JS engines, and the debuggers, profilers & other development .
Both of which are known to have notoriously unintuitive UI's, especially when compared to their commercial competitors.
> Libre Office
Literally just copy & paste M$ Office UI, and honestly still manages to screw that up putting things in different places.
This changed lately for both products.
GIMP, Inkscape, and LibreOffice aren’t competitive with their commercial alternatives.
Which leaves Blender, which is the exception of a high quality open source tool that’s not for developers. I’ve spent a lot of time thinking about this, and I think they’re two reasons it exists: 1. The comparable commercial tools are very expensive, e.g., thousands of dollars per year, versus a bit over a hundred a year for something like Photoshop. 2. Developers have a particular affinity to 3D modeling, e.g., it’s the biggest gatekeeper to various types of development like games programming and AR/VR.
But I agree 100% that Blender is a fascinating exception, and I’d love to hear more theories about what’s made it so successful.
This was specially the case when blender was new and AFAIK command line driven. In those days a SGI machine alone was more expensive then the car of the average Blender user.
and perhaps not coincidentally, GIMP is infurating trash from a UX perspective.
That's usually the driver of quality, even if pure software engineers could easily find stuff to criticise.
I think you're right & the open-source issue could be because closer coordination is needed between product & engineering.
And while I'm biased [1] (as the founder of MintData), I think the future is instead:
- The line between Engineer & Designer gets BLURRED -> 0
- The line between Prototype & Software gets BLURRED -> 0
In the end, I think powerful tools that redefine how software is created will win out, but this will take some time*
Hat tip to LightTable, Subform, Figma/Sketch, Framer/X, Visual Basic 6, and all the other tools that have provided us with the right inspiration.
Think about integrating a Design System, a developer framework (React, Vue,) creating simulations/prototyping directly with the artboards (like click this button and see it navigate to this other screen).
On top of all that there's cloud access and management for all these designs, and collaborative editing.
All I'm saying is that the big players aren't just trying to build a piece of boxed software. They're going for platforms and a connected suite of services. It's hard to have all that as open source.
High fidelity collaboration between product, eng, design, and all other stakeholders is EXACTLY what's missing from today's tooling.
Figma has great multiplayer support, and we've worked hard to add it to MintData as well (bias[1]: founder here), and I think this is just the start.
In general, we need better integration of this tooling with CI/CD systems and the human workflows that naturally occur today in any org of > 50 people in technical roles.
Plus, designers aren't exactly positioned to just go make their own OSS design tool the same way developers are.
But it is true, outside of developers, nobody cares at all about Open Source and you mostly get weird looks if you try to explain. We are probably still bad at explaining it.
Oh also remember Dreamweaver :)
What I always find interesting about these pieces, is they always seem to be saying “they’re old now and need to be replaced” rather than marveling at the durability of original approach, which has been astounding. Same can be said for plain text, Unix shell tools, spreadsheets, NLE editors, the DAW. These should be celebrated for how successful their designs have been, instead of lamenting how many “old tools” we're using.
For me, the last "killer" Photoshop feature was layers. That was in 1994. I still use it every day, but only because I have almost 30 years of muscle memory. It's getting slower and slower for every release.
Granted, it inherited a bunch of nifty web-savvy features from Adobe ImageReady in the first half of the 2000s, but the whole sh*tshow that went down when ImageReady was killed was internal politics and a sign of crappy things to come.
It's interesting that the same navel-gazing, customer-ignoring attitude that killed QuarkXPress in favour of Adobe InDesign struck Adobe.
(By "killer", I mean a feature that completely changed the way I could work with graphics. Sure, I've saved a bunch of time with Actions, but the feature was not transformative.)
I've used Sketch, Illustrator, and Photoshop pretty heavily in my career.
Your statement is a bit like saying that a motorbike is just a bicycle with a few specialized features for people who want to go fast.
The way component libraries, CSS outputs and Craft plugins work with Sketch make it a totally different workflow to Illustrator, even if the basic features are the same (draw vectors).
People were touting it like the new hot shit, when it came out, but from a developer point of view it still felt like building with legos.
But yeah, if you say "everything was Photoshop" than Sketch and Figma are orders of magnitude better, haha.
The output of web design is, ultimately, HTML and CSS, so what reason could a professional have to work with tools that can only yield an approximation of what they are paid to do? In my view, a designer without full mastery of at least HTML and CSS doesn't really deserve his title.
Going a little farther: with some knowledge of JavaScript, JSON and how to transform it (map, reduce, filter, sort), a designer can ask for some sample data and come up with a functioning prototype that offers truly important insights into the problems his design is supposed to solve. Client-side frameworks like Svelte.js are making all this very easy.
Nothing is more maddening, and a waste of time and money, than a Photoshop mockup using rudimentary, and generally too self-complacent, content.
Design is a different skill set than writing code. For some highly visual/spacial people, design is easy and intuitive, and managing lines of text is very unwieldy. Be like, 1% empathetic dude.
Anyway, if designers wrote the code you'd be out of a job. Design should be a continual conversation between someone with the vision and someone with the skills to implement it.
The reality is that they are very different disciplines, and the ability to integrate those competencies can be a competitive advantage for a company.
The output of web design is ultimately a rendered, interactive webpage. We approve or reject websites by viewing them in a browser, not by looking at their code.
> a designer without full mastery of at least HTML and CSS doesn't really deserve his title.
Add to this the fact that the vast majority of web developers are very far from having a "mastery" of HTML and CSS. It's a huge API full of hacks and pitfalls.
Teach rudimentary HTML and CSS to a designer and they'll begin to think in that rudimentary interface, forgetting a competent developer with their far greater arsenal of tricks and tools can actually implement any UI they could imagine.
Your argument could apply to a field where the path from idea to end product is more straightforward. For instance, a comic book writer is expected to master the full pipeline from idea to colored page. A Disney concept artist on the other hand, is absolutely not required to know anything about 3d modeling. Web design mostly falls into that later category, we don't want our designers' creativity burdened by our medium's tedium.
Software development now has long established practices to develop and deliver incrementally. Where it is understood that you are delivering value piecemally.
With the disconnect present between design and development, I think design is still lacking in working out how to approach problems incrementally. All too often, you are handed down a design to deliver in one go, when you can't reasonably do that.
Perhaps it's my lack of familiarity with the field, but that's my perception. (To be clear, majority of software devs still struggle with it too, but core principles have been known and applied for 20 years).
Do any of the tools mentioned (or not) specifically focus on that aspect of coordination?
The design function (designers, product) can make changes widely, or isolate them to specific components, and test these changes at each step rather than the "all in one go" we're used to.
However, the article about DSL at AirBnB does not address my concern fully — how does one go from an existing component to a new component, design-wise, is my question? They seem to be mostly concerned with the consistency of the end result, especially in a large and diverse team. I wonder about the consistency of the interim results (which frequently end up being the end result).
For now, those interim steps are usually left to the software developer to decide on, meaning that until the full "migration" is considered complete, the component will be somewhere in between. And as projects are descoped and priorities change, it is a very real risk that components will be in that half-baked state forever.
I know that I have gone through the exercise a number of times, always leaving designers unhappy, because I implemented only parts of what they designed before I was pulled onto another project. And while I try to be cognizant of the design issues, I neither have the time, knowledge nor experience to do a good job of it.
If design instead provided incremental steps that are not necessarily half-baked, but just steps in the right direction, I think it would improve results developers put out, and at the time of "descoping", the component would still be consistent and usable.
It sounds like an entirely different axis to what the tools are providing today — we've gone from bitmap mockups, over vector mockups and state transitions, to interactive and explorable mockups and component libraries, but we are missing that "road" from "now" to "there" (a timeline of mockups with all the phases). I know designers can choose to do this "timeline" together with developers "manually", but it seems like a great thing for a tool to help with.
As a developer, I like being given a "feature" to work on, and I prefer not to break it up before hand — I start on something small that should bring some value and that will give me an idea of what step should come next. Basically, I know how I can develop an interim result that is of as high quality as the end result would have been: it just achieves different or fewer things.
I would expect a tool that has "current state" as the start, and maybe "end state" as the end (though in software engineering, we found out that the expected end state is never the end state), and it would allow a developer and designer to effectively work together to design the first step in a coherent manner that will take them both to the end state. "Coherent" is important here so it's not just a step towards the end state (which is what developers usually resort to, which are commonly artificial improvements which might not be improvements at all).
It can’t replace all of our traditional UI. However, with more A.I. requiring less inputs, there may be a future where data, not UI sets apart services.
Wasn't it possible to set up Firebug to do this, before it died and was replaced with the built-in tools? (Or am I thinking of a pre-quantum add-on to the current tools?)
[0]https://developers.google.com/web/tools/chrome-devtools/work...
I need 5 different chat apps on my phone in order to talk to all my friends and colleagues. And that doesn’t even include many of the ones I’ve read about online which are apparently popular elsewhere, like WhatsApp, WeChat, and Telegram. Standardization is great, but the set of tools we end up using is an accidental emergent property.
https://www.invisionapp.com/inside-design/macaw-team-joins-i...
[0]: https://developers.google.com/web/tools/chrome-devtools/work...
https://developers.google.com/web/tools/chrome-devtools/work...
Do you mean to say Framer and not Framer X? Because both are totally different. Framer was mostly geared towards prototyping while Framer X is for creating shared design systems (apart from prototyping ofcourse).
https://github.com/linpengcheng/PurefunctionPipelineDataflow