Colored tags (or default tags) - xDocFooter Revamp

Development
,
#1

​
Hello everyone! :star_struck:
This proposal is tackling the idea of having colored tags (or default tags).
You can see the initial tags discussion here: general tags revamp.

Goal

The idea of colored tags would be to have another level to normal tags.

While normal tags should categorize the page in the eco-system of knowledge based on the page’s content (normal tags = extreme summarization), colored tags could be at a higher/lower level and categorize the page…

  1. based on its actionability (how is that page used? who will it be useful to in the future?)
  2. based on the information’s life cycle (creation or collection, processing, dissemination, use, storage, and disposition, to include destruction and deletion)

Why default tags?

They should be default tags in the sense that, once configured, they are configured globally with specific colors and labels. This standardizes the way people organize pages making it actually useful to use tags.

Look (isolated)

Any default tag will get another class on top of the .tag class. Example, the #done tag makes use of the .success-tag (named like to stay cohesive with the success box). Its tooltip message stays cohesive with its meaning.

Note: the x will be an actual icon that will match in color the text of the tag

image

MVP requirements

Ideally we’d make these tags configurable, but I think, for efficiency purposes, that we could see what the initial feedback is on a fixed/ non-configurable set of default tags and then move from there. In the initial discussion of this whole revamp, I proposed a set of 4 tags corresponding in color to the 4 boxes we have (info box, success box, warning box & error box):

  • #done - this tag would help put all done projects and tasks in the same place. 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 - would make following on-going researches and projects much easier
  • #to-improve - would make review from managers easier to see at a glimpse and problems in the context of a page easier to spot
  • #to-update - would make keeping everything up to date and correct easier

In the MVP phase, these tags would be stackable and have the same behaviour as any other tag. They would just be colored and be suggested in the Add tag UI.

Full requirements

Ideally:

  1. we’d have a new entry for Tags in the Global Administration > Look & Feel or in Search
  2. you could set a maximum of 10 colored tags choosing from 10 tag looks (once you use a look/color, it shouldn’t be available for the others)
  3. you could set the tooltip for each tag
  4. you’d have an inline preview of how every one of them would look like
  5. include these tags in the search dropdown as suggestions for easy search

Semantic HTML

Regarding the HTML, I have a question on making it semantic.

First, I wanted to make nested buttons but learned quickly that’s not very good.

Is it the right idea to implement this:

  • have a div with a colored background that contains a link (the tag text) and a button (the x)
  • if you hover on the div, it becomes darker (and tackling seperately the other states)
  • if you hover on the x it gets a padded darker container around him (and tackling seperately the othe states) - close to the idea of the like button revamp

This idea was explored below.

Implementation & hover states

Hover on the tag text

image

Hover on the delete button

image

HTML for tag

Ideally we wouldn’t just type x, but use an icon.

<div class="tag success-tag">
<a title="View all pages that are done" href="/xwiki/bin/view/Main/Tags?do=viewTag&amp;tag=done">done</a>
<button title="Delete tag" class="tag-delete-btn success-tag">x</button>
</div>

CSS/LESS

Disclaimer: I’m pretty sure filter:brightness() is not ideal for dark themes, so a mixin might be needed for the hover states of everything.


/* restyling the tag class */

.tag {
border-radius: 999px;
overflow-wrap:break-word;
word-wrap: break-word;
margin-bottom: 0;
font-weight: normal;
text-align: center;

vertical-align: middle;
touch-action: manipulation;
cursor: pointer;
background-image: none;
border: 1px solid transparent;
font-size: @font-size-base;
line-height: 1.428571429;
-webkit-user-select: none;
-moz-user-select: none;
-ms-user-select: none;
user-select: none;

margin-right: 6px;

display :inline;
padding: 3px 0px 3px 9px;

}

/* tag states */

.tag:hover {
filter: brightness(95%);
}

.tag:focus {
filter: brightness(90%);
}

.tag:active {
border: 3px solid transparent;
}

/* general case */
/* colouring the tags - normal tags */

.simple-tag {
background-color: @xwiki-page-content-bg;
border-color: #e8e8e8; /* box border color variable - which is it? */
}

.simple-tag a {
color: @text-color;
}

/* example of a colored tag: success case (status:done) */

.success-tag {
background-color: @alert-success-bg;
border-color: @alert-success-border;
}

.success-tag a {
color: @alert-success-text;
}

.success-tag:hover{
filter:brightness(90%);
}

/* styling the delete tag button */

.tag-delete-btn{
display:inline;
border:none;
padding:3px 9px;
border-radius:999px;
margin-right: -4px;
}

Let me know what do you think about:

  • the color of the delete icon:
    • should it be consistent(gray) despite the color of the tag
    • should it take the color of the text?
  • the whole concept
  • HTML & CSS

​

1 Like
Tags look revamp
#2

I’m somehow missing the bigger idea here. How is this going to look when viewing tags in other contexts like on the page that lists pages for the tag or in the tag cloud?

Also, how is this going to work with wikis in other languages, in particular with a fixed list as you propose for the start? What happens if a tag is renamed, will the color stay or will it be gone?

Suggesting these tags in the search dropdown seems odd to me, this will only be useful in very specific cases. Also, note that the dropdown currently doesn’t provide search suggestions but search results. We would first need to decide if we want to additionally provide suggestions there which could be quite confusing for users. If this is implemented, this needs to be an opt-in feature. Imagine, e.g., a public wiki like xwiki.com and how odd it would be to have such tags there in the search dropdown.

You seem to have a very particular use case in mind, which is wiki pages that represent tasks or projects. However, XWiki is a general-purpose wiki software that is primarily aimed to be a knowledge base. Has this feature been requested by anyone? I’m wondering because tracking project status based on tags seems to me like a very special way to use XWiki and I’m wondering if we won’t spend time on a feature here that won’t be used by anybody. So, asked differently, is there any evidence for an actual demand for this feature? If you’re looking at tags, I think what would be needed much more than colored tags is a revamp of the look of the page that lists all tagged pages. It doesn’t follow XWiki’s styling conventions at all, it doesn’t even use the icon theme.

1 Like
#3

yes, I was asking myself the same thing, especially since in XWiki the traditional way to do this is through XClass/XObjects metadata (tags would be a poorman’s choice).

1 Like
#4

Did you consider just having a set of prefixed colors without any semantics attached? And, simply allow user to pick arbitrary colors for tags. Google keep is working that way for instance.

1 Like
#5

Why would we set a limit to 10 colored tags? And IMO having the same color for a few tags could be useful. E.g. we want to tag documentation pages with the version they were introduced in. We can use color to highlight the fact that “this tag is related to the version” but: we would need a lot of tags (more than 10) and we would need the same color for all those tags.

Let me know if this example is not in the scope of what we want for colored tags.

I agree with the way you implement the tag itself :+1:
It’s the same implementation as a regular tag right? Plus the class for styling ofc.

Yup, see XWIKI-21600; $services.icon.renderHTML('cross') can be a solution.

IMO it should take the color of the text because it keeps things more consistent, which can avoid bugs on some edge cases (e.g. black background and white text with a difficult to see grey icon), …

Thanks!
Lucas C.

1 Like
#6

Thanks a lot everyone for your feedback! It helps a lot! :blush: I’ve tried to reply to most of the messages and write some conclusions at the end, let me know what you think about them when you find the time!

I personally think it can be very useful, but I also understand that this truly depends on the style of knowledge organization everyone has. Because of this diversity of styles, it’s important that XWiki supports as many of them.

I’m fully aware that the search dropdown doesn’t provide suggestions. I’ve written it here concisely, but there is the plan in the future to tackle the revamp of the dropdown and to include suggestions there. The structure of the dropdown would be changed so it won’t be confusing to users.

I agree completely it would need to be opt-in & it wouldn’t be good for public wikis to suggest configured tags unless those websites know their average user’s interests very well or/and they want to conduct traffic to a certain category of knowledge.

This will be debated more in the discussion about the search revamp, but even for xwiki.com I can see suggesting tags in search very useful. Again, a topic for another time, let’s focus on the colored tags in the footer of the page for now :sweat_smile:

Yep, aware of this. It’s in my plan to look at that page too. :grin: From my own perspective, we should first fix the look and experience for the first things the user interacts with when discovering the product. This is at least my thought process in setting revamp priorities, but I’m completely open to suggestions, especially every time we set the monthly roadmap and I propose what I’d like to work on that month.

Tags are clearly in this category and colored tags are something many software have in some form or another (either as colored tags or colored dropdowns). It’s also something we can improve so we have an advantage in a specific feature area. For example, many Notion users requested tag support on pages, yet they still do not have it (they have select/multi-select in databases and users can use databases to create a workaround, but it’s not ideal).

I think this may be the better way to go, keeping in mind all of the feedback.
This seemed to me slightly more complicated to implement on the backend (and, thus, implying more hours spent on this from a dev), because each tag would have to have a color (actually a CSS class) corresponding to it. Maybe this is easy to do or we have most of what we need to implement it easily (would appreciate if someone could let me know about this).

Also, the tag addition UI would need to be custom fully as it would need to offer the posssibility to add color to any tag (not just select from a list of 4 predefined tags) and I tried searching for an open-source UI that could implement this, but haven’t been successful yet. Esentially, we’d jump directly to a more generalized full requirements version so it would imply a bit more effort form the start.

An idea for this tag addition UI would be the following (which i will explore in a seperate proposal after we decide what to do about colored tags):

User opens modal for adding tags

opened modal for adding tags

User defined a tag

one tag defined

User defined multiple tags

multiple tags defined

Conclusions based on feedback

This proposal is changing from having an initialy small, static list of colored tags to creating the possibility for a user to create a tag with a certain color attached to it. That color will be used everywhere that specific tag appears.

A possible version for the tag additon UI is described in the previous paragraphs. That UI is a custom one and we might not find one that is already existent, open-source and supported.

Of course, we could use a tag input UI (example) and add extra functionality to it, but the experience of a tag input UI without colors is entirely different than what we need, tbh.

What do you think about the conclusions? :thinking:

Tags look revamp
#7

I don’t see the benefit for colored tags ATM, but if this proves to be useful, then the color of the tag shouldn’t be set when you add the tag to the wiki page (I doubt you want the “Science” tag to have different colors on different pages). I think we’re talking about two separate actions:

  • associating a tag to a wiki page: this is done from the bottom of the page; if the tag is known (has metadata) then display it using that metadata (e.g. color) otherwise use the default display (e.g. the default color)
  • associating metadata (e.g. a color) to an existing tag: this is more of an administration task; you don’t want any user to change the color of your wiki tags; we could have an administration section that allows an administrator to associate metadata (color) or some known (predefined) tags.

Thanks,
Marius

1 Like
#8

This actually sounds pretty good and I agree it might prove as the better solution to avoid situations like deleting a tag on a page and adding the same one with a different color (and now having different pages with different colors).

Thanks a lot!

#9

Hey @amilica leaving my feedback as requested on #XWiki chat.

I really like the idea of colored tags, as I’ve used them extensively in the past to categorize content.

This is especially true for teams that agree on semantics and how each tag will look. :+1: For example, a tag about a product could be product name + color of branding

The default tags proposed (done, in progress, to improve, to update) are nice as a default options, but an administrator should be able to change them globally or remove them altogether and replace with new ones.

Regarding the limitation on 10 colors, we could use them as preset to speed things up, but still allow the user to choose a custom one.

About creating and managing them. In my opinion, having options for creating them on the spot and managing them globally are both necessary. Even if I am an admin, I can still perform content creation on the page. In this case, having an UI for creating something so simple as a tag without the need to go to admin sections (interrupting my flow) is a big plus. However, also as an admin I would be required to keep things consistent inside a wiki, so a global page would be more helpful here.

This works similarly as how other tools treats tags. Below, you can see a really quick flow I did on how the creation and color selection of a tag works inside Gitlab. From here we can see that providing options when creating a tag is really important (“Create project label” and “Manage Project Labels”)

Gitlab’s tag creation on the fly

tag creation flow

Managing created Labels in Gitlab

tag manage

#10

So, basically this proposal to change includes 2 changes:

  • adding a list of preset tags to the XWiki tags
  • associating colors to the preset tags.

By preset tags I mean the following:

  • today, in XWiki, a tag is a piece of string (a value) that was filled in on at least one page from the wiki. Other than that, a tag does not exist as an object (it cannot exist without any page that has that tag)
    • related to this functioning, a tag is “created” as soon as the string is present on a page, so there is free tag creation for everyone
    • also, any string that is added on a page becomes automatically a tag, without any form of declaration and any previously added tag is a suggestion, without other form of declaration
    • when a tag is deleted from the last page it’s present on, it “disappears”.
  • what this proposal entails is:
    • creating a tag would be an explicit action - even if very quick from the UI
    • a tag would exist even if there would be no page associated to it
    • the tag suggestions would be made based on the list of existing tags (as they have been defined, even if there is no page associated to the tag)
    • deleting a tag would be an explicit action.

If we go for this choice, we need to decide:

  • who can add tags? Is it an existing right or a new right?
  • who can delete tags?
  • the definition of the list of tags should be global or have some form of scoping? (for example, should the tags be defined at a subwiki level?)

For the first 2 questions the current XWiki approach is interesting, as it ensures the following:

  • any user can use any tag on a page, even if an admin has not yet defined that tag
  • however, despite that, the list of tags doesn’t endup “polluted”, because as soon as a user deletes the only remaining association of a tag with a page, the tag is also “deleted” and not visible anymore in the wiki (in the suggestions for tag add presented to other users). The user doesn’t need special rights to do this.

Of course, we can also go for a mixed approach in which:

  • there is list of predefined tags - additions and deletions of this list is done by a designated right (admin or other)
  • however, any user is free to add any other string they want when adding tags on a page, and it becomes a tag
  • when deleting tags from a page, if the tag was added “on the fly” it will disappear when the last association with a page is deleted while if it was defined in the preset list, it will not disappear
  • however, with this approach it will be difficult to know which tag is which type (not clear if it’s needed for a regular user, though).

The management of tags as a preset list is interesting, but it’s a more complex functional question, and it’s independent of how the tags are decorated (colors or not). Adding colors along with a definition of a tag is a question that is easy to answer once we’ve decided how we want preset tags to work.

Also, if we decide to change tags to make them use a preset list, we also need to think about how we’ll migrate existing wikis.

The question raised by @MichaelHamann about how would all the other tag involving features change to include preset / colored tags is also to be clarified along with the definition of preset tags.

From my point of view, the footer revamp that includes tag display revamp does not need to change this functioning of tags, it can be done without. The design could be created to admit colors for tags (for when we will implement them), but without necessarily using any.

Thanks,
Anca

#11

I kind of agree with this. There’s not been a lot of request for this (I don’t remember any TBH), while we have tons of more urgent requests for improving other things. I think it’s interesting to discuss what colored tags could be if one day someone is interested to implement it but I wouldn’t put it as a priority.

Thanks

#12

I agree

This is a very good source of inspiration. The idea of being able to search if there is a tag with a certain name already can be used in avoiding the mess with different pages having the same tag with different colors.

Would be nice if step 2 and step 3 of the process would be merged into something like:

  1. a single field for inputting a tag
  2. while typing in the input, there is also made an automatic search for any tag that contains the user input
  3. if there is any tag that resembles the input, the UI suggests the user to choose one of them or he can create a new one
  4. if not, just showcase possible colors to choose from to create a tag

Even if we take out the colors from this equation, the idea of searching through all the tags as the user inputs a tag name to check if there’s no other tag close to the user’s one is very good. It’s close to how labels work in this forum, too.

Yes, this is all correct and very well explained for the initial feature this proposal presented. In the last replies of this discussion, the proposal kind of changed from having a preset set of tags to being able to add color to any tag.

Okay, will keep this in mind.

Oki doki, I think I’ll document the feedback and ideas in a seperate XWiki design page just to make sure this discussion doesn’t get lost in the forum and move to a higher priority revamp