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".
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.