Overlapping card shadows | Sketch Tutorial (2019)

▶︎▶︎ www.udemy.com/course/learnske... - I've been noticing all over the place lately that overlapping card designs are creating a bit of a paradox when it comes to the drop shadows being cast. On a hunch, I went back through the Google Material Design guidelines and found that Google themselves present this paradox as a best practice.
We are dealing with 3 overlapping surfaces if you include the background. It’s further back than the rear card. We know that because the rear card is casting a shadow onto it. So what about the front-most card? If it’s casting a shadow onto the rear card, we know it has elevation from it. That means the elevation from the front card to the background has to be different than from the front card to the rear card. Overlapping surfaces at two different elevations: get two shadows.
Here’s what Google Material has to say about elevation and shadows:
“All Material Design surfaces, and components, have elevation values.
Surfaces at different elevations do the following:
• Allow surfaces to move in front of and behind other surfaces, such as content scrolling behind app bars
•Reflect spatial relationships, such as how a floating action button’s shadow indicates it is separate from a card collection
•Focus attention on the highest elevation, such as a dialog temporarily appearing in front of other surfaces
•Elevation can be depicted using shadows or other visual cues, such as surface fills or opacities.
When a surface overlaps another surface, either partially or completely, it indicates that the two surfaces occupy different elevations (but not the degree, or amount, of difference between them). Surfaces at higher elevations appear in front of those at lower elevations, meaning they are positioned at different elevations along the z-axis. Surfaces may overlap one another by default, or become overlapped as a result of motion that changes their position in the UI.
When surfaces have different opacities or insufficient contrast from one another, it can make it difficult to tell which surface is in front of another. Avoid ambiguous overlap by ensuring surface edges are clearly defined.”
So let’s look at how to quickly and easily fix this shadow problem in Sketch using just a few layers and a mask.
-
Launch Sale! Take my complete Sketch course on Udemy for 75% off:
▶︎▶︎ www.udemy.com/course/learnske...
-

[@gatozion]

That's great for Dribbble, but developers hate me if I send this design on zeplin :(

[@agamagdziak2334]

You are doing the best video about sketch program. thank you

[@rudityasw.a1823]

Thanks for nice video and explanation. Very useful tips.

[@josephatodaro]

You got it!

[@tonynm5353]

Great tutorial, can you add a file to download? can't repeat this in sketch 65

[@carlosvilla4293]

Nice explanation, is a lot useful.

[@josephatodaro]

Glad to hear it!

[@karimouni8557]

Very useful thx 😊

[@leandrobernardini]

Sorry sir, how can you get that smoooooooth cursor movements? Thank you!

[@josephatodaro]

That's motion blur from Screenflow :)

[@dalvinchitauro4041]

yes... black

[@w0mblemania]

"engineering can catch up". The problem there is that the engineering cost is about 1000 times the design cost. What takes an hour to do in Sketch, can take weeks to do properly in code, if it's even possible. And then there are all the edge cases, hacks and maintenance problems.
Instead of creating designs that require the "engineering to catch up" a professional designer needs to be working WITH engineers, and producing designs that can be implemented in the real world, in a reasonable time frame, within available budgets. Otherwise, these are just designs that can work only in the imaginary world of Dribbble, where things like project cost, status bars, different display sizes, Dynamic Type and German localization don't matter.
If the engineering team already has a realistic shadow compositing system in place, that's great: use it! But requiring (possibly very difficult) technical requirements in the design is going to give your team (and you) some big problems.

[@josephatodaro]

True to a degree - but if it weren't for design pushing things forward, everything would still look like Windows 3.1

[@w0mblemania]

@@josephatodaro It's not just design that pushes things forward -- anyone with a bit of training can push out aesthetically pleasing graphics -- it's the melding of design with engineering that makes the things people want and need. The concept is nothing without a practical, workable implementation. That's why for every 10,000 beautiful designs on Dribbble, there are a handful of truly excellent production apps out there.

[@brandenbyers1992]

And SwiftUI makes this concept easy to apply (despite not having quite as much control over the drop shadows). Here is some example code and screenshots: gist.github.com/brandenbyers/123b4978c1be00d72f908c84a53229cb
I don't think the lighting is correct for the top rectangle's bottom shadow, but it should still convey the basic idea.