Review Typography #5
Comments
|
Couple decisions, that need to be made before we start fiddling with typefaces:
My advice: use custom font (more choice, nicer fonts), use Typography.com. Why this particular service? Typekit is terribly slow (depends on JavaScript) and basically makes your website unavailable when it goes down (and it does). Webtype is nice but less affordable. Google Fonts also relies on JavaScript. I've been using HFJ's Typography.com since they launched for many projects and it has proven to be the best choice. They have classy fonts, that are very well prepared for the Web rendering. Also — you get the source files. In terms of form — are we keeping the 100% sans-serif appearance? If yes — we have a good starting point to pick something. |
If it's a popular font and you're including standard stuff linking with CSS isn't a huge deal, right? Also, as a rule of thumb fewer typefaces the better. It would be nice to find 1 typeface with enough weights that we wouldn't have to grab another or many more. One of the popular sans-serifs, like PT, Source, whatever would be good all around. That's just what I can think of offhand that's free, but definitely think Typography.com is worth the look. |
Does it mean we get to host them? That would be the preferred solution (by me at least 😛). I'd prefer not to hotlink them as to have less things to worry about (the dev team is tiny and the ops team does not exist yet 😉). |
|
We have a Typekit account, though we're not using it for anything yet. I'm open to dropping that in favor of H&F. We definitely don't need to constrain ourselves to free options. |
|
I'd like to throw a vote behind the open sourced fonts. |
|
I used to love the League of Moveable Type, but I don't think they are built for the web as with such emphasis as HFJ are. They just have lower quality in terms of rendering. Another thing is that the majority of fonts are serifs and really specific display fonts, which I don't think is what we want. Also I don't think that we need to make everything that we use Open Source. |
|
Agree with @thefoxis is here, HFJ fonts are top notch for web usage. I think the other things to consider are:
More thoughts as I have them. Definitely don't think we have to go open source just because we're an open group. Best tool for the job, I say. |
|
http://www.typography.com/fonts/ideal-sans/styles/ Might fit really well with Gittip's loving personality. |
|
@thefoxis The font in the wordmark is Edmondsans. |
|
There are some good insights on localization on Wikipedia and Google has a massive guide and tooling for i18n. Still digesting the latter. I think the most interesting ones are CSS Janus that helps convert |
|
E.g.: http://www.fontbureau.com/fonts/bentonsans/ (used by Heroku). |
|
For the record, we talked on yesterday's call about the need for Gittip to work with all languages. We need to understand the implications of that for chosing typefaces. |
|
By way of brainstorming, I recall @dowski commenting at one point that contextualizing a site for China is much more than translating to Chinese. There's a whole different aesthetic to site design (much more cluttered and crowded from a Western point of view), so maybe we need to think a little deeper cross-cultural Gittip? Maybe we'll need to run gittip.asia after all and we can relax a bit about language support on gittip.com? |
|
Well, I have very little experience with creating such huge, cross-cultural/language platforms, but what makes sense to me is separating some language versions from main Gittip. Then we have absolute control over font, The key here would be how to manage separate instances or whether to get the user's language and switch fonts / text direction and couple others. I think the challenge is how to prepare proper infrastructure and handle it with minimum overhead, not find a universal font. Because if you think about Japenese, Mandarin or Arabic, these are completely different glyph sets, so afaik it's another font anyway (system one). So the goal would be to find a good webfont that supports a variety of latin alphabet localizations (Polish, Hungarian, Czech, French, German, Spanish, etc.) and come up with a strategy for those who are entirely different. I think that sounds reasonable? I've tried searching for writeups on similar strategies but failed so far. |
|
@thefoxis - Basically, find a single font that covers all of Europe. Then address the font issue per language after that. If that's accurate, then I agree. I can find lots of fonts that have a wide range. In fact, Noto Sans has a lot of support and Google seems dedicated to expanding that support. But I can't seem to find anything decent that covers such a huge range. To keep moving, I think we go with your approach. |
|
@whit537 — any opinions on back-end implementation for language support? I think we've came up with reasonable approach. |
+1. Thanks for doing the legwork, @thefoxis. This means that we could go with Ideal after all. I believe last we checked @mtrythall and I were +1 on Ideal, and @thefoxis was +0. Is that still accurate? Can we move forward with Ideal? |
|
I'm +1 on Ideal if it suits our coverage needs 👍 |
@thefoxis We're discussing backend i18n on gratipay/gratipay.com#957. Do we want to block on that for our redesign project? |
Sweet! So let's proceed with Ideal and see what it looks like in actual use. :-) |
|
I was only pointing out that we'd need to address other languages somehow, I think the default browser behavior is to use whatever system font available to render needed characters. So we should be save with Chome translate, I'd presume. As for proper i18n I defer, we can implement whenever, it's more of a back end thing to swap all copy, and adding a dropdown with a language picker isn't a big deal. Yay! :) |
|
🐣 |
|
IRC ftr. :-) |
|
how do we sort out Typography.com? @whit537 I think you should set up an account (it's a yearly subscription) and add ScreenSmart Ideal Sans. First five packages are free. The question is whether we buy the desktop version — I'd need that for the design + at some point it might be usable for PDFs, any print materials and such. So it would be useful to own it. Unfortunately HFJ doesn't have desktop sync as Typekit. If we decide to buy we should just get Ideal Sans base package (I think?) and the web versions are automatically added to the subscription. |
|
Made an account. Reading up.
http://www.typography.com/faq/question.php?faqID=15 Wuh? Does that sound right? |
|
|
Groan. |
|
Okay! I've added What's next, @thefoxis? Are you saying that you also need a desktop version in order to proceed? |
|
You get the source files when moving to production. The only bottleneck is that they generate a folder with files that you need to upload to a directory that you specified, and then once you hit publish it actually pings the server to see if it's there. So no-go for automatic deployments and such. But if you don't modify the project you do it only once. I guess that's the price for not depending on JS injection (Typekit, Webtype and such). @whit537 — desktop versions would be useful, otherwise I can't really use it in the design phase. I own Whitney and Gotham, but not Ideal Sans :( |
Whoa whoa. What? :) That's just the directory contents that can't change, right? So when it "generates a folder with files", what are these files? Just font files, so only font choice can't change? |
|
Yeah.. well, we've been there at &yet. What I mean by no automatic deployments is that when you change fonts within the kit (let's use Typekit terminology) they give you another folder, with a different name. So you need to upload it again and let them ping the specified server for it. So no for automatic deployments when you change the font set (like font widths, add new typefaces). I've pointed it out to HFJ that their process is broken. |
|
Phewf 👍 |
We decided in #5 to use Ideal Sans. I found it unsuitable for large swaths of body text like we have here on BG. Here I'm trying out the expansive Surveyor for body text.
IRC
The text was updated successfully, but these errors were encountered: