Request: Less Obtrusive Status Updates


#1

This post is about updates that appear in the middle of the thread, on https://phabricator.wikimedia.org/T195728

For example:

Johnywhy renamed this task from Request: Allow passing a MediaWiki parameter in the internal link syntax to Request: Allow passing MediaWiki parameters in the internal link syntax. Sat, May 26, 10:30 PM

Johnywhy updated the task description. (Show Details)

Johnywhy updated the task description. (Show Details)

Johnywhy updated the task description. (Show Details)Sun, May 13, 1:28 AM

Johnywhy updated the task description. (Show Details)Sun, May 13, 1:34 AM

Johnywhy updated the task description. (Show Details)

etc etc etc

These status updates are INCREDIBLY ANNOYING, serve no great function relative how much they interrupt the thread, and make the thread harder to read. Actual comments get buried in the status updates.

I often revise and improve my posts. Edit/Publish/Edit/Publish/repeat is my preferred workflow. That preferred workflow is a benefit for me and readers. It’s a flow that supports continual improvement, and give users access to my latest version.

But, my workflow produces so many status updates, the actual comments get buried. Status updates interrupt the reader’s flow.

@Aklapper commented:

Would you please prepare task description changes locally and once done add them here in one edit, to not create gazillions of “Johnywhy updated the task description. (Show Details)” entries which make the discussion in this task harder to read because of all the required scrolling?"

But it’s not practical to draft my changes offline, because I always want the public version to be the latest and greatest. @AKlapper’s request that i draft changes offline is asking me to change my flow due to a flaw in this user-interface. It’s asking me to endure more effort, and to prevent readers from having access to my latest version, so that they won’t have to see status updates. It’s asking me to not use the technology as it’s designed to be used.

if the purpose is to indicate to reader “did this post change since the last time i viewed the page”, that could be communicated with a simple visual flag. In addition, the timestamp of the last edit could be displayed, with a link to switch to (or expand) the full history. In other words, the same method you use here in this discussion forum:

Putting status updates someplace besides the comment flow doesn’t “obscure” history, anymore than wiki page history is “obscured” by putting it in a separate view (as MediaWiki does), instead of cluttering wikipages with change updates.

Currently, status update messages on Phabricator obscure actual comments. I think it’s an uncommon, and awkward, design for discussion software.

Another alternative is to put them someplace else-- outside the thread.

In the meantime, people can hide those updates by adding the following to your own phabricator css:

.phui-timeline-minor-event, .phui-timeline-spacer{
display:none;
}

I use a google chrome browser extension to apply CSS to phabricator.

If a poster tried to obscure their own changes from other readers, that would be obfuscation. But that’s not what’s being suggested here. If a reader hides other people’s status updates, that is not obfuscation.


#2

Would you want to remove all status updates? or keep some like “Added a revision”?

if you have lots of custom fields it can get annoying to have to scroll through all the changes to see the flow of the conversation.


#3

i would like to keep ALL updates,
and move them ALL out of the reader flow.


#4

This is basically https://secure.phabricator.com/T12963 - it comes up from time to time, but generally the “harder to read” issue isn’t really strong enough to actually merit action - this is more of a “nice to have”.


But it’s not practical to draft my changes offline…

why is that? What’s stopping you from drafting your ticket before publishing? There’s a very handy Task Preview tool for exactly this use-case.

Please stop CC’ing me by quoting my name. Thanks.

Aklapper can now Mute the conversation, which should stop this. Also, since he’d removed himself from the subscribers, it shouldn’t auto-add him on mentions.


#5

What’s stopping you from drafting your ticket before publishing?

I do exactly that. But I sometimes publish many minor edits (maybe just 1 character) , but even minor edits clutter up the feed.

@AKlapper is asking me to save multiple versions locally, without publishing them. Until (I guess) I’ve accumulated a lot of changes, and then publish all at once.

That would be an inconvenience for me, and would deprive readers of my latest version.

But i completely understand his point of view. No offense, but these in-feed status updates suck. A lot. I’ve never seen another discussion feed like it.

It’s distracting, obtrusive clutter.

Cheers!


#6

AKlapper is asking you to make your edit, review your change in the Preview, before submitting, and make all the minor fixes there; He’s not asking you to keep a local copy of the task in a drawer for next week.

And I really don’t understand why you can’t review your change before hitting Publish.


#7

To repeat, I do review before publishing. I make all edits that occur to me when I publish.

Then, some time later, additional edits occur to me.

In any other discussion software I’ve used (including this one), my inclination for continual improvement doesn’t cause ever growing clutter in thread.

It’s not my fault Phabricator turns on a clutter switch. It’s not fair to blame me for Phabricator’s unusual and atypical design, or Phabricator devs unwillingness to refactor.

To repeat again, in case we’re not clear, I preview before publishing. I make all edits that occur to me when I publish.

I promise I’ll try to preview a bit longer before hitting publish. Btw, I added this paragraph after publishing. I didn’t think of it before.

Cheers


#8

I think we found the root of the problem here: Maniphest is not a discussion software. It’s a ticket system.
In a ticket system, it’s important to know what and when changes happen to the ticket, so that comments make sense a year down the road, when someone is looking at it.
In a discussion forum, discussions usually only live for a short while (hours/days) and only relevant to the participants.

It’s not your fault that Phabricator made some design choice; It is your fault that you ignore the behavior of the tools you use.

I’ve seen the case akplapper complained about - you’ve made 29 minor changes in the scope of 4 hours. That doesn’t look like “proper review” was done.

Do this: When you think you’re done editing the task, wait. Get up, walk across the room. Come back, review your change; if you make any changes, repeat.
This is also useful for making sure you don’t post things that may be interpreted in a negative light, and for making sure your post is clear to other readers.


#9

We all recognize the importance of choosing the right color because of those that are color blind, has anyone considered ensuring the tool is friendlier to those who are dyslexic?

I work with a lot of developers who are dyslexic or have dyslexic tendencies (including myself), I think it can come with the territory, those who are not inflicted might not have considered how hard it is for someone who suffers to craft a coherent sentence.

If you do suffer from this, when you write something, no matter how many times you reread it, you will not see the wrong word/grammar, only later for someone to point out the obvious mistake (making you feel like a complete idiot), this can sometimes undermine the message you are trying to deliver.

No amount of review or walking around or getting fresh air is going to make you see the mistake. You see what you want to see, not what is written.

I don’t particularly like seeing my mistakes captured for all eternity front and center so that people say “What is all this chatter on this thread?”, and bringing my inadequacies to everyones attention.

It would be nice if at least the adjacent task description changes could be collapsed (at least within some time delta, or when its the same author), this would at least help to reduce the embarrassment factor (whilst at least partially addressing the request above)

I’m not convinced its about if Phabricator is a discussion client or an audit trail, its about using the system to document the tasks to the highest level of quality, in a clear and coherent way, without trivialities such as spelling mistakes, grammar or incorrect tense getting in the way.

Having the ability to optionally edit your latest response is a great feature for any tool.

Just my 2 cents on looking at this request from another perspective


#10

Just my 2 cents:

I think it is really important to see as easily as possible to which version of the task description/title the comments on the comment feed are related to. For keeping a proper “audit trail” as mydeveloperday mentioned in their comment. Hiding edits to the description opens big possibilities for mistakes for no other apparent reason than slightly cluttering the feed (which I personally don’t see as a problem at all, since the updates about edits look different from actual comments and are thus very easy to ignore).


#11

“It’s not a discussion forum”

– but it is a discussion thread. You yourself refer to it as a “discussion”.

In a discussion forum, discussions usually only live for a short while (hours/days)

– We live in a different universe. Hours/days? There are many threads in the world which remain relevant for years/decades.

“updates about edits look different”

Regardless, in a sea of status updates, one is forced to scroll around, visually scanning for comments buried amidst the status updates. That’s an inconvenient, error prone user experience. If this wasn’t a problem for some people, we wouldn’t be talking about it.

Seems like status updates seem might be intended to protect this resource from nefarious and dastardly deeds. To broadcast “see, caught ya, you changed what you wrote!” It doesn’t seem particularly necessary to put such updates in the primary reader-flow. If one click gives readers the whole history, its job is done.

“important to see as easily as possible to which version of the task description/title the comments on the comment feed are related to”

Can you share an example of that? Seems that if the OP improves the task description based on comments, then the comments have done their job. I’m not arguing against an audit trail, only to more it out of the main reading-flow. I believe reviewing the audit trail is likely not going to be the usual, day-to-day activity.


#12

Seems to me, the purpose of a Task description is as a seed. It’s the seed for a development effort. So, it should be well-written, to ensure it provides a strong, clear description of the problem and proposed solution if any. The first published-version is not likely to be the best version. Therefore, continual improvement via document-editing should be encouraged and enabled.

MediaWiki.org is, I believe, both customer and sponsor of Phabricator. MediaWiki.org makes wikis. The whole point of wiki is to encourage and enable continual improvement via document-editing.

Yet Phabricator gives a negative consequence to continual improvement via document-editing.


#13

I think this discussion has outlived its usefulness. There’s an upstream ticket for this issue in https://secure.phabricator.com/T12963, which covers basically everything that is mentioned here.
The way I see it, this discussion is now about “should this be a med-pri or low-pri in the upstream”, when we know that upstream doesn’t get to things that are much lower than “unbreak-now-pri”.

The ways forward here are:

  1. A Phacility customer can put their Mana points towards the ticket, raising its priority,
  2. Someone can try coordinating directly with Phacility to contribute this code, or
  3. Wikimedia can try to implement this on their fork, if they feel inclined.

#14

He reports that you are incorrect about this.
https://phabricator.wikimedia.org/T195728#4248365


#15

re: mute: From https://secure.phabricator.com/T13068, it looks like “Muting is stronger than mentions”, so it should work, although the UX is problematic.

From your link, it looks like unsubscribing is not stronger than re-mention: "@mentioning a user in a new comment will re-add them. I think this is expected/desirable: you’re explicitly calling them back to the task."


#16

Person should have option to say “don’t call me back”, somehow.