Be nice. Or else.
Designer at Shopify Joined about 4 years ago via an invitation from Allan G. Evan has invited Travis Hines, Verne Ho, James Wood, Nathan Garvie, Hugo Costa and 4 others, Cedric Heim, Denise Spiessens, Russell Baylis, Ryan Langlois
Yes, unbearably bad.
I use Enki: https://github.com/enkia/enki-theme
It also matches how it's implemented, which is well documented in the Material guidelines. Nothing wrong with it.
Kinda seems like you're looking for something to nitpick, this is not an app-specific survey, and has nothing to do with the actual viability of the app itself
That plugin seems to break my custom keyboard shortcuts and workspace layout. Advanced type options, certain tools, and all sorts of other things have gone missing. And seems to make PS crash more often. :(
(In all seriousness, can we ever have a discussion about Photoshop on DN without it being immediately related back to Sketch? There's nothing in the title about Sketch. Nothing bashing Sketch. Nothing asking for opinions on design tools. Just some simple PS tips. Sketch fans are starting to sound like Jehovah's Witnesses around here.)
I've never used Sketch for a website, and I rarely use Illustrator. There's a lot of tool overlap. Depending on your workflow/preferences you don't need them all.
Maybe you should try it before assuming.. especially since Save for Web is now depreciated. I just exported an SVG directly from Photoshop, no cruft. They added artboards. They updated layer styles. They're working on a streamlined UI that's more focused towards UI design. How is that not improving existing workflows?
I design in Photoshop at whatever resolution is the most common of our users, and I also preview my designs on that most common device (typically iPhone 6, Nexus 5). When designing, I keep in mind the divisions or multiplications to asset size when scaling up or down to additional resolutions (@1x, @3x), (mdpi, hdpi, xxhdpi). I do not always work pixel-perfectly, because that wastes time, plus some assets or text areas or whatever sometimes have larger bounding boxes than how I've laid them out (for whitespace/dimension scaling purposes) so I find tools like Zeplin don't work well for me.
What I end up doing is manually marking up dimensions (usually margin/padding are depicted with semi-transparent coloured bars, with the colours working as a legend to quickly see which dimensions are shared, which helps with defining constants. I try to keep these consistent between screens, too). Then, larger rectangles for image assets/text fields/whatever to help show where whitespace is included in the asset, marked up with any size constants, font sizes, file names, etc.
All dimensions in pt/dp or %. I've had a lot of success with handing this off to developers and only needing minimal tweaking afterwards.
Designers should be capable of architecting a visual language for an application's UI layer
I disagree. That would be like saying a front-end developer should be capable of designing a visual language for an application's UI layer. They may be able to do it, but it might take them longer and not be up to the same quality standards.
Designers should be able to understand in general how the front-end is being architected, and design something that doesn't overcomplicate things for whatever platform it is. But I wouldn't expect a mobile designer to write production code for, say, an Android app's UI elements.
If a team's resources are limited, this might be an acceptable compromise, but more often than not a front-end developer will be able to implement a (well designed, properly spec'd and communicated) design in code more efficiency (in both speed and implementation) than a designer could.
I know the basics of a lot of different programming languages and I could code an app from start to finish (back-end and front-end on web, iOS, or Android) but it would take me an incredibly long time and I'm sure developers would want to re-write all my code. Knowing how those platforms work, however, has improved my designs and my ability to efficiently communicate my designs for those platforms, and it means I can jump into the code to troubleshoot bugs or make small tweaks and adjustments rather than asking a developer to increase padding by a couple pts. In my experience, this has been the most efficient approach.
It is, it's giving the impression that the panel in front is closer and moving faster as a result. It's not the parallax people are used to, but it is still technically parallax.