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

simplified icons, added full support for all add to home screen platforms #442

Closed
wants to merge 3 commits into from
Closed

Conversation

pbakaus
Copy link

@pbakaus pbakaus commented Sep 22, 2014

This PR adds support for Win 8.1 live tiles and streamlines the icons used across all add to home screen platforms. It implements all recommended meta tags across all platforms.

@addyosmani
Copy link
Contributor

Thanks for working on this @pbakaus! We'll begin testing and discussion of the implementation shortly.

@sindresorhus
Copy link
Contributor

I personally favor trying to find the minimal set of 'looks good enough, but doesn't require boilerplate' option, however I can also see value in all of the options being documented.

I'd prefer to keep it minimal too. H5BP has good docs for all this we could link to.

@pbakaus
Copy link
Author

pbakaus commented Sep 22, 2014

Pushed another commit with fixes. Reverted to 192px as baseline for the icon size, as Android is more important to support than Opera Coast (and Coast will eat the picture anyway, then scale up).

<meta name="msapplication-starturl" content="./">

<!-- Color of navigation buttons (back/forward) (Desktop) -->
<meta name="msapplication-navbutton-color" content="#FF3300" />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

weird indentation on all of the above

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Open for other suggestions on how to visually nest.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't visually nest. Rather prefix the comments: <!-- MS - Tooltip (Desktop) --> or something.

@addyosmani
Copy link
Contributor

@sindresorhus Open for reviewing this, but if we do end up reducing scope or trimming implementation, there's always the docs directory which is prime for extended work like this.

@addyosmani
Copy link
Contributor

Thanks for the PR! Before this can be merged, please sign the CLA at https://developers.google.com/open-source/cla/individual

@pbakaus
Copy link
Author

pbakaus commented Sep 22, 2014

Done!

On Mon, Sep 22, 2014 at 4:29 PM, Addy Osmani [email protected]
wrote:

Thanks for the PR! Before this can be merged, please sign the CLA at
https://developers.google.com/open-source/cla/individual


Reply to this email directly or view it on GitHub
#442 (comment)
.

@paulirish
Copy link
Member

I covered some of this stuff back in #60. I think that while thorough and correct, having all this in the initial markup will severely inhibit adoption. H5BP was avoided by many developers because of the sentiment "better to use something when you need it, rather than start with the entire kitchen sink". Which.. seems reasonable.

Favicons seemed solved these days by the combination of @mathiasbynens' eternally updated blog post and the comprehensive realfavicongenerator.net. And yet they change, too. iPhone 6+ added a brand new asset requirement.

I wonder if this is better suited to a build step rather than dirtying up the initial markup.

@alrra
Copy link
Contributor

alrra commented Sep 23, 2014

iPhone 6+ added a brand new asset requirement.

Note: Some things have changed since the iOS 8 release, however, the iPhone 6 Plus still uses the 120×120px touch icon like the other previous models of the iPhone do.

@addyosmani
Copy link
Contributor

@paulirish @alrra Thanks for chiming in with your thoughts :)

I share your concern that including every possible combination will scare off beginners. I've also been hesitant to add icon generation to the build process for a few reasons (please do let me know if this is unreasonable):

  • Real-world sites are likely to want to tweak and customize their icons per device manually, through an image editor to get the look right.
  • Adding a build step to solve this problem would move the introduction of boilerplate from our HTML into our Gulpfile. This may end up making it feel like the 'kitchen sink'

That said, for funsies, here's what a build step for icon generator would look like using the Favicons module by @haydenbleasel:

favicons({
    // I/O
    source: 'images/logo.png',
    dest: 'dist/images/icons',

    // Icon Types
    android: true,
    apple: true,
    coast: true,
    favicons: true,
    firefox: true,
    windows: true,

    // Miscellaneous
    html: null,
    background: '#1d1d1d',
    tileBlackWhite: true,
    manifest: null,
    trueColor: false,
    logging: false,
    callback: null
});

The HTML option basically specifies the file (index.html etc.) to write the icon data to. It's unclear to me (without further testing) how well existing modules tackle generating icons + splashscreens, but this could be a start if we wanted to go down that route.

Any further thoughts?

@haydenbleasel
Copy link

Sup @addyosmani and crew. If you need a demo of Favicons, it'd look something like this. Creating a new branch for the Gulp plugin is on my to-do list. Also, let me know if you think of adding things like extra icons or splash screens (as mentioned), always happy to look into expanding the module. Good work with Web Starter Kit btw, loving it.

@addyosmani
Copy link
Contributor

Thanks for sharing the demo @haydenbleasel. If the consensus is that a build process is the way to go here, we might have a few suggestions for additional icons/sizes that could be generated (the list from @pbakaus in this PR might be a good indication). Really cool to see your openness in expanding the module :)

@pbakaus
Copy link
Author

pbakaus commented Sep 23, 2014

+1 for build step. I think there's a lot of value to have all of them in place automatically when you need them, and not before.

@haydenbleasel
Copy link

Also it might be good to mention that Favicons isn't particularly light, it outputs a LOT of files (if that changes anything). See the Travis log for deets.

@mathiasbynens
Copy link
Member

I agree with @addyosmani: taking care of icons in a build step implies that every icon is just an automatically resized version of a high-resolution master icon. For best results each icon is pixel-perfected individually, though. Then again I’m not sure how many designers actually do this.

@addyosmani
Copy link
Contributor

Taking care of icons in a build step implies that every icon is just an automatically resized version of a high-resolution master icon.

That was my concern. That we may be making an assumption that automation is the right call here. That said, unsure without doing a survey how best to gauge if designers really do create these per project. Might warrant further research either way.

@haydenbleasel
Copy link

The best way is definitely to design each icon individually, but for most basic applications it's just a chore to get things right. However this does raise an interesting idea about defining multiple source images that range in complexity (for smaller and larger icon sizes)...—
Sent from Mailbox

On Tue, Sep 23, 2014 at 7:17 PM, Addy Osmani [email protected]
wrote:

Taking care of icons in a build step implies that every icon is just an automatically resized version of a high-resolution master icon.

That was my concern. That we may be making an assumption that automation is the right call here. That said, unsure without doing a survey how best to gauge if designers really do create these per project. Might warrant further research either way.

Reply to this email directly or view it on GitHub:
#442 (comment)

@paulirish
Copy link
Member

​Could the build task default to auto-resize but also take options for
manual selection of differently sized source images?

@haydenbleasel
Copy link

@paulirish Yeah I reckon I'll modify the source property to accept a string or array so we can get some better favicons happening.

<!-- Tile icon for Win8 (144x144 + tile color) -->
<meta name="msapplication-TileImage" content="images/touch/ms-touch-icon-144x144-precomposed.png">
<!-- Icon in the highest resolution we need it for, reused for Safari -->
<link rel="icon" sizes="228x228" href="images/touch/icon-192x192.png">

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will need switching to a 228x228 image.

@gauntface
Copy link

+1 build step if:

1.) It can add in the markup
2.) It can be used to customise each specific favicons

An alternative is to move to static templating which would be easier on the eye and feel more manageable.

@addyosmani
Copy link
Contributor

Yeah I reckon I'll modify the source property to accept a string or array so we can get some better favicons happening.

@haydenbleasel any timeline on when that might be available? :)

@gauntface could you expand on how static templating might fit in here?

@gauntface
Copy link

What I'm thinking is, you might have one for ios 5+, one for Chrome add to home screen, one for Opera Coast and you just pull in a single template for each - it will look a little cleaner and make maintenance a little easier.

@gauntface
Copy link

Chatting with @addyosmani - @haydenbleasel I think I'd almost prefer to have a separate icon for each category of device - i.e. an icon for iOS, one for Chrome for Android, one for Windows Phone.

What would people say to this approach?

@addyosmani
Copy link
Contributor

I won't comment on the per category of device icons, but will say I'm more open to us opting for an automated solution to generating favicons having spoken to a few developers about it. What would be useful for us to consider here is:

  • Minimal set of changes we would need from tooling (the kind Mr @haydenbleasel in this case)
  • How we document customizing the icons if tooling is the default. It seems like we could use a guide for those that want to create per device icons with or without the tools in place.

@haydenbleasel
Copy link

Yeah there's kind of two methods i can implement:

  1. Minimal solution, define a set of images that determine icons produced based on size e.g.
source: {
   small: 'small.png',
   medium: 'medium.png',
   large: 'large.png'
}
  1. Descriptive solution, define an image for each favicon (can overlap) like @gauntface was talking about e.g.
source: {
   opengraph: 'large.png'
   apple: 'medium.png',
   android: 'medium.png',
   favicon: 'small.png'
   ...
}

Maybe a bit of discussion on this before I start working on something.

@addyosmani
Copy link
Contributor

Having flexibility to specify a per target source as well as the option in 1 would be fantastic - would this basically allow us to support 3 possible configurations?

  • User can specify just one hi-res image
  • User can specify a small, medium and large set of images
  • User can specify per target OS images

For 2) we'll want to make sure the high-level targets are at minimum supported (Android, Windows Phone, iOS) but it looks like you know what needs to be done there :)

@gauntface any other asks from your end? I would absolutely love to be able to land support for build-time generation in 0.6.0

@haydenbleasel
Copy link

Okay @addyosmani, new version of Favicons is out. Besides a few async fixes there's also support for an OpenGraph image which I must have forgotten initially. The important stuff though:

You can now define multiple source images like so:

source: {
    small: 'logo-small.png',    // Should be 64x64px or smaller
    medium: 'logo-medium.png',  // Should be between 65x65px to 310x310px
    large: 'logo-large.png'     // Should be 311x311px or larger
}

I've taken the route of multiple source image sizes suggested by @mathiasbynens and @paulirish rather than the per-platform route proposed by @gauntface as each platform has sizes that can range from around 16px to 310px. Therefore I've had each platform select a source image depending on the size I'm about to convert them to.

Also gave you blokes a mention on the readme for good measure. Hope this helps and let me know if there's anything else I can help with!

@addyosmani
Copy link
Contributor

Fantastic work @haydenbleasel 🌟

@gauntface @paulirish I think the next step forward here is to decide whether we want users to define 2-3 multi-res images for their projects vs a single high-res image we use to seed the icons being generated.

In either case, we can provide them with some WSK flavoured defaults and comment up the Gulpfile with more detail about customization. Any preferences here?

@gauntface
Copy link

I would want to have an ios, a chrome and a IE + Opera Coast icon - high res for each

@paulirish
Copy link
Member

Could the default be ask users for a single image, but also recommend providing three unique ones instead? Could then take the time to describe what each asset is used for and recommendations on visual treatment.

I feel asking for three separate assets here by default is a lot to ask.

@sindresorhus
Copy link
Contributor

I feel asking for three separate assets here by default is a lot to ask.

👍 For a simple default.

@arthurvr
Copy link
Contributor

arthurvr commented Oct 6, 2014

+1 for what Paul suggested. Asking for three unique ones would be quite annoying, but there must be an opportunity to input them all three.

@addyosmani
Copy link
Contributor

Goooood to see we're on similar pages. Fwiw, my vote is for a single asset by default too. We can document and include comments guiding them to define three but assume most people will just go for the simplest setup possible.

@gauntface sgty?

@addyosmani
Copy link
Contributor

friendly ping @gauntface :)

@haydenbleasel
Copy link

@addyosmani Quick update you might find interesting, I've been talking with the creator of the aforementioned realfavicongenerator.net and we might be doing some work together that will make Favicons and RFG more awesome (using his comprehensive API).

@addyosmani
Copy link
Contributor

👍 That is great to hear :) Looking forward to learning more when you have the details hammered out!

@gauntface
Copy link

+1 from me to get this in. I think some of the files could be renamed and the splash screens have slightly rotated WF logo's, but this can be fixed up after accepting and are minor issues given that we hope developers will change these anyway.

@haydenbleasel
Copy link

ping @phbernard - read this stuff too :)

@paulirish
Copy link
Member

fwiw,

I've been talking with the creator of the aforementioned realfavicongenerator.net and we might be doing some work together that will make Favicons and RFG more awesome (using his comprehensive API).

All, there is a status update ("in progress!") on that over here: itgalaxy/favicons#14

@phbernard
Copy link

Oh, I feel like I missed the party! :) If that can help, here is the opinionated approach of realfavicongenerator.

The tool has two constraints in mind:

  • Many people have little knowledge of Photoshop, Gimp or whatever and/or have not enough talent to do serious graphic design. That's me. So everything they have is a high resolution logo from their customer, marketing department...
  • Many people don't have time to deal with this tiny little thing named favicon. It should be a 5 minutes task just before lunch time.

Web devs/designers with talent and time are welcome and RFG let them do as they want (yet some improvements are expected in this area) but this is not the primary use case.

This is compliant with the idea of @addyosmani and @paulirish to submit a single, high res picture. And more pictures if available.

Next, RFG has two tasks:

  • The obvious task: generate the pictures and HTML code that work everywhere.
  • The tricky task: make the icon look good everywhere. Different platforms need different designs. Let's take the favicon of GitHub, a black silhouette on a transparent background. If we take a high res version of this picture and make it a apple-touch-icon.png, adding it to the home screen will produce a black square. Because iOS fill transparent regions with black. To be a decent iOS icon, this picture needs an opaque background and margins (else, the silhouette touches the borders).

I think this last point is really important. It is easy to miss it and focus only on the technical aspects.

As @paulirish mentioned a few hours ago, @haydenbleasel and I have started to work together on RFG integration in his neat Gulp plugin.

@gauntface
Copy link

Closing this off to move the discussion to this issue: #599

@gauntface gauntface closed this Jan 14, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants