folletto

However, you can design things implemented in HTML/CSS without actually knowing anything about HTML/CSS. ;)

That's a nice metaphor, but no, we aren't saying that you are doing a job, and actually you don't know how do to it and you have someone else doing that for you. The plumber metaphor is flawed.

I can tell you, because it happen every day. It happens to me every day. And if you don't believe me, just read around the comments from people, here and on the article page, that do exactly that.

By the way, there are also comments of people saying that designer must think a bit over what's technically possible, to innovate. Figures. ;)

The problem however isn't in agreeing or not, but in not being so sure that your point of view is the right one.

And I'm talking with a straight face, yes. :)

It's a wonderful quote, because it also says that before coding you might want to learn cognitive psychology, social psychology, gestalt theory, marketing, copywriting, information architecture, usability, economy, statistics, science of materials, architecture and so on and on. :)

There's not just "design" and "code" out there, the design field is way more deep than that, so that quote might translate well to a designer that can't code, but studied in depth social psychology, urban architecture and team cooperation techniques. :)

Please, try to understand that there are different kinds of people, intelligences, sensibilities and talents, and that what's easy and simple for someone, might be hell for someone else.

Some professionals might do a more than excellent job if they focus and pair with a developer, instead of trying to be something they are not. ;) Some others instead, might become better professionals by learning how to code. Different people, different skills, and they can both work on the web very efficiently in both small and big teams. :)

I love the attitude you express in the third paragraph. We need way more people willing to teach and support others understanding them. :)

People are different. What takes you a month could take years to others. Don't assume that we have equal skills and talent. If you can learn how to write markup in a month... great! Good for you. :)

Other designers, are still doing great, without knowing how to code. ;)

It's not fair, sorry. ;) I met plenty of designers that can't code, and they are doing great working in pair with developers. :)

The point is that we should stop to say that designers who can't code aren't valuable. Of course, and it's exactly the last part of the article, if you can code it's better. ;)

Hello. :)

I suggest you to read the About page over that article then. ;)

That point is underlying the whole article. ;)

What it tries to clarify - and well, it might have failed, of course - is that we should stop to simplify the problem as "designers should code", because not all designers should. But yes, all designers could, and if you feel that way, or you are prepared for that, or if you want that, you can learn to code. Exactly like a developer can learn how to design.

In either case, exactly like it's wrong to say "developers should design" but it's correct to argue that a developer with design knowledge will be better at its job, it's equally wrong to say that "designers should code", but it's correct to argue that a web designer with developer knowledge will be better at its job. ;)

I worked with lots of excellent designers that aren't able to write a single line of code. And still paired in a good team with a developer, they did marvels. :)

Again, I agree. The whole article isn't built on that dichotomy. It's just a sequence from a simple perspective to a more complex perspective, and actually ends saying that it's better if you are willing to expand your view, exactly like you are saying. :)

~

On the second part of your comment, well, you are talking about "web designer" specifically, and with a very specific definition of it as well. If that's your definition, then yes, he have to do that. But er, it looks more like a Frontend Developer to me, and I never heard of a "Concept Artist". ;) However, it's a matter of terminology here, and there's surely some confusion about it. :)

I know, it's wonderful when you can do both, but I think it shouldn't be forced on everyone. Not everyone is a specialist, and not everyone is a generalist. Forcing one, or the other, is harmful. :)

Pigeon-holing? Quite the opposite. I'm making the difference between "should" and "could". That's exactly because not everyone is a specialist, neither I am, but at the same time not everyone is a generalist! :)

Exactly like I'm saying in the middle of the article, "you have to know this stuff", but you don't have to know also how this stuff is done, you can, of course. But it's not a must. :)

It's always sad for me to hear people with bad experiences with designers or developers, but really, I don't think that "code" is the answer. I believe that "teamwork" is the answer. Knowing. Discussing. Collaborating. I've never seen a team doing that failing, regardless of the mix of skills :)

Kudos to you if you were able to do it. However, please, reach the end, it says the same thing. :)

Don't worry, there's nothing "after this". "Designers should code" exists only in the web design field. It's fair to suggest that "Designers that can code are better", but it's not a must in any way. That's the point. :)

Probably you never met amazing designers that can't even put a "." at the end of their sentences.

People are different, with different mind, and intelligences. Forcing such a designer to "code" is just going to destroy his skillset, that otherwise would be of great use in a good and collaborative team. :)

Yeah, that's a huge collection of communication problems, great. Exactly on spot. :)

You're right. Every discussion about "designers should code" always shows problem in teamwork and communication, not in coding skills. :)

And even if as I was saying learning to code is a way to create these skills, like designing things is for developers, another way is just listening to the developers/designers in your team. It works very well and it's way more efficient for a lot of different people. :)

Teamwork, and trust.

Sure, not everyone agrees with his theory. However, that's not the point of the article. :)

Yes. Yes. And I can say that this happens in every field. Check this small interview to Erik Spiekermann about typography: http://intenseminimalism.com/2011/everybody-is-influenced-by...

I think that Buildwithme is instead an excellent website, with a good usability and it's one of the few websites that tries to break the taboo of "making an app of a webapp". And I think it delivers pretty well. Of course, it's not possible with all the webapps (and not suggested).

On the other side, I think it's a very different problem, and I'd advise to not mix things up: there's style, there's identity, there are UI canons.

Bultwithme for example mixes web+mac UI canons, has a mac style and doesn't work a lot on identity.

Take Nike.com to have another example. It uses a web style, a bit toward the app format, with UI canons that are almost everywhere app-like... but it has a very strong identity.

On the other side, take Lightroom. It's obviously an app and uses desktop UI canon... but it has a definite identity that you can't mix up with anything else.

Also dropbox, as you cited, uses a quite standard web style and web UI canon, but it has a strong identity.

Don't reduce the identity to the UI canons or interaction styles: they are very different things. ;)

Programmer-mentality is somewhat different from other mentalities, but it's still bound to simplicity laws.

The technologies you are describing were already there, but it's not just a problem of technology, feature set or execution power. It's also a matter of simplicity.

Node.js is working because it gives so much power with a very simple approach. And by approach I mean also how much is simple to understand it and start producing something useful.

That's exactly the reason why we use more abstract languages, and that's the reason why Node.js is getting a lot of attention recently. If you don't know any language, do you think it's simpler to start with Erlang or Haskell, or with JavaScript? I don't have any proof, but my bet is surely on JavaScript. :)

And even the most obvious things are important. Because maybe a uber-developer can ignore the small details, but most of the programmers aren't uber, they just want to develop easily and happily. Every little detail matters. Just see how many steps you need to install Erlang on your machine, and how many steps you need to do the same with node. It seems stupid, I know. But when you sum every detail... it matters. :)

At the same time, this gives power to the uber-programmers out there to bring on more cutting-edge solutions when they need them, and feed the "simple" level with their discoveries and experience, making the language and frameworks evolve.

If you're right, one day we are going to have simple coroutines - in the complex, environmental and social sense expressed above. Maybe even in Node.js, because in the end JavaScript 1.7 afaik supports yield and V8 could implement it in the future. ;)

High-level: I mean something with a steep price tag, with maybe high margins for you. Something like "1000 users, 24/7 assistance" with a really high price. Or something less. However, I think that you should be able to offer also something "high end". Think about restaurant menu design: the highest priced item isn't almost ever bought, but it raises the bar for everyone else. It's a matter of perception. Of course, you must be able to satisfy that high-end request, so if you can't do 24/7 assistance I don't mean you should still add it. :)

Freemium: I agree on your positions. Just maybe think of a small, really small solution that could be free forever. This one is also a matter of perceptions. If you hurry me with 30 days of testing, I think twice before subscribing, since I need to do that at a time when I'm going to have 30 days of test time. Otherwise, I'll just subscribe and I'll test it when I can. Some days of full trial and then put on free is a good solution imho.

The video doesn't start - I know it could be a line problem, but it should me blazingly fast everywhere, since that's what you're using to sell your product. And once started, it's tiny!

Also, excluding the video there aren't any screenshot around, and the "Tour" is just a list with tiny thumbnails.

Excluding those things, however, I think that everything else is well done: it clearly states the price (maybe, add a high-level offer with an high price tag) and explains pretty well some advantages. Also, the try button is everywhere so it's ok. :)

Why don't you offer a basic free-forever account with like: 1 user, 1 project, 1 invoice/month, etc. Something like this. I think it would be perceived really better than a 30-days test (that will still exists!).