11 comments

  • John PJohn P, over 3 years ago

    Weird that you miss out the massive con that if you start producing this part of the work you now have responsibility for it. Basically you're making an engineer's (who is almost always paid more than you) life easier and putting more responsibility on yourself.

    As someone who is highly competent in design as well as code I would never take on coding responsibility unless there was a fat pay increase to justify this increase in responsibility.

    I absolutely agree that things coded by designers (or designed minded developers) generally work and feel hundreds of times better but I think it's wrong to preach this to people without painting the full picture of what this entails.

    14 points
    • Nik SytnikNik Sytnik, over 3 years ago

      Totally agree with this: not worth it unless you need to improve your financial situation. In my case, I'm way better off now as a designer who codes than when I started off as a print designer.

      Another thing missing is that you won't be productive at all unless you use some really advanced tooling. CSS pre- and post-processors, templating languages, module bundlers such as Webpack/Browserify, task runners, scaffolding tools - you name it. Good luck designing a large-ish project writing vanilla html/css without things getting out of control.

      I would only recommend working like this to the type of person who becomes bored and unmotivated unless given really hard challenges.

      0 points
  • Weston Thayer, 3 years ago

    When you design in the browser, you're forced to consider things like layout immediately, from the blank page you started with until the last pixel. And there's all those browser/bugs quirks that you have to look up.

    Then there's the question of whether you should create good HTML/CSS from the start. Should you stop and consider whether <section> is appropriate here or just go with <div> soup? What about when you need interactivity that CSS can't handle? Do you hack the JS or pull in a framework...

    My point is that designing the browser introduces a whole new set of design decisions that have to be made, which slows you down and might not be an appropriate use of time, depending on where you are in the design process.

    Design benefits from experimenting with variations. If you've ever had an idea that involved a dramatically different layout, but then shied away because "the code would be hard", it might be time to use a different tool that makes trying different layouts easy (Sketch, Photoshop, etc). Just my 2c

    10 points
    • Duke CavinskiDuke Cavinski, 3 years ago

      Spot on.

      I can code, many designers I know can code, but I am way less creative in the browser because I'm in the weeds of semantics and structure and less likely to take risks I'd otherwise take in Sketch that a talented and thoughtful engineer would ultimately and happily take on.

      This dead horse is a black spot on the ground at this point.

      7 points
      • Jimmy HookerJimmy Hooker, 3 years ago

        Totally agree with this. It uses a very different part of your brain to be concerned with the logic and implementation details of a design rather than the aesthetics.

        0 points
  • Gareth LewisGareth Lewis, over 3 years ago

    I'm a developer turned designer. I'd never go back to designing in the browser.

    7 points
  • Duke CavinskiDuke Cavinski, over 3 years ago

    This is insulting to engineers.

    4 points
  • Cristian MoiseiCristian Moisei, over 3 years ago

    Downvote.

    3 points
  • Darrell HanleyDarrell Hanley, 3 years ago

    So I disagree for reasons that I think differ from most of the comments in this thread. Designing in the browser supposes that your ultimate output will always be the browser, but I think the way that we're heading is developing for the internet, not the web.

    I think a lot of designers underestimate the sea change that libraries like React and Vue represent in how engineers are thinking about digital products. We aren't building for the web anymore. We're thinking, long term, about building for everything, be it the web, apps, and API dependent interfaces like chatbots and virtual assistants. As a result, everything that was good about designing in the browser is now completely abstracted away. Yes we still have CSS, but it's a lot more programmatically related now than it was in the past, and I think long term we're going to abstract CSS away to be something more universally accepted that will translate down into CSS. We're doing so much of the application in Javascript, so much more in the way that it's becoming impossible to decouple programmatic javascript from presentational ones because they are now strongly related.

    I still feel strongly that designers should learn to code, and that a designer who really understands javascript will be the most set for the future, but I think that we have to decouple this notion that designing digital products means designing for the web. You are now designing for the internet and that means that your outputs will take a wide variety of forms that are not intrinsically linked to the technologies of the browser. If anything, you should be working in Sketch, designing atomically, accounting for states, and prototyping constantly.

    1 point
  • Andu PotoracAndu Potorac, over 3 years ago

    What about mobile? :)

    0 points
  • Mattan IngramMattan Ingram, over 3 years ago

    The problem with designing in the browser is how slow and awkward the browser makes it. I actually completely agree with the benefits of skipping Sketch and going straight to the browser, but there are downsides which don't have a lot of tools to fix them yet.

    I am rebuilding my portfolio and wanted some scattered images absolutely positioned and overlapping each other next to a paragraph of text. This should be the simplest thing to do since I don't even need to worry about flow or layout, just pushing images around. But in the browser it requires awkwardly typing in numbers in the Inspector Panel and then playing around with different screen sizes, and then retyping the numbers and hoping I don't accidentally refresh and overwrite all my Inspector Panel overrides. Then once I have what I want, I have to manually copy those values over to my text editor and my actual code, OR I have to awkwardly connect my browser to my file system and let the Inspector Panel write directly into my code (which is not always straightforward when you are using something like SASS and haven't set up sourcemaps).

    In theory designing in the browser should be as easy as Webflow but without all the limitations Webflow puts on you (what do you mean I can't build an HTML table to display some simple data?), but currently it is not and the barrier to simplicity will prevent many designers from making that switch.

    There was a tool posted here in DN a week or so ago that seemed like it was an attempt at improving on this with a direct hook to your file system so your edits could be directly written to your code, but a lot of the reactions in the comments were poo-pooing it based on the fear that inexperienced designers would be coming in and completely messing up clean code.

    0 points