Bug 116703 - Make clear distinction on differences between "Export" and "Save As", and move items in those filters accordingly
Summary: Make clear distinction on differences between "Export" and "Save As", and mov...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Main-Menu UX
  Show dependency treegraph
 
Reported: 2018-03-30 07:46 UTC by Mike Kaganski
Modified: 2018-09-27 21:03 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2018-03-30 07:46:01 UTC
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".
Comment 1 m.a.riosv 2018-03-30 10:01:05 UTC
+1
Comment 2 Regina Henschel 2018-03-30 12:39:34 UTC
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".
Comment 3 Mike Kaganski 2018-03-30 12:48:11 UTC
(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.
Comment 4 tagezi 2018-03-30 13:43:10 UTC
(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.
Comment 5 Mike Kaganski 2018-03-30 14:57:49 UTC
(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.
Comment 6 tagezi 2018-03-30 15:05:04 UTC Comment hidden (off-topic)
Comment 7 Mike Kaganski 2018-03-30 15:17:47 UTC Comment hidden (off-topic)
Comment 8 tagezi 2018-03-30 15:35:21 UTC Comment hidden (off-topic)
Comment 9 V Stuart Foote 2018-03-31 05:29:43 UTC
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.
Comment 10 Heiko Tietze 2018-04-04 15:03:02 UTC
+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...
Comment 11 Regina Henschel 2018-04-04 15:16:44 UTC Comment hidden (obsolete)
Comment 12 Heiko Tietze 2018-04-04 15:24:44 UTC
(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.)
Comment 13 V Stuart Foote 2018-04-04 16:10:44 UTC
(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.
Comment 14 Thomas Lendo 2018-04-04 19:37:43 UTC
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.