Bug 133857 - Rename Remove to Merge and introduce a real Remove function
Summary: Rename Remove to Merge and introduce a real Remove function
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.8.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Section
  Show dependency treegraph
 
Reported: 2020-06-10 11:27 UTC by peter josvai
Modified: 2024-06-15 03:17 UTC (History)
2 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 peter josvai 2020-06-10 11:27:06 UTC
Description:
you have inserted a document through Insert / Section / link...

and want to remove it...
now, hitting the remove button doesn't do what the button says...
doesn't remove it, but instead converts it into normal text...
this is, doubtlessly, a major bias...

imagine your text... a book of some 150 pages..
of which 25 pages are embedded using a file, another document 

(you'll choose to work on small documents for various reasons...
one of them being that your netbook is not that powerful to offer a smooth operation eve at the document length over 100 pages
OR
because you like to edit sections separately...
say, there are several contributing authors, and several short stories or essays, whatever, the point being: different stories, different editing sessions)

now, you want to remove a section? you simply can't

and I'm certain that most users / writers / editors will hit "remove"...
cause they'll believe they know what remove means in that context :)

and then...
they'll have 25 pages of text there... with no borders... and no option to remove, other than making a 25 pages long "select" and hitting delete...
which, as a risky thing, is not the favorite of any editor..

.........
this is why a remove section should be there..
and a convert to normal text, or "adopt" as normal text, whatever the name, only it should be human readable :)




Steps to Reproduce:
1. Insert -> Section / as link
2. try to remove it
3.

Actual Results:
you can't

Expected Results:
you should be able to press "remove", and the section should be removed


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.2.8.2
Build ID: 1:6.2.8~rc2-0ubuntu0.16.04.1
CPU threads: 2; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: hu-HU (hu_HU.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 Roman Kuznetsov 2020-06-10 14:42:34 UTC
I confirm that behavior in

Version: 7.0.0.0.beta1+ (x64)
Build ID: c46a704943be830d603ba0421a329ccb58b8b209
Потоков ЦП: 4; ОС: Windows 10.0 Build 18362; Отрисовка ИП: Skia/растр; VCL: win
Locale: ru-RU (ru_RU); ИП: ru-RU
Calc: threaded

but I don't know it's a bug or not.

UX team, what do you think about it? 
Should button "Remove" remove only section but don't delete a text from section as it's now?
Or "Remove" button should delete a section with all its content?
Comment 2 Jean-Francois Nifenecker 2020-06-10 17:21:24 UTC
I would like the underlying data to be removed when I ask for section removal.

I guess this is just a question of vocabulary/language. Removing a section is just that: removing
Comment 3 Jean-Francois Nifenecker 2020-06-10 17:24:24 UTC
(In reply to Jean-Francois Nifenecker from comment #2)
> I would like the underlying data to be removed when I ask for section
> removal.
> 
> I guess this is just a question of vocabulary/language. Removing a section
> is just that: removing

Gosh, I hit a button with a bad keystroke...

I guess this is just a question of vocabulary/language. Removing a section is just that: removing a section, NOT the data.
Perhaps another option is due: removing a section AND its data?

Otherwise, I strongly oppose to data loss the OP asks for without the user being aware of it.
Comment 4 Heiko Tietze 2020-06-10 18:00:39 UTC
How about Remove (delete; to be introduced) and Merge (current remove)?
Comment 5 peter josvai 2020-06-11 06:03:02 UTC
(In reply to Heiko Tietze from comment #4)
> How about Remove (delete; to be introduced) and Merge (current remove)?

this would be great... 

"merge" is much better than "convert to normal text", to start with...

and "delete" is also great, however, "remove" would be better in my opinion...
(I'll explain in my next comment)
Comment 6 peter josvai 2020-06-11 06:33:26 UTC
(In reply to Jean-Francois Nifenecker from comment #3)
> (In reply to Jean-Francois Nifenecker from comment #2)
> > I would like the underlying data to be removed when I ask for section
> > removal.
> > 
> > I guess this is just a question of vocabulary/language. Removing a section
> > is just that: removing
> 
> Gosh, I hit a button with a bad keystroke...
> 
> I guess this is just a question of vocabulary/language. Removing a section
> is just that: removing a section, NOT the data.
> Perhaps another option is due: removing a section AND its data?
> 
> Otherwise, I strongly oppose to data loss the OP asks for without the user
> being aware of it.

hi, 

I believe it is not about vocabulary, but operation...
I mean, there is something the user wants to do, she or he looks for an operation
which a functionality will perform...

now, when inserting a section by LINKING a document...
what rises as a need in the user's head is to get what has been placed there OFF...

bear in mind that it is inserted by LINKING, so, removing will not suggest
the deletion of the original document in any circumstance

to satisfy our linguistic ambitions :)
when we insert a section, two things happen in a sequence...
#1 a section is being created
#2 a document is being linked "into" that section ... 

so when we say remove, to think of removing the inserted text comes naturally :)

REMOVE / DELETE / UNLINK are synonyms... as we know

when "delete" is used in this context as a title of the "button", one might think of the deletion of a text... 
however, that would be stupid on that user's part, cause the text is LINKED into the document... she or he linked it... not to mention leaving the "protect" checkbox checked, too...
moreover, today's computers use recycle bins, so deleting something is not as big a thing as it is in a Linux environment, when "rem" will delete stuff for good :) 

anyway, whoever thinks that removing a link will cause deleting what's been linked, is just overanxious... but will learn fast


PS:
my other argument would be that a section means a container and its content...
when someone sees a section and a button next to it: "remove"
she or he will very intuitively think that pressing that button will make 
that section disappear..
it is not linguistics, it is logic, that of the workflow...

the other option, which the user would expect, could be: "remove linking only" ("merge" linked text into the document)  
(merge sounds very good! part of it because "merge" is a verb which computer users in general are pretty familiar with)


PS 2:
another argument could be that one sees a paragraph...
and there is a button next to it "remove"...
what the user will expect to happen in the case of hitting that button is
that the text disappears...
NOT that the text becomes merged to the previous and following paragraphs...

PS 3:
since the document is linked, the chances that any user will think that removing the section will delete the linked document, I'd expect to be less than 1%


sorry for the length
Comment 7 Heiko Tietze 2020-06-14 11:55:06 UTC
So let's change the current "Remove" into "Merge" and add a real "Remove" with a tooltip "Remove the linked document here but keep the original file untouched", or the like.
Comment 8 QA Administrators 2022-06-15 03:41:14 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2024-06-15 03:17:49 UTC
Dear peter josvai,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug