-
Notifications
You must be signed in to change notification settings - Fork 688
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
Comments
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. |
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. |
@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? 💃 |
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) |
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. |
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 |
Closing this in favor of #1574 (same issue but specifies says we need PNGs) |
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.
The text was updated successfully, but these errors were encountered: