Describe the problem
Flows are currently displayed as a list of API operations, but don't bring much information. Their purpose is to explain how to use the API to achieve some particular goal, but I don't believe they fulfill it.
there is no specific data that we could expect from an example (parameter value, return value...)
the links to API operations are all broken in the UI
there is no step-grained description to explain why we make each call and what happens
the data contains duplicate information about the operations instead of simply linking to the operations (and twice: once in steps, and once in operations)
All of this makes this feature both pointless and broken in its current form.
Expected behavior
Technically, such a flows description could be achieved without the imposed structure, using free text global pages, if we provide a way to link to documentation elements (see https://github.com/joffrey-bion/livedoc/issues/111). That would force users to create their own presentation themselves, but as of now, it would be a better alternative than a broken feature.
Alternatives
Fully develop the feature with a nice UI and step-grained descriptions.
The only reason to keep the feature as an opinionated imposed structured declaration would be if we add real value, especially in terms of presentation. Unless this is achieved, it might be preferable to just remove the feature completely.
Describe the problem Flows are currently displayed as a list of API operations, but don't bring much information. Their purpose is to explain how to use the API to achieve some particular goal, but I don't believe they fulfill it.
steps
, and once inoperations
)All of this makes this feature both pointless and broken in its current form.
Expected behavior Technically, such a flows description could be achieved without the imposed structure, using free text global pages, if we provide a way to link to documentation elements (see https://github.com/joffrey-bion/livedoc/issues/111). That would force users to create their own presentation themselves, but as of now, it would be a better alternative than a broken feature.
Alternatives Fully develop the feature with a nice UI and step-grained descriptions. The only reason to keep the feature as an opinionated imposed structured declaration would be if we add real value, especially in terms of presentation. Unless this is achieved, it might be preferable to just remove the feature completely.