With the release of a lot of high-DPI displays (aka “retina” displays, but also others on both Android and iOS devices), it’s just a truism that images on these displays have tended to not look their best, all the time. High-DPI displays are having to scale up low-resolution images, and it’s just not great.
There is a simple solution for this, using either CSS or Javascript tricks, but the basic principle behind it is to make an image twice as big on each dimension (four times the area), and then let the browser scale it down into the space it’s supposed to fit into. This lets the high-DPI displays have more information to work with and to make images which scale much better. The problem, of course, is that larger images require more space and bandwidth. With various CSS and JS techniques, you can target it such that the high-res images are only sent to browsers that really need them, saving on the bandwidth.
Anyway, lately we’ve been making those sorts of changes to WordPress.org too. If you’re visiting on a high-DPI display, you may notice that the main header logo is of a higher quality, or you might have noticed that the Showcase looks particularly good, or that we now have some very high resolution images on the Logos and Graphics page. Little changes to the graphics, here and there. It’s an ongoing project to “retina-all-the-things”.
Back in December, we made some changes to allow plugin authors to put banner images above their plugins in the directory, and the response has been great. So, now they get the high-DPI love too.
Plugin authors already have the ability to make a banner-772×250.jpg or png file in their assets directory and have that be used for the banner image on their plugin listing. As of today, they can add a banner-1544×500.jpg or png file, for use on high-DPI displays only. When the website detects that the viewing browser both has a high-DPI display and the high-res image exists, then that image will be shown instead of the low-res image, but scaled to fit into the proper space. This makes them look particularly sharp on high-DPI displays.
Now, before you go forth and create, please remember that one thing to keep in mind here is filesize. If you’re using photographic material for your banner, then it is highly recommended that you use the JPG file format. If you’re using drawn or generated materials, PNG is the favored format. However, in either case, you will want to apply high compression and try to keep those files as small as possible. Small files transfer to the browser faster. Also consider that a fair number of high-DPI displays will be phones, for example, and perhaps not using high-speed connections. So keeping that high-res file as small as you can would be a good thing. If you wish to use a PNG compression tool before uploading, that might be a good idea as well.
And there you have it. Plugin authors, go forth, and show us your high-resolution banner skills!
BTW, if you want to see it, I gave my Pluginception plugin a high-res image, for testing. It’s a simple image with some well-defined lines that make the difference easy to spot if you’re looking for it. You’ll need a high-DPI display to see it though.
dremeda 12:19 am on July 28, 2012 Permalink | Log in to Reply
Good stuff, Matt. I would like to contribute here. Whoever ends up owning it, you have your first contributor/volunteer.
Ben Tremblay 1:48 am on July 28, 2012 Permalink | Log in to Reply
Detail: that URL was not clickable in EMail. ThunderBird is pretty well behaved with that sorta thing.
Odd it wasn’t a live link.
Links in header and footer were just fine.
dllh 2:24 am on July 28, 2012 Permalink | Log in to Reply
Can you clarify what level of involvement with the community the lead for this should have had to date? For example, I’ve gotten a few patches in here and there but don’t know that I’m sufficiently familiar with all the things to be a useful lead on something like this. Wouldn’t surprise me to learn that others who’re interested in pitching in have similar feelings. Are you hoping to land somebody who already has a solid insider view of things or are you after a fresh perspective?
Matt Mullenweg 2:01 pm on July 28, 2012 Permalink | Log in to Reply
I don’t think being super-involved in core is necessary, in fact it’s probably better to have a beginners mind with regard to much of this. However you’ll want to run things by folks with more experience just to make sure you’re leading people on the right track.
Emil Uzelac 2:55 am on July 28, 2012 Permalink | Log in to Reply
Good stuff indeed
Tom Auger 5:16 am on July 28, 2012 Permalink | Log in to Reply
Boy oh boy, this is such an important piece of the WordPress puzzle! My own journey (still in its infancy) in becoming a useful contributor has been fraught with good intentions and big learning curves. If I had more experience I’d definitely volunteer to shepherd this thing into a true roadmap for the would-be contributor.
Mike Bijon 9:37 am on July 28, 2012 Permalink | Log in to Reply
Hi Matt, I’d like to be considered for this position too. I’m a 1-time core contributor and have worked with the PDX WP Meetup and Codex lately. More details, http://www.mbijon.com/about-mike-bijon/. Now that I’m not a full-time developer at work, and take on a lot more planning & PMing tasks, I think I could be a lot more productive with this than I’ve been with trying to make rare, quiet coding windows.
Also, for tracking changes to the CCH:
Audit Trail has most of what you need, http://wordpress.org/extend/plugins/audit-trail/, but would have to be turned into a feed. Adding some open diff tools could help make it more readable, http://www.raymondhill.net/blog/?p=441, or https://github.com/austincheney/Pretty-Diff. Although what would be interesting is to build a way to deploy all content via a git or Github repo, http://drupal.org/project/content_staging (which would also solve a lot of commercial users’ Dev > Production deploy problems).
Japh 1:34 pm on July 28, 2012 Permalink | Log in to Reply
Hey Matt, the Core Contributor Handbook is already an excellent resource, and I’d love to see it grow even further.
I would also like more information about what your expectations are for this role. Specifically, how much experience with core contribution do you feel is necessary? How much time per week do you expect this role will require?
Matt Mullenweg 2:02 pm on July 28, 2012 Permalink | Log in to Reply
Answered the experience question above. As for time, I would plan for 10 hours a week as a good baseline, as with any serious volunteer commitment across WordPress.
Siobhan 3:59 pm on July 28, 2012 Permalink | Log in to Reply
Hi Matt – I’d love to help out with this. I was looking at it before and wondering if you needed someone to help out.
I’m a documentation specialist (http://wordsforwp.com) and I spend a lot of time communicating with devs and translating what they say into beginner speak. I build a lot of documentation projects from the ground up, and work with a lot of developers on similar projects to this, so it’s right up my street. I’d be more than happy to get involved. My time is a little limited over the next few weeks but as of the end of August I have 10 hours per week for sure.
Andrea Rennick 10:33 pm on July 29, 2012 Permalink | Log in to Reply
I’d vouch for Siobhan having the chops to take the lead on this.
Azizur Rahman 5:22 pm on July 28, 2012 Permalink | Log in to Reply
Hi Matt, count me in to be one of the volunteer. I don’t think I can do 10 hours at the moment to take a lead, due to my other volunteering commitment at the moment. I am happy to be supporting whoever ends up taking the lead.
Beau Lebens 10:59 pm on July 29, 2012 Permalink | Log in to Reply
If anyone is planning on coming to the Dev Day for WCSF, I plan on making contributions to the CCH part of the action for the day.