canonical / design-vanilla-framework

Design components for Vanilla Framework.
https://vanillaframework.io
GNU General Public License v3.0
62 stars 11 forks source link

Create a Sketch cheatsheet #414

Closed kwm14 closed 3 years ago

kwm14 commented 5 years ago

Created a cheatsheet guide based on @lyubomir-popov spacing variables document, which highlights components affected when changing the horizontal or vertical spacing.

@spencerbygraves @lyubomir-popov can you take a look, review and let me know if it makes sense 👍

001-spacong-variable-cheatsheet

lyubomir-popov commented 5 years ago

@kwm14 @spencerbygraves thanks Karlos, very nice presentation. But I feel I didn't provide a clear enough brief, sorry about that. The comments below are my fault for not clarifying initially.

• px values are only true when 1rem == 16px, which changes on bigger screen to 18 and everything adjusts accordingly. So I think it's probably best to not use units, and shift the focus from exact numbers to things that match between components. This is why I intended to use colours instead of numbers, so it is true in all cases. Something like this, but a long list of all components instead of just 3:


$sph-inner

This variable equals 2 baseline units. It is used as the default amount of space between a component’s vertical edges and its contents. The screenshot below shows all components using this variable: image


• It should work as a flowchart - or a steps of decisions for a designer mocking up, or a developer implementing a mockup of a new component. Something like this:

  1. Am I dealing with vertical or horizontal space? • vertical -> look at variables starting with $spv- • horizontal -> $sph

  2. Inside or outside? • -inner • -outer

  3. Which elements should it match? I.e., if put next to something , it should be constructed similarly. Usually this has to do with amount of content inside it, is it one line / multiple lines, etc.

  4. In the case of vertical spacing, should it align with free flowing text (like a button often has to)? Or should it be symmetrical top/bottom, like navs, tabstrips etc that do not sit next to free flowing text? • yes: use var with nudge compensation • no: use vars used in menu, tabstrip etc.

And finally, we should make sure we don't use this decoratively - as in the orange strip, where the value 472px is not meaningful. It depends on the amount of text, and it is not based on any of the spacing variables used in vanilla. This is because things like that undermine the impression of strong logic behind every decision, and could tempt developers to disregard these as just fancy designer infographics. We want this to be a common language between design / development, so either side can review and question the correctness of any decisions, or spot errors creeping in. And most importantly, make these vars familiar enough to devs, so they don't feel tempted to just hardcode things like this:

@kwm14 thinking about it, this will probably be easier to do with codepens, as it will be too laborious otherwise. Let me give it a try and I'll update the thread with a demo once I've set it up.

kwm14 commented 5 years ago

@lyubomir-popov thanks 😄 no worries at all. Let's sync up and discuss tomorrow when back I'm back in the office tomorrow 👍

cristinadresch commented 5 years ago

@kwm14 Lyubo will be off for 2 more weeks, should we leave this one on blocked for now or can we progress on it without him?

kwm14 commented 5 years ago

@cristinadresch Ok cool. I will move it out of the iteration and speak with him once back in the office 👍

anthonydillon commented 4 years ago

@lyubomir-popov is this still something you want to do? I wonder if you can keep it up to date with changes in the codebase?

lyubomir-popov commented 4 years ago

Yes, definitely still valid, rather large though so I need to finish the modular table before starting this.

bartaz commented 3 years ago

We are not doing it.