Skip to content
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

Replace the Font Awesome icons with images #1477

Closed
psivesely opened this issue Nov 15, 2016 · 9 comments
Closed

Replace the Font Awesome icons with images #1477

psivesely opened this issue Nov 15, 2016 · 9 comments

Comments

@psivesely
Copy link
Contributor

The context of this is that the Torbutton security slider provides a better user experience and greater exploitation protections than disabling JS alone, however, it breaks Font Awesome icons in SD as they are used currently. This is a legitimate decision to protect users on behalf of the TBB devs, as remote fonts/icons may contain malware.

See #1024 and specifically #1024 (comment), where @micahflee made the suggestion for this issue.

@redshiftzero
Copy link
Contributor

Note this was done for the source interface in #1480 but could also be done on the admin and journalist interface to remove this dependency. I used the SVG images from this repo to replace the icons.

@ninavizz
Copy link
Member

ninavizz commented Dec 18, 2016

Many of the icons used in the interface (that I observed) are more distracting than helpful. In general, buttons should never have icons unless it's next/prev buttons as arrows, or the circle-arrow on a reload button. Buttons should always be either text or icons, but rarely both.

I'd recommend killing all of the icons on buttons. The cloud/arrow graphic in the "upload" screen is valuable, and if there's an arrow-down "download" icon on such a button that I would have missed in a journalist or media-org interface, that should also remain—but yes, as an SVG.

@psivesely
Copy link
Contributor Author

Many of the icons used in the interface (that I observed) are more distracting than helpful. In general, buttons should never have icons unless it's next/prev buttons as arrows, or the circle-arrow on a reload button. Buttons should always be either text or icons, but rarely both.

Curious what you think of Github's use of icon + text buttons or Gmail's (see photos in https://play.google.com/store/apps/details?id=com.google.android.gm). Personally, I think in both cases what they've done both looks good, and is helpful to the user. When text is accompanied by icons, it can often help me find what I'm looking for faster than just scanning the text.

@ninavizz
Copy link
Member

ninavizz commented Jan 28, 2017

@fowlslegs So: there's ALWAYS exceptions, to rules. My "never use icons on buttons" guidance, is a good rule to follow if you have no UX person on your team full-time. I'm looking at the "Open" button above, and that's done great. The icon itself is perfectly balanced with the text, and it appears to be a very faint green. With GitHub, most users here are on this site ALL THE TIME, and so all these visual thingys are genuinely helpful. GitHub's is a very specific, high-level user, and there's an assoload of different concepts being bucketed and available for use. The icons here are also very, very well-matched pictograms to their functional mental models... and designers tweek each one I'd bet, to make it render properly at the size it's shown at (yeah, we even have to do that with vector art!).

Designers know how to make these things work both to visually look rad, and to ease cognitive processes for users. I agree—when icons on buttons are done well, they're the best. They're too often done poorly, tho.

Like: I can do HTML and CSS, but there's no way I'd advise anything I fully coded to go into a live environment. Unless it's, like, HTML plopped into a Drupal site's page body. Even then, my HTML and CSS won't be able to reflow nicely.

Understand a little more why we don't code, but instead spend hours on stuff you guys scratch your heads at? 💃

@ninavizz
Copy link
Member

For now, the interactions and flows within the Source UI for SecureDrop are so, so, so very simple, that I'd like to keep icons off of buttons. When they're truly needed, they're great. They're not, in my opinion, truly needed in the source UI, tho. (I also don't wanna evoke MS Office PTSD in users, heehee)

@ninavizz
Copy link
Member

BTW—The Noun Project, is THE BOMB place, for finding icons. Seriously, it's like a goldmine. All of the icons I've proposed in my wireframes and am offering-up here as SVGs, began as SVGs I got from the Noun Project. http://www.nounproject.com

Type in concepts or a literal object/shape type, and you get so much great stuff. Creative Commons licensing notes, I'll always include with each submitted SVG for final use as art.

@psivesely
Copy link
Contributor Author

Thanks, your explanation is very helpful. I think I agree that removing the icons from the source interface is a good idea. I do wonder, however, if the main /lookup view of the journalist interface should have icons. It has a significantly greater number of buttons (maybe not quite an "assoload" 😸) and journalists will spend time there daily; these aspects are reasons you gave for icons being appropriate for Github, and wonder if for the same reasons some of them should remain in the journalist interface.

@heartsucker
Copy link
Contributor

@ninavizz Could you email me PNGs of all the remaining SVGs? This includes the new ones that were added in #1558 and #1538. This is a relatively easy fix that would also allow us to close #1574.

@redshiftzero
Copy link
Contributor

Closing this in favor of #1574 (same issue but specifies says we need PNGs)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants