[SPBS]

> neither are you ever going to use Confluence as a filesystem storage to replace Google Drive. This means that your knowledge’s single-source of truth needs to accept external tools content as possible documentation. This interfacing, though, can’t simply be about linking files and urls in one place, it has to be deeply integrated so that it feels natural, native even. We should be able to put a Google Sheet file in a folder, attribute tags for example.

What's wrong with using just links?

(reads to the end)

Oh, it's lowkey a promotion for his product it must obviously have this native interfacing that he's hyping up about. I honestly don't see what the problem is with keeping a collection of links to Gdocs/Gdrive/Figma in the knowledge base. That's pretty much the only guaranteed way to use these tools, because all of them want to silo you into their website.

[thecodrr]

Except you can open them in an iframe. Which is what Dokkument (the product being promoted by the author) is doing. Not sure how much more useful that is than simply opening it in another tab which would work 100 times better since you won't have to jump a ton of hoops to make sure everything works fine.

[polote]

The link methods works fine for tech people, but less for non technical ones. By displaying directing the content you save one click and you make the workflow more natural (and it also gives the idea to do it, if a user see a link in a blank document he will like "meeh why would you do that", whereas when you see an iframe, you get the logic easily). Also the iframe is the first step, the next step is to directly interface with Google, Github and others via API, so that you can manage rights, creation, deletion, .. and the user only has to choose which type of document he wants to create.

[thecodrr]

You should also probably look at T&C of the services you are embedding to see if they allow it.

There's a limit to how much integration you can add via an API. Not to mention that a lot of services don't even have an API or have outdated ones.

> By displaying directing the content you save one click and you make the workflow more natural (and it also gives the idea to do it, if a user see a link in a blank document he will like "meeh why would you do that", whereas when you see an iframe, you get the logic easily).

Not sure what you mean here by "link in a blank document". Why not just directly open the 3rd party app in a new tab when you click on an entry in a side menu? There's no click saving, really. You are just embedding the tab that'll be opened.

The other problem is that most apps are not built to be embedded in an iframe. While they might appear to work normally initially, one click could break them because iframe is not the same thing as a normal browser window. Of course, you could provide various workarounds for it but the experience will be subpar at best.

[polote]

> Why not just directly open the 3rd party app in a new tab when you click on an entry in a side menu?

Because you lose the ability to give tags, attributes, page comments, document feedback. For example, there is no comments in a Google Sheet, by embedding them in a page with comments, you can have comments, you can also give it tags and all ...

> While they might appear to work normally initially

Even Github doesn't allow iframe embedding. The goal is to facilitate discovery, if you need to use the app, you would open it in its own tab. A chrome extension would help going back to Dokkument from Github, or add a github file into dokkument and also bypass the iframe protection.

The whole point of the app is to facilitate discovery and sharing following a common framework, we are only a hub and redirect users