ABOUT THE WEBINAR
As our teams and number of applications expand, it is easy for each new app to look and work slightly different than one before it. This lack of consistency inevitably leads to duplication of work for both developers and designers. From a customer’s perspective, it can cause confusion and in some cases dissatisfaction with your brand. In this webinar, we’ll explore a collaborative tool called a Living Style Guide or Pattern Library that can encourage inter-team communication across multiple apps to help solve the problems that arise with expanding teams and applications.
During this webinar we will cover the following topics:
- The anatomy of a Living Style Guide
- Who it benefits and why you should use one
- Incorporating a Living Style Guide
- Resources to start your own Living Style Guide with Mendix
QUESTIONS & ANSWERS
We have a living style guide, but how do you prevent developers from not setting the right classes and configuration on the right widgets? (especially for 1 UX-designer for multiple development teams)
You should integrate the living style guide with your QA team. So, in order for a task to be marked as done the developer will have to ensure that they followed to steps outlined in the living style guide.
How does the new AtlasUI Sass file layout (one custom-variations.scss file) contribute to the living style guide vision?
Having a living style guide that is a central repository for how, where, and why to use your application’s components ties in nicely to the centralized variables file in the Atlas UI Framework. Atlas UI provides the components and the living style guide provides the how and why.
If you have multiple applications, how would you keep all theme folders up to date to the 'main' style guide? Continuously delete and replace them?
With the release of Mendix 7.9, there are some exciting new features, like building blocks and page templates, that can be packaged and saved for future applications. I’m not 100% sure if the theme folder will be incorporated in this new addition, but I think it will. This will help centralize the theme across applications.
Is it more efficient to use helper classes such as btn-danger or just to define certain elements and define them in the Sass?
This really depends on how comfortable you team is with classes. But in certain cases, such as buttons, you can style the various rendering types to look drastically different than just a color change. That way your developers can just change the selection on the drop down to have a completely different button style.
When would you advice to NOT to use a living style guide?
I think this would depend on the relationships between your developers and designers. If you have a close-knit team that talks regularly and you are working on a more experimental application that is not going to passed on to another team, then you could hold off on creating a living style guide. But if that were to ever be handed over to another team, it would be important to create a living style guide.
What's the best method for implementing a living style guide mid-project?
There is no wrong time for implementing a living style guide, by creating one earlier on your team will reap the benefits faster. As far as how to implement a living style guide mid project is concerned, I recommend documenting patterns and features that you anticipate will come up in the immediate next sprints. Then you can document the remaining items.
View more webinars on-demand at developers.mendix.com.