"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.
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.
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.
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.
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.
Don't widgets, controls, etc. do just that? As you mention they are just parts and to create complex applications you still have to consider business logic, data access, third party API integration(if needed), interaction logic, navigation logic, etc. You are looking at this strictly from a web designer's point of view, which is understandable since you are one, however creating applications is much more complex and we've automated the parts of web development that could be automated. Sure you can come up with more widgets and controls but the framework is already defined.
Yes and no. We're starting with solving for web designers, and the vast majority of their work comes nowhere near the complexity of full-blown applications. The fact that a designer has to know how wire up a form submission, or have to write JavaScript just to get a navigation bar working, or worry about setting up a MySQL server just to get some dynamic content on the page seems broken. It feels like what blogging used to be in the 90s - code HTML and push via FTP. But we've moved past that, and I know we can move past hand-coding HTML/CSS/Wordpress when creating dynamic websites and simple applications (of which many are glorified CRUD form wrappers).
Ok let's look at some of the use cases you mentioned.
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.
Pessimism aside, isn't that exactly what happened with desktop publishing software? The work of manual typesetters, etc was automated, and print designers became a lot more relevant.
Historically, some tasks have proven easier to automate than others. Much of typesetting and printing was rote, thus it was automated fairly early in the history of computers.
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.
You're right, but I'm not arguing that programming can be automated as a whole. I'm saying that most rote tasks in web development (writing HTML/CSS, linking together various libraries, pushing code through processors, wiring up a basic UI to a database, etc) can be.
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?
> 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.
> "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.
> 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.
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.
It's very, very common for web designers to do their creative work in Photoshop or Illustrator. Then, they either code it themselves or hand the PDF/AI to a coder. So I don't believe the supposed blandness of the web results from a lack of visual design tools.
But would people really like it? There's a 20-year history of people trying to make the web look pretty (splash pages, flash, fancy-schmancy javascript transitions etc.) and people hating them for it. There's something to be said for bland uniformity when what you really care about is the information, not what it looks like.
1) web design is an engineering discipline because you have to make things fast and fault-tolerant on top of making it look good. there's a lot more moving parts to a website than there is to an InDesign export.
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.
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.
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.
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.
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.
> 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.:
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?
"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.
> 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.
they didn't years ago. it's standardized some, but it was a nightmare 15 years ago. this "oh no there's so many devices!" is what I hear from people that never had to implement one site for IE3, NS2 and WebTV at the same time.
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]
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.
> 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.
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.
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.
While it's a hassle to develop for various size phones
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.
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).
"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.
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.
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.
"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...
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.
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.
Your quotation talks about design, not about looks. Huge difference.
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.
First, a little context goes a long way. Read the article. It talks about design in the context of how things LOOK and feel NOT in the context of programming design/design patterns.
Second, Just because someone who uses an application doesn't give a shit about how it is implemented does NOT mean implementation doesn't matter. You can have the slickest interface with the coolest animations but if it's not implemented correctly you can have security leaks, compromised data and in some cases absolutely NOTHING [1] behind your so called "the only thing matters" Interface.
[1]http://www.androidpolice.com/2014/04/06/the-1-new-paid-app-i...
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.
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.
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.
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?
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.
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.
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.
63 comments
[ 3.9 ms ] story [ 109 ms ] threadI 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?
[1] https://dl.dropboxusercontent.com/u/600458/Screen%20Shot%202...
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.
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.
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:
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.
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.:
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
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]
[1]http://webaim.org/techniques/textlayout/#column_width
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?
http://www.w3schools.com/browsers/browsers_display.asp
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.
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).
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.
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.
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.
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.
See also: http://motherfuckingwebsite.com/
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.
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?
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.
> 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.