Proposal: Optimise high level structure for target audience

[michaelstingl]

I was thinking about an approach to optimise the structure for the different target audiences. This is first draft:
(Examples in brackets)

---

User Documentation

• Web UI/Client
• Desktop Sync Client (Installation, usage, easy troubleshooting)
• Android App
• iOS App

Admin Documentation

• ownCloud Server Backend (Installation, Configuration, Maintenance)
• Web UI/Client (Branding)
• Desktop Sync Client (Branding, Mass Deployments, more troubleshooting)
• Android App (Branding, Play Store Distribution, MDM)
• iOS App (Branding, App Store Distribution, MDM)

Developer Documentation

• ownCloud Server Backend (PHP API, OCS API, manual theming, app development)
• Web UI/Client (ownCloud Design System)
• Desktop Sync Client (Build the client)
• Android App (Build the app, use SDK)
• iOS App & SDK (Build the app, use SDK)

ownCloud Product Documentation

• Platform (Basic principles across all platforms)
• Web UI/Client (UI/Design)
• Desktop Sync Client
• Android App
• iOS App
• ownCloud Server Backend

---

Where Does This Need To Be Documented?

This would be the root level for all other docs.

Why Should This Change Be Made? (Optional)

Optimise the structure for the different target audiences.

What Type Of Content Change Is This? (Optional)

• New Content Addition
• Old Content Deprecation
• Existing Content Simplification
• Bug Fix to Existing Content

Which Manual Does This Relate To? (Optional)

• Admin Manual
• Developer Manual
• User Manual
• Android
• iOS
• Branded Clients
• Desktop Client
• Other

We would need to split up the desktop and mobile docs for the different audiences. This can be done over time…

@settermjd @pmaier1 @felixboehm I talked with you in the past – what do think? Please provide feedback, and I'll iterate…

[michaelstingl]

Related issues with requests to change the structure:

• Update the documentation's structure #302 (mostly Server Admin Manual)
• Restructure admin manual - concept #658 (mostly Install instructions in Server Admin Manual; closed for now – will be handled in follow-up issues)

Those change requests are on a higher level and can be done independent from my proposal.

[pmaier1]

Nice, thanks! I like the structure, makes a lot more sense than the current one and should guide the respective audiences better 👍

Would we then drop the versions (as we currently have 10.0, 9.1, 9.0, etc.) and only have one documentation for the current version?

[felixboehm]

Basically, this is an overview page of all the different docs.
And versions are one more dimension on top...

By default, just show the current version, with „latest“ in the path.

[michaelstingl]

Yes, for every product you can have multiple versions. Antora navigation can handle this. But you don't need to list all previous versions on the overview page. That would ruin it.

[settermjd]

I really like where this is going, @michaelstingl. Perhaps we should catch up and map it out further. Then, I can work with @PVince81 to get it into a future sprint, so that we can begin to implement it.

[michaelstingl]

@settermjd I think we don’t need changes in the repo structure for the server backend. Or should we bring the server docs to the server repo?

For the client/apps repos, I think we only need subfolders? User, Admin, Developer?

Does this work for Antora?

[settermjd]

@PVince81, can we get time for this scheduled, pls?

[PVince81]

we have some tasks to finish currently, can schedule this afterward, yes

[voroyam]

@michaelstingl I would love to get together and exchange concrete plans for restructuring the user docs.

[voroyam]

2 years without progress.