Frontend & Documentation UI improvements for lib-jitsi-meet TypeDoc site

[emphor11]

What problem are you trying to solve?

Problem / Motivation

While exploring the lib-jitsi-meet TypeDoc documentation site, I noticed that although the content is technically rich, the frontend UX could be improved to enhance readability, navigation, and contributor onboarding.

For new contributors especially, understanding modules, events, and relationships between entities can feel overwhelming due to dense visual structure and limited affordances in the UI.

---

Observations

Some areas where the frontend could be improved:

• Navigation sidebar becomes cluttered for large modules and events
• No clear visual hierarchy between:
  • Core modules
  • Events
  • Errors
  • Interfaces / classes
• Limited responsiveness and usability on smaller screens
• Hard to quickly grasp relationships between modules (mental mapping issue)
• Search and discoverability could be more intuitive

---

What solution would you like to see?

Proposed Improvements

I would love to contribute frontend enhancements such as:

• Improved visual hierarchy (spacing, grouping, typography)
• Better collapsible navigation for large module trees
• Clearer distinction between modules, events, errors, and interfaces
• Optional visual cues or tags for commonly used APIs
• Improved responsive layout for smaller screens
• Minor accessibility improvements (contrast, focus states)

These changes would be purely frontend-focused and would not affect the core library logic.

---

Contribution Intent

I am interested in working on these improvements and submitting a PR if the maintainers feel this aligns with the project’s direction.

Please let me know:

• If this is something the maintainers would welcome
• Any existing UI/UX guidelines or constraints
• Preferred scope for such improvements

Is there an alternative?

No response

How could this be implemented?

No response

Screenshots

No response

🏢 Have you checked the Community Forum?

• please make sure you check https://community.jitsi.org

[alisha-1000]

Hi @emphor11, thanks for opening this issue — the UX concerns you mentioned around navigation, hierarchy, and discoverability resonate with me as well.

I’d be happy to help work on some of these frontend / TypeDoc UI improvements (purely on the documentation site, no core logic changes).

Before starting, I wanted to check with the maintainers:

Whether UI/UX refinements to the TypeDoc site are welcome at this stage

If there are any existing design guidelines or constraints to follow

What scope would be preferred for an initial PR

If this sounds reasonable, I can start by proposing a small, incremental PR (e.g. navigation hierarchy or collapsible sections) and iterate from there.

Thanks!

[saghul]

I'd like to hear a more elaborate plan here. The main objective here is for it to be useful, so adding a layer of maintenance is probably out of the question. Is it the plan to find a better typedoc template? Roll your own?

[alisha-1000]

Thanks for the clarification — that makes sense, and I agree that minimizing maintenance overhead should be a primary goal.

My intent would be to avoid rolling a custom solution and instead stay as close as possible to upstream TypeDoc patterns. Concretely, my current thinking is:

Approach

First evaluate whether an existing, actively maintained TypeDoc theme or template already addresses some of these UX issues (navigation hierarchy, collapsibility, responsiveness) without requiring long-term divergence.

If an external theme is viable, prefer configuration and light overrides rather than forking or maintaining a separate theme.

If no suitable theme exists, limit changes to small, well-scoped CSS and minimal JS enhancements layered on top of the default TypeDoc output (e.g., collapsible sections using existing DOM structure, visual grouping via CSS only).

Non-goals

No custom rendering pipeline

No deep TypeDoc internals changes

No long-lived fork that would need frequent updates as TypeDoc evolves

Initial scope

Start with one narrowly scoped improvement (e.g., collapsible navigation for large module trees or clearer visual grouping of modules vs events).

Validate usefulness and maintenance cost before expanding further.

Before implementing anything, I’d plan to share a short proposal outlining the chosen approach (theme vs minimal overrides) so we can confirm it aligns with the project’s expectations.

Happy to adjust direction based on your guidance.

[saghul]

Sounds good. Happy to discuss a proposal when you have one.

[alisha-1000]

Hi @saghul — that makes sense. Here’s a concrete proposal with a strong focus on keeping maintenance overhead low:

Approach

• Stick with the default TypeDoc theme.
• Avoid any custom rendering pipeline or deep TypeDoc internals.
• Prefer CSS-only improvements; use minimal JS only if strictly necessary.
• Initial scope (small & incremental)
• Improve navigation usability for large module / event trees by adding collapsible sections using the existing DOM structure.
• Add clearer visual hierarchy between modules, events, errors, and interfaces using spacing and typography only.
• Minor responsive and accessibility improvements (sidebar overflow, focus states, contrast).
• Non-goals
• No custom TypeDoc theme fork.
• No JS-heavy UI or long-lived maintenance burden.

Plan

• Start with one narrowly scoped PR (collapsible navigation + basic visual grouping).
• Validate usefulness and maintenance cost before expanding further.

If this direction aligns with the project’s expectations, I’ll follow up with a small PR demonstrating the first improvement in isolation. Happy to adjust scope based on feedback.

[saghul]

I'd rather you find a theme close(r) to what we need first.

[alisha-1000]

Understood .

I’ll first evaluate a small set of existing, actively maintained TypeDoc themes that are closest to lib-jitsi-meet’s needs (navigation scalability, hierarchy, responsiveness), and avoid anything that requires forking or heavy customization.

I’ll follow up with a short comparison and recommend one option (or confirm if none are suitable) before proposing any implementation.