Establish sponsor logo settings/guides

[mattstratton]

Need to clarify a few things, and then update the code and the README to reflect.

1. Sponsor logos should NOT have a border in the image file itself
2. Do we think there should be a border around the images? If so this will be done in CSS
3. Confirm standard size of logos.

Please discuss :)

[kmugrage]

While not normally a fan of borders on images, I prefer them with the current layout. Because orgs have all different shapes and sizes of logos they tend to blend together or look jumbled if there's nothing consistent about them.

[mattstratton]

Interestingly, in the new setup where the logos are consistent this might not be a thing.

[tduffield]

My vote is to keep all logos 100x100 with no border. We can handle any styling with the CSS.

[mattstratton]

I also agree that there should be no borders on the images themselves. We will update docs to reference this. I'm keeping the issue open until the docs have been updated.

[mattstratton]

Question to self - what docs do I think are supposed to be updated? I am not sure that our current docs say anything about the sponsor logo files (well the README says they have to be png and how to name them; I guess that's what I meant?)

[jyee]

Should we be a little more explicit on the file format? We probably ought to specify dimensions (200px square. Images show as 100px square, but 200px will kick in for retina). Also, should we specify PNG-8 and run through something like ImageOptim?

[phrawzty]

what docs do I think are supposed to be updated?

Right now the README (correctly) addresses the two most pressing concerns: how to get Hugo up and running, and how to set up a new event within the framework. Could we not just add some bullet points outlining the salient details surrounding the logos (i.e. size, format, no border)?

but 200px will kick in for retina

I don't world wide web that well. What sorcery is required to have images upscale to retina automagically? :)

[jyee]

Retina is wonderful because it's lazy magic: You don't need to do anything other than send an image that's double the dimensions.

Right now we're specifying logos as 95px wide in the html.

• If you send a a 95px wide image to a non-retina device, the browser just displays it.
• If you send a 95px wide image to a retina device, it makes up the extra pixels and usually looks a bit blurry.
• If you send a 190px wide image to a non-retina device, the browser scales it down and it in nearly all cases it looks good.
• If you send a 190px wide image to a retina device, it gets to display all the pixely goodness.

[phrawzty]

Retina is wonderful because it's lazy magic

Ah, lovely!

Proposals:

• Set official image dimensions to 200px square, with no hard border. 👍
• Harness the awesome power of HTML to constrain said image to 100px square. 👍
• Utilise stylistic sheets of a cascading nature to draw a border around the image AS IF BY MAGIC. 👍

r? @mattstratton

[phrawzty]

something like ImageOptim

@jyee This appears to come in two flavours: OS X and a beta Web API, the former of which we can safely discard as a possibility. Are you familiar with the Web API - what's the user story look like there?

[mattstratton]

I agree with the proposed README updates, @phrawzty. Make it so :)

Regarding the ImageOptim thing, I would say let's add using something similar to the docs, but there really is no way we can "enforce" this. Personally, I do my optimizations with CodeKit2, but that's a Mac only story. I think that simply requesting folks use their own judgement on this one is fine, but it's a really good idea to put in some links to some good options for doing it.

[phrawzty]

Harness the awesome power of HTML to constrain said image to 100px square.
Utilise stylistic sheets of a cascading nature to draw a border around the image AS IF BY MAGIC.

What is (or should be?) the canonical method for actually doing these two things?

[mattstratton]

Those things are done in the core code of the site - events cannot actually do it themselves. So those two items don't need to be in the docs (other than as reference maybe?)

[phrawzty]

Fair enough. I'll modify the documentation appropriately; that said, where should we be making these changes in the core code of the site? I'm not at all up to speed on Hugo or our implementation of it.

[mattstratton]

This is where it would happen (at least this is where the sponsor images get drawn):

https://github.com/devopsdays/devopsdays-web/blob/master/themes%2Fdevopsdays-legacy%2Flayouts%2Fpartials%2Fevent_footer.html#L17

This is where the CSS can be fixed:

https://github.com/devopsdays/devopsdays-web/blob/master/themes%2Fdevopsdays-legacy%2Fstatic%2Fcss%2Fstyle.css#L72

[phrawzty]

I can't help but notice that those links point to the "legacy" theme - are we using this theme throughout, or?

Sorry if these are dumb questions. 😕

[mattstratton]

Yes, the "legacy" theme is the one that matches the "current" devopsdays website look and feel.

The devopsdays theme is where we can be working on new UX, etc.

For reference:

https://github.com/devopsdays/devopsdays-web/blob/master/config.toml#L1

https://github.com/devopsdays/devopsdays-web/blob/master/wercker.yml#L6

This commit is when it got merged

72c9a64

[bridgetkromhout]

Hi, @phrawzty - is this issue done? I ask because I don't see the CSS borders when building locally, although I do see them on github.

[mattstratton]

@bridgetkromhout do you still not see the borders? I see them on http://devopsdays.github.io

If you do correctly see the borders, we can close this issue as complete.

[phrawzty]

@bridgetkromhout @mattstratton Yes, I see the CSS borders when building locally.

[mattstratton]

Okay this seems to be working.