Page MenuHomePhabricator

Allow collapsing and uncollapsing not changed text blocks (js version) (No. 4)
Closed, ResolvedPublic5 Story Points

Description

Motivation
Unchanged text is usually not that interesting during an edit conflict, but people should still be able to view and edit that if they want. This ticket is about the ability to expand and collapse these text blocks as needed.

Acceptance Criteria

  • By default, all unchanged text blocks are collapsed
  • If you click on the arrow, the corresponding text block expands
  • If you click on the arrow of an expanded text block, it collapses
  • If you click on the edit button in collapsed view, the text block expands and goes into edit mode.
  • If you are in editing mode of the respective text block, you cannot collapse the text block.
  • If you click the check mark after editing, the text box stays expanded
  • The text that is shown in the collapsed view, should be the same as in the current edit conflict ("start text .. middle .... end text")

Mock collapsed view

Mock expanded view after clicking on edit


(the arrow is grayed out(same color as the grayed out edit icons when the other version is selected) because to communicate that the box can't be collapsed when in edit mode)

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Lea_WMDE triaged this task as Normal priority.Jul 5 2018, 8:41 AM
Lea_WMDE updated the task description. (Show Details)
Lea_WMDE renamed this task from Make unchanged text editable (No. 4) to Allow collapsing and uncollapsing not changed text blocks (js version) (No. 4).Jul 5 2018, 8:47 AM
Lea_WMDE updated the task description. (Show Details)
WMDE-Fisch set the point value for this task to 5.Jul 5 2018, 8:49 AM

Sanity note: When working on this before implementing the JS edit the following points should be part of T195721

If you click on the edit button in collapsed view, the text block expands and goes into edit mode.
If you are in editing mode of the respective text block, you cannot collapse the text block.
If you click the check mark after editing, the text box stays expanded

Change 454569 had a related patch set uploaded (by Andrew-WMDE; owner: Andrew-WMDE):
[mediawiki/extensions/TwoColConflict@master] [WIP] Allow collapsing and expanding unchanged text blocks

https://gerrit.wikimedia.org/r/454569

Andrew-WMDE updated the task description. (Show Details)Aug 22 2018, 3:07 PM
thiemowmde changed the task status from Open to Stalled.Aug 29 2018, 9:42 AM
thiemowmde added a subscriber: thiemowmde.

The acceptance criteria in this user story are blocked on T195721: Support JS enhanced editing on the merge view (No. 7) being resolved first. We accidentally put this story into the backlog of WMDE-QWERTY-Sprint-2018-08-14, but forgot about the dependency. Sorry.

thiemowmde removed Andrew-WMDE as the assignee of this task.Aug 29 2018, 9:42 AM
thiemowmde added a subscriber: Andrew-WMDE.

Mock expanded view after clicking on edit

Just to be sure, shouldn't the greyed out arrow in this mock be facing up? @Hanna_Petruschat_WMDE

Yes, it should. It is greyed out in in this mock because the box is in edit mode. Still, thanks for your eagle eye.

@Hanna_Petruschat_WMDE, please correct me if I'm wrong, but if I remember correctly the style guide asks us to not flip such expand/collapse arrows any more. See T187099#4015542 and T190147 from the Advanced-Search project.

@Volker_E, is this behavior written down somewhere in our style guide documents?

I'm a little uncertain. On one hand I totally agree to keep the patterns from other widgets for the sake on consistency. nd for now we can go with this behavior.
BUT: This is a very different use case compared to the other ones we see in the linked tickets (Thanks Thiemo for gathering them and linking them here!) In this case the arrow is at the bottom of the field and will stay there when the box expanded. I would find it very confusing to click the arrow, scroll to the end of the box and see the arrow facing down again, now having the feeling there is still more to see. Clicking the arrow again would then collapse the box? Keeping the arrow in one direction is a common bahvior if the arrow itself is part of a header section and in the best case being made visible as active. This use case here is as explained above a slightly different one.

This discussion should probably take part in a seperate ticket to not distract from the actual task here. But I'd be interested to see what you think of that @Volker_E.

I would find it very confusing to […] scroll to the end […] and see the arrow facing down again, now having the feeling there is still more to see.

This is indeed a very relevant difference. I missed that. Thanks!

Andrew-WMDE changed the task status from Stalled to Open.Oct 4 2018, 2:13 PM
Andrew-WMDE claimed this task.
Andrew-WMDE moved this task from Sprint Backlog to Doing on the WMDE-QWERTY-Sprint-2018-09-25 board.

This task went missing initially after being stalled, but can once again be worked on since T195721 is nearly completed

Change 454569 abandoned by Andrew-WMDE:
[WIP] Allow collapsing and expanding unchanged text blocks

https://gerrit.wikimedia.org/r/454569

Change 464600 had a related patch set uploaded (by Andrew-WMDE; owner: Andrew-WMDE):
[mediawiki/extensions/TwoColConflict@master] [WIP] Allow collapsing and expanding unchanged text blocks

https://gerrit.wikimedia.org/r/464600

If you click the check mark after editing, the text box stays expanded

One question to that ( I think we talked about this, but I want to have the answer written down here and can't remember it exactly ):

  • We have per-generated "intelligent"(1) php-side generation of the collapsed text blocks.
  • So this is not available for the JS stuff.
  • If someone changes a "unchanged" paragraph and saves this change, the per-generated collapsed block might not be valid anymore.
  • Do we therefore disallow collapsing for that paragraph once the user changed it?
    • This could be re-allowed again, when the user resets the paragraph to the initial text.

Alternative:

  • Implement "intelligent" text block collapse generation on JS side

(1)

  • We take the first line of the paragraph and cut it after the last full word that's closest to a set limit.
  • We do the same with the last line only that we cut at the beginning and have an ending close to the limit.
  • We add an optional eclipse to the cut of parts and put them under each other.
  • If the text is below a set limit this whole thing will be skipped and the text will be posted as it is.

@Lea_WMDE

Oj great observation @WMDE-Fisch :) . What is the current behavior we have with pure php? If something is changed there, are the changes propagated to the collapsed preview? And do I understand it right that we cannot just call the method that is doing this again when we close a paragraph, when js is enabled?
We definitely don't want to forbid the closing of the paragraph. For now I suggest with keeping the potentially wrong summary (which would always show the updated version when expanded again), until I talked with WMDE-Design about it (or it turns out we can easily call the php method from js)

Oj great observation @WMDE-Fisch :) . What is the current behavior we have with pure php? If something is changed there, are the changes propagated to the collapsed preview?

PHP is only executed when the page is first initialized. There the content of the collapsed text is build. After that PHP is only called for saving the page. But that's unrelated to the feature here. The collapsed text has no role there, it's just a visual thing.

And do I understand it right that we cannot just call the method that is doing this again when we close a paragraph, when js is enabled?

Yes we cannot use it just like that from JS. To call the PHP "collapsed text generator" we would need to expose its feature to some API somewhere. But it would be easier to implement its functionality in JS.

We definitely don't want to forbid the closing of the paragraph. For now I suggest with keeping the potentially wrong summary (which would always show the updated version when expanded again), until I talked with WMDE-Design about it (or it turns out we can easily call the php method from js).

Affirmative. :-)

P.S.: My rough estimate for implementing the PHP collapse generator into JS would probably be something around 5 - 8 points depending on the further integration. One could argue, that we could get rid of the PHP implementation then because collapsing is for JS only anyway, but the PHP version has the advantage of being rendered right away.

Possible issues I see with the current collapsing algorithm:

  • Why are the lines cut off so early? There is plenty of room (depending on the window size). I would like to see more text.
  • The cut-off point does not dynamically respond to the browser in any way (window size, font size, zoom). This is a pity.
  • Why is the last line not right-aligned?
  • The three dots appear like they are part of the text. It's hard, sometimes impossible to tell the difference.
  • Shouldn't there be a space separating the dots from the text?

Here is a quick draft, done in pure CSS via Firefox' debug console:

Storytime resulted in selecting the second option (fading out)

Change 467726 had a related patch set uploaded (by WMDE-Fisch; owner: WMDE-Fisch):
[mediawiki/extensions/TwoColConflict@master] Allow fade-collapsing and expanding unchanged text blocks

https://gerrit.wikimedia.org/r/467726

Change 464600 abandoned by WMDE-Fisch:
Allow collapsing and expanding unchanged text blocks

Reason:
Abandoned in favor of If271eb28c1b97bfd137f5deb7b766cbd0cee2241

https://gerrit.wikimedia.org/r/464600

Change 467904 had a related patch set uploaded (by WMDE-Fisch; owner: WMDE-Fisch):
[mediawiki/extensions/TwoColConflict@master] Add browser tests for fading collapsed paragraphs

https://gerrit.wikimedia.org/r/467904

Change 467963 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/TwoColConflict@master] Streamline fade-out effect CSS on collapsed text blocks

https://gerrit.wikimedia.org/r/467963

Change 467726 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Allow fade-collapsing and expanding unchanged text blocks

https://gerrit.wikimedia.org/r/467726

Change 467904 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Add browser tests for fading collapsed paragraphs

https://gerrit.wikimedia.org/r/467904

Change 467963 merged by WMDE-Fisch:
[mediawiki/extensions/TwoColConflict@master] Streamline fade-out effect CSS on collapsed text blocks

https://gerrit.wikimedia.org/r/467963

Lea_WMDE closed this task as Resolved.Oct 22 2018, 9:49 AM
Lea_WMDE moved this task from Demo to Done on the WMDE-QWERTY-Sprint-2018-10-09 board.