Closed Bug 1197623 Opened 8 years ago Closed 7 years ago

Rework attendee icons


(Calendar :: General, defect)

Not set


(Not tracked)



(Reporter: MakeMyDay, Assigned: MakeMyDay)



(Keywords: icon)


(4 files, 1 obsolete file)

While working on bug 1174511, the available icons representing user type, role and status seem to not play nicely together in all combinations. For instance, the icon for an optional participant might be mixed up with a group or the icon for the meeting chair looks like a representation for a room. Also, the tentative status icon is not very obvious. A better fitting set of icons would be nice.

Eventually, we also can combine the user type and role icons and make the status icons usable for a separate decoration of the former. I will attach an idea how this might look like, but I would appreciate if anybody else could pick this up as I'm lacking any talent in graphic design. SVG icons would be the extra mile.
Attached image icon_proposal.png
The goal of the attached proposal is to combine the different dimensions of attendee properties (user type, role and participation status) into two or if possible one icon following an understandable concept - mainly colors for the role and symbols for the user type. The status should be technically a separate icon but capable to be used also combined.

N.B.: The property rsvp is left out intenionally here - four dimensions would be too much complexity to understand the icon at a first glance I think. Also, this can easily be represented otherwise, e.g. by a note within the imipbar or a checkbox in the FB dialog. For that, there is already bug 984011.

Richard, what do you think about it?
Attachment #8651538 - Flags: feedback?(richard.marti)
Comment on attachment 8651538 [details]

I like this proposal. It's more consistent with the colors than the actual version. The status can be overlayed with a layer above the role/user icon. The role/user image could be more or less directly used from your proposal. It ahs already the correct dimensions and is also sharp. The status icons needs some love as they are a little bit too big, something of 8px * 8px could work.
Attachment #8651538 - Flags: feedback?(richard.marti) → feedback+
Attached image itip-icons.svg (obsolete) —
I've experimented a little bit with SVG (first time), but I'm not sure whether this is really well crafted. There are still little flaws (some icons are not fully 16x16), but I upload the svg file anyway to get some feedback.
Attachment #8658319 - Flags: feedback?(richard.marti)
Comment on attachment 8658319 [details]

This is looking already really great, we have a new icon designer ;). I have seen only really small thing like the id="needs-action" which could be made with only one circle with white fill and black stroke. And on "tentative" the text y="14" would look better centered on my system. But it could be better to use a path instead a font because it could look different on different systems.

One question, how do you plan to use the icons? As one image and then using -moz-image-region or with pointing to the ids like itip-icons.svg#needs-action? For the first it would be better you are using viewBox="0 0 96 48" instead of width="96" height="48". Then the scaling would be better.

But all in all this is a good starting point.
Attachment #8658319 - Flags: feedback?(richard.marti) → feedback+
> One question, how do you plan to use the icons? As one image and then using
> -moz-image-region or with pointing to the ids like
> itip-icons.svg#needs-action? For the first it would be better you are using
> viewBox="0 0 96 48" instead of width="96" height="48". Then the scaling
> would be better.

I'm still experimenting. I'm actually not sure what is the best option to make the file not loaded multiple times.
Assignee: nobody → makemyday
Ok, let's get in the review for this. I changed the structure a little bit, added an role icon for UNKNOWN and modified some others icons a little bit. I will upload the svg as well.

I kept the status icons with two circles, because the outer one has an additional stroke (this is not visible in the .svg file, but will be when the icons get overlayed on each other) - for a double stroke with different colors I haven't found another solution.

This bug is only about adding the icons. Bug 1174511 will be the first to make use of them.
Attachment #8660478 - Flags: ui-review?(richard.marti)
Attachment #8660478 - Flags: review?(philipp)
Attached image itip-icons.svg
And just for convenience, this is the svg from the patch.
Attachment #8658319 - Attachment is obsolete: true
Blocks: 1174511
Comment on attachment 8660478 [details] [diff] [review]

This is looking good. I only don't know if it would be better to copy every single icon instead of using "use". Robert Longson commented in bug 1153615 "use" is using a lot of memory for the overhead.
Attachment #8660478 - Flags: ui-review?(richard.marti) → ui-review+
Comment on attachment 8660478 [details] [diff] [review]

Review of attachment 8660478 [details] [diff] [review]:

Check out the discussion in bug 1153615, it seems <use> tag will clone the images using more memory. The toolbar svg uses fragment identifiers to select the images. Would that also work here? I'd appreciate if you could change the svg file accordingly.

::: calendar/base/themes/common/calendar-itip-icons.svg
@@ +117,5 @@
> +    <use id="group-nonparticipant" class="non" xlink:href="#group" x="48" y="32" />
> +    <use id="ressource-nonparticipant" class="non" xlink:href="#ressource" x="64" y="32" />
> +    <use id="room-nonparticipant" class="non" xlink:href="#room" x="80" y="32" />
> +    <use id="unknown-nonparticipant" class="non" xlink:href="#unknown" x="96" y="32" />
> +</svg> 
\ No newline at end of file

A whitespace snuck in here.
Attachment #8660478 - Flags: review?(philipp) → review-
Yes, the use seems to make processing slower and memory footprint bigger. I can change this back to the previous approach, but to me this a workaround for a core bug. File size, readybility and maintainability would suffer from that.

Referencing the fragment identifiers actually does not work, but I have no idea why.
I like the structure that exposes just one icon based on some part of the URL, so I'd prefer if we could solve it. Robert, can you help us out here? You did a great job investigating this in the other bug. I guess the solution would be to use fragment identifiers, but we are having trouble getting it to work right.
Flags: needinfo?(longsonr)
Why not write a tool that inlines <use> elements. You write the svg with <use> elements and then run the tool on it and ship the output. 

Both the source and output could be valid SVG so you could test both and you'll get the performance benefits of avoiding <use> when you don't need it with the maintenance benefits of code reuse.
Flags: needinfo?(longsonr)
Comment on attachment 8660478 [details] [diff] [review]

Re-requesting review as we discussed the other day on IRC to go with the existing patch.
Attachment #8660478 - Flags: review- → review?(philipp)
Blocks: ltn47
Blocks: 1229141
Blocks: 1229148
Attachment #8660478 - Flags: review?(philipp) → review+
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.7
Depends on: 1235355
You need to log in before you can comment on or make changes to this bug.