Be nice. Or else.
Community Staff Founder at Bjango Joined almost 5 years ago via an invitation from Christophe T. Marc has invited Matt Kelsh, Rene Ritchie, Dan V Peterson, Troy Mcilvena, Graham Clarke and 12 others, Jeremy Olson, Ramy M., Andrew Hart, Ricky Synnot, Aen Tan, Justin Velgos, Nik Fletcher, Rok Benedik, Nghia Nguyen, Jared Sinclair, Matt McDaniel, Elliot Jackson
Thanks for mentioning this. I was wondering why it looked a bit strange. Also, a pretty US-centric quiz made it a little more difficult for international viewers.
Adobe really, really, really should have rebooted Fireworks, rather than killing it. :/
This might sound ridiculous now, but I think this will make more and more sense over time.
Ridiculous is good! Aiming high is good! I think you’ve hit on some great points, and the industry isn’t addressing them now.
This will become especially important in AR and MR interfaces, where the visual appearance and functionality is not really possible to work with separately (I had to do that with VR and it was an extremely painful process to say the least).
I can imagine AR and MR would make the current tools even more unsuitable.
What we're doing now is essentially double or triple work. A designer makes the mock-ups and then those are recreated in a prototyping tool and/or animation tools and then recreated once more when implementing (or some combination of those).
Yep, it could definitely be smoother. I don’t inherently think double or triple work is bad — the initial pass aides in thinking and can evolve quickly, my prototypes are usually Hollywood sets with giant faked bitmaps to give us the starting values for the code, and the code is the real deal. Some repetition, but each stage is optimised for a different thing, and not all work is replicated. But yeah, it would be great if there was a nice way to keep these things in sync better.
Again, I realize this sounds ridiculous today, with the tools we have now. But I really don't see how this wouldn't eventually happen anyway.
I don’t disagree, but I can think of two good counterpoints (for the sake of the discussion and completeness):
It’s been the promise since the dawn of computing (Java and Swing, anybody?). That doesn't mean it’ll never happen, but I think we’re likely to still have vast mix of native and platform agnostic tech in the future, as we do now.
Thanks for giving me a lot to think about, and for this discussion.
It also sort of has the benefit (and downside) over code that photoshop etc have: You can potentially do things easily that are very hard for developers to implement.
AKA the After Effects effect. :P
As you’ve said, it can lead to cool results. You just have to be careful and discuss things as you progress.
I wouldn't really want to build a prototype that is even complete enough to hand to a user though.
Nope. And for that purpose, some of the simpler, but higher level prototyping tools are great! If anything, this is yet another argument for having lots of prototyping tools at our disposal.
I agree with this but would also say code helps overcome a lot of the creative 'ceilings' you hit in Sketch, Photoshop, InVision, Principle etc.
They definitely have limits, and code is limitless. Using a visual tool should save you time. And, if it’s not, I agree to not use it.
I think it’s important to make a distinction between working things out and implementation. I find using a visual design tool saves us a lot of effort, because we can make a lot of decisions in an environment where things are quick to change. Code’s flexibility comes at a cost.
I have a slightly different style of working — I am happy for my prototypes to be a little looser, but once the developer has set up the code, I’ll go in and tweak it. It means we’re not locked into the prototype. It’s just a stepping stone. I’m not saying that’s better, just different. There’s many ways to make this stuff work.
I've lost count of the amount of times I came up with an idea I couldn't design because the tools I was using simple didn't have the features I needed. Eventually I gave in and learned to code and I've never looked back.
That’s great! Framer really shines with interactions that are not possible in other prototyping tools.
I agree. Pipelines and better production flows are the way to go, with specialised tools handling their specialised tasks (in some cases that scope might be big, in others it might not be). Everything should be automated and part of the development workflow. A design tool on its own island (or cloud) isn’t much use, from this perspective.
In many cases, I’d say code is the worst design tool choice. Code is incredibly flexible, but it’s slow and expensive to work with. It’s not visual. It requires skills that many designers do not possess.
The point of a design tool is to work things out before committing to code. If you’re in a situation where writing code is quicker and easier, then sure, do that. That’s definitely not an approach that works all the time though, especially with native apps and lower level languages.
I think artboards are fundamentally broken in terms of how we interact with them. I realise they’re the best we have right now, but if we’re dreaming up future tools, I would want something different that avoids all or most of the issues.
But I see component and screen states existing within artboards, working more like elaborate symbols that can enable, disable, or change layers within.
What would you want?
I see a lot of value in things being stacked, where you spend less time panning and zooming, and where deltas are more obvious (subtle changes are far easier to pick up via temporal shifts where the new thing is shown where the old one was, rather than space shifts with different versions next to each other).
I think we likely need both, but in their current form, artboards are pretty bad, and ultimately fragile to work with. They require so much time managing their deficiencies.
I agree with most of your points, except I am not sure I want it all in one tool.
There is probably a bigger, more fundamental discussion that needs to be had — how far do you want to take things in a design tool? Do you want to almost be able to build the final product? If so, would you then want to be able to output code? I think we’ve been there before with FrontPage, Dreamweaver and others. It’s not good, except for some specialised cases. Please note I’m not saying you’re suggesting that, I am saying that is a possible logical conclusion, and a place we’ve been before.
I personally prefer my main design tool to not be linked to a specific execution or platform — want to use it to design for the web, iOS, Android, games, macOS etc. With that in mind, I do not want a tool that is tightly coupled with CSS grid or Auto Layout or Core Animation etc. I want it to be a nice superset of the most critical visual features. In cases where I do need to help generate specific output, I’ll use a specialised tool, like PaintCode if I want Core Graphics code.
UI is inherently stateful, artboards suck at that
Yep. Artboards are good at seeing a range of potential designs, but bad at representing state. Artboards are broken in lots of other ways, but I agree that the general concept can be good for some uses (seeing lots of alternate designs side by side).
I agree that layer comps are better, but as you’ve said, the idea isn’t perfect. It was created to help manage versions of retouched images, and it’s good at that, but not great at managing states. You can use them in various ways that helps, but they’re very clearly not made for this purpose.
Simply having fade-in and fade-out presets on whole screens is not enough. We need more control over animations.
I see the value in many types of prototyping, and I don’t think I’d want to be restricted to just one. There’s currently a wide spectrum, and I think they’re all good, at different times? Principle and Framer are great a single interactions, Flinto is better for a wider scope, XD and InVision are better for an overall view of the product (yes, some of those tools cover other uses, too).
I’m not sure I want integrated animation and prototyping. I’d rather have good ways for keeping prototypes in sync. And even then, prototypes will be replaced by production code. Could prototypes be kept up-to-date with the production code? Maybe. Should that even be a goal? Maybe?
Separating all raster work from a UI tool isn't perfect, at least for me.
Yep, I agree. I guess this again gets to an important question: What would you like integrated into your main tool? What would you like as separate tools? Asking for too much in the main tool means you’ll end up with a monstrosity that doesn’t do anything well. Having a workflow that’s too fragmented means issues when moving between tools.
I’d honestly settle for something that got the basics right. Many tools struggle with rendering without glitches, are slow to use (workflow), are slow (performance), aren’t colour managed well, have incredibly basic masking abilities, have broken shape boolean ops, and exporting is an afterthought, rather than part of the foundation of the tool.
It may not be what everyone wants, but I would like a tool that is robust, fast to use, has excellent visual design abilities, has good state support, and doesn’t tackle animation or prototyping, but does allow good integration with the wide range of prototyping tools that exist.
I want something that integrates better with developers, too.
A blurry shape or a few stacked blurry shapes could do that.
In Sketch: Gaussian Blur to shapes (it’s at the bottom of the inspector on the right of the screen, when you have a vector layer selected).
In Photoshop: Mask Feathering can be applied to shape layers in the Properties panel.
In Illustrator: Gaussian Blur can be applied to any object or group, in the Appearance panel.
In Pixelmator: Gaussian Blur can definitely be applied to bitmap layers, but I’m not sure about shape layers.
In Pixelmator Pro: I’m not sure yet. :)
Be nice. Or else.
Designer News is a large, global community of people working or interested in design and technology.