This is a set of ideas how the frontend CSS code of OFN could be improved over time, as well as help with the overall design of the app. There are a few drivers for this:
- A growing team of devs
- Mobile support needs improving
- More general UX improvements, as this thread suggests
- Potentially scenarios where new themes need to be developed
1: Build a style guide
There are a bunch of good reasons to use a style guide - see http://alistapart.com/article/creating-style-guides for a good explanation. http://styleguides.io/ has loads more resources if interested. It could help specifically with OFN in a few ways:
- Encourage more consistent, modular, smaller CSS
- Help with fixing the backlog of UX and mobile issues
- Provide a prototyping tool for new UI development, that then gets built into the app
I’ve started a proof-of-concept here:
Note: this is copied from OFN, some images are missing. The intent is to have a “living style guide” that is based on the live OFN CSS.
2: Convert all SASS files to
(or at least a consistent format if possible)
There is a mix of
scss files in
/assets/stylesheets. It would be great to know the backstory why if someone could post a response. However, having 2 formats makes the overall codebase harder to manage, particularly for new devs.
This article lists a number of reasons why to use SCSS over SASS (several of which I have found to be important).
3: Adopt BEM as a format
It is a known fact that the right styleguide can significantly increase development speed, debugging, and the implementation of new features in legacy code.
There are a number of naming formats in CSS. I’ve been using BEM recently and found it pretty solid. What is really useful (beyond the naming conventions) is the focus on modular components (blocks).
4: Structure CSS files using atomic design principles
Read http://bradfrost.com/blog/post/atomic-web-design/ for more info.
This is strongly related to 3 and about building a modular UI system. The CSS files could be structured into something like this:
/atoms (or base) /components /templates /pages
Note: I’ve compressed the atomic design “molcules” and “organisms” into “components” as the former can create confusion as to what goes where.
While building the styleguide prototype, I’ve noticed the OFN CSS is quite heavily nested. It should be possible to display a
product component without being nested under
.darkswarm products for example - what if there was a need to show a sidebar promotion for example? This also might be factor in the 6000+ selectors the app CSS file has. With refactoring it might be possible to reduce this and remove the need for the
5: Add stylelint as a CSS linter tool
http://stylelint.io/ seems to be a strong tool of choice currently. This is just about also increasing consistency and helping with the other points.
How could this be done?
This might be approached thus:
- Setup a live styleguide that can be built within the project (very happy to continue with my start on this)
- Add new
/componentsdirectories. Potentially do some initial moving of CSS files for base.
- Setup stylelint to scan the files just within those new directories and agree on a basic set of rules to use.
- When components are edited, aim to move the CSS into a new file under
/componentsat the same time, adjusting for BEM style.
- If new components are needed, e.g. a card layout for products, build these intially using the styleguide as a design/review tool.
All feedback much appreciated. Also, this is a bunch of fairly bold points (all in the name of future improvement!), so please give any historical reasons why things are a certain way, or if there are strong preferences for other kinds of conventions, tech, etc.