Designing Badges #71
Comments
abbycabs
modified the milestones:
July Mozilla Science Project Call,
August Mozilla Science Project Call
|
Possible coloured dots solution (I'm sorry, I did this quickly): |
|
Hi @acabunoc I am a little confused by your requirements here, are you trying to view the badges by badge earner as well as by badge evidence? Also, can you give an example of the context for these badges? |
|
Hey @iamjessklein, yes! Context:
|
|
I just spoke to @acabunoc IRL to get a better sense of what is needed. Here's the 411: Background
Probem
Requirements
|
|
Amazing @vazquez, thank you! |
|
I like the coloured dots solutions you've put up! We need something that would integrate well with any publisher platform. I think that does the job much better than the more traditional badge. |
|
Hi -- ORCID has been thinking a little about the concept of Person Citations. I've independently (not officially!!!) been playing around a bit with how this might look: I think in extending this concept of a person citation, it would be interesting to have the role names themselves link to/display the badge somehow. (Maybe a popup, tooltip-style?) Related to displaying the badges in ORCID, I think this one is a little trickier. ORCID takes a "multi-source" approach to displaying publications on an ORCID Record. For example, a reference to one DOI may appear multiple times, and then are visually grouped in the interface, with the one from a preferred source displaying by default. Right now ORCID doesn't have any concept of something that displays on, say, a DOI for an ORCID record, but isn't tied to a set of publication metadata provided by an ORCID member. In some ways it would be easier for the badges to display in ORCID if the works were pushed into the ORCID record from paper badger. Could use a tech design session to figure this one out. I'll set up a time for us to discuss. |
|
Alternatively you could use a tag cloud approach, where each badge is weighted by the count of badges of each type. Also it's possible to have an author affiliated to multiple institutions, in some papers we can have up to 30 authors cited. How would you associate the orcid id in each case? |
|
have you folks considered using / extending an existing svg font for these badges? The work of optimizing for small display sizes would already be done for you, and you could enhance visual discriminability with fixed colors for each badge. Some possibilities:
|
|
Wasn’t aware of this. Thanks! Will look into it. Amye Kenall From: Daniel McCloy [mailto:notifications@github.com] have you folks considered using / extending an existing svg font for these badges? The work of optimizing for small display sizes would already be done for you, and you could enhance visual discriminability with fixed colors for each badge. Some possibilities:
— |
|
@akenall here are two good starting places: |
|
Thanks! Amye Kenall From: Daniel McCloy [mailto:notifications@github.com] @akenallhttps://github.com/akenall here are two good starting places:
— |
|
SVG would be more preferable as it scales better on devices and browsers supporting it. Also can lead to smaller downloads, but not in all cases. And may be faster to render. Most latest crop of browsers now support SVG; although this wasn't the case in the past. Would be good to use standard icons if they are well supported and understood by the target audience. Well worth considering -- are there any other well accepted icons that can support the other badge types, not listed above? |
|
@Alicole I stuck in PNGs here just so everyone can see them at roughly the target size; all the icons are available as SVGs too. Here are some additional ideas:
|
|
@drammock -- thanks all seems fairly comprehensive; interesting to see that there are PNG equivalents, which is good as this means we can have a fallback for those browsers still not 100% compliant with SVG. Just a case of deciding on the merit of introducing them now or later. Also how we go about marketing them, after the others have been available for a while. I suppose this is something for a wider discussion with various partners of badge scheme. |
|
Here are drafts of a few of the missing or sub-optimal icons in a gist. They are created to be compatible with FontAwesome insofar as they are created with the same height/width/viewbox and are fairly visually consistent. |
|
This sounds great in principle. However I'm always wary of all-inclusive solutions, especially as it's important to be mindful that in the process we don't trip up over intellectual property issues. As I've noticed one of the fonts have glyphs for Mendeley and Google Scholar, as well as doi and others. Sometimes a more measured minimalist approach is better -- following less is more. So that we only include what is needed here for the issue in question, ensuring all glyphs comply with distributed licensing models that are intellectual property free. Creative Commons come to mind. |
|
@Alicole I'm not sure I understand the objections. Sure, FontAwesome and Academicons contain some official logos, but we don't have to use them for the badges (why would we?). Regarding the license issues, did you look at the license?
If your mention of "minimalist approach" refers to file size, there are tools for subsetting Font Awesome (and adding in your own custom glyphs) so that load time would be very minimal. |
|
@drammock -- that's fine in principle, but with compliance laws abound, it's important to be careful when approaching anything purporting to be open source. Moreover why do we always approach everything through dev eyes? -- minimalist in this context, simply means to keep the contents to the bare minimum; just concentrating on what matters to the project or issue in question, without broadening the scope beyond of what is required. |
|
While I do add font awesome to most of my projects (really liking this work, @drammock!), since this is a widget we load onto external sites, we should probably be more minimal than usual. Thanks for the reminder @Alicole! I would actually prefer svg for our badges (for some of the excellent points you make @drammock), but I don't think that the whole font-awesome library is necessary. On some other mozilla projects we make a custom lightweight font for specialized icons -- Can we strip down font-awesome for just the badges? |
|
@acabunoc I've finally gotten around to a complete draft of my proposed icon set (a subset of 9 fontawesome icons plus 5 custom ones). Here is a demo page and here are the fontello-generated fonts. |
|
Very nice @drammock ! Is the idea to export them as PNG and use them instead of the current images? |
|
I think you can import them as a font instead of loading the PNGs |
|
@jos the long-term idea is to have this as a webfont, that publisher websites can add to the pageload, and the icons would go in similar to what @acabunoc drew in the lovely colored dots mockup. Specifying colors in the CSS (so that, e.g., the funding icon was always green) could also aid visual differentiation. |
|
@drammock -- nice set -- pretty succinct too -- good work. Should be a massive improvement to existing images -- just need to ensure glyph is self-explanatory. Have these been approved by other project partners? |
|
@Alicole this is the only place I've posted it, so other project partners will only have seen it if they saw it here. |
|
@Alicole regarding self-explanatory, I'm happy to hear opinions about which ones need improvement. |
|
@drammock -- have looked at latest version of font awesome and cannot see any other glyphs that might be more appropriate. So unless any other person objects, it should be OK to go with your selections. Just a thought: as some publishers might not want to go with these yet, is there any way to provide an option to select the images (possibly as default) or new glyphs instead. Might also enable some kind of fallback if the font fails to load. |
|
@Alicole you can see how fallbacks are currently handled by viewing the source of the demo page at lines 230-239: several different font file types are specified (svg, woff, woff2, eot, ttf) and the browser will try them in the specified order until it successfully loads one of them. This does not protect against the fonts being completely unavailable (i.e., if they are hosted on a different server than the web page that is loading them). Possible approaches include: each publisher hosts the fonts locally (hard to roll out updates/bugfixes); hosting the fonts on a CDN (probably not free); mozilla hosts them (vulnerable to route failures: page loads but font doesn't). That said, there is nothing currently in place for, say, falling back to PNGs if all the fonts fail to load (though even with PNGs there's still the same question of where to host them, with the same ups and downs mentioned above). I also have nothing to say about giving publishers the ability to choose old vs new-style badges... it certainly complicates the deployment; if I were in charge I would only want to support one set of badges, not two, but I'm not in charge. |
|
@Alicole I like the option to select images -- this makes a lot of sense since Badgr needs an image to store by default. Images as a fallback also makes sense. We can talk about this at the MozFest session this weekend. @Alicole, can you make it out to MozFest? (short notice...) |
|
@acabunoc -- Just seen your message about MozFest, would be great to finally meet. But as you say this is quite short notice. Maybe next time. |
We currently have some assets from @akenall
help wanted: Designer, Input
Summary from @vazquez
Background
Probem
Requirements
But we need to design badges that:
Discussion / inspiration:
@akenall has started some discussion on updating the design to be simpler like the stack overflow badges
Add any comments here! Looking for a contributor who wants to own this design (you don't need to be an actual designer!) -- we're looking to implement these visualizations by the August project call.
The text was updated successfully, but these errors were encountered: