Project Refactoring
Project Refactoring (WIP)
1. Example - Styles
(1.1) Component Style is mostly not influenced by the implementation of Angular Themes. They are overwritten, resulting in side effects, when working with Angular Material Components. e.g.: when removing Style of the home-page.component in scss
Although they are Dark Themes, the underlying Material Theme is not. By creating new Components, the style needs to be adjusted manually for every Theme.
(1.4) Implementation of Components for features must be non-reliant on those effects, so that:
- the Theme defines colors
- the implementation of the Component defines Layout.
(1.5) If further customization is required, a strategy for material overrides must be defined, so that:
- No Side-Effects appear for other Components.
strategy for color-names
// TODO
usage of multiple color code notations
preferred format should be RED, GREEN, BLUE
instead of FULL_NAME
or #FFFFFF
,
reason: with this notation RED, GREEN, BLUE
, rgba(var(--color),0.-1)
can be used. it allows to automatically generate accent colors.
if full names or hex codes are still required, a preprocessor can be used to generate scss entries.
ensure proper color usage
note: serves as example, might be irrelevant after refactoring! this is still the incorrect approach on styling material components!
this is a flat-base + custom attribute '_color="x"' where x is 'a b?' -> a = {'primary', 'secondary', 'cancel'} and b = {'fill','stroked','flat'}
<button mat-flat-button _color="primary flat">
to ensure, that styled components are working for every theme:
- create a component containing all styled components
- secondary and primary is the same color in 'high-contrast', this creates side-effects
- different names for same values. Another theme might have different values, creating theme dissonance. "suddenly the color is a different color, when switching a theme"
strictly forbid individual customization of elements to prevent bloating and side effects
icon is bigger, icon color different.
- creates side-effects on other themes, components or when changed.
- it's another item, that needs to be maintained
2. Component Scope
(2.1) The reuse of components has advantages. DRY - Principle However, if a Component includes several subcomponents, if those subcomponents have properties in context to the parent Component, those subcomponents cannot be used for other Components.
(2.2) e.g.:
app-room-join is used by different components.
If requirements change:
e.g.: form-field to be full width, or button should be different,
there's no elegant way to use this component in new components.
Issue
The main issue here is, there's a lot of effort in these components, but their style is dependant on their functionality vice versa.
Possible Solution
A possible solution might be:
- when creating a subcomponent, don't use style on that subcomponent, so that:
- the subcomponent only implements the functionality
- the parent component controls the layout style
- the theme controls the component coloring.
3 Translation
(3.1) Different components import different language files (type: json).
This is an Issue, when reusing components. A subcomponent uses the translation of the parent (if not otherwise specified, which itself is a workaround, to this issue).
E.g.: For every cancel button, the translation has to be redone resulting in countless duplicate entries, for a translation.
Issue
- trivial translations have to be defined for every new component.
- side effects when reusing components
Possible Solution
- common pool for translations
- introduction of new pipe for common pool translations
4 Brand Identity & Design
(No need to go fancy here)
A design choice can only be justified, with a common goal. Otherwise, it's highly subjective.
Considering the target audience for this project, it's important to keep this in mind.
It should create a lasting impression on the target audience.
Issue
- no definition of 'corporate design'
- constant overwriting of components ⇒ crude implementation ⇒ no goal ⇒ non-maintainable code
- different design philosophies
- material design framework, but forcing a unique selling point by overwriting said framework, resulting in different design approaches
- too many colors and themes (no brand colors, difficult to maintain, bad implementation, side-effects e.g.: changing background-color, changes text color in a non-related component)
- too many elements, that don't serve a purpose ⇒ which is irritating for users? (those elements need to be maintained)
- why is it (maybe, potentially) irritating for some users?
User uses product during critical moments, overcomplicating (and constantly changing) UI elements will hinder that behaviour.
Also the learning curve for new users gets too steep. (normal users don't have the context developers have)Solution
- define a design which serves as benchmark for every future implementation
- create components based on that design
- use those components for features
- stay on track, don't lose scope
- don't overcomplicate features
- if an implementation of a feature takes too long due to overcomplicating and micromanaging the design, ultimately the feature release will be delayed, it's important to release a feature as fast as possible and then evaluate whether additional features are really necessary. It's important to get feedback from active and new users regarding future features or other requests. (This excludes anecdotal requests)
scratch notes:
- When does a feature become a new Application
- How to handle anecdotal requests? CRM
- Provide resources for target audience e.g.: https://www.jetbrains.com/help/
- Link features within the web app to those resources e.g.:
- user uses certain feature, link article describing features or insights https://www.jetbrains.com/help/idea/work-with-maven-goals.html
- provide user with options to migrate from other system e.g.: https://www.jetbrains.com/help/idea/migrating-from-eclipse-to-intellij-idea.html
- provide educational templates / articles about how to integrate a feature in lectures e.g.: https://www.jetbrains.com/help/idea/product-educational-tools.html
- always provide help (see s.1)