Actions for Trevor

• Write list of potential filters
• Research different diffs
• Write a comment here about direction

Here's my Product Manager 👨🏻‍💻 direction for this third round of wireframes.

Reduce whitespace — We've received several comments about the amount of whitespace in the tool. Some of this is because of the two-column nature, both some is from how the wireframe is designed. We can tighten it up but avoid cognitive overload. The date column can be eliminated (a user suggested it appear like it does in iMessage, which I think is an idea worth pursuing) and the 'edit boxes' can be expanded horizontally. You should even explore putting the timestamps inside the editbox or making them visually less important.

Making the 'edit boxes' more space efficient — The 'edit boxes' are the different UI elements (currently light blue and light green) that contain the page and section edited, edit summary, and link to the diff. Each edit box will contain the same information, and the words "edited the section" or "edited" will become redundant. One user suggested using the § symbol and eliminating the redundant text, like such:

Surfacing the diffs in-line — After I complete T179044: Looking at different Diffs I'll have more direction for you on this topic.

Building filters UI — At the top of the timeline, please wire up the 5 required parameters: Username 1, Username 2, Wiki, Start Date, End Date. Also add these optional filters (which we may or may not build, but we need a way to represent them in the wireframe.) These can be hidden under a 'Filters' dropdown (like YouTube) or always visible.

• Show 'Thanks' activity (ticbox)
• Show @Mentions (ticbox)
• Show cross-wiki activity (ticbox)
• Mark edits that tripped an Edit filter (ticbox)
• Suppress these pages (text field with 'pills' like such.)
• Suppress these namespaces (text field with 'pills')
• Open diffs: (drowdown)
  • In-line, one column
  • In-line, two column
  • In a new tab

Happy to clarify anything that is ambiguous or confusing. I'm excited to see your work!

I've completed comparing the different diffs available to us. You can find my write-up and some examples at this meta page.

For now, I think we should explore both the one-column and two-column wikitext diffs. My hypothesis is that most users will prefer the two-column for article edits and the one-column diff may be easier to read for talk page edits.

Hi all!
Here are updated wires that have incorporated Community feedback. For example, we've reduced the white space in all of the wires. Two of the wires are variations of the same one, one without a gray background and less divisions between dates and one with the gray background and boxes to show the difference between dates.

We've also included samples of what different kinds of styled diffs could look like. Please leave your feedback!

Looking good. We won't need to pursue the "Edit conflict" diff idea on page 5 of your PDF. It's not really applicable to all of these types of interactions.

Moving forward, we should a different diff for page 5, as it includes a real username.

@CSindersWMF I like that each revision is less verbose! :)

@CSindersWMF Right now the colors are for the users (i.e. the left is always one color and the right is always another). Would it make more sense if the colors had some other semantic meaning? For instance, they could be yellow if they deleted more than they added, and blue if they added more than they deleted? I could also adjust the shade based on the amount difference (i.e. all adding would be darkest blue).

I don't know if this is a good idea, it just came to me and I thought I'd share. :)

@dbarratt meow! i would say no to colors for semantic meaning just bc sentiment analysis can be so wrong and also more colors = more complexities for users to figure out.

i vote we just have one color for one user, and another color for another. i'll find some colors that work for accessibility/visibility across browsers.

I agree with Caroline that multiple colors will make it harder to read the timeline. Let's just use colors to reinforce that the edits on the different side of the vertical line are from different users.

As for semantic meaning — I think there's potentially some room to indicate individual comments that may be toxic as judged by their contents or if they triggered an AbuseFilter. I also think we'll need to include visual indications of byte change, if the action was a revert, if the page was marked for deletion, etc. Both of these ideas (and others) are on the design prioritzation.

@TBolliger so i'm adding this as information to the top box that summarizes the users:

— Edit count in specified date range
— Total of interactions between users
— Total number of pages where both users have edited
— Link to XTools ‘Edit Counter’

Now that we're working off the shared prioritized list in T179607: Interaction Timeline V1 we don't need to worry about the filters at this point.

We don't need specific wireframes for error messages or loading indicator if you can share written guidance or examples of existing design patterns to use.

The 'Interaction Summary' box should include the 4 things in your previous comment. The link to X-Tools will point to a page like this.

We'll talk byte changes and minor edits on Monday.

🤘 🎸 ⚡️

Error messages to support:

• Zero usernames provided
• Only one username provided
• Wiki not provided
• No edits to show during selected date range
• No edits to show because the two users have never interacted
• General timeout/failure
• Invalid date range (e.g. start date is 2017 while end date is 2016)

create one new wireframe (will ask for some design guidance from @Nirzar)

• Represent byte changes and minor edits
• Grouping multiple successive edits by the same user
• Wikitext export

and also have a visual audit (again with @Nirzar on the current prototype)

Hi all!

Here's an example of an error message, we could use the 'quick alert' from this page:
https://doc.wikimedia.org/oojs-ui/master/demos/?page=dialogs&theme=wikimediaui&direction=ltr&platform=desktop

According to Nirzar, the loading indicator is pretty 'standard', like a regular spinner.
But here's the progress loading bar:
https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.ProgressBarWidget

Sounds good, we'll use the standard loading indicator. I'll update the tickets.

I don't agree with using an alert dialog for every error message, as we don't have a 'submit' button. Some of the error messages could be triggered if the user is too slow in adjusting their query (e.g. only provides one username). There's a similar discussion on T180083 that has some other ideas.

Note to ticket followers. Caroline and I have moved the conversation about error messages to T180083

Here's some quick documentation for minor edits and byte changes. You can view both byte changes and minor edits on the Donald Duck history page.

Minor edits

Only some edits are marked as minor. Users can optionally mark their own edits as minor if they've made a small change not important enough to be reviewed by another editor. Users can easily lie about making minor edits, so we will just want to display an indication on each edit box.

In existing tools (like page history and Recent Changes) this piece of data is shown with a bold m displaying in the log entry. In this screenshot of three edits, only the middle edit is marked as minor.

Byte change

There is a byte change to every edit. Byte change is an indication if an edit added/removed a lot/little content. If the user added characters, the byte change is represented in green as (+N). If the user removed characters, the byte change is represented in red as (-N). If the byte change was the same before and after the edit, it is represented as a grey (0). If the byte change is over 500 (either added or removed) the byte change is displayed in bold. This screenshot shows all 5 varieties:

We do not need to display the total byte count — just the change.

My recommendation

Users already understand the bold m and grey/red/green byte change designs. Let's re-use them, but tuck them somewhere innocent in each edit box.

Please either resolve this task, or associate an active project tag to it - thanks! :)

In T179032#3775200, @TBolliger wrote:

This is a tracking ticket and will move from AHT sprint to sprint.

I don't think that's SCRUM. :P

• Information density wires by EOD today
• header, byte, userlinks, and stickied by EOW
• 2-hour whiteboard meeting this Friday for 'successive edits by same user'

From a whiteboarding session with @CSindersWMF about T181566: Interaction Timeline: Bundle multiple successive edits to the same by the same user

Idea #1 would have two states — collapsed and uncollapsed, with the toggle outside the edit cards. When collapsed, the card displays the number of edits and the page name, but not the edit summaries. Clicking on the edit card opens the combined diff of all three edits. We need to decide a default state (collapsed vs. uncollapsed) and could potentially provide users with the option/filter for the default state.

Idea #2 would also have two states — collapsed and uncollapsed. The default behavior is collapsed and the card displays the number of edits and the page name, but not the edit summaries. The link to uncollapse lives inside the edit card. Clicking the link uncollapses the edits, clicking the rest of the card opens the combined diff. We could potentially provide users with the option/filter for the default state.

We'll still need to decide if this covers Use Case #3. I think there's a strong case to be made either way and regardless I do not think Use Case #3 needs its own design.

First draft of Bundling wires — EOD Dec 13.

Hi all, added some bundlesssss.

This is very much a work in progress, still working on these for the new year. But what are your thoughts about how we are grouping information?

The screenshot shows which wires are related (one is the collapsed, and then the corresponding expanded wires).