• Marc EdwardsMarc Edwards, almost 8 years ago (edited almost 8 years ago )

    Given the wide variety of abilities required, I'm not sure there will ever be an ultimate tool for vectors, bitmaps, prototyping, animation, responsive layouts and production code. The very best tools for each of those tasks are typically poor at any other job. And it’s been that way for the entire history of software and web design. Doing one of those well is hard enough.

    Illustrator is a great example of that — it is the best vector tool on the planet, but terrible at even generating bitmaps from vectors, let alone attempting everything else on the list. That doesn’t seem to matter if you pair it with something else for styling and bitmap generation.

    If anything, what we need is better interoperability, rather than one giant monstrosity that does it all.

    3 points
    • , almost 8 years ago

      Yes, the main problem really is interoperability which in the long run could either lead us to better standards or tools that compete by supporting several features in one application. I don't agree that your can't provide great vector and bitmap tools in the same application which Affinity Designer proves. Such applications are huge undertakings and I wouldn't expect any app to do it all but in an utopian future it certainly would.

      1 point
      • Marc EdwardsMarc Edwards, almost 8 years ago (edited almost 8 years ago )

        Yep, I agree that it might work out ok to include 1 or 2 of those main functions.

        • Vectors + bitmaps = Photoshop?
        • Prototyping + animation = Flinto and Principle?
        • Vectors + production code = PaintCode?

        In terms of interoperable formats, PNG and SVG should take us most of the way. SVG 2.0 adds lots of great stuff. I don’t think there will ever be a single format that can travel between all tools. There just isn’t feature parity to allow for that (nor should there be).

        1 point
        • , almost 8 years ago (edited almost 8 years ago )

          Yes SVG would be an awesome format to keep at the base across several applications! Interaction tools could probably accomplish a lot with SVG animations and javascript (pretty much how framer does it already). So I actually think a lot could be accomplished with a single file format (or as in this case: a combination of separate files). But if import and export tools are good enough this would be less of an issue anyway.

          One of the best productivity features for me recently has actually been copy and paste (Sketch/Illustrator/Affinity objects can be pasted directly between both Slack, Trello, Photoshop and Keynote). And if most apps are that quick and easy to use it wouldn't be such a big problem if features are scattered across several different applications.

          (Ps thanks alot for having this discussion I can't help but get pumped for what could be possible in the future :-p)

          1 point
    • Vlad Danilov, almost 8 years ago (edited almost 8 years ago )

      This is what the interoperability deals with.


      // At this point, I'd like to take a moment to speak to you about the Adobe PSD format. // PSD is not a good format. PSD is not even a bad format. Calling it such would be an // insult to other bad formats, such as PCX or JPEG. No, PSD is an abysmal format. Having // worked on this code for several weeks now, my hate for PSD has grown to a raging fire // that burns with the fierce passion of a million suns. // If there are two different ways of doing something, PSD will do both, in different // places. It will then make up three more ways no sane human would think of, and do those // too. PSD makes inconsistency an art form. Why, for instance, did it suddenly decide // that *these* particular chunks should be aligned to four bytes, and that this alignement // should *not* be included in the size? Other chunks in other places are either unaligned, // or aligned with the alignment included in the size. Here, though, it is not included. // Either one of these three behaviours would be fine. A sane format would pick one. PSD, // of course, uses all three, and more. // Trying to get data out of a PSD file is like trying to find something in the attic of // your eccentric old uncle who died in a freak freshwater shark attack on his 58th // birthday. That last detail may not be important for the purposes of the simile, but // at this point I am spending a lot of time imagining amusing fates for the people // responsible for this Rube Goldberg of a file format. // Earlier, I tried to get a hold of the latest specs for the PSD file format. To do this, // I had to apply to them for permission to apply to them to have them consider sending // me this sacred tome. This would have involved faxing them a copy of some document or // other, probably signed in blood. I can only imagine that they make this process so // difficult because they are intensely ashamed of having created this abomination. I // was naturally not gullible enough to go through with this procedure, but if I had done // so, I would have printed out every single page of the spec, and set them all on fire. // Were it within my power, I would gather every single copy of those specs, and launch // them on a spaceship directly into the sun. // // PSD is not my favourite file format.
      1 point
      • Marc EdwardsMarc Edwards, almost 8 years ago (edited almost 8 years ago )

        Such a great comment. :D

        The PSD format was never designed to be an open standard. And yep, it’s 25+ years of legacy in a binary format. Not an easy format to read reliably. I’m not sure it should even be attempted — the only tool that will ever have feature parity with Photoshop is Photoshop.

        1 point
        • Vlad Danilov, almost 8 years ago

          The PSD format was never designed to be an open standard.

          Yet it is now a major part of design workflow and has to be open elsewhere. Adobe cannot choose destiny for its own creation but surely can help it grow.

          it’s 25+ years of legacy in a binary format.

          Instead of piling up stuff, they could’ve just versioned it like others do. Currently, it’s very suboptimal even just in terms of file size.

          Agree that in practice these things significantly affect development. It takes a strong will and courage to stand against them, just like when starting a home renovation :)

          Back to the original topic, the interoperability is still infeasible, proved by many projects OpenDoc, ActiveX, OLE, COM, Flash, Silverlight, etc. Best option for a design tool is to be an extensible platform.

          1 point
  • Luca Candela, almost 8 years ago

    My absolute musts:

    1. Constraint awareness: we design for devices and technologies that resize elements based on the available screen real estate, state of surrounding components etc... A constraint based design tool makes creating complex screens a breeze, even sketch is a chore when updating a lot of different screens.

    2. Ability to mix and match styles (like in CSS): tools out there let you create widgets and symbols, but it's not very useful often as you have to make different symbols for green buttons and red buttons, or have to "isolate an instance" but then the red buttons don't stay synced etc...

    3. Collaboration enabled: no design tool I know of allows a team to easily collaborate in the same design, and especially for big applications that quickly becomes a problem. How do we split the files? How do we keep common elements synchronized?

    2 points
    • Marc EdwardsMarc Edwards, almost 8 years ago

      Constraint awareness.

      I agree, but I also feel that I don’t want to spend a lot of time remaking things for production. And I also feel that tool-generated-code often sucks. So we’re stuck: Does the design tool have it’s own, separate responsive system? Or is it mapped directly to CSS, CSS’s flexbox, Android’s layout system or iOS’ Auto Layout.

      All options are bad, really.

      Collaboration enabled.

      What I don’t like: Custom, siloed, cloud-backed collaboration. This is a solved problem (Git etc). I’m not sure why everyone tries to keep re-inventing it.

      0 points
      • , almost 8 years ago

        Constraint awareness when built into our applications and when integrated with smart guides really could prove useful. We've already seen quick Sketch plugins that offer constraint awareness via webkit and Edge Reflow did it at a basic level too so I wouldn't be surprised to see more of this in the future.

        Also: agree about using git. Would be awesome and I think it's possible to do it already by using illustrator svgs? Might be worth a try.

        0 points
        • Marc EdwardsMarc Edwards, almost 8 years ago

          I definitely agree about having responsive abilities in design tools. I think a good approach might be to allow some simple constraints, accepting that the layout will have to be remade for the target platform. Good for prototyping the design, not necessarily for building production code.

          1 point
  • Csongor BartusCsongor Bartus, almost 8 years ago

    The browser with Gulp has it all. What is really missing a web specific, web only editor.

    0 points
  • Adam RasheedAdam Rasheed, almost 8 years ago

    It would be sketch with better typography tools and version control.

    0 points
    • , almost 8 years ago

      I’m not so sure about that, Project Comet has a lot of useful features that could potentially leave Sketch in the dust. But yes, Sketch with better typography tools and version control would be awesome (version control is definitively on that list as one of the desired features).

      1 point