I would like to suggest removing the work summary from the implementation page (and consider removing it also from all the other pages) for the following reasons:

• This solution is symptomatic of a desktop-first approach, where we assume that people can consume different content side-by-side, but this is not the case for mobile devices.
• We display the exact or similar content with a slightly different layout, but this is a scenario where redundancy is not necessary, it can actually be potentially distracting. During a usability study in Bangla (on the function definition page) users noticed the work summary, probably due to its prominent position and background color, but did not notice the “Add labels in another language” button, or from the same study most of the participants did not notice the “Publish” and “Cancel” buttons.
• The different (visual) layout does not considerably improve the understanding of said content.
• During the same usability study, users understood the content of the work summary, but “most of the participants did not notice the live preview of the work progress”. Maintaining such live preview functionality might be not the right investment at this time.

My recommendation would be to explore how we can make the existing content more visually rich, in order to improve discoverability and accessibility, without the need to add a new section on the side of the page. This approach can provide the same rich experience no matter the device, and can bring more attention to existing features such as the add labels in another language or the publishing workflow.

I agree with all points stated by Amin.

Additionally, the component Work Summary, apart from not really providing any significant benefit to the user, is technically flawed:

• The Work Summary was built under the assumption that it would only be used in the context of the FunctionEditor, where the root zobject contained in the global state is a Function Definition/Z8 object.
• Later, this Work Summary component was added into a ZPersistentObject page, where the user would be creating a new implementation, but the way that the Work Summary grabs the data wasn't reworked. So it continued to assume that the root ZObject was a Function/Z8, in a page where the root zobject was an Implementation/Z14
• This caused an obvious accumulation of bugs which were patched and hacked but the underlying data model has not been appropriately fixed to account for both cases.
• The consequence is that the behavior is highly unstable and unpredictable. For example, this is the Work Summary representing the same function in two different pages

The Work Summary would require a total rework to fix the way it access the state and gathers the necessary data, but considering Amin's arguments, I strongly believe that it is not worth the effort and we would benefit from completely removing this component, as currently it gives no benefit but it takes time and focus from the team.

My recommendation is to remove this component and focus on the crucial elements for function definition and implementation creation. Once that's done, consider the possibility of adding informational components if they are needed.

Closing this due to the decision made and implemented: https://phabricator.wikimedia.org/T321161