In brief
The vision prototype is intended to show early how IncluLearn.AI might feel to people before the full AI and data infrastructure is connected.
It is neither a static mock-up collection nor the finished product. The interface is being built as an evolutionary foundation: navigation, terminology, accessibility building blocks, the DE/EN structure and reusable components should be retained where validation shows that they work.
At the same time, the boundary is explicit: the currently visible materials, jobs, users and subject results are demo data. The prototype must not be read as if the full processing chain were already productive.
Not “which AI model?”, but “what do I want to do with my material?”
A central product decision is to keep technical pipeline language out of the primary navigation.
Users should not need to choose between OCR, VLMs, embeddings, sonification or individual model names. The interface should focus on tasks such as:
- opening and continuing work on materials,
- reviewing subject results,
- making reviewed versions available,
- finding shared content,
- later generating suitable outputs.
Technical detail may be important for specialists, but it should be progressively disclosed rather than become an entry requirement.
Three status dimensions should remain separate
The UX concept distinguishes three important states:
- processing – has the material been technically processed?
- subject review – has the recognised meaning actually been checked?
- access/provision – who may see or use which version?
These should not collapse into one green “done” state.
An automatically generated result can be technically complete while still being unreviewed. A subject-approved version is not automatically published or available to everyone.
This distinction directly connects the platform to the project’s AI governance.
Accessibility is not a later retrofit
Accessibility is treated as a technical baseline for the web prototype. This includes:
- semantic HTML before additional ARIA,
- complete keyboard operability,
- visible, unobscured focus,
- status information that does not rely on colour alone,
- reflow and zoom without loss of core functionality,
- reduced motion,
- clear and localised system terminology.
German is the reference language, while English is structurally maintained in core views.
A synthetic workflow instead of isolated screens
The demo now connects several views into one example flow. A concrete semantic demo slice shows how recognised structure could later become reviewable.
The wording “could” matters: the visible workflow is a product and UX hypothesis that enables feedback. It is not a claim that the entire subject-processing pipeline is already implemented.
The underlying UX concept goes further, describing a guided “prepare material” flow, clear next steps, review tasks and a material page as the stable point of return. Parts of that remain target design rather than implemented functionality.
What is not yet productive
The platform documentation explicitly lists several components as planned:
- FastAPI backend,
- asynchronous worker,
- PostgreSQL and object storage,
- productive authentik/OIDC integration,
- versioned semantic schemas,
- productive processing-service orchestration.
The current web application also still consumes demo fixtures more directly than planned for the later product platform.
Why this matters to the advisory board and partners
Because backend functionality is not yet fixed, navigation, terminology and workflow can still be changed relatively cheaply.
Useful feedback is therefore not only whether the demo “looks good”, but questions such as:
- Is it always clear what has already been reviewed?
- Is the next useful step understandable?
- Does the interface assume unnecessary technical knowledge?
- Can review be performed fully non-visually?
- Are sharing, subject approval and publication clearly separated?
Such feedback can still shape the platform before backend and production data models make changes more expensive.