-
Notifications
You must be signed in to change notification settings - Fork 693
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider replacing FontAwesome glyphs with PNGs #5546
Comments
Hi @eloquence, this is something I can definitely take care of. |
@DrGFreeman I would personally like to see the visual language between the Web UI and the new SD Client mirrored as often as possible; to that end, there is a cleaner Download icon we're using, there. It's SVG is here: freedomofpress/securedrop-ux#17 (comment) @eloquence How do you and @emkll feel about having the existing download icon in the JUI replaced with the cleaner version from the Client? |
...following-up on the above, I replaced the |
👍 Thanks @ninavizz :). Since we're replacing these glyphs with PNGs anyway, I'm favor of the specific choices presented in the screenshot above; they're both clear and aesthetically pleasing. |
Cool! I went ahead and created new PNGs for them, and the rest of the fa-glyphs I could find in the JUI. @DrGFreeman So... all the sizes of the font-awesome glyphs, were strange and random; presumably because their "font size" was something consistent and not random, yet they all rendered at different random sizes. Likewise, the text-fonts in the JUI all render a bit odd, so it was a little hard to get consistent(ish) sizing in replicating the existing footprints with PNGs. And yes, I was more generous with padding in how they're placed in the mockup. Hoping it's not too much trouble doing this—and thank you again, for volunteering to give it a go! :) All the PNGs I created, are 3x the size of what they are at 100%; which is to budget for image degradation on HDPI monitors. There are a few other glyphs in the Admin interface, and because that's a different codebase I didn't touch them, here. Did you want to include that in a PR as well? Happy to make replacement PNGs for its Old: docs/messages = 9x12 Old: reply fa-reply = 16x16 Old: fa-envelope, fa-envelope-open = 16x16 Old: download = 13x13 Old: star = 14x13 Old: unstar = 14x13 Old: trash = 11x13 |
Thanks @ninavizz! I'll start replacing the FontAwesome icons with the PNGs you provided. I'll use a constant height for now and we can adjust individual icons later. Below is the list of unique FA icons I found with a search of the code base. On the right, I put the matching icons from those you provided. As you mentioned, there are other icons which do not have corresponding icons in your file. For those, I'll convert the FA icons to PNG and use those in the layout. If you'd like to change some of these as well, just let me know.
Here's where these icons are used:
|
So great @DrGFreeman, TY!! Yeah, the glyphs that are most commonly exposed to users, that also render poorly at such a small size, were my only real priority for replacement for simpler glyphs. All of the replacement glyphs, I sourced from Google's material.io icons library. So, wherever attributions are mentioned in the code, a happy FOSS attribution to it should be included as well. Attribution probably does not require use of the "G" word, probably just "icons sourced from material.io are under an apache 2 blah blah license" is adequate. The bell, plus, check, chevron, edit, info, and bang icons, all render pretty cleanly—or are only exposed on rare occasion to admins, so if you are able to create PNGs from them, I would love that so much. If you need a hand, please (as always) just give a shoutout, happy to lend a hand. Again, I appreciate you taking on this PR, so much. Teamwork is the bestwork. :) |
Thanks @ninavizz. I used the link you provided to get the star icon svg in order to make colored versions for when sources are starred/unstarred. This is what it looks like in Tor Browser with "Safest" setting: I'll keep working through the other pages and submit a PR when all pages are completed. Regarding attribution, I don't know where this would go, in the source code itself? Maybe @eloquence would know? |
Dang it my friend, you are FAST!! That looks AWESOME! Thank you! The only nits I'd have, are if the vertical alignment between the icons and the text could be a little better—but I suspect that's a much bigger thing than your most excellent PR, so no worries. Wow. Really stoked to see this done, @DrGFreeman. Death to tofu-glyphs, woo! :) |
Replace all Font Awesome icons in JI with PNGs so they are displayed correctly with Tor Browser in "Safest" setting (freedomofpress#5546 & freedomofpress#5576). Related changes included: - Increase font size of source submisison counts text in / - Ensure consistent vertical spacing in users table in /admin/
Replace all Font Awesome icons in JI with PNGs so they are displayed correctly with Tor Browser in "Safest" setting (freedomofpress#5546 & freedomofpress#5576). Related changes included: - Increase font size of source submisison counts text in / - Ensure consistent vertical spacing in users table in /admin/
Replace all Font Awesome icons in JI with PNGs so they are displayed correctly with Tor Browser in "Safest" setting (freedomofpress#5546 & freedomofpress#5576). Related changes included: - Increase font size of source submisison counts text in / - Ensure consistent vertical spacing in users table in /admin/
Description
The Journalist Interface uses FontAwesome for various icons in the UI, which are rendered as Unicode placeholder glyphs is FontAwesome is not present, which is the case in Tor Browser's "Safest" security setting:
The current implementation is based on the reasoning that it's not necessary to use Tor Browser in "Safest" mode in the Journalist Interface, given defense in depth against unauthorized use (2FA login, authorization token). However, we do ask users to use "Safest" to visit the Source Interface, and journalists may make the assumption that they should do so for the Journalist Interface as well (we have little evidence one way or the other).
To avoid unexpected breakage, it seems reasonable to replace these glyphs with static PNG assets, rendered a high enough resolution to scale well on HiDPI displays.
The text was updated successfully, but these errors were encountered: