Silly question: is this a button? If so, what happens when a user clicks it?

Currently, it's a banner with two links - the first to the edit history page and the second to the user page for the last editor. For this task, I would say let's present the content as static. We can then go back and add the links once we have the opt-in flow settled (which should live in a different epic). Does this make sense? Or should we get the flow settled before starting work on this.

Sorry, but I don't quite follow what this has to do with the opt-in flow. Keeping them static sounds fine for Q2. I just wanted to understand if the user will be booted out of Marvin when they click the links or if we won't enable them until we support edit history and user namespace pages.

In T176980#3657019, @Niedzielski wrote:

Sorry, but I don't quite follow what this has to do with the opt-in flow. Keeping them static sounds fine for Q2. I just wanted to understand if the user will be booted out of Marvin when they click the links or if we won't enable them until we support edit history and user namespace pages.

:) this is what I was referring as well. I think we'll probably do the latter - boot user out of Marvin and show a modal that says "this functionality isn't available on this experience" or something of the sort. This is the portion that I was saying depends on the opt-in flow - we'll have to make sure the out-in and back to mobilefrontend experiences are consistent, that users aren't confused by the messaging, etc.

@ovasileva

Our last edited bar has 2 major issues

• looks like one editor is responsible for writing the entire article. the last editor might have just fixed a typo.
• it truncates most of the time because it's not structured. it's just a string.

Both of them are design issues, we're not going to solve these issues with Marvin as we promised, because we don't want to change the design.
what we can do though is show the same/similar information in a better manner so when in the future we want to fix these issues, it's easier. basically setting up for future.

we can do that by

1. splitting the same data in a structured manner.

splitting will give us mroe control in the future to replace this data with better data or hide/show based on our requirement

2. the truncation problem is easy to solve on interface level. splitting will solve that to.

Here's what I mean

Treatment 1

Here we display same information

1. last edited
2. last editor
3. Bonus: number of total edits

in a structured manner. that way, we can take off any of these cells, or add cells like this. Modular :)

Treatment 2
Just solve the truncation problem

This is very similar to what we already have but just making sure the entire string is split into pieces so it doesn't truncate.

Developer note
None of these are interactive, nothng will happen if someone taps on it

@ovasileva Let me know which treatment, and what degree of change is acceptable and I will flesh out the desktop version and add the spec to the description.

I think adding total edits is a good idea - let's go with that one.

I don't mean to bikeshed but should we put the total edits cell _above_ the last editor cell? This will make it clear that the context of total edits is still the article and not the editor.

I don't mean to bikeshed but should we put the total edits cell _above_ the last editor cell? This will make it clear that the context of total edits is still the article and not the editor.

good point, will fix that when I flesh it out.

In T176980#3661349, @Nirzar wrote:

I don't mean to bikeshed but should we put the total edits cell _above_ the last editor cell? This will make it clear that the context of total edits is still the article and not the editor.

good point, will fix that when I flesh it out.

I'm okay with this, but I think it is a bit strange logically - now we will have:

• last edited (closer to present)
• total edits
• last editor (closer to present)

Not a big deal either way, just seems a bit strange to me.

I see your point. Hm, total edits does increase for each new edit so in a sense it's also close to present but if that doesn't work, how about:

• total edits
• last edited
• last editor

here's a revised version

I'm not sure, here it feels almost like too much information. I think we should display either number of editors or number of edits. I preferred the first layout personally - up to Nirzar though.

@Nirzar, if the answer is no, this task will be ready to work on. If the answer is yes, please update the mock.

Here's updated mocks after reviewing with Olga

same data points but different treatment.

we need

• updated x duration ago
• last edited username
• total edits
• total editors

@Nirzar, looks great! Please update the description with the screenshots and specifics!