Moving away from <img> based icons to using CSS does not mean we have to
change the actual icons that are visible to the user, so I think maybe
we can avoid a debate on that for now. I'm currently working on the CSS
to back this up and, at the moment, the user still sees the same old icons.
Here's a gist of what the CSS look like atm:
https://gist.github.com/tfennelly/f43c42c7efa68dd701cc . We could
obviously clean that up a lot using a CSS preprocessor (ala Less), but I
think you can get the point that after making this change, it will be a
lot easier to change how we handle icons e.g. one could easily use the
old icons of today, or swap in something like Font Awesome.
From a Jelly point of view... I updated the <task> tag + there's a
simple <l:icon> tag. Some examples:
* <l:icon name="document_add-16x16"/> (instead of <img
src="${imagesURL}/16x16/document_add.png"/>)
* <l:task href="${rootURL}/" icon="up-24x24" title="${%Back to
Dashboard}"/>
From a migration point of view:
1. I've also written a tool that can be used to search through all the
.jelly files in a filesys tree and replace the existing icon markup
with the what we'd be proposing as the new task/icon tags.
2. I will write a Jenkins plugin to make the tags backward compatible
on earlier version of Jenkins.
On 20/06/2014 20:47, Gus Reiber wrote:
Yeah, so fair questions...
...and my list here definitely remains an ask, not a tell.
What I mean by device friendly, is that a font can scale in size, up
or down, to fit into a variety of screen sizes in a way that an image
does not. Additionally, a font can take advantage of your phone or
pad's anti-aliasing to get that full sub-pixel clarity out of your
Retina display. And in general, a phone's cache space and browsing
bandwidth are going to be more variable and limited, so reducing
download size and number of requests is particularly helpful for less
powerful devices.
...granted phones are getting better and better, but when would you
ever want a page to load more slowly, even as that margin of
difference goes down?
Here is an article that lays out the main arguments for why font icons
are good:
http://css-tricks.com/html-for-icon-font-usage/
My summary and Jenkins specific thoughts are these....
1) Number and size of server requests, in a bare-bones Jenkins install
I count 15 server requests for icons, that may not seem like a
ridiculous number of additional requests, but it is more than an order
of magnitude more requests than are necessary.
2) Vector based imagery is easier to deal with for page design and
readability
3) Fonts are easily programmatically and CSS manipulatable to reflect
states and status in a way that images are not
4) Using fonts provides a convenient way to package a base-pack of
icons plugin authors can easily borrow from
5) The simplification forced by the abstraction into a single color
makes creation of new and matching icons a little easier
6) At the moment, anyway, they are on-trend, or at least have a bit
more modern vibe than the Tango Feet icon pack, currently in use
I think you are right, the big down-side is the lack of multiple
colors and the relative ease of creating 1-off custom icons as a PNG.
It is hard to beat the tried-and-true bitmap for whipping up that 1
button you need right this second. If we were to embrace font-based
icons, we would definitely need to handle backwards compatibility, so
my hope would be that if a community member wanted to use PNGs, they
still could. Conceivably, by swapping CSS files, they could swap fonts
for PNGs on a global basis, if that was the users preference.
On Fri, Jun 20, 2014 at 11:54 AM, Daniel Beck <[email protected]
<mailto:[email protected]>> wrote:
> 4) Adopt a new icon library, likely based on a glyph-font
library like Font-Awesome to enhance performance and device
friendliness
What exactly is the problem with normal icons? Jenkins isn't
dial-up friendly anyway, so optimizing the first-time loading of 5
icons won't make a difference. What specifically does 'device
friendliness' refer to?
Font-Awesome seems to be pretty small and doesn't have icons with
"modifiers" (e.g. New Item's star, Build History's pencil). Isn't
this going to be a problem?
Does this mean single color icons instead of properly colored
icons? Will these be all the same color, or color still be used to
distinguish the icons?
There should be a migration strategy for plugins that makes old
plugins not look out of place (and new plugins on then-current LTS
installs). I think I've mentioned it before, but having to install
the latest & frequently-not-greatest because plugins raise their
minimum version to get new _icons_ wouldn't a good solution.
-----
Icon-related issue that could be cleaned up while this is being
worked on:
- "Manage Jenkins » Script Console", "Build History", "(Build) »
Changes", and "(Build) » Edit Build Information" use the same icon
- as do "Manage Jenkins » CLI", "Console Output", and "(Node) »
Script Console"
--
You received this message because you are subscribed to a topic in
the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/jenkinsci-dev/zDaX4yiWLLw/unsubscribe.
To unsubscribe from this group and all its topics, send an email
to [email protected]
<mailto:jenkinsci-dev%[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the
Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/jenkinsci-dev/zDaX4yiWLLw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
[email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
