Live data from Hacker News

IBM Type

ibm.github.io

61–70 of 130 posts

Re: IBM Type

#61
post #26

Earlier quoted context omitted.

> And the biggest png files are not even pngcrushed... Makes sense (that they are not) if the difference is just ~20% as in here.

In nearly every subfield of computing, along nearly every metric, most people would kill for a 20% improvement. A processor 20% faster would dominate the market for years. A new compression algorithm that was 20% smaller would be either copied or used by every archiving system. And yes, a website reduced by 20% is significant.

>In nearly every subfield of computing, along nearly every metric, most people would kill for a 20% improvement

I doubt it. 20% is not even worth to turn a straightforward algorithm to a more complex and convoluted (but more performant) one, or to switch backend technology, or db store, etc.

As for a "20% faster processor"? Big deal, I was raised in an era when we got 2x faster processors every 2 years.

(Besides, we do have processors that are 20% faster than others, and they don't "dominate" the market, even at the same price range some might go for perceived quality stability -- e.g Intel vs AMD, over the small speed increase).

>And yes, a website reduced by 20% is significant.

To whom? It's as if people never heard of opportunity cost.

Just go measure how many websites, even leading ones, go to any great measure to reduce such bloat, and you'll find that it's not that significant in the real world. Up to a point, of which 20% is not even close, you can be bloated without punishment in the modern web.

Re: IBM Type

#62
post #21

Great page, it only took 13s to load. With no wonder when it takes 13.8 MB. And the biggest png files are not even pngcrushed... du -ch editorial-1.png editorial-3.png product-1.png product- 2.png product-3.png product-4.png 2,5M editorial-1.png 832K editorial-3.png 368K product-1.png 288K product-2.png 284K product-3.png 1,2M product-4.png 5,4M total vs pngcrushed: du -ch editorial-1.smaller.png editorial-3.smaller.…

It also looked messed up on mobile - the nav bar took up 20% of the screen. Definitely a point in favour of the motherfuckingwebsite.com school of thought.

Motherfuckingreat style guide! Thanks for the laugh - for which partially the wording is responsible and partially it‘s the hopelessness of a „so true, but it will unlikely ever change towards the better“...

Re: IBM Type

#63
post #3

While interesting, is this really necessary? Call me skeptical, but value add = negligible, justification for an entire department to spend several months+ working = likely. I can see why companies like Apple and Microsoft would want to be involved in making fonts, they make their bread and butter by creating warm-fuzzies and having a consistent design language; IBM though, less so? Genuinely interested to hear other…

> IBM though, less so? Why would IBM not also benefit from a consistent design language? Irrespective of what people might think of their products, they are involved in a wide range of business sectors (services, desktop, mainframe, AI, etc.) and I would have thought that consistent typography would help to give them a more integrated feel. Sure there is an element of "me to" about this - Google, MS, Apple, even Orac…

You can have a consistent design language without creating your own font though.

Re: IBM Type

#64

Never use pure black (Hex value: #000000) for text, but instead, a range of grays. This irritates me greatly. I can understand somewhat the justification against pure white (a poor attempt at compensating for monitors being set by default to insane levels of brightness), but pure black? It doesn't make sense to reduce contrast this way.

An art professor instructed me that black pigment paint was to be avoided as it makes the image look flat. Rather, a black-like colour is to be built in layers of darkening shades. I could see this applying to graphic layout with multiple colours, but I'm not sure if it fits for printed type.

Re: IBM Type

#65

Earlier quoted context omitted.

It also looked messed up on mobile - the nav bar took up 20% of the screen. Definitely a point in favour of the motherfuckingwebsite.com school of thought.

I remember websites. I miss them dearly.

Pepperridge Farm remembers

Re: IBM Type

#66

Earlier quoted context omitted.

> IBM though, less so? Why would IBM not also benefit from a consistent design language? Irrespective of what people might think of their products, they are involved in a wide range of business sectors (services, desktop, mainframe, AI, etc.) and I would have thought that consistent typography would help to give them a more integrated feel. Sure there is an element of "me to" about this - Google, MS, Apple, even Orac…

You can have a consistent design language without creating your own font though.

Yeah, I think web sites that insist on having their own fonts are being a bit narcissistic. The user should have the fonts that are pleasing to their eyes installed and their browser should use them. Web sites insisting they know better have too many people doing design. Go ahead and cut that cost, we won't notice.

Re: IBM Type

#69

Earlier quoted context omitted.

I just heard of pngcrush for the first time. I usually use optipng. Any insight which is better?

I realise this doesn't answer your question, but there's a nice macOS GUI with multiple crushers built-in: https://imageoptim.com/

Also take a look at ImageAlpha - https://pngmini.com/ - great for single images (happy fan of both!).

Re: IBM Type

#70
Thanks for the love and critique. Issues are love too: https://github.com/ibm/type/issues/new

Some things to keep in mind:

— v1 will not be released until early next year. We published publicly so it is easy for teams to test and give feedback.

— The documentation site was a quickfix and will merge into a silky smooth GatsbyJS site later. Give that project some love at https://github.com/gatsbyjs/gatsby

— We are constantly making breaking changes until v1 based on font-loading performance, design specs, and more

Post reply on HN