From proposal page, I donāt understand the functionality of āDocumented byā
Does it matter who the author and when specifically that page was created if multiple people review, edit, copy, update it?
Does that mean it will collect all the users who not only changed the page, but read it? To me, this is a bit misleading and resembles the collection of statistics of visits and changes to the page.
I think the idea is to list all the authors of the page from the history (so show all the contributors of the page instead of last version author).
Itās not a bad idea, now it might be a bit expensive since itās not an information we have in the current document, it would definitely have too much impact on the page view unless itās asynchronous.
As @tmortagne said, I was only referring to those who modified the page in some way. I can understand the term review have be a bit misleading, will take it out.
These two sentences contradict themselves.
How do they contradict?
āall the people that modified the pageā includes ālast people that modified the pageā
I wrote in the proposal why we shouldnāt showcase all of them (because there may be too many)
Let me know if you were referring to something else
Just a note: from a collaboration point of view it doesnāt but knowing the creator of a page is a very useful information in XWiki when developing. But I opened recently an improvment ticket to have all current authors information of a document directly in the information tab: Loading... so the creator information wouldnāt be lost if this is implemented.
Iām +1 for the general idea.
Some remarks:
In general, this looks nice. As noted by others, these are several improvements that should be considered separately.
Maybe Iām looking too much at this as a simple (non-advanced) user.
So here it is ā¦
When I see the word Documented by, it first conveys to mind the work on the document. In other words, each user can commit any actions on the document based on the permissions granted.
Review refers not to a document but to actions on an article or a review. As far as Iām concerned, it overlaps with the Blog application (which Iāll mention here more than once).
There are no questions regarding visualization. The question is small in functionality and binding. For example, if the point is to display the last 5 unique authors, then this duplicates the History tab, which provides more information (ideally when a summary is also specified). Letās assume a situation where this tab is disabled visually, and the URL processing file is configured to block access. Then, it will be nothing but a Blog where only the owner or a specific group will have all the information. Ordinary visitors/readers will see Documented by. This could be an improvement or a new feature to the existing Blog application.
The very last word Documented by is confusing because, at the Ńore level of the platform, users edit documents through Edit, and therefore the result is a document modified by.
OMV, the further introduction or discussion of this field has 3 ways:
Oh, thanks for pointing this out! Yep, this would definitely be useful to have implemented
Oki doki, makes sense. Does this mean the proposal would be better off splitted in 3 seperate ones (like, tags, creators/modifies in the doc footer)?
Totally agreed. Iāve said in the proposal that we should have all avatars revamped as circles. Iāll try identifying all places where we might need to change CSS classes. Places that I noted so far:
user-avatar (.navbar-avatar > a > img (in the navigation bar).commentavatar img (in the Comments section)img.xwiki-selectize-option-icon (in the User Avatar macro selector)_avatar linkview typetext (in User Directory)#avatar img (in the Profile section).notification-event-user>img (in Activity Stream, Notifications ).drawer-nav .drawer-brand img (in the Drawer menu).user img.user-avatar, .group img.group-avatar (in LiveData)I just took the colors for the info, warning, success and error boxes in Iceberg. Iām thinking these could be the colors that define the default suggested tags. They have a good contrast for text readability:
So, as Iāve said in the proposal and here as well, I was thinking of using the colors for the info, success, warning, error boxes as they have a pretty good symbolism in relation to the 4 default suggested tags that I was proposing ( done, in progress, to improve, to update)
Iāll have to give more thought to this.
Yep, this is a good idea. Iāll think of some ideas for ordering contributors.
Oki doki, fair enough. Other options would be:
Feel free to add more ^^
Yep, makes sense
Replied to this to @mleduc , totally agree with this, as said in the proposal. See the earlier reply for places Iāve identified so far that make use of the avatar image (and if you can remember any other places, feel free to add, Iāll search more anyway)
Now that we agreed on the general idea, I indeed think it would be beneficial to split into separate discussions.
Unless I missed something, there is no such thing as ādefault suggested tagsā. Auto-suggestions are based on existing tags of the wiki.
Anyway, we can discuss this on a discussion dedicated to tags revamp. But I would consider the colors as an improvement on top of the tags UI revamp as this seems to be bringing some additional complexity.
I didnāt understand that you wanted to propose these tags specific tags, I thought they were just examples. Why do you think they are good tags to propose by default? Would this be configurable?
No, no, there are no defaults. The idea would be to introduce these default suggested tags in the revamp
Agreed
Ideally, they would be configurable, but, initially, I think it could be a good idea to see how people respond to a specific range of default tags for a period of time (until we get questions on it or feedback)
I did suggest these because they are pretty much the most used in project management and Iāve always seen knowledge management kind of motivated and elevated by project management.
As said in the proposal, the tags would mean:
Of course, there could be others as well. If we want to support any popular knowledge management philosophies we could introduce the tags Project, Area, Resource, Archive ( in support of the PARA method developed by Tiago Forte). Not ideal as we would probably need to explain to a lot of people the concepts and it wouldnāt help the discoverability.
We could also try to organize a small research on this and see which statuses do people usually organize around. 
XWiki is not a project management tool, even tough it can be used as one.
Therefore, I donāt think we should make any effort to support any specific methodology and instead focus on being generic and configurable.
+1 for the idea
The main issue for me is that its style is not consistent with any other button in the UI.
Especially important for accessibility 
Fortunately this shouldnāt be too difficult to do from a technical perspective: here is an example of changing an attribute on all āuser avatarā pictures.
Like button change :
Why leave the text in black? I think making the text the same shade of blue as the icon would give more cohesion to the button.
About the tooltips, I worked on them for XWIKI-19139: Like button can't be focused by tabulator (#2107) Ā· xwiki/xwiki-platform@e0b58cb Ā· GitHub, itās pretty new and they are not the best I agree ^^ā
For a button, its accessible name should always contain a description of its function (here, like or unlike the page). In this case, we also want to give an idea of what the number next to the button means. Both pieces of info are important, even though you donāt need to put the second one in the tooltip.
- We have a few default tags that the user can choose from, like:
- #done - this tag would help put all done projects and tasks in the same subcategory. These would be the pages that would be most likely to get archived or deleted each few years, making the process of cleaning up much easier.
- #in progress
- #to improve
- #to update - if anyone stumbles an outdated page, they can easily mark it for update
- Because these tags are very close to the Comments section it makes feedback and progress tracking much easier for the reviewer.
- Each of these default tags should have special colors to be easy to spot. The colors would be based on the info, warning, success and error boxesā colors.
Those colors schemes have enough contrast (I made sure of it earlier this year 
) and donāt bring in too much complexity in the color theme, for a secondary feature.
Great idea +1 for revamping the footer
Like others Iām not convinced the ādocumented byā, personally Id prefer page statistics such as number of views at that place, perhaps thereās a solution to allow admins to choose context themselves?
I very much like the default tags for progress/status of the page. I can imagine the default tags (specifically those indicating the page is not fully done) could have a little bulb somewhere at the top of the page. That way readers would immediatly be informed about the current state of the page (opposed to currently where theyd read the page, find out parts are missing and then see the tag in the footer)
I also like the colors for the default tag +1
I think that from a collaboration POV itās interesting too to know the creator of a page since, when in doubt about adding something to the page you may want to know who wrote it and contact the person for additional information about the spirit of the page, etc.
Now as others have noted, itās costly to compute and displaying the last one is useful IMO. We could keep displaying the last one but provide a link to the information tab where we would compute and display all authors (possibly starting a job that would take some time).
@amilica I think this thread should be closed and several new threads created with new proposals for all topics, taking into considerations the comments received so far (and mention the new threads in this thread as a follow up). As a general rule, itās much simpler to have small and concise threads, it helps getting feedback and getting something actionable out of it.
Thanks!