Where the design community meets.
Creative Director & Designer Joined over 7 years ago
You're aligning it correctly. It might feel off to you because you don't have a descender in the label (as explained earlier), but that is arguably the best way to vertically align for EU languages.
Overall, instead of trying to reverse engineer the decisions of Material, I suggest you look further into the advantages and disadvantages of using a baseline in your system (absolute vs. relative baseline vs. free-floating stacking). There's a lot of implications that are way more severe than the one you're stuck on (localization, system font scaling, accessibility), which are all impacted by the choices you make.
Just to give you further context, the other common alternative, is to vertically align using the ascender+baseline, which is used by iOS, OSX and Windows (this usually doesn't use a baseline, or uses a ridiculously small baseline unit, like 4 or 2).
It is aligned correctly. It appears off because you're using all caps (which I believe should be used in buttons only anyway), not in lists or in headers.
In general, aligning using the x-height will always give you a truer alignment (as it accounts for both descenders and ascenders), at least for English and most European languages (minus the ones with crazy diacritic glyphs).
If you know you'll be always using all caps, or using eastern languages you should define a type ramp that optically aligns from the same baseline (e.g. going a few pts smaller).
Let me expand of this.
"Do you feel the need to create one?"
· Designing systematically is a good habit of any mature designer. So yes, you'd want to be doing that. That being said, its the propagation behind designing systematically that turns those rules into a formal "design system" as most of us know it. The degree of rules and documentation that you need is highly variable depending on the work you do and how you intend to divulge this information internally (e.g. Zeplin's style guide covers color and type quite well on its own right)
"Where do you start from?"
· You'll start from content. Whatever is the most important piece of data your work revolves around, you'll start by designing it and defining rules around that. Then you'll try those rules against other components. If they work great, if not: can you find a single value which works in all (or most) cases? · Once you've gone through this exercise, you'll realized that there's only a limited sets of values that works (note how many design systems are based off a 4px grid? Well, that's not a coincidence!)
"But they take a long time?"
· Also this is fairly relative. If you're planning to do a lot of documentation, a living style guide, then yes - that can be a lot of work. If you're planning to have a system driven by your work files, then you're just investing some set up time in favor of facilitating future work.
The bottom line: you probably don't need a public facing design system (e.g. Salesforce Lightning, Material, etc), but you want your design team and eng to all agree on the basic design rules across your designs (type ramp, , colors, grid and layouts, spacing system). That'll shorten the handoff and QA time and make your life overall much more enjoyable :)
The turn Adobe has taken is just sad. Commissioning random UI Kits (which frankly are useless to any actual designers, unless we're talking about a widely adopted design system) as opposed to creating functioning products is not the right way to boost adoption. And posting here without being transparent as to why you're doing it (publicity) isn't either.
What should be questioned is not the price or the amount of money you made, but why something like this should be thought of as " business". I think it can be more a lot more fun and rewarding to do something for the community and release it for free than convincing yourself that its a viable business idea and thus become outcome dependent.
I'm not saying it was never done before, you're always going to find an outlier example. I'm saying it wasn't necessarily customary, or it was done in a way that could still contribute to the larger community. Think about The Iconfactory: they had free and paid icon sets.
Monetization is a new cultural phenomenon (IG, Youtube, Steemit, Twitch) and I would be surprised if there was not a correlation between the two.
When price is within certain boundaries, its not a matter of income disparity as much as Its a matter of perceived value. A dark theme for Sketch is useless to some and valuable to others.
You partially bring up the most interesting part of the question, which is the cultural aspect: certain things used to be free (nobody ever thought of charging for theming an app, since the IP there is pretty much zero - https://www.adiumxtras.com being a great example of that). And I have the feeling that people who have been involved in design for a shorter period of time have not experienced that.
I think the real question is why are (younger?) designers trying to make a buck off each other instead of truly contributing to the community?
Pixel Preview! If you want people to actually design in it, you must support pixel preview. Until then I'm not sure who you're really catering to.
The answer is the same for any product that doesn't evolve. I call it 'loser's mentality'. You can interpret it as you wish (in fact even the literal interpretation will do), but its basically a vicious cycle created by people who don't know how to make decisions and tend to make bad ones when they do. There's a lot of companies like that and none of them is aware of what their real issue is.
I have avoided Adobe products for a while, especially after they introduced the updated "new file" window. Now Illustrator CC 2018 won't even export SVGs anymore, rendering it basically useless for any production job. https://forums.adobe.com/thread/2401916
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.
Every single day. I don't understand how people keep up with publications / websites otherwise. Feedly + Reeder.