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"
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'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/
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.
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 [email protected] 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.
[+] [-] devins|8 years ago|reply
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.
[+] [-] firmgently|8 years ago|reply
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"
[+] [-] matte_black|8 years ago|reply
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.
[+] [-] EnderMB|8 years ago|reply
[+] [-] promeus|8 years ago|reply
[+] [-] digi_owl|8 years ago|reply
Hell the very article linked to irks me because of the persistent bars (so typical of Medium.com derived sites) that cramp the actual article area.
But even worse is sites like the new Reddit, that tries to behave more like a mobile app than a document.
[+] [-] primitur|8 years ago|reply
Shameless plug: http://h5mag.com/
(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...)
[+] [-] projectramo|8 years ago|reply
You need a language and a metaphor for those items too.
[+] [-] realusername|8 years ago|reply
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.
[+] [-] codingdave|8 years ago|reply
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.
[+] [-] goatlover|8 years ago|reply
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.
[+] [-] narag|8 years ago|reply
After using a lot of different dev tools, I disagree. There are orders of magnitude easier environments than others.
[+] [-] zackbrown|8 years ago|reply
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/
[+] [-] michaelmrose|8 years ago|reply
I do not long for bygone days.
[+] [-] davidjnelson|8 years ago|reply
[+] [-] faitswulff|8 years ago|reply
EDIT - took a look at Haiku, looks great!
[+] [-] pcmaffey|8 years ago|reply
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?
(..from a designer and engineer.)
[+] [-] mygo|8 years ago|reply
No ifs, &&’s, || but()’s about it.
[+] [-] goatlover|8 years ago|reply
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.
[+] [-] prepend|8 years ago|reply
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.
[+] [-] Townley|8 years ago|reply
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.
[+] [-] RobertRoberts|8 years ago|reply
I had a friend work with a client using a Squarespace site, and his client asked "Can we put a red circle ad in the top right corner?"
His reply was "Maybe". If they were using a non-canned solution, the answer would be "yes".
[+] [-] Arbalest|8 years ago|reply
[+] [-] Bizarro|8 years ago|reply
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.
[+] [-] andrewingram|8 years ago|reply
[+] [-] mattkevan|8 years ago|reply
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].
[0] https://supernova.studio [1] https://meetalva.io [2] https://github.com/airbnb/Lona
[+] [-] cwilson|8 years ago|reply
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.
[+] [-] saintPirelli|8 years ago|reply
There are plenty of very smart people laboring away to make this happen, but as it turns out, it's not that easy.
[+] [-] goatlover|8 years ago|reply
[+] [-] radva42|8 years ago|reply
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.
[1] https://www.formbolt.com
[+] [-] prepend|8 years ago|reply
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.
[+] [-] garyclarke27|8 years ago|reply
[+] [-] degif|8 years ago|reply
[+] [-] patleeman|8 years ago|reply
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.
[+] [-] andrewingram|8 years ago|reply
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.
[+] [-] seanmcdirmid|8 years ago|reply
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.
[+] [-] davidjnelson|8 years ago|reply
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.
[+] [-] lionpixel|8 years ago|reply
Sketch -> Zeplin -> Storybook (React Component)
Works like a charm! Developers are super happy and productivity increased by three.
[+] [-] blauditore|8 years ago|reply
[+] [-] ninjamayo|8 years ago|reply
[+] [-] davidjnelson|8 years ago|reply
[+] [-] deltron3030|8 years ago|reply
Pagedraw is a tool that converts Sketch or Figma files into the HTML and CSS of React render functions.
[+] [-] zimorodek|8 years ago|reply
[+] [-] fiatpandas|8 years ago|reply
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
[+] [-] AriaMinaei|8 years ago|reply
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 component not only produces the surrounding <div>, it also accepts an instance of another component that it then places inside that div: 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 [email protected] if you want to know more :)
[+] [-] Const-me|8 years ago|reply
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.
[+] [-] tomcooks|8 years ago|reply
So is the appeal of a lean, semantically correct, fast-loading page.
[+] [-] dsego|8 years ago|reply