
It's Inevitable: Designers Will Rule the Web - callmevlad
http://blog.webflow.com/designers-will-rule-the-web
======
lambdasquirrel
_" If the web is to reach its full potential, we have to empower many more
people, with fewer technical boundaries. The needs and capabilities of the
internet will grow faster than society can train up new computer programmers,
so we have no choice but to transcend past programming to interact with this
beautiful new medium."_

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.

~~~
callmevlad
I'm not arguing that we should get rid of code altogether, that is an
impossible task. I'm saying that we shouldn't require code for things that can
be automated, and there sure are tons of parts of web development that can be.

~~~
lambdasquirrel
The truth is that programmers have been trying to automate themselves since
the beginning of the trade. Garbage collection, higher order functions,
automated deployment tools, wordpress, they are all related. We are lazy, we
don't like doing meaningless repetitive stuff that somehow nonetheless
requires programming experience. As far as I can tell, lowering the cost of
implementing software hasn't put a dent in the demand for programmers.

~~~
kkilat
I agree, I don't think this is about eliminating programming "jobs" at all.
It's really about eliminating the "meaningless repetitive work" you mentioned.
In that way it could actually be freeing to developers -- allowing you to
focus more of your time and energy on the really innovative things that CAN'T
be automated.

~~~
jarrett
Today we have such powerful tools for web development that, at least for me,
there is hardly any "meaningless and repetitive work" involved. Those aspects
of the job _have_ been automated. For example, I use SCSS instead of pure CSS,
eliminating whole classes of drudgery. I use Rails' form_for instead of
manually populating text fields with their current values. Another class of
drudgery eliminated.

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.

------
nathas
> "Unlike many technical disciplines, design is impossible to automate"

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.

~~~
callmevlad
Consider the diversity of design we see in printed magazines, and the lack of
diversity on the web. That's not really automating design, it's making it
bland and uniform. Imagine if web designers had a tool like InDesign, and it
actually worked by generating the right code - I personally think that would
be extremely liberating to designers.

~~~
jiggy2011
But magazine designers don't have to care about usability to the same extent.
Once people have to interact with your stuff consistency becomes important.

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.

~~~
callmevlad
Yes, I agree, and web design tools should enforce/encourage good usability.
Good usability doesn't have to be tied to software or code.

~~~
jiggy2011
You can't really enforce usability through tools , the best you can do is give
people a more restrictive set of tools to work with. The more flexibility you
have, the more power you give to screw it up.

------
mgkimsal
"If that wasn’t enough, the explosion of smart phones and tablets has made the
job of the web designer even harder. Designers can no longer assume a fixed-
width canvas..."

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.

~~~
jarrett
> Compare with dozens of monitor and window sizes on desktops

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.

~~~
copergi
>In practice, I think many developers just choose a fixed with, e.g. 960px,
and leave it at that

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.

~~~
jarrett
> they were wrong to do that then

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]

[1][http://webaim.org/techniques/textlayout/#column_width](http://webaim.org/techniques/textlayout/#column_width)

~~~
copergi
Because we already had tons of different display devices with tons of
different sizes and resolutions. People just said "it works on my screen so
that's good enough". 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.

~~~
jarrett
> Because we already had tons of different display devices with tons of
> different sizes and resolutions.

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.

~~~
copergi
>What kinds of devices are you referring to?

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.

~~~
jarrett
If the 20% figure you gave was accurate _for a particular site,_ then your
conclusion would be absolutely correct. That particular site shouldn't have
done a fixed-width 960px layout.

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.

~~~
copergi
>if I make a site that turns off people using low resolutions, I don't get
many visitors using low resolutions

This sounds fairly obvious doesn't it?

[http://www.w3schools.com/browsers/browsers_display.asp](http://www.w3schools.com/browsers/browsers_display.asp)

------
danso
> _Design is a universal language. It transcends borders, races, and spoken
> languages. It is constantly changing and adapting to new ideas, new
> platforms, and new environments. It’s inherently more human than programming
> - most of us can tell good design from bad, while a only a tiny percentage
> can identify good code. Design is the interface between the problems we
> face, and the solutions we create to overcome them._

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.

------
camus2
Ok,guy selling a wysiwyg , webflow , "drag and drop with no code".

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).

------
jarrett
I don't believe there is a major leap to be made. Here's why.

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;}
    

Or, if they _do_ have the power to express those rules, they're doing so in
one of two ways: Letting you write CSS ad-hoc, or building a complex GUI that
maps to those CSS rules. In the former case, you're back to hand-coding. In
the latter case, you're using a clunkier proxy for hand-coding.

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.

~~~
callmevlad
1\. I think a good abstraction should make it clear what the underlying
implementation is doing, and Webflow gives you access to the generated code if
you need it. Sounds like a leaky abstraction, but aren't they all? ;)

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.

~~~
jarrett
> Webflow gives you access to the generated code if you need it.

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 someone who has the brains to learn a complex graphical editing tool, the
above should not be difficult to learn.

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?

[http://en.wikipedia.org/wiki/Visual_programming_language](http://en.wikipedia.org/wiki/Visual_programming_language)

------
mgkimsal
"The next 25 years of the web will be all about design. We can make
significantly more progress by opening up the power of web development to the
masses."

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.

------
fragsworth
This problem, taken more generally, is the question "What will come of us as
we progress towards the singularity?"

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.

------
jmzbond
I think in the Valley there's an over-emphasis on design, sometimes one that
comes at the expense of utility.

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?

------
k-mcgrady
OT: When I scroll down on that page in the latest Safari the title scrolls
over the text [1]

[1]
[https://dl.dropboxusercontent.com/u/600458/Screen%20Shot%202...](https://dl.dropboxusercontent.com/u/600458/Screen%20Shot%202014-04-02%20at%2018.09.18.png)

------
palakchokshi
"The design of a solution is much more important than its implementation under
the covers, since the latter is almost always invisible to the user and can
take on so many different permutations. Whether it’s a simple web page, a
data-rich online newspaper, or a full-blown interactive application - how
users experience it easily trumps the underlying code used to build it."

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...

~~~
mgkimsal
In some respects, it _is_ more important, and I say this as someone who is
more of a server-side guy. Regardless of how scalable your data system is, and
how secure your code is, if the front-end that people use looks like crap,
they will not use it, and they'll use some other garbage system that exposes
their data and crashes regularly, but it feels nice.

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.

~~~
palakchokshi
He said "much more important". Sorry but that's just not true. Secondly I
present to you [http://sfbay.craigslist.org](http://sfbay.craigslist.org)
[https://news.ycombinator.com](https://news.ycombinator.com)
[http://en.wikipedia.org/wiki/Main_Page](http://en.wikipedia.org/wiki/Main_Page)

~~~
mgkimsal
those are outliers, and have a network effect ('moat'?) around them that
ensures the game is theirs to lose. CL and Wikipedia started over a decade ago
- anyone trying to get any sort of mindshare in those markets would not
succeed without something that had a design (visual and ux flow) that was
appealing to the users. In rare instances that might be barebones plaintext,
but in most cases it won't be.

------
gexla
Thank goodness. If designers don't need development help to bring this stuff
to life, we can finally move on to bigger and better things. Hurry up! We can
then focus more on building what Warren Buffet calls "moats" around our
business so that people can't easily create "me too" competitors.

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.

------
voidr
If the web will solely consist of static .jpegs then yes: designers will rule
the web. However at the moment our webpages are interactive and starting to be
adaptive and accessible as well. We also might have some data on the backend
that need to be manipulated in the UI. And theres also performance. I don't
think there is a way to expose all these to designers without requiring them
to code and actually have an understanding beyond design.

> 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](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.

------
ixmatus
I think there's a fundamental misunderstanding from people that do not know
how to program "in the large". Real programming is actually heavily reliant on
human creativity and synthesis. Just like good visual design.

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.

------
evli
If this comes to be remotely true, it would only drive the salaries for web
developers even lower.

------
Executor
I disagree with your vision of the next 25 years. Enterprises waste money
creating new html templates for each web solution (as well as said
developers). Imagine if all web pages had minimal layout design (with little
or NO usage of images/css). That way developers can spend 100% of their time
on the backend (business logic) - not on the front-end. Thus development time
could decrease and features can increase. This is because front-end is a waste
of time and if only we can culturally accept functional (think Google.com) not
creative design, then no developers will rule the web.

------
fjabre
It's ironic that the very same types of people who are automating jobs away
from the masses in all kinds of fields and industries would feel threatened by
the point this article is trying to make. I love what webflow is trying to do
and I really hope they accomplish it.

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.

------
Joeboy
There seems to be an underlying assumption that every website needs a
designer. One of the great things about the web is (or used to be) that
anybody can publish on it. I hope there will eventually be a backlash to the
"conspicuous design everywhere" trend.

~~~
visakanv
I think designers will rule the "visual web", which will be a huge part of the
"popular web", but there will always be a market for quality. I would happily
read unformatted .txt files online if it's written by somebody I admire.

See also: [http://motherfuckingwebsite.com/](http://motherfuckingwebsite.com/)

------
visakanv
Counterpoint:
[http://motherfuckingwebsite.com/](http://motherfuckingwebsite.com/)

------
gexla
The future (as did the past) belongs to people who can sell.

