...
Design is an iterative process, and thus product is expected to be always in a continus continuous process of change. A change in product is not only in regard of its features but also in regard of its characteristics and this document focus is on the later.
...
To define how to measure product characteristics
To provide a mechansim mechanism to measure where a component/feateur feature of the product is on our quality bar.
To detect/predict a weakness or area of imporvment improvement in a component(s) of the product.
To suggest a list of attributes which can help in mesuring to measure the quality of product component(s).
...
Data Sources: Making data drivin driven decision is easy, but getting the data might not be that simple for some attributes, mainly usage.
What is our quality bar. Does this document needs to define it, or shuold should it rely on external resources, like other estabilied established OEPs, and in case such reference doesn’t, what to do about that…
What what is the smallest unit or building block of the product, and how does it relate or mapped map to the techical technical product. (While I try to call it componenetcomponent, no matter if we agree about the name/notion it would be important to explicity explicitly define it, and list it… Can it be taken from the mindmap, and if yes then at which level
Do We we need to group them per technical context to ? To group them per technical core it would simplify the measurability measure of attributes , (i.e. you measure measuring an attribue attribute of techncial core componenet, then it a technical core component would affect all product compoenent components that uses use that technical core compoenentcomponent)
In case when different stackholders stakeholders have different prioritypriorities, or would optimize for different attribute, how can that be resolved?
For example an enterprise scale provider of Open edX it might not be concern if a change/featuer increase feature increases maintainability cost in terms of ( human or/and IT resources), because they can afford that however other porivder providers would find it a blocker.
How does this relate to different use cases (ref Use Cases and MindMaps )
How does this relate to different use user bases ( small scale, higher scale…etc)
...
In order to convert product components into artifact artifacts we propose to create a list of attributes, that would belong to product componenetscomponents. Just as Open edX Proposal #57: Core Product is defining what are the componenets components of the product are, this is defining their attributes.
...
An attribute can be though of as a signal, a character of the component, or for the product as a whole. As the product is a compostion composition of its componenetscomponents, its attrubtue attributes or characteristics are a composistion combination of all its every componenetcomponents. Simply put on other words, an attribute can be defined eitehr either at the compoenent component or level or at the product level.
Characteristics of Attributes
Just as each compoenet component product has a collection of attributes, each of its attribute attributes can be defined as its attributes, or meta attribute, those are just
An attribute must be measurable so that we can define its criteria. We should aim for the quantitative nonsubjective non-subjective type of data. But it might not be always the case; i.e. what does the UX look like? It might be a subjective opinion, ; in such cases, we can try to revert to the census agreement or/and for to the subject matter expert.
Attributes might conflict with each other, for example optimizing for modularity might affect the performance or/and maintainability.
We might try to overcome this by setting the importance of each attribute relative to other attributes.
RearchitectureRe-architecture: Can we rebuild it in a way that is try to take the best of each attribute…does attribute… Is the overall cost worth the outcome?
When developing new features/components it's important to take the previous point into consideration, i.e. we should strive to ensure that adding a new component does not affect attributes of other components in a negative way, unless there is a strong need to. iI.e. Adding adding more MFEs improves the modernity of UX but decreases the efficacy/performance of the dev tool.
Some attributes might have well-defined OEP, which is a good thing, in that case, we don’t want to redefine that OEP but rather utilizes use it for PoV
Component Attributes
Below are example of suggested list of attribute.
PerformacePerformance
Modernity
a11y
i18n/l10n
Modularity
Maintainability
Adoption Rate
Usability
Scalability
Developer Friendliness
Can it be deployed and enabled in the stable releases? (cf MFEs)
Is development active on it?
How many different community members depend on it? Is there collaboration on it?
Documentation - does it exist? Is it up to date?
User awareness - do users know about it?
...
To get overview of product featuersfeatures/componentescomponents) https://www.mindmeister.com/map/2385779758?t=FnCLcUqgZ7
Table/Sheet example for Componenetscomponents/Attributes attributes https://docs.google.com/spreadsheets/d/1fVKuxeNYwZNjR2roTQ-WJjqxlnZQa9dzNLWL8jBXmhw/edit?usp=sharing
Visual detaling realtion chart detailing the relation between product features and characteristics https://lucid.app/lucidchart/15ea9319-9aad-423f-b2bd-f43845702e1f/edit?viewport_loc=-448%2C-27%2C2729%2C1374%2C0_0&invitationId=inv_7ac311d4-d0af-4d9b-926f-720181a5d87f
...