Currently we have, e.g., HTML in "Save As" filter list. I suppose that it should not be there, since we don't position LO as HTML editor. IMO, we should clearly state the distinction between the "Export" and "Save As" filter categories, and move all filters that represent "auxillary" formats (i.e., not editable text *documents*, spreadsheets, presentations, drawings, and desktop databases) to "Export".
+1
LibreOffice is an HTML editor. The quality is poor, because no one has cared for it for several years. But nevertheless it exists. Up to now "save as" has those formats for which import and export filter exists; "export" has those for which only export exists. Therefore HTML is correctly under "save as", and "XHTML" under "export".
(In reply to Regina Henschel from comment #2) > LibreOffice is an HTML editor. The quality is poor, because no one has cared > for it for several years. But nevertheless it exists. No it is not. It is a text document editor, and can generate HTML from text document, but it doesn't qualify as HTML editor (https://en.wikipedia.org/wiki/HTML_editor). > Up to now "save as" has those formats for which import and export filter > exists; "export" has those for which only export exists. Therefore HTML is > correctly under "save as", and "XHTML" under "export". First, it is not like this: e.g., we (correctly) have PDF in Export. Second, the said criteria is of no use from user's PoV. Anything in Save As is a first-class citizen for any user, and users expect a program that "saves as" HTML to be the HTML editor, in the sense that they expect features added and compliance level kept high. As far as there is developers' consensus, we don't aim to support fully-featured HTML editor, so we should not make this impression in users. This distinction is much more important, so *even* if it wasn't like it before, it's not a reason to keep it further.
(In reply to Mike Kaganski from comment #3) > As far as there is developers' consensus, we don't aim to support > fully-featured HTML editor, so we should not make this impression > in users. This distinction is much more important, so *even* > if it wasn't like it before, it's not a reason to keep it further. This sounds kind of weird. There is a caste of developers. And there are all the rest. Anyone who is not a developer (documentation team, localization, support, marketers) can shut up and continue to be a slave servant to they master (developer). Because they not write the code.
(In reply to tagezi from comment #4) This is a wrong point of view. I think not about developers now, but abut users. Let's call us a super-duper HTML editor. Will this do any good to anyone? No unless somebody writes the code. Currently the code is not suited for being an HTML editor, and (what's important) no incentive to change this coming from any developer. In this state current UI is misleading. You can leave it as it is, and let users believe in wrong things. You may take over this area of code, and implement missing bits. But unless there's someone writing the code, no matter how much voting you do, the program won't become any different by some magic. The "Caste" is open, and we welcome anyone to come. So please don't put it like there's some confrontation that there isn't.
(In reply to Mike Kaganski from comment #5) > (In reply to tagezi from comment #4) > You may take over this area of code, and implement missing bits. Does this mean that the project does not need other teams? If everyone writes code, who will localize, test, write a documentation?
(In reply to tagezi from comment #6) This is hilarious. Could you please describe which logical syllogism allows to conclude that from the said? Otherwise I take those words as FUD.
(In reply to Mike Kaganski from comment #7) > (In reply to tagezi from comment #6) > > This is hilarious. Could you please describe which logical syllogism allows > to conclude that from the said? Otherwise I take those words as FUD. In my opinion, everything is obvious. If a person wants to save some kind of functional, they must quit all their businesses and start writing code. For example, I'm writing a guide on LibreOffice, and a message comes that a function is not supported now, because there is no one to write a code for it. In fact, the developers tell me that I should not write documentation, but should only care about my convenience working in app and write code. In fact, the developers explicitly say: "If you are not a developer, you are nobody, and your opinion does not count. We will not support this, but since it is Open Source, you can finish to explain to users how to use app and will join our caste. "
Agree with Mike and Regina regards distinction to be made between what are Export formats and what are Save-as. The distinction here is less an issue of UX and Design and more an issue of ESC and project management. If setting bounds (i.e. making distinctions in what gets first-class effort) helps to focus dev efforts and the QA process it is a good thing. It can go too far, take GIMP XCF for example, but making the distinction helps to constrain project scope. I've long held the subversive view that OOXML should be an Export format, concentrate on ODF and SVG ;-) IMHO citing HTML was just an unfortunate example. The Writer Web module is a WYSIWYG mess held over from HTML 4.0 transitional with no support for inline CSS nor any active content, essentially abandoned in place, with no movement on bug 95861. And the supporting Web wizard was stripped out at 5.4 (bug 99967)--good riddance.
+1 for not being an HTML editor, similar to PDF. Users would miss both. Compromise would be to _export_ to HTML (where we have XHTML and XML right now). PS: needsUXEval needs to get accompanied by CC'ing to ux-advice...
That would mean, you will remove the entire Write/Web module?
(In reply to Regina Henschel from comment #11) > That would mean, you will remove the entire Write/Web module? I don't want to see HTML generated with LibreOffice (or similar tools). (And no, I don't suggest to remove the filters completely.)
(In reply to Heiko Tietze from comment #12) > (In reply to Regina Henschel from comment #11) > > That would mean, you will remove the entire Write/Web module? > > I don't want to see HTML generated with LibreOffice (or similar tools). > (And no, I don't suggest to remove the filters completely.) Yet HTML/XHTML is generated! Multiple methods... But Regina's concern is the functional, if neglected, Writer Web module. It provides a Normal (onto a document page) and a Web (unlimited size) canvas mode, as well as an HTML "source" editing mode--available to adjust content, markup and in line style. It is the default mode for opening a HTM/HTML/XHTML document (even roundtrip). Like it or not we are an HTML editor, we just don't do it well.
We cannot be so 'clear' as GIMP is as users are used to save their documents in different formats also from other office suites. I would say we should only save formats we also can open/import, but then we have to save also PDFs (Bug 103947) instead of export it. As Stuart mentioned, someone has to make a decision what we want to (prominently) save and what is a 'second class's export and import format.
(In reply to Heiko Tietze from comment #10) > +1 for not being an HTML editor, similar to PDF. Users would miss both. > Compromise would be to _export_ to HTML (where we have XHTML and XML right > now). We know that we have users that are really happy with the HTML - for limited functionality of course ;) So I would not make life harder then needed, and leave this as is. @mike: you mention HTML as example. I don't know if there are more?
v7 on Linux (list depends on OS and build) Draw SaveAs: odg, otg, fodg Export: x/html, pdf, svg, various raster formats Impress SaveAs: odp, otp, fodp, uop, various MSO Impress formats (pptx...) Export: x/html, pdf, svg, various raster formats Calc SaveAs: ods,ots,fods,uos, various MSO Excel formats (xlsx...), dbf, html, slk, csv Export: x/html, pdf, xml, jpg, png Writer SaveAs: odt,ott,fodt,uot, various MSO Words formats (docx...), xml, html, rtf, txt Export: xhtml, pdf, epub, jpg, xml, png Math SaveAs: odf, mml Export: - (only Export as PDF) Option 0: Keep as it is under the assumption (expert) users are familiar with the organization. Option 1: We keep only the open document formats in Save/As and move everything else into Export. This has been done for GIMP and it's very annoying (but clear to understand). Option 2: SaveAs holds open document formats and MSO. Meaning html, dbf, slk, csv / rtf, txt / mml get moved into Export. Somewhat confusing in case of Calc since CSV is as important as Excel. Or in case of html when Writer is used as editor. Option 3: We drop Export and keep everything under SaveAs. IIRC the list of supported file formats can become quite large. Option 4: Keep only "lossy" formats under Export. That applies to all raster graphic formats- loading exported data does not allow editing. For Draw html, pdf and svg would go to SaveAs, in case of Calc html and xml, etc. In the end, the function is kind of "Export to Raster Graphic". Option 5: Different menu options with Save As > Open Document | Microsoft Office (another menu entry for other office suites)| Markup Languages (html, xml, svg, mml, csv) | Raster Graphics. Not sure where to put epub and PDF, maybe Markup, but we could drop this format since we have a dedicated command.
Original vision: 1 next 5 (based on MacOS Pages) Directly saving new documents into DOCX/DOC is unadvised and people shouldn't do that. This certainly doesn't work out to well. And having it under Save As suggests kind of full compatibility. However from usability perspective pain in the ass. I even search for PDF export in the save as dialog once in a while So opting for option 3. Ideally I would like some 'Export to' text to file formats where this more an export, compared to 'save' feature. So say: Save as: Rich Text (.rtf) [Export Mode] Or the list being split in sections: - Native * odt * - MSO compabibility * doc * docx - Images * jpg * pdf
+1 for Option 4 or (second class) Option 3, mentioned in comment 16.
Hmm, have to say it is appealing to do Option #1 and follow the GIMP model. Clean and simple--if it is not ODF it is not native! Save-as only ODF. Flip a coin about SVG and CSV (various separators). Sorry OOXML, and MS Binary are really Export formats anyway ;-)
(In reply to Heiko Tietze from comment #16) > Option 0: > Keep as it is under the assumption (expert) users are familiar with the > organization. +0.8 My personal preference, but maybe not the best solution for general public. It has its logic, though. > Option 1: > We keep only the open document formats in Save/As and move everything else > into Export. This has been done for GIMP and it's very annoying (but clear > to understand). Please no D: The GIMP approach bites me in the face every time I use the damn thing. (Even though I understand the rationale.) > Option 2: > SaveAs holds open document formats and MSO. Meaning html, dbf, slk, csv / > rtf, txt / mml get moved into Export. Somewhat confusing in case of Calc > since CSV is as important as Excel. Or in case of html when Writer is used > as editor. Why only MSO? And where to even draw the line after that? E.g. RTF and (especially) CSV are used quite a lot, and presumably expected to be found from "normal" Save dialog. > Option 3: > We drop Export and keep everything under SaveAs. IIRC the list of supported > file formats can become quite large. This would make things worse wrt perceived compatibility/completeness. Also would necessitate some sort of comments or section titles in the list (as Telesto mentioned). > Option 4: > Keep only "lossy" formats under Export. That applies to all raster graphic > formats- loading exported data does not allow editing. For Draw html, pdf > and svg would go to SaveAs, in case of Calc html and xml, etc. In the end, > the function is kind of "Export to Raster Graphic". +0.2 For average (not dumb-) user, I think this makes the most sense out of the discussed options. Although for consistency, I think PDF should stay under Export also in Draw. Also, "lossy" as criterion might be problematic, as e.g. CSV is definitely "lossy" when it comes to formatting :) (Sure, there's a warning...) > Option 5: > Different menu options with Save As > Open Document | Microsoft Office > (another menu entry for other office suites)| Markup Languages (html, xml, > svg, mml, csv) | Raster Graphics. Not sure where to put epub and PDF, maybe > Markup, but we could drop this format since we have a dedicated command. Can all the save/export formats really fit under a single category? Also, it would probably take a user at least two attempts to find where e.g. CSV or RTF or XML is under such a structure (terms like "markup language" probably aren't understood by everyone). (In reply to Telesto from comment #17) > Original vision: 1 next 5 (based on MacOS Pages) > Directly saving new documents into DOCX/DOC is unadvised and people > shouldn't do that. This certainly doesn't work out to well. And having it > under Save As suggests kind of full compatibility. Well, there is a warning when saving as non-ODF...
(In reply to Mihkel Tõnnov from comment #20) > Well, there is a warning when saving as non-ODF... And a checkbox to disable that dialog and people are really forgetful. And export working pretty well 80% of the time, so people obviously start to ignore those.. They highlighting bug mess on of those examples. Or style name mess and plenty of duplicates. Flip-flopping around. Option 4 also fine :-). Never annoyed me However Save as File Format picker should get some warning that docx export doesn't equal a 100% MSO document. Nor LibreOffice being features being 100 transposable to MSO. To page anchoring/to paragraph anchoring/ highlighting as background c. Numerous additional page breaks. They warning still suggesting a full native docx being generated without applying tricks to match docx --- FWIW: Not really seeing they point of Export and Export As though (Writer), can both not be merged somehow?
Not sure if this is the right place, but please consider to arrange save as/ export file format order (even if choose option 4) Say the most used on top and they less used lower. I always have kind of 'search' for they proper filter (no I don't save templates all day. No not interested in transitional DOCX export) Export Slide/Page (Impress/Draw) should export to PNG/or JPG not WMF (and export to includes PDF, which one of the reasons to merge Export and Export As, IMHO) Also maybe add most recently picked. And even more off topic (please include 'versions of' ODT) in save as (different bug, but same area; as i'm slightly inclined to simply list older versions in they drop down (somewhere at the bottom). Instead of picking first odt and next version (adds additional clicks). And as long as the file picker relatively nicely structured.. (of course ends up becoming a long file type option list in the long term, so maybe not feasible)
This is the approach GIMP also uses. I use it on a daily basis, yet, I don't like it. If you want to be absolutely correct then you need to move almost everything from Save to Export. In order to put a certain file format into Save, there must be a 100% exporter and a 100% importer for that format. That is, everything from the document must be able to be saved into that format and everything must be possible to load back as well. Should a file format be in Save or Export if the importer has a known bug, say, it doesn't load back the font spacing correctly? Say, it is planned to be fixed in a future version but in the current version of LO, it is failing. Strictly speaking, it is an Export now because you cannot get this info back. Will you move it to Save when the bug gets fixed? And will you move it back to Export when a new bug turns out? I think this is a very small win for a lot of frustration and a lot of confusion for everybody, who has been using either LO or MS Office for a longer time. Therefore, instead of making this Export vs Save separation, I would display an alert in the Save dialog for the formats that are not even planned to act as a full-featured export-import format. I would keep the Export menu for formats nobody ever wants to import from. Example: PDF. Example: WARNING! This file format may not save all the details of the document. Reloading it may suffer from data loss.
We discussed the topic in the design meeting. There is no clear picture and we have one advocates per option 0, 1, 3 (see comment 16) but three for option 4. That is to provide only "lossy" formats under Export, in particular all raster graphic formats. To be more precise: If a file format is permanent making the plain save operation working on this format it belongs to the save menu. All other formats go to export. I believe that's a description of the current state and no action is needed. What do you think, Mike?
Since I wrote this, I got a bit clearer understanding of how it's implemented (thanks to Kohei). The filters that can *both* import and export are listed under File->Save As. The filters that do not have import functionality (export-only) are listed under File->Export. This makes Save As dialog to only list file types that you can open, edit and save using File->Save (or corresponding toolbar button) without choosing resulting file type (modulo "not a native file type" warning). The quality of both import and export of the respective filter is, indeed, not taken into account by the implementation. So: - there may be some file type that we can import and export using the same filter. It will be in Save As. - there may be a file type that we can import using one filter, and export using a different filter (example: PDF). It will be in Export. - there may be a file type that we can't import, but can export. It will also be in Export. - there may be a file type that we can import, but not export (example: DXF). It will not be in either. I am now OK with the current status (as a developer, seeing a clear picture). *If* there would be user request to change something with this, there could be some procedure: 1. Identify filters that do not offer good enough quality, that UX feels should not be in Save As, but only in Export; 2. Change respective filter's registration into two different filters, one for import, one for export. But as said, not an issue for me anymore. Closing accordingly. UX: feel free to open if needed.