14 comments

  • Rhys MerrittRhys Merritt, 5 years ago

    I found the article a little difficult to follow. The intro spoke about the big news, a new file format - with a summary of the benefits. The next paragraph started talking about symbols, with seemingly no precursor to the title "But We Already Have Symbols, Don’t We?"... What?

    11 points
  • Paul GrantPaul Grant, 5 years ago

    But should designers sketch?

    7 points
  • Thomas Michael SemmlerThomas Michael Semmler, 5 years ago

    The actual information hidden in the article is fantastic, but the interpretation of it couldn't be more wrong:

    Translating a visual design to CSS/HTML is now a mundane task of the past. The responsibility for all-things-UI is back in the hands of designers.

    The frontend has never been lessmundane. Creating HTML/CSS files is not enough anymore, it hasn't been for a long time. This will not bring "control back to designers", no. At best, it will open the door for further processing a sketch project into a prototyping environment or whatever else will come from that. But unless sketch starts to implement Design Features that only CSS can provide, any graphic program will always be inferior.

    Here is a list of things that sketch would need for this statement to become remotely true:

    • feature queries
    • advanced mediaqueries (orientation)
    • custom properties (native variables)
    • currentcolor as color value
    • flexbox
    • flexible and relative value units (vh/vw, ex, ch, em, rem)
    • CSS Grid Layout (minmax definitions)
    • Semantic Elements
    • basic dom events
    • basic dom states & pseudo elements (:nth-child(n), ::placeholder, ::after, ::before)
    • forms and everything associated with it
    • ... that also means, today, implementing following advanced concepts that modern day frontend development relies on:
    • the Shadow DOM
    • scoped style
    • custom elements

    for all of that, sketch also needed to implement the cascade. You basically would have to make a browser.

    And this list is only CSS. Now we are even ignoring the fact, that the frontend layer today is being created and maintained to a majority with JavaScript.

    For all of that, you need good, solid, readable, scalable and maintainable, semantic frontend code, just html and css alone. You can't just throw a bit of html and css in there and think that this will be sufficient. And designers now that, which is probably the reason why many of them gain an understanding of the technical nature of the frontend, while the rest stays away from it entirely and delegates that task to the people capable of dealing with that.

    And honestly, by the logic behind this sentence:

    The translation into components needs thorough thought, but will probably be solved through clever algorithms.

    ... it would be more realistic to admit, that the discipline actually getting replaced by algorithms is user interface design, not frontend development. Design has become more and more about implementing trends and delegating creative decisions to big data. I am not saying, that this is gonna happen, I don't believe it - but in the premise of the quoted sentence, I tried to draw a picture that seemed more logical.

    Designers don't need a tool that bend html & css in a way that make them feel like they are "in control". They need a tool that provides them with an interface that operates based on the concept the web and its technologies runs on. It is not hard to learn enough HTML and CSS to start making web interfaces, or to at least learn what these things are actually capable off.

    It really pisses me off, when HTML and CSS are being spoken about or treated as something that limits Designers. The web has capabilities, that print never had. At this very moment, there is not a single program that is able to enable designers to make interfaces that embrace the capabilites of the web platform. You can get something similar, if you combine many programs - and that won't change for quite some time.

    4 points
  • Eric BlattbergEric Blattberg, 5 years ago

    That post was, at best, inscrutable.

    1 point
  • Johannes Lamers, 5 years ago

    Version control for designers in now within reach! So exciting! I've asked the maker of Tower (git) for mac to make it compatible. Join discussion here!

    1 point
  • Eliot SlevinEliot Slevin, 5 years ago

    This is interesting - I think arguably more for generating sketch files than sketch files generating code.

    Imagine a browser plugin which exports the page, layers, objects, fonts and all - to an organised sketch file. Stuff like that's now possible.

    0 points
  • John PJohn P, 5 years ago

    Can you open it without re-zipping it?

    This strategic move will make designers and frontend engineers skip (the visual aspect of) frontend frameworks like Bootstrap or Zurb Foundation and go from Sketch straight to implementation.

    ??? surely if the dev team required it to be built using Bootstrap then it will still be built using Bootstrap. Not really sure what this has to do with frontend frameworks or how it negates them.

    0 points
    • Darrell HanleyDarrell Hanley, 5 years ago

      The primary beneficiaries of this sort of plugin would be projects that use component based systems, like anything built on React/React Native or Vue.js

      Like, lets say I have a button component for my React project. I could then setup some plugin to pull styling information directly from Sketch (background color, border radius, etc) use those styles verbatim for every instance of that Button. I could also map symbols to represent different states of that button (default, hover, focus, active, etc) and add additional classes myself for things like animations.

      Such a plugin would save developers from having go to though and manually match styles from comps to how they would appear in the browser or in an app.

      0 points
      • Thomas Michael SemmlerThomas Michael Semmler, 5 years ago

        so.. for example that button's text and icon in there has fixed dimensions and uses inline svg, not an svg sprite. How do you deal with turning this into a responsive component? I can already see absolutely positioned text in this scenario. And that svg, if the designer changes it, you'd have to manually update this entire component anyway, because it is not using a reference.

        I doubt the actual value of this, though I know what you mean. But if sketch does not understand flexbox or css grid layout, why would you trust its capability to interpret design into html and css, when not even designers get a say in this.

        0 points
        • Darrell HanleyDarrell Hanley, 5 years ago

          You aren't obligated to use everything wholesale, you can pick and choose what content from the layer you want for your actual code, say the color, border-radius, or text alignment.

          You wouldn't manually update the component, you would programatically update it. You could also programmatically create an SVG sprite if that's the approach you want to take.

          The point here is that you can extract any data programmatically from the Sketch file and do with it whatever you please. A lot of this seems to be going over the heads of the design community for the time being, but what opportunities this provides for automation and tooling are astounding.

          0 points
  • Viktor T, 5 years ago

    From Sketch, not as much focus on the file format there... https://medium.com/@sketchapp/b8f1ed22adbe

    0 points
  • Rory Smyth, 5 years ago

    Seen a few of these types of post. Yet to see a practical example. If it's already in the beta, why has no one produced anything. I want to see this new file format in action.

    0 points
  • Andree Huk, 5 years ago

    Thanks indeed for posting, guys.

    0 points