> For organizing content, yes. For communicating with others, no. For example, we are using Word documents on the edge, when communicating externally. We cannot expect them to access our internal wiki, and neither we want them to.
You can't just copy the Markdown (or whatever format your wiki uses)? Most of them read fine as plain text.
> Sure, if you have the budget to do it right. The excel-based solutions are often done so, because everyone has excel anyway, and the one coming with that has no budget or buy-in to procure the server-based solution.
You don't need a server to use SQL (see: SQLite, H2, Derby, or even Access).
> You can't just copy the Markdown (or whatever format your wiki uses)? Most of them read fine as plain text.
In the process you will lose links, images, etc. Additional complication is, if these are multiple wiki pages, you have to save each separately.
You are not going to explain that to normal users. (Ever explained to a user, why he cannot attach word documents into bug tracker, but he is supposed to put the content of the document right into the appropriate text fields? Not fun).
> You don't need a server to use SQL (see: SQLite, H2, Derby, or even Access).
The reason why Access is not being used is, that it is not a part of the most sold Office SKUs (neither SoHo nor Pro). In fact, I just tried to quickly find out, which are the the non-365 SKUs that do include Access, and I failed.
And again, normal users are not going to use sqlite, h2 or derby without having some kind of forms frontend. Access would be ok, but it is not accessible to everyone who has Excel anyway.
Err, no? They're preserved in the source just fine.
> images
Good riddance.
> Additional complication is, if these are multiple wiki pages, you have to save each separately.
Depends on your wiki system. For example, Gollum[0] (GitHub's wiki) stores everything in a Git repo, so it's trivial to get everything out using your regular file management tools.
> And again, normal users are not going to use sqlite, h2 or derby without having some kind of forms frontend.
DBeaver seems fine to me, and supports pretty much everything.
We are talking about normal users there, not developers. Think salespeople, assistants, project/product managers. They are not going to use git or dbeaver. Nor they are going without their diagrams, charts, schemas or links rendered inline.
If you understand this, you will understand why Word and Excel are still a thing.
You can't just copy the Markdown (or whatever format your wiki uses)? Most of them read fine as plain text.
> Sure, if you have the budget to do it right. The excel-based solutions are often done so, because everyone has excel anyway, and the one coming with that has no budget or buy-in to procure the server-based solution.
You don't need a server to use SQL (see: SQLite, H2, Derby, or even Access).