I feel like I always see 2 sides of Salesforce : this side that produces thoughtful well-done design work and the other, not great side which is actually using their products. Do they use any of this design or is it all exploratory and conceptual?
It's pretty awesome how they're using it actually. They completely rebuilt Sales Cloud with this new UI. I'm hoping it makes using SF more bearable... https://developer.salesforce.com/trailhead/lex_migration_whatsnew/lex_migration_whatsnew_nav_setup
I agree this is very well put together after looking through it for a few minutes, and you could build some really great web apps with it.
However, and maybe I'm the odd one out, but I kind of hate how these frameworks have everything defined in all these name spaced recyclable classes. But that's the whole point! you say. I know I know, but having a short HTML document where every element has 5-10 classes just because they each accomplish something different, with none of the styling classes specifically relating back to that page element itself just rubs me the wrong way.
This is a problem for text editors to solve. Browsers love this approach and it makes a ton of sense from a development perspective too. We shouldn't compromise on output just because it looks/feels clumsy to work with.
It's definitely a different way of thinking about how your design works. It's a system so there should be a decoupling of the class from a specific page element which will seem weird to someone who is not thinking of the design as a collection of modular components.
I wouldn't recommend it for smaller projects, but removing the design complexity from the CSS and managing it through classes in your views makes a world of difference in large, complex projects. It's an amazing feeling being able to drop in a collection of classes into a view and performing all your design in the view rather than trying to do the same within your CSS architecture that has a tendency to become easily bloated and disorganized.
No I know. I've used it on large Shopify themes and apps. Just still rubs against how I learned so it's a different approach for sure.
I think it's first-and-primary focus is not for others to build web apps with it, but for Salesforce’s team to build and extend its sites/apps with. If the team can adopt and learn to use this system, it's a huge win—everyone understands and uses the same design language.
Building a system like this for an environment where you potentially have a few dozen to hundreds of different people making code changes has to be crazy difficult and a monster—I can see the reasoning and argue for classes that accomplish specific things. The fewer the dependencies, the less room for error when extending the system and less likely that the changes will negatively impact the hundreds of use-cases.
Yeah that's for sure.
It does feel odd when you are looking through someone else's code like this because of how bloated and clunky it looks initially, and they don't seem to explain their approach anywhere. But if you can get past the initial appearance and dig deeper into the approach behind it, it's basically a very optimized way of implementing CSS that is easier to maintain and scale and minimizes bloat. I would even call it a thing of elegance. :)
On teams it's easy to get in the mindset of coding things on the fly as needed, and it feels like the fastest way to get things done initially. But that leads to a lot of reinventing the wheel, specificity issues (styles leaking to areas they shouldn't, fighting IDs, !important patches), and inconsistent design implementations, to say nothing of how much time is wasted by the next person working on that code just trying to figure out what's going on. And even in projects maintained by a single developer, it's easy for structure and specificity issues to creep in over time as a project grows and evolves.
The Salesforce System is built on SMACSS and BEM concepts which has quite a few benefits: it makes the code more human-readable, it minimizes specificity issues, and it improves the speed and consistency of implementations (to name a few).
SLDS is obviously built to solve web app needs so it won't be for everyone, but it does seem to have a great set of components and using these kinds of increasingly popular CSS standards will make it easier for developers coming from other systems to hit the ground running.
It's a gold mine for enterprise designers.
It's gorgeous and seriously well documented. I find it hard to believe all those components and component variations are necessary though. The CSS could do with losing a few KBs...
I'd love to hear from someone at Salesforce who can testify to what it's like working with this?
I think all build processes for anything reasonably complex should include some kind of module like task like purify-css or un-css to get rid of unused CSS (in order to make this kind of concern moot). That said, this method does not seem to be recommended by the team, nor is this policy enforced as often as it should be when CSS frameworks are used.
Comprehensive and crazy well documented. Cool beans.
There's a lot of smart thinking here.