Hello! When updating some bits of UI in xwiki-platform, I happened to run multiple times in the same problem: the current XWiki Icon Set does not have the icon I want.
I compiled the instances where I ran in this issue in the past months. Here is my main proposal:
This unique link does not reflect enough the importance that this list has in actually using icons when developing interfaces from experience, it’s difficult to find it when new to the project. I think we should update it to
I think we need some consistency in the names. For example caret-left and move do not look consistent. Move is quite generic and could be about lots of things (moving a page to another location for example). What about prefixing all “arrow” operations with arrow to indicate there’s a notion of arrow in the icon?
The icon for move seems weird for silk as it’s a left arrow.
The icon for resize-horizontal seems weird for silk as I don’t see what’s horizontal in the chosen icon
2 icon names don’t have a mapping for some icon themes and I think we need the mapping to be complete as otherwise it won’t work.
I don’t agree with this fix, because I think a strength of the icon set is the easiness of the names. Systematically adding prefixes will make using this feature more difficult than it needs to be. AFAIK we don’t have specific icons for moving pages or moving attachments in the iconset so this lack of specificity is not an issue. I agree that caret-left and move have different naming conventions (based on the character vs based on semantics), but it’s something that’s already in the iconset with ‘add’ and ‘caret-right’ for example. I don’t think this is much trouble for devs so I’m in favor of keeping things the same.
Unfortunately, silk was created in 2005 and not updated for a long time, so there’s some huge holes in its icon theme cover. When checking out a list of the icons in silk, I could not find anything closer to those we would expect for those actions.
I think it’s more important to have an icon set that can represent a variety of icons, even if silk is a bit left behind. If we don’t provide enough icons in the set, devs will need to:
hard code icons, defeats the purpose of having an icon set (see Loading...).
Regarding silk shouldn’t we just start deprecating it? As you said it’s starting to get old, and I think we’re all more relying on FA those days than on silk. IMO it would make sense to deprecate it and stop bundling it in the future, maybe when we move to 16.x or 17.x.
You’re right, I did only check the documentation page, which was out of date, but the mappings in FontAwesome.xml and Silk.xml do have values that are not mentionned here…
I’ll move this list to the icon theme documentation and update it so that it fits what we currently have.
The point is that the name should be about what the icon represents and not about a concept since otherwise 1) we’ll have namespace problems and 2) different icons can be used for the same concept (e.g. use one icon for “move page” and another icon for “move attachment” or “move a panel”).
I didn’t say that we shouldn’t add these icons but we need an acceptable mapping for the other icon sets. This is crucial as otherwise the whole concept of icon set goes away (if you can only use a single icon theme).
Well, it means we would not be able to use the Elusive icon set. If we don’t want to support it, then we shouldn’t list it. However, I think it’s a good idea to list it and to perform the mapping as it offers a proof that the new icons can have mappings in several icon sets and that’s important. So yes IMO we do need to make the effort of providing mappings for all icon sets, just as a proof that we can find mappings and thus that we are not adding an icon that is too specific to one icon set.
This was not my point. My point was that we need a mapping for the bell icons, for all icon sets.
Sounds good generally speaking, but could you explain precisely what you mean by deprecating? I think we need to make sure that contrib extensions (or custom code) continue to work if they use Silk. Does deprecating mean that when using Silk in future XWiki versions, the UI would get broken? IMO, one simple solution that could be acceptable would be that each icon set could provide a default icon when no mapping exists for a specific name. That would allow Silk to continue “working” (even if it would be with icons not nice) in the future, at a low cost.