It's Inevitable: Designers Will Rule the Web
blog.webflow.com
blog.webflow.com
I couldn't make my job go away if I wanted it to. You don't just say, oh, this problem is too hard, so we're going to transcend it.
I wanted to do frontend/design-ish work the last two job searches. What did I do instead? Well, I managed to actually get some in on 20% projects, and spent the remainder on image processing, field algebras, and... lots of stuff in between. Like administering an Oracle DB, hacking postgres plugins, munging data with clojure and python, fighting with SBT and the scala type system. Before you can start playing with design, you have to write the code to make it happen. And before you can even do that, you have to get the customers' data out of their database, munge it, get it replicated across your own datacenters, etc.
What's left is still coding, without the repetitive parts. Instead of going on vacation, I take the extra time to produce more and better software.
Wire up form submission: Submitting a form in just HTML requires setting the action attribute to point to a backend that will accept the form and do something with it. Wiring it up does not require knowledge of code, it requires knowledge of knowing where to post that form to. What kind of automation do you envision here?
Writing Javascript to get navigation bar working: Lots of widgets/controls exist with javascript based behavior enclosed with the UI(they even have extension points via properties that can change how the control behaves by setting properties e.g. slide left slowly, slide up with a bounce, etc). If you need your navigation bar to behave in a custom way there is no way around writing javascript to implement your custom behavior.
Setting up MySQL server to get dynamic content on the page: Unless you want to put MySQL connection code directly in the frontend(not recommended) you will have to write some code to get the data from the backend.
Now if your goal is to move away from hand-coding simple applications and Wordpress templates for creating simple Websites then the Title of your blog post is a tad exaggerated at best and a bit of link baiting at worst.
An entire article of wishfull thinking.
There have been efforts to automate programming, but so far it has proven impossible. That's because programming is almost never rote. It's likely that automating programming is tantamount to inventing a true artificial intelligence. If that happens, the implications extend far, far beyond web design tools.
That's never a rote process for me. Every bit of HTML or CSS I write requires human judgment. Any part that doesn't is handled for me by preprocessors.
I'm guessing that instead of "writing HTML/CSS," you'd have designers meticulously dragging objects and setting properties in a GUI. Isn't that just the same thing with another skin? If I have to click to set a property instead of typing the property in a text file, have I saved myself any work? Have I eliminated the need for some bit of technical knowledge?
> linking together various libraries
Concretely, what sorts of tasks does that entail? Generally there's a few moments to drop the files into the right folder, and a few more to add the appropriate tag(s) to the <head> or the bottom of the bottom of the <body>. How do you eliminate those steps? Or does the user still have to perform them, except in a GUI environment instead of a text editor? If the latter, then I'd argue the same as I did above about HTML and CSS.
Or do you include certain standard libraries by default? If so, that's fine, but the same is achieved in more traditional, text-based frameworks.
> pushing code through processors
Which processors do you have in mind? SCSS and Uglify are quite trivial to run. I wouldn't call that a pain point at all.
> wiring up a basic UI to a database
I'm still not convinced that can be automated beyond the basic interfaces that something like MS Access provides. Which don't cover most use cases. Can you give an example?
I disagree. You have design-as-a-service with things like 99designs.com, you have great templates with WordPress, you have Bootstrap and other CSS frameworks that get you 90% of the way there (works on different form factors automagically, lots of flexibility), you have style guides for native iOS and Android apps...
You don't "automate" design, you share it based on principles that just about everyone likes. Your design doesn't need to be unique, but your idea and purpose do.
Design seems a lot easier to get 90% of the way there than get code to a point where programmers are less needed.
Not to mention, the last time I checked, we hadn't solved all computable problems, nor will we in any future timeframe.
This is a common red herring in discussions about AI limitations. Computability theorems don't prevent computers from perform engineering tasks better than humans can.
Humans are under the same constraints of "cannot solve all computable problems" as computers are.
2) any tool sufficiently powerful to render complex websites will make it considerably easier to create simple bland websites
3) the mythical oracle described above would not only be of interest to webdesign, but all of computer engineering. i wish you the best of luck.
Back when Flash was in vogue there was all kinds of print designers using it to produce very creative websites. But the consensus was that people hated them.
They never should have, and I'd say it's probably easier in some respects with smartphones because, while there's a multitude, they're all fixed, and you can generally target, say, 3-6, and cover a huge variety. And people generally can't change their font sizes.
Compare with dozens of monitor and window sizes on desktops. 13, 15, 19, 20+, with varying types of DPI and available fonts on systems. Not so much monitor sizes I mean, but... is the browser window full screen, or partial? People resizing windows would lose info, or not see it in the first place, and get lost. Back in the early days the "256-color palette" was considered a requirement for many projects.
While it's a hassle to develop for various size phones, it's still a more controlled and uniform set of sizes, imo; it just takes a lot more work.
In practice, I think many developers just choose a fixed with, e.g. 960px, and leave it at that. The desktop window size and DPI can be largely ignored at that point. Phones and tablets really did throw a wrench into that easy solution. But I can't complain, because users should have access to devices with smaller screens.
Yes, but they were wrong to do that then, and the world is better off now that mobile devices are forcing those people to do things less badly.
Why was that wrong in a pre-mobile world? In many cases, using the entire width of the window would be a big mistake. For example, in a typical blog layout, you might have a main content column and a narrower sidebar column. If you expanded these to fill the entire width of the window, you could end up with lines of text that are, say, 1600 pixels wide. Which would be bad for usability and accessibility.[1]
What kinds of devices are you referring to? (Remember, we're talking about the days before mobile was a big enough market to justify making mobile versions of websites.)
Do you mean Blackberries? I'd humbly submit that, from a business perspective, Blackberry support wasn't an important goal for many sites.
Or do you mean laptops? There was a long time when mobile wasn't big and just about every laptop supported at least 960px.
> You don't need to have text fill the entire width of the display to have a site work everywhere, I don't understand why you brought that up at all.
I thought you were suggesting that the pre-mobile, 960px technique was bad for large screens. It sounds like I was mistaken, and you're actually referring to smaller screens.
Everything from monitors to PDAs to laptops of various form factors. Even as late as 2007, 20% of displays seen in web stats were 800x600 or smaller. There were also plenty of devices that could have accessed the web but people didn't bother because the web was so broken with IE 1024 crapsites. The iphone happened in 2007. There was no period where the number of people getting boned by fixed 960px sites was insignificant.
>Remember, we're talking about the days before mobile was a big enough market to justify making mobile versions of websites.
That is begging the question. You can't assume X as a premise to demonstrate X. 20%+ devices were smaller than 960px. It took (and still takes) no extra effort to design a website correctly rather than with a fixed grid. Just as it took no extra effort to design a website correctly rather than for IE only. It is not a co-incidence that "best viewed in IE 5" and "best viewed in 1024x768" buttons were best buds. Both stem from the same source.
However, as someone who was a webmaster in 2007, I can tell you that the 20% figure was not even close to true for my particular sites. Other webmasters I knew told me the same.
So I'd say that this, like all things in web design, admits of no hard-and-fast rule. Rather, the answer is "it depends." In 2007, it depended on what your analytics were telling you. Most sites nowadays have a strong business need to support phone-size displays, but even today, not every single site does.
This sounds fairly obvious doesn't it?
It's even easier if you adopt the mobile first approach,though it's not valid for every project,it's valid for most projects.Thinking mobile afterward is hard.
Oh jeezus...I consider myself more a humanist than a tech evangelist, but this makes me throw up in my mouth. Design is vital, don't get me wrong, but the problems and tensions we have with design often come from abstract/vague specs and opinions...Placing value on "code" doesn't necessarily mean "Programmers-first"...but in order for a sane eco-system with relatively stable specs, programmers and engineers cannot take a back seat to the design process.
OP, doesnt understand that, these webbased products DONT WORK.
Even during the flash area,designers needed basic coding knowledge to add listeners to events, and, the twist is , some designers became coders because they had to , in order to stay competitive on the flash job market.
Web designers WILL always need to learn to code if they want to stay competitive ,period.
Things change fast on the web,and wysiwyg web tools cant integrate all the latest web techs, all the latest best practices,etc...
Finally, web designers dont work in the void,they work in teams with coders, and coders hate wysiwyg generated code.
So no ,not going to happen,like it did not happen with Dreamweaver (that even tries to be less designer oriented and more code oriented now).
There have always been visual editors for the web. As the author suggests, they have relied on abstractions of the underlying code. For example, the CSS box model (width/height, padding, border, margin) are often abstracted as draggable handles on bounding boxes. Yet these systems suffer from some fundamental limitations:
1. They obscure the underlying implementation, making it harder for designers to understand and fix problems when they inevitably occur. On a related note, the lack of visibility into the code inhibits learning.
2. They lack the power to express more advanced styling rules, such as the following:
/* Paragraphs have 20px margin above unless they follow a heading */
p {margin: 20px 0;}
h1 + p {margin-top: 0;}
/* Don't indent the top-level UL, but indent 20px for each level of nesting */
ul {margin: 0;}
ul ul {margin: 0 0 0 20px;}
/* Divs that are immediate children of forms get 20px margins, but divs nested
within those don't. */
form > div {margin: 20px 0;}
3. They lack the power to express idiosyncratic JavaScript interactions. They can provide some generic primitives like rollouts. But many, many real-world apps need fine-grained control over interaction. For example, today I built a system of nested lists with sorting, deletion, and insertion to arbitrary depth. It was so idiosyncratic that it couldn't have possibly been made into a generic component in a visual editor. Problems of that nature are fairly common in my work. And no, the idiosyncrasy is not a sign that something's wrong: Different problem domains often call for (slightly) different interfaces.
4. They don't play very well with dynamic websites. If you need forms or for HTML to be generated from a database--both of which are very common needs--you can't express that generically in a visual editor. Expressing that kind of logic is an act of programming. Historically, efforts to abstract programming into a visual process have been disappointing or outright failures. Source code is the only workable way to express a computer program.
2. Yes, they do now, but they won't always. For example, we're already working on an intuitive implementation of nested selectors. But I agree with you, things like pseudo-elements, complex selectors, etc are harder to move to the UI - but it's not impossible.
3. I agree with you to an extent, but consider this: the entire Webflow blog - including the JS interactions, working forms, etc - was built by my brother Sergie, a designer who doesn't code. There will always be ultra-custom components, but they don't make up the vast majority of web development.
4. See #3 on forms. And I think you'd be surprised by what you can do with content pulled from a database in a UI. We have something in the works, and honestly it has to be seen to be believed.
So you're assuming that the designer will have to do some hand-coding after all, yes? I agree that it will almost always be necessary. So, how do you ensure that the generated code is pleasant to work with, and not a mess? Historically, that's always been a huge problem in this genre of software.
> For example, we're already working on an intuitive implementation of nested selectors...move to the UI
It sounds like you intend to build a graphical representation of the concepts that code has traditionally expressed. As I briefly touched on, that ambition has a troubled history. Many attempts[1] have been made, but none has replaced text-based programming in the mainstream. The basic problem is this: Code represented graphically is still code, it still carries with it all the cognitive challenges of code, and now it's in a clunkier format than text.
> the entire Webflow blog - including the JS interactions, working forms, etc - was built by my brother Sergie, a designer who doesn't code.
Naturally, you can author static content (with limited styling logic) in a visual environment. There have been plenty of apps for that dating back to the early days. Dreamweaver comes to mind. I don't dispute that much. My point is that I don't see room for a dramatic advance beyond the status quo of that genre. And that there are known limitations to the status quo.
The only form I see is an email list signup, which points to an external service. Again, that's always been easy with visual editors. It's also easy in code. E.g.:
<form action="http://external.service.example.com/" method="post">
<label for="email">Your email:</label>
<input type="text" id="email"/>
<input type="submit" value="Sign up"/>
</form>
For this example--an email signup form--the backend is where everything interesting happens. The backend for an email signup form such as the one above could easily be tens of thousands of lines of code. Or more. So I don't think it's fair to say that a non-coder "built" that email signup form.
> And I think you'd be surprised by what you can do with content pulled from a database in a UI.
I'm familiar with apps that do that, and I think I know their upper limits. Applications like MS Access have been doing that for years. Those kinds of abstractions have always existed and always will. The problem is that they're limited. Assumptions about the user experience and business logic are baked into the abstractions. Do you foresee a breakthrough on that front?
No, the next 25 years will be about mobile, and whatever that evolves in to. More specifically, it'll be about using whatever hardware manufacturers give developers access to. How design plays in to that will be tied to the same constraints that development is tied to.
Most of us assume every job will eventually be automated on some longterm time scale. This is based on the assumption is that all the hard AI problems will be solved.
The only argument to be had, then, is which of the jobs will be automated first? Design (Artistry), or Engineering? Many commenters here (as engineers, I assume) defend the longterm prospects of engineering. Let's try to break this problem down a bit.
If you want to automate the creation of art, which I assume is the capability to give a computer an input similar to "Design a good looking site", or "Make a pretty picture", then you need a computer that has knowledge of 1) computers, and 2) humans. If the computer doesn't understand humans as well as humans themselves do, then the art will be limited and there will be humans who can create better art.
If you want to automate Engineering, you need a computer that has knowledge of 1) computers, and 2) the language and communication required by artists. This seems at first glance not much different from solving the hardest AI problems, but the knowledge required is a small subset of total human knowledge, and it's possible that this is implemented first because of hardware limitations preventing us from solving true, complete human-knowledge AI.
We, as engineers, are putting ourselves out of jobs. We're making our jobs easier by creating better programming languages and automating as much of our own work as possible. There has to be a limit to this, after which we're no longer telling a computer lines of code, but instead speaking to it in natural language. Once this happens, we're no longer necessary. But I can see a future where the people telling the machines what to do are still valuable, though they will eventually be automated too.
If we look at the most popular places in the Web, like Craigslist or Wikipedia (or day I say YC), none of them are particularly beautiful. And they could be made more beautiful today sure, but they started with something highly utilitarian.
At many start-up events, I've seen ideas that didn't really solve problems and weren't that utilitarian, but were so BEAUTIFUL that people assumed they were great. I worry about this, because then the founders get a lot of "false positive" responses, and when they actually enter the marketplace, they might find that reality <> expectation. Bad for them, but also bad for everyone else, because what's the cost of this huge emphasis on design as opposed to true utility?
[1] https://dl.dropboxusercontent.com/u/600458/Screen%20Shot%202...
did you just say that how an application LOOKS is more important than how it is implemented? Ok not even worth talking about this anymore.... wish I could downvote...
Looking good is important at the start of the experience, otherwise there won't be a long term relationship to demonstrate the awesomeness of the rest of the system.
Regardless, absolutely NO ONE who uses an application gives a shit about how it is implemented. All people see is the interface.
That may include elements that depend on implementation to make it responsive, but what matters is how it looks and feels to the user (i.e. fast). How that is achieved is irrelevant.
How it looks isn't "more important", it's the only thing that matters. All implementation changes are driven by design concerns.
It's interesting this article mentions that development has just been getting more complex. I don't know that this trend will reverse, but good luck.
> 3D artists have modeling and animation software that they can manipulate directly
And nowadays they also have to start worrying about the physical properties of those models.
Reference: http://www.youtube.com/watch?v=MG4QuTe8aUw
It appears to me that this article generally doesn't want to understand the difference between print and web.
Programmers are always automating and we are succeeding at it. Many tasks and roles have been eliminated in the last ten years by better tools and services.
Designers don't really do that, they get better tools to better represent their vision from...programmers.
I think design and art is crucial and the people that do it well are critical. But not as critical as the people that support the entire ecosystem.
If I were to say who would rule anything, it would be mathematicians, in every domain of knowledge - even design - mathematics is the ultimate intellectual tool to express abstraction, cardinal to the act of automating and reducing.
You're not special. You can be automated. I hope you are and I hope I am too. This is the future and I welcome it.
See also: http://motherfuckingwebsite.com/