"Export as HTML" could just emit a webpage rather than a fancy ZIP, for better UX

ara4n commented 9 months ago

Steps to reproduce

Export a room as HTML
Get a zip file, with bits of HTML and CSS and attachments etc in it.
Watch as less technical users get confused with wrangling a ZIP file, and opening stuff at random until they find messages.html

Outcome

What did you expect?

Just open a webpage with the static exported history on it. This has the advantage that:

You can immediately preview what got exported
You can save it however your browser likes (e.g. "save as web file, complete" in Chrome)
You can print to PDF if you so desire.
You use the existing UI/UX for manipulating HTML archives, rather than inventing an entirely new thing which is neither MHTML nor MAFF nor Web Archive or whatever.

What happened instead?

The app assumed the user was a developer who would know how to handle a ZIP of HTML+CSS, rather than treating them like a normal user.

Operating system

No response

Browser information

No response

URL for webapp

No response

Application version

No response

Homeserver

No response

Will you send logs?

No

t3chguy commented 9 months ago

Just open a webpage with the static exported history on it. This has the advantage that:

I don't think this is feasible as we'd need to base64 encode all media which would make the file very large and would be very duplicitous with avatars.

NickTupp commented 7 months ago

Hey all, the current feedback we have had from our on-prem environment users:

Cannot export Emojis's if used in a chat
Export of chat not capturing all data. When large chats are opened as a html file, the ammount of lines needs to change in the browser to expand the chat so it may be printed to a pdf in a viewable format.

Would there be any way it can be exported to a pdf file in the future? This would make it very user friendly for non tech savy users. Worst case if you exported to html you could print to pdf if all data is captured.

t3chguy commented 7 months ago

@NickTupp that sounds unrelated to this issue.

ara4n commented 3 months ago

I don't think this is feasible as we'd need to base64 encode all media which would make the file very large and would be very duplicitous with avatars.

I'm not sure why you'd need to base64 the media? I'm envisaging generating a huge HTML view of a timeline (i.e. made out of normal image tags, which may well be backed by blobs), and then relying on the browser's built-in "Save Page As..." to save that as an html archive or PDF or whatever. The blobs would get blatted out to disk as files by that engine, i think.

The only disadvantage I see is that if the HTML is too large for the browser to render, it might OOM. However, it sounds like we may have that problem with the current approach already (https://github.com/element-hq/element-web/issues/27615).

ara4n commented 3 months ago

and then relying on the browser's built-in "Save Page As..." to save that as an html archive or PDF or whatever. The blobs would get blatted out to disk as files by that engine, i think.

Turns out in Chrome at least, it's awful - it doesn't save the blobs, and misses loads of other stuff too. Similarly save as PDF chokes on the blobs. So yes, i guess you'd need to inline them as data URIs, which would indeed be horrible and exasperate memory problems.

ara4n commented 3 months ago

random thought: if you could get the blobs served by a service worker as SW-backed fetched URLs, perhaps that would work to persuade Save Page As to actually save them.

element-hq / element-web