Every proposal like this seems to assume that the web is basically the same as paper, and therefore should have tools that work like print tools. And this may be true for many marketing sites, which are effectively posters with download buttons. This is probably the kind of thing the author has in mind, because his wishlist doesn't include anything to do with interactivity, video, sound, etc.
But these are the best parts of the web! As much as designers want to believe it, a web app isn't actually a series of pictures. There are far more possibilities than with paper, and you remove all of those possibilities when you insist on designing like it's paper.
This is by far the biggest problem, web design with a print mindset.
A designer needs to understand and work with their medium and as long as they keep trying to represent the web (where their designs will be shrunk, enlarged, reflowed, include a time dimension and at any point entire elements can appear and disappear as a result of interactions) as a bunch of static 2D pictures they're working against their medium and are basically out of date. This was kind of understandable in the 90s when the concept of designing for the www was becoming mainstream. Around that time I was expecting it to take 5-10 years for the old generation of designers to fade out and for new people to arrive who would be trained and understand that print design isn't web design. I underestimated the problem, because that didn't happen.
It's now 2018 and I still regularly see job ads asking for developers who will create "pixel perfect PSD to HTML conversions". This is so wrong-headed.
I enjoyed the article, I remember rubbing sheets of Letraset transfer and literally cutting and pasting with a scalpel and Pritt Stick. The author is obviously clever and understanding of the current problems in web design. But I can't help thinking the main question the article asks is similar to "why is there still no point and click software with which I can write a high-quality novel?" or "why can't my beautiful rendering of a car be output as a working vehicle"
> It's now 2018 and I still regularly see job ads asking for developers who will create "pixel perfect PSD to HTML conversions". This is so wrong-headed.
I'm not sure if we've actually moved away from this or are moving more toward it. It used to be somewhat expected that a site should be functional without css (by putting the core content at the top), javascript and images but no one designs for that anymore. Half the buttons on the modern web are meaningless without a font served from a CDN.
And now we're moving toward a web built on canvas + web assembly, our user agents will have less control than ever. Maybe we can even cut out the middle men and render the psd directly.
> And now we're moving toward a web built on canvas + web assembly, our user agents will have less control than ever. Maybe we can even cut out the middle men and render the psd directly.
I know you're making a bit of a slight, but I won't kid you that publishers—frustrated by the fact that certain interactive features and desired visual structures require an understanding of the platform and code (even if they just have to hire people who -do-)—have started some move back to using print-version PDF's served to applications like Texture (recently purchased by Apple). Even with any compression or download-size problems that might come along with it. The art teams and editors are all very happy to keep doing the same process they've been doing for ~25 years, after having another technological progression dangling in front of them. If they could just take the PSD, stick it in a black-box folder and have it come out in their publication on every platform they output to... I think they might dance in the streets. Or start drinking earlier.
Am a programmer who has worked with first-hand with such publications. And now doesn't.
I applaud you for being a designer who actually codes. I feel that a true designer in the modern web must have a strong grasp of interaction design and how to build those experiences, and the consequences of various design choices, and to me that must mean that they can speak those ideas in code.
I am sick and tired of designers who are mostly glorified pixel pushers that throw together something pretty, but give no thought to edge cases or application states that force their designs into becoming ugly or having a poor interaction, or just becoming downright unusable, all because they rely on shallow and antiquated schools of thought that were born out of the paper and magazine media industries. Pretty, but rigid designs.
> I am sick and tired of designers who are mostly glorified pixel pushers that throw together something pretty, but give no thought to edge cases or application states that force their designs into becoming ugly or having a poor interaction, or just becoming downright unusable, all because they rely on shallow and antiquated schools of thought that were born out of the paper and magazine media industries. Pretty, but rigid designs.
I love working with designers who know they have no idea how to code, admit to having no idea how to code, but persistently work with the developers to ensure a smooth hand off of designed assets. Everyone's job is easier when they attempt to understand the other team member's job and tasks as well. I don't expect everyone to understand how to code but I don't think anybody likes working with someone who makes their job harder.
I agree with your latter statement - I've worked with a few teams now, and the best output always comes from teams that have designers with good foundation knowledge (i.e., of the psychology of design, alignment, balance, colour, gestalt, typography, white space etc - they could be highly effective print designers as well), who work closely with developers with deep understanding of the medium, where both sides are reluctant to compromise, but understand where they need to.
For the former though, I actually wish more designers had better knowledge of the "shallow and antiquated schools of thought" from the print world. A lot of that was born out of decades of iteration, and many of the toys that the web gives us aren't actually very useful for the kinds of content that many of them are tasked with publishing.
While I agree with you, from my experience, it seems like something that is more often normal to have knowledge of for older designers but seems like more of a passion for young designers to fully grasp as they may have to go out of their way to acquire such skills. I've found great people to work with of all ages but if they don't have coding skills and understand the evolution of graphics into interfaces or web assets than it becomes more and more difficult to continue working together on tight projects.
Unfortunately I rarely come across designers like this. It seems many designers prefer to be more like “concept artists for apps or interfaces” and leave gritty implementation details for the developer to figure out, rather than be actual designers who can think within development constraints, and consider all edge cases and state changes over time.
> Unfortunately I rarely come across designers like this.
Perhaps that's because "designer" is just a label that anybody can use, as opposed to e.g. an "MSc industrial design" which is someone with proper education.
I understand your sentiment but I will respectfully and strongly push back on the idea that if you don't code you're just pushing pixels.
You're ignoring the other aspects of design; research, testing, etc. Just because I don't code doesn't mean I don't understand the ramification of what I put down on 'paper'
I have coded in the past but I chose to let that skill drop as it takes practice and time.
By example, here's an overview of my methodologies. In fact, I call out how I can save coding time by iterating ahead of the dev.
I've worked with some talented designers in the past, and this rings true every time. They are often seen as great designers because they don't compromise, and the result of that is a happy designer, a not-so-happy client, and an unhappy development team. It's been almost shocking at times how little some of them have known about basic web standards, and how leading design teams have been built by people that would consider things like mobile-first to be "a fad".
I am also designer who codes, and like the author was classically trained but switched to digital medium. You are hundred percent right, designers who cannot comprehend UX part of the medium will never be able to deliver interactive experiences, they always will see web design like it was in early 2000, visual first. But there are small portion of us that uses design language for functional purpose, we care for UX first. The visual part of designing a layout is moving away from focus, its more important to make original illustration, compelling video or audio. PS> The funny part is that those print layouts are broken in current web with 80 percent mobile web consumption:)
A friend of mine agrees with your position and has built a business out of crossing this great divide between print and the web and actually I think his toolset is exactly the kind of 'DevTool for Designers' that this article is calling for .. so I'd be quite intrigued what other designers think of it.
(I'm just a friend of the founder of h5mag, and would love to know what isn't DevTools'y about h5mag, from a developers perspective. Disclaimer: I'm a developer...)
> having the code update itself intelligently and automatically.
That's why what the author wants is impossible. Everybody tried to make the perfect design Tool for web content starting back from Frontpage, it just never worked, not even once.
There's so much invisible pieces in web which are not related to the design. Does the markup makes sense? How does the design integrate with the features (web isn't static print at all). How does the code renders on non-standard screen sizes? Is the code generated maintainable and readable for future use? Is there a right balance between design and loading time?
The core issue is that if you would provide all the features in a software that the code provides, it would be more complicated than learning coding itself. That's also why nothing replaced a text-editor to code after all these years. If you would invent something to replace it, it would be more complicated than directly learning to code.
FrontPage and other early content management systems were never trying to make the perfect design tool. They were trying to make web authoring as easy as Word. And in that, they did work. (My first startup was doing content tools in those days, and we did very well up until the dotcom crash.)
The problem is that it is difficult to serve both purposes - ease for content authors isn't the same UX as ease for designers. And the effort to write good underlying code no matter what insanity the users do is a hard problem. I don't feel that it is an impossible task... just a hard one, and there isn't enough business need for such a tool that anyone has made a go of it.
> That's also why nothing replaced a text-editor to code after all these years.
Have you ever used anything like Flash Designer? Because that was better than using a text editor for making flash programs. There are plenty of design tools in existence. It's just that the web ones never caught on in mass.
The core issue is that if you would provide all the features in a software that the code provides, it would be more complicated than learning coding itself.
After using a lot of different dev tools, I disagree. There are orders of magnitude easier environments than others.
This has been done before, and it's time for it to happen again.
Hailing from 1995, Flash (nee Future Splash) was a dev tool for designers. Design, animate, optionally code, then ship to production on any device. For that connection between design and code [and the imaginativeness, the creative empowerment!] there's still a big ol' Flash-shaped hole in the world. [1]
More recently, in the game industry, Unity brought together design and code in a compelling way — by integrating existing tools. E.g. do your 3D modeling in Maya, do your coding in Visual Studio; find a common workflow to design and code together for any platform through Unity. This has worked well enough for Unity to capture > 50% market share in the game industry over the course of the last ~decade.
The key to this problem is a workflow-unifying tool that
1.) enables designers and developers to create software together through comfortable + familiar tools
2.) ships that software to every device
Like Unity. Like Flash. It's been done before.
[1] I'm passionate enough about this subject that I've dedicated my career to it. I'm on the Haiku team (YC W18) and we've taken a lot of inspiration from Flash, Unity, and modern software practices to build a cross-platform solution that allows designers and developers to create software together. https://www.haiku.ai/
Flash also came with the first truly interactive sites no the web (where it has been surpassed by HTML5) and with a ton of games (where it hasn't been surpassed).
People may ignore it cause it's not "serious", but gaming in all its forms is a huge chunk of computing and it's only going to get bigger.
Smartphones are taking over the roles previously held by consoles and before them by PCs, as the foremost gaming platform. And that was something that blindsided people at first, because everybody focuses on the "serious" use cases.
Your quip here ignores the original conversation, which is about "dev tools for designers." You also conflate the "bygone days" of slower connections with the "bygone days" of monolithic rich media binaries/downloads.
Average web page size has increased dramatically over the last decade [1][2], suggesting "massive sites" are more of a today-problem than a bygone one.
I understand "Flash" was the trigger-word here, and it is for a lot of people. "Flash Player" the consumer experience was fundamentally different from "Flash," the creation environment. Flash the "dev tool for designers" was the baby thrown out with the bath water.
Bloated websites are still a problem and life is a matter of perspective. For those in crummy parts of the world including some backwaters in the US I'm sure bloated sites are especially annoying.
During flashes heyday though virtually everyone was effected. Almost everyone had a slow connection and we pushed slow flashy crap out anyway. Who were we designing experiences for?
Thanks! More platforms are coming soon; we started with a single platform (Mac) so we could launch and iterate.
Our animation engine IS a UI engine, and we decided to ship an "interactive animation builder" as its own thing. If you can make any pixel render any value at any time, you can express any UI. Component composition, layouts, form controls, and more are coming soon.
A note to all designers reading this thread: HTML + CSS is the best design tool you could learn.
Don't think of it as code, or engineering. Get over the mental block. It's not more complicated than learning Photoshop or Illustrator. It's just a different interface. One that gives you total control. Where you can build things that actually work, and aren't just static representations. If you do web design, learn to work with the final medium. Otherwise, what are you really doing?
+1. HTML and CSS are not programming languages, so it’s not programming, it’s design. As a designer shouldn’t you know this powerful design tool? The web browser itself can be your canvas.
> Where you can build things that actually work, and aren't just static representations.
Designers can do that in PowerPoint for presentations or mockups.
There is also Adobe Edge for the web and theme designers like Divi in Wordpress.
> HTML + CSS is the best design tool you could learn.
The problem for designers is that you're asking them to mentally translate from a medium they're good at (visual) to a textual medium. But we've had GUI tools for making visual stuff for several decades now.
The web is behind on this front, even though companies have tried to make things like Dreamweaver, Flash Designer, Frontpage and Edge. With gaming, you have Unity. A lot of desktop software has layout managers and visual tooling.
It's kind of silly to expect designers to want to work with a textual format in 2018. Smalltalk came out in the 70s.
I’ve thought about this a bit. About why some people like “tools” over “languages.” So some people are fine to spend 100 hours leaning the Photoshop interface, but not 100 hours learning css and html in basic form.
I used to think some people are just dummies. But it really comes down to some people preferring workflow with little abstraction between action, mental model, outcome.
So even though “highlight text, click bold, see bold” and “type <b> and </b> around text, save, refresh browser, see bold” are really similar; the gap with switching tools and having to mentally model what will happen is more compatible with some people’s preference than others.
Honestly, Mozilla could just shove a DreamWeaver clone into Firefox and make a lot of designers and developers happy.
The challenges for developing software that would let someone who doesn't know HTML/CSS produce HTML/CSS seem high. In the "drag and drop interface" did that drag mean that the column should be 60px smaller? 10% smaller? 1.21rem smaller? Should the font get smaller when a username is longer than 15 characters, should the column get bigger, or should it overflow to the next line? Is there custom menu interactivity at different breakpoints, or can I just let Bootstrap do its magic?
That said, Sketch or Figma plus an exporter gets wonderfully close to what the author is talking about. And as a developer, I appreciate being handed imperfect HTML and CSS over being handed a picture of a website. At least with the former, I can copy and paste into the appropriate location, or throw out that which my judgement decides is counterproductive or unnecessary.
So I don't believe that this DesignTools utility needs to be perfect from the get-go, or address most/all of the edge cases that will come up during development. It just needs to decrease the cognitive workload that developers take on during the "PSD >> application/website" process.
Recent example I've come across. Wordpress used for a non-blog site. Sure it looks fine, but I can't deploy that to something that doesn't have PHP, which is more often the case these days.
> "We deliver all of your static content (html, js, images, etc.) over a secure SSL connection and serve it on a CDN. Firebase Hosting is for hosting static assets. Firebase currently doesn't offer any way to execute your code on Firebase's servers."
Is there something like a wordpress front end for authoring and managing content that then generates all the static content for you to deploy?
In the olden days, blogger.com used to have this feature so you could self host. They ditched this in I think 2009 so google could get deeper data on all those blogs users.
I entirely expect so. With the advent of single page site frameworks, it is pretty trivial. This is exactly what firebase targets. The backend stores structured data, and the static assets delivered as frontend code then organise the presentation. Well, strictly firebase was originally intended for mobile apps, which already work that way. But with frontend heavy frameworks, this process is easier to replicate than ever.
Can production-level, front-end developers get some cool design devtools too?
I've never been able to play around with Sketch because it's Mac only. Every browser-based, UI design tool that I've ever played with has been so klunky, or non-intuitive that I just gave up after a couple minutes.
I'd love to have a nice prototyping tool using Bootstrap 4 or Material that has round-tripping like the old-school IDEs used to have.
Figma is web-based, surprisingly high performance (it's written in C++ I believe, and compiled to web assembly), and is roughly on-par with Sketch feature-wise. The ecosystem isn't as rich, and it probably falls short in some areas whilst being better than offers.
The problem is that our design tools are not good enough. Sketch combined with a handoff tool like Zeplin is lightyears ahead of Photoshop for web and app design, but fundamentally, at heart, it's a draw program. You make a page, draw a bunch of boxes and call it a website.
It's not. It's a page layout. But websites and apps aren't pages, they're dynamic systems built from interactive components with multiple states and screen sizes.
All visual web builders do is replicate traditional drawing tools, but output to HTML/CSS rather than Postscript or bitmaps. This is not enough, except for the most basic of brochure sites.
There's still a massive gap between designs and working code. Some things that are easy to do in Sketch are tough in code and vice versa - it's too easy to do things that become problems later. And because it's static images, it's not easy to show live data or interactions.
Prototyping tools like Framer and Flinto can help here, but again, it's never a true representation of what can actually be done in code.
For both layout and interaction, the developer has to recreate something that's already been created - it's an inefficient process, and one that go wrong unless the design team thoroughly understands the systems they're designing for and can know the consequences of their design decisions.
I've seen it happen many times where developers struggle to implement something that the designer did quickly without really thinking about. Not the designer's fault - just falling down the gap between design tools and medium. And not enough collaboration between the teams.
There is some really cool stuff on the horizon however. React, and the move towards component-based design and development is making this possible. But it's early days.
Supernova Studio [0] is an interesting start, along with Alva [1] and AirBnb's Lona[2].
I haven't considered myself a front-end developer in quite some time (at least 7-8 years), but it used to be what I'd put on my business card. Since then I've focused almost entirely on PM and Design. I have a decent front-end background, but I'm by no means pushing production code.
I recently decided to give Webflow a try after a good friend, who does happen to be a front-end dev (and quite good), told me how cool he thought it was.
He wasn't wrong. Yes, you have to pay to really do anything with your creation, but I think it might be worth it (if you're a designer who doesn't want to learn to code). I was extremely impressed with how quickly I could export my assets and various measurements from Sketch and lay everything out in Webflow, especially when it was time to build the various breakpoints and add some animations.
What would have normally taken me a few days (over the course of a few sessions), instead took me 2-3 hours, tops.
More importantly I used flexbox for much of the page, which is something I hadn't touched before. I've of course read about it and have a basic understand of how it works, but I'd have spent A LOT of time getting that aspect of it right had I been coding from scratch.
The best part was, at least from what I could tell and based on their claims, all of this would have exported to clean code worthy of a production site. Pretty cool.
So, as the author mentions, Webflow is very interesting. It's just not exactly practical because of the way it's tied to their CMS and hosting platform. If you're only really building marketing sites for clients who need basic hosting anyway, it might be perfect for you, but outside of that I can't imagine where I'd use it. Certainly not on a product team, but it's still worth playing around with on the free plan.
The author seems to assume that all software developers unanimously decided that a visual web editing tool isn't going to happen and should not be worked on (even though he is entitled to it, for some reason).
There are plenty of very smart people laboring away to make this happen, but as it turns out, it's not that easy.
Visual builders seem like a somewhat controversial topic on HN, but I personally am a huge supporter of the idea. So much so that I invested a lot of time in building a visual builder for database software myself [1].
It's a tool that looks perfect for UX designers, who can use it to build fully functional CRUD apps without writing code.
For example starting with the standard CRM and invoicing apps and going to more complex apps for inventory management, product & project management - virtually any kind of database software can be built without writing code.
This tool (yours?) looks promising and I’ll try it.
I’m skeptical though as I lived through the 90s 4gl database software for PCs like Clarion, FoxPro, Access and others that promised the sane thing but required lots of coding for the final 10% needed to go live.
I agree, I come from a finance background, now designing erp / crm. I can code and I’m expert in SQL and Excel. I’m amazed how primitive software languages, still are and how terrible they are for GUI, all they seeem to offer is - if then else, case, loops, some pattern matching and recursion, they’re all the same - not much better than VB for 20 years ago. SQL is more advanced and powerful. Shame nothing like SQL for UI, HTML is declarative but too dumb and static no equivalent to AI query analyzer to auto layout screens based on constraints and designer inputs from a graphic tool. NO designers should NOT have to use text to design, especially not 3 different primitive languages, ridiculous arrogant way of thinking from coders, who would no doubt struggle to draw a smiley. Anyway rant over, your tool looks amazing from a cursory glance, what tech stack is built on? your website doesn’t say?? can forms / nodes easily connect to Postgres Functions? I use functions for all data IO. Is it easy to port to high performance server stack,from local machine prototype? I’m happy to pay licence fees, just for the tool though, I must have complete control over anything built by it. I have seen a similar python based tool, but it is hosted output only, so of no use to me.
A problem I and my friend are tackling from a different perspective - what happens to the Web, when it's already out there and a designer wants to introduce some new changes. This process is still in the stone age of internet - emails and screenshots are the rockstars here. As the title of this blog post says - we are also trying to come up with a "DevTools for designers" with https://finch.io - a web fine-tuning toolkit for live or development websites that tries to balance between a "designer tool" and a "devtool".
Lately I've been working with designers through Sketch + Zeplin and its been pretty great. I like being able to pull CSS and SVG/PNG assets out of the tool and it speeds up mockup to built site quite a bit.
What worries me about a tool that outputs html + css is then having to take that markup and integrate it with whatever client side framework or server side template engine so that its consistent with the rest of the code base, follows set code and style standards, is fully responsive and adheres to whatever arbitrary standards are set by the dev team.
I just don't have a lot of faith that a tool can be flexible enough to output markup that can then be used effectively. I imagine a developer will need to massage it into place in order to get it to conform well and by that point it might have just been easier for a competent web developer to build it from scratch. For prototyping or building out functional mock ups, it could be quite useful, but if the end goal is to hand a developer some markup and stylesheets and then let them build out the business logic, then things could get messy pretty quickly.
It's a good dream though and I hope that one day we can let designers do more of the view layer work but I'm cautiously optimistic.
My main issue from working with Zeplin is that it can't "explain" the layout, it can only give you dimensions in a specific static scenario. For example, a layout might be based on a grid system that can only be derived from looking holistically at every design artefact (including written words), because any individual layout gives an incomplete piece of the puzzle.
Ultimately I found that Zeplin doesn't replace the need to have conversations about most aspects of a design; and whilst it can provide value in some cases, that scope of that value tends to be vastly overstated. If you know that your design system uses a base unit of 8 pixels, you can eyeball most dimensions up to about 8 units, and guess pretty successfully above that.
Even when design tools can generate code, they don't generate the code you probably want. On the desktop side, there have been more aggressive attempts to allow for code ahead to co exist with the code behind (e.g. XAML), but even then if any kind of abstraction is involved, hand written code will win in the end. There has been more work in academia about round tripping between code, and direct manipulable output (e.g. see Ravi Chugh's work).
Anyways, I'm a strong believer that design and prototyping should be firewalled off from production. Even when the assets are transferrable, the iteration speed demanded by the design process means they'll necessarily lack the polish of production assets.
Developers will need to customize with code for (finger in the air) 20 more years. Eventually we’ll solve this with AI, but talk about a hard problem. It will eventually happen.
Until that point, we need tools that output real applications in ( to start with ) react that allow real time collaboration between design, engineering, qa, product, and project/execs/stakeholders.
If there were a tool that would generate perfectly acceptable code, we'd already be using it and coding on top of that. Whenever something is automated away, it's usually abstracted away as a module and manual work continues on a higher level.
I think I would like to see in web design tools some of the principles that people like Alan Kay and Bret Victor laid out over the years. I work in React and I often think that there is a big disconnect with my team and the designers. I do not believe that all web applications need a design tool but many do. I actually think that we should have a unified dev tool that allows us to write code and design interfaces like we 've been doing in Visual Studio for years now when we were developing Winforms.
Pagedraw looks interesting if you're into building components: https://www.youtube.com/watch?v=UhVXKJpwtVA (The video also makes sense to watch if you're a designer and want to get an idea about how React works, if you already know React, start at min. 15)
Pagedraw is a tool that converts Sketch or Figma files into the HTML and CSS of React render functions.
anyone played with framer’s design mode? It produces markup and style from a sketch-like interface that you make interactive with a JS interactivity API. It’s meant for prototyping, but you could make a fully functional app if you were crazy
The responsive design system is really intuitive as well, and is easier to reason about than regular css techniques.
The code markup that comes out is.. quite messy, but it made me realize the potential of design tooling that could completely take care of the work around html and css for an individual component (for me, they take at least 2x time compared to JS for some types of components)
It kinda goes against the rigor of producing lean code, and does away with expertise, but it’s definitey a version of the future: designers could output a bundle that was a packaged responsive UI component that exposed a JS API
There is an extremely powerful tool that developers have always had and designers sadly never had: functions.
Look at every website you've built. The frontend is made possible only by functions. You may call them React components, or Vue templates. You may even have your own view library. But they all boil down to the characteristics of simple functions:
As in, they are parametric, they compose, they recurse, and, most importantly in visual design, they do NOT match 1-1 with HTML nodes. Let me qualify:
Look at this simple <Button> component (defined in React for example):
The <Button> component does not match 1-1 with the number of HTML nodes it produces. That's how you build abstractions – it's why you can re-use this button in different situations without changing its source. And, you do the same thing for other reusable piece of your project. That's how you keep the complexity of your frontend manageable.
In visual design tools however, these abstractions aren't possible. What you get to work with are layers. Every 'thing' on the screen is made of a layer, sometimes more than one layer. Every 'thing' you want to put on the screen will make your hierarchy at least linearly more complex. That is the opposite of what programmers have, where they can create hundreds of 'things' with the ease of controlling just a few 'things'.
The most that visual design tools have done to manage this complexity so far, is a feature known as Symbols/Components as it's named in Sketch/Figma. It helps, but it doesn't give you anywhere near the power of functions. It's not parametric, it hardly composes, and it doesn't recurse. Also, you can't create the above <Button> component with it.
Now, why haven't design tools given us something as powerful as functions (or React/Vue components)? Because functions have complexities of their own, eg. type annotations, or runtime errors, just to name a few. Can you imagine having to fix runtime errors when you're in the zone playing with shapes and colors? I certainly can't.
This is all not to say that it's impossible to make such a powerful design tool. It is possible. It's just harder. You gotta rethink the whole thing from the ground up. But there are tons of low hanging fruits in this growing industry. You can take Sketch's UX and add animation/multiplayer/history to it. People want that. So it's easier to invest on those and get rapid adoption rather than invent something completely new and convince people to jump ships.
--
ps. We're building such a tool. We call it TheaterJS. No online demos yet, but we'll have a private beta soon. Hit me at aria@theaterjs.com if you want to know more :)
> In visual design tools however, these abstractions aren't possible.
I occasionally use MS expression blend. It’s a visual design tool, yet it’s quite good at working with styles, control templates, data templates.
These are XAML markup equivalents of functions. They don’t match 1-to-1 to visual elements, and you can compose them; even recursively if you want to, see e.g. HierarchicalDataTemplate.
HTML doesn’t have templates, but there’re third-party libraries implementing them on top.
IMO the main reason why people still code web design is legacy: until recently, clients were too slow, different browsers were less compatible, i.e. coding was the only viable option to ensure acceptable quality results.
I remember in React, we are able to do WYSIWYG visual design by using a library called sturctor. It was a pain to set structor up, however, and it has a limited state management facility.
Hi all, I'm the author of the article. Thanks very much for linking it here.
It's very easy to fall back on entrenched opinions and unhelpful developer-vs-designer stereotypes, and see any call for a visual tool to be one to remove or demote code from the process altogether. That is absolutely not what the article states or is about.
I'm adamantly against canned solutions that make things easier for designers but harder for developers; rather, I want something that merges the power of code-centric tools with the speed and approachability of visual tools.
Basically: Visual Studio Code + DevTools + Codepen + a browser rendering engine + the stuff we use Gulp / Grunt / Browsersync / Sass etc for on the command-line, but bundled into something useful for non-developers - with added GUI deliciousness that would obey good code rules.
Rather than just 'draw anywhere' and getting all that FrontPage-y style rule nightmare, it might be more 'define a grid, then draw a div into a grid cell, then either create or apply a class,' etc.
Interaction is definitely supposed to be part of this (something I did not go into depth with in the article) - defining states for sure, as well as animation.
One use context is creating a component library / pattern library that will be consumed by several different user types. For instance, Material.io or the Salesforce Lightning Design System, IBM's Carbon Design System, etc, intended for producing web applications.
Designers need a style guide, front-end developers or 'designer-devs' want to see live examples with code snippets, other kinds of developers might want to know about data sources and where the variables are used in a particular component.
A visual tool should make it very easy to both create and edit such components, and maybe add a bit of metadata like 'this component is recommended for use as the nav' and 'it has these dependencies' - so you can more easily export it into something like Clearleft's Fractal tool, etc. In the long run, such metadata might let an opinionated tool automatically snap things into place / recommended source order to guide beginners, but always modifiable by developers.
And similarly, being able to open a library of components, see a 'molecule' like a nav bar, then drill down to atomic components like ULs, buttons, see what the data placeholders are, etc - preferably also with some human-readable annotations.
(Obviously I am handwaving the complexity of actually doing something like this, but conceptually, it _ought_ to be doable.)
By its nature, I would want this kind of tool to promote understanding of CSS inheritance and modularity, so that it would lend itself to creating reusable symbol-objects, much as we are used to in Adobe apps and Sketch, and previsualize the changes to the cascade, or get warnings that "x other classes depend on this, are you sure?"
For instance, InDesign style palettes can roughly map onto text and object styles - your basic H1-H6, standard HTML styled elements. The missing part in Adobe is scoped/modified or additive styles, but that's just a conceptual step forward. In a code context, an "H1, but inside a product grid" style can decompose to BEM classes, and the app or tool should make this clear as we already do with Inspector computed views.
So just to clarify, what this really should do is help visual designers make the leap into becoming hybrid designer-developers (and vice versa) but if someone simply wants to use it to sketch things out freehand, regardless of end use or code quality, it should help them do that, albeit in an opinionated way under the covers.
As I allude to in the article, we don't ask visual designers to write raw PostScript. We depend on the tools we use to author it correctly when we draw boxes or type text into our documents; the Web has added robustness. I'm not that worried about it producing spaghetti code.
Any visual tool should produce at least well-structured, readable code; lean towards making sure it's standards-compliant / uses best practices; but also is flexible enough to let you author it in any way that is suitable for your needs, so you're not trapped in canned layouts or overly-prescriptive boundaries.
Great article I agree with everything you say. A few items I would add to your Wishlist.
Different graphical viewpoints, a Logical not strictly WYSIWYG, to see relations between components, easy to use calculations and functions. Excel like grid layout with constraints and auto layout for different screens, but better than Excel at dealing with text and graphics and blocks larger than cells ie mix Excel Word Powerpoint Photoshop ,constraint solver into a single app. Seamless PostgreSQL db interface, eg right click a cell or node and link to a PostgreSQL input or query function.
I don’t understand why languages are so orientated to primitive files when we have amazing and much more useful databases and as you allude to they have virtually zero GUI capability, even Apple‘s supposedly new language Swift just rehashes the same primitive abstractions, that basically just provide temp data containers, little functions and simple control of flow. With Little regard for more advanced abstractions such as relational database, let alone a GUI.
"In 2018, web browsers offer vast potential to interactive designers, as revolutionary as what PostScript and desktop publishing offered for print thirty years ago."
No they don't , almost half a century after the creation of the most influential software technology , Smalltalk. Development tools still largely ignore designers mainly because designers try to stay as far away from coders as possible and coders as far away they can from designers.
These are two cultures that are founded on polar opposite ideals and principles.
A browser, in particular, is from a designer perspective nothing more than an abomination and is laughable to compare web apps and web technologies with specialized designers tools like Photoshop, Illustrator, Blender, Zbrush, Maya, 3DS Max etc. with the ugliness of Javascript , CSS, HTML and XML and is no coincidence that those technologies have so tiny presence on the web. Even WebGL which supposed to bring design and designers to web browsers is pretty much an abandonware.
For now, we can only compromise with modern IDEs that are somewhat designer-friendly like Pharo, Delphi, Squeak etc. and maybe we designers wait for another half century until the so-called "IDEs" catch one and another century for web technologies to move to HTML12 which may or may not be at last designer-friendly.
Especially when we take into account the blazing fast evolution of designer tools (which drive also the hardware evolution mostly through games) and the glacial pace of the evolution of software development tools stuck to the curse of backward compatibility, those two worlds continue to move apart with an accelerating rate.
In the meantime, the gap (or more likely the abyss) between those two cultures will remain. Designers avoiding coding like the plague, coder being mesmerized by their "readable code" completely oblivious to what makes a design good, kneeling before the glory of the holey grail know also as "not reinventing the wheel" or "not fixing what is not broken".
It is sad that 30 years ago designers and coders were so close together as communities, the closest they ever been was during the 80s with the introduction of Amiga 500 which gave birth to some of the most popular design tools but those days are long past.
It's funny because I joined a "coders and designers" facebook group out of curiosity and after 2 years the only design related talk have been a mockery about designers and a couple of mention of design tools from the rare breed of game developers that tend of frequent the group. Can't say I am surprised.
But hey if coders want to continue to believe that coding is an art and that design is an essential part of software development, who am I to judge. I am also delusional at times. None is perfect.
>These are two cultures that are founded on polar opposite ideals and principles.
Designers have a bias in favor of form (brand identity), developers a bias in favor of function (usefulness, productivity). That's why you have those conflicts between devs and designers over the amount of whitespace and functionality within the viewport, and possible results that can be either based on feature overload and bad UX, or that miss crucial functionality.
A way to get both on the same page is information architecture that is informed by generative UX research and positioning. You come up with a content, data model and schema that informs representational and functional parts of your app. Basically a parent discipline for designers and coders within an organization, roles/teams that are made up of designers and coders. This helps to limit the functionality to what you really need, and gives the designers a frame of reference for their prototypes.
Currently, the only thing that designers have shown general interest for is visual coding languages. Unreal engine has Blueprints which probably the most advanced visual coding language out there and in both and 2d graphics visual coding workflows have taken, scripting may have not been so successful but visual coding is definetly something designers so a genuine interest from.Designers tool have become so immensely complex that basic GUI design which usual UX people are accustomed too is no longe enough to satisfy the complexity. Visual coding is here to stay in the designer world and most likely it will leak to the coding world too. For me its the only viable option that I am aware for bring both cultures together.
But these are the best parts of the web! As much as designers want to believe it, a web app isn't actually a series of pictures. There are far more possibilities than with paper, and you remove all of those possibilities when you insist on designing like it's paper.
Disclaimer: I am a designer who codes.