I wonder if Samuel Segal feels similarily.
“Ugly as a Mass Experimentation of Learning is Pretty Damn Cool.”
Here’s the standard complaint about using @font-face in a website:
“Windows XP doesn’t seem to do anti-aliasing very well,
and even with Clear Type enabled, the custom fonts can look jagged and rough.”
Here’s my standard reply:
Fontue Font Optimization Workflow – Open Sourced
With the Fontue web font server open sourced, I’ve done the same for the workflow scripts I use to to generate the fonts for @font-face use.
It’s a pair of scripts that pipe fonts in and out of other conversion programs like FontForge, sfnt2woff, Batik, and EOTFast. Along the way, doing a little clean up of the font file itself.
These workflow scripts are now included in the Fontue source code.
Kernest’s Web Font Serving Engine – Fontue – Now Open Source
I’ve talked to a number of people and organizations that want to start adding web fonts to their websites – but aren’t comfortable relying on a third-party service for something so integral to their online presence.
With that in mind, I’m pleased to announced that Kernest‘s underlying web font serving engine – dubbed Fontue – has been released under the MIT License.
Fontue is designed to be the lightest, fastest way to serve web fonts to @font-face supporting browsers while saving bandwidth and keeping CSS clean and readable.
Get more information at Fontue.com or download the latest version from Github.
An iPad App I’d Like to See – Shorthand
Inputing anything on the iPad more complex than – ‘I want that’ – is frustrating, even moreso with the keyboard.
The thought of taking notes on the iPad during meetings is still ridiculous. And I started wondering how people quickly took notes before we all became such proficient touch typists.
The idea of a single gesture representing a word (or series of words) rather than a single character is very appealing. And with a Javascript library like Raphaël, this could even be a web-based app.
Shorthand has least as much of a learning curve as QWERTY.
How Media is Like a Camera Lense
A Message on the Space Telephone Answering Machine
Dave Slusher’s clambake from April 6 2009 accompanied me on my between meeting drives today.
Yes, you read that correct – 2009.
A podcast he recorded more than a year ago.
It’s a great listen. He discusses how the people publishing to services like Twitter don’t own their own words. The company does. And the company – rather than the community – decides on the direction to take the service. Offline – there’s even a name for this type of arrangement.
Following that thread, Dave works through the burn out of being on the receiving end of a firehose of continuous ephemera – for a year. Or longer. And how publishing tiny bits continuously hampers publishing bigger, more substantial bits.
Dave also includes a cover of Daniel Johnston’s ‘Walking the Cow’ by Kathy McCarty. It’s a song fIREHOSE introduced me to. Mike Watt‘s ambling bass line has an immediate calming effect on me – not unlike disconnecting from the real-time stream.
It’s one of my all time favorite clambakes. Thanks Dave.
the title of this post references an even earlier Evil Genius Chronicle
Demanding
Ironic given the internet’s origins as a national defense project.
Though, the same problem exists with our nation’s highway system.
Back in art school – I built a table that fell apart when anything was placed on it. No, that project was not funded by DARPA.
What if You Forced Apple into the App Store?
If you’ll recall, back when the iPhone was first released, Steve Jobs declared the best way to build apps for it was to build websites.
To which John Gruber replied:
Since then, Apple released the App Store, an iPhone Developers SDK, and has made “there’s an app for that” so popular it became its own meme.
And despite Apple’s restrictions – the $99 Developer registration fee, faxing your business incorporation agreements to sell as a business, only using Objective-C and Apple development tools, Apple needs to accept your app & subsequent updates – there’s huge demand for building native applications in the iPhone.
But there’s big money to be made selling native apps! Well, maybe [1].
All of Apple’s restrictions are disincentives to build native apps.
And I’m confident Apple knows it and is encouraging it.
If you’ve spent enough time within the iPhone (or iPad, iPod Touch) you’ll notice some very interesting inconsistencies between how native apps behave (especially Apple’s own) in contrast to Safari. Inconsistencies that make me think Apple would still prefer you just built web sites.
The biggest example:
- Load up a web page within Safari
- Click ‘+’
- Now click ‘Add to Home Screen’
You just put an item (a web page) that lives in Safari on your iPhone’s home screen.
If the web site publisher included <meta name="apple-mobile-web-app-capable" content="yes" /> in the header of the web page, it will display full-screen when you click it. Just like a native app.
Now, load up Music, Videos, Photos, Mail, or Maps and figure out how to put one of the items on your home screen.
Yeah, weird, huh?
Makes complete makes sense if Steve Jobs is true to his word – the best app for the iPhone is web-based one rather than native.
There’s no downside to releasing an SDK with all its restrictions and taking developers’ money. At worst Objective-C receives more attention, few more Macs are sold as development boxes, and the membership fees pay to keep Apple’s crazy restrictions in place.
Notice as well, that Apple still permits Javascript-based apps in their App Store.
It’s like we can’t take a hint.
1. In a recent survey of 100 iPhone developers:
“But app developers want to make money, and Apple benefits most when they don’t. – Andrew Benton”
“Half of all [iPhone] developers will earn less than $682 per year.” – Tomi T Ahonen
In fact – Apple benefits from little to no app sales in the same way Google benefits from little to no AdWords clicks – no need to pay out.
Elsewhere:
URL Shorteners Are So Last Year
URL shorteners were all the rage in 2008 and 2009 – primarily due to the character constraints within the short messages service that was all the rage in 2008 and 2009 – Twitter.
URL shorteners take a long url, for example, this Google Map url:
and transform it into something like: http://tinyurl.com/y3lxdru
Every URL shortener uses their own magic sauce to create the short random string - i.e. the 'y3lxdru' part - and stores right next to the long URL. So if there's a tiny.cc/y3lxdru or a j.mp/y3lxdru - they probably don't point to the same Google Map. In fact, if I understand how bit.ly (aka j.mp) works - their shortened URLs only exist for a few months - and then are 'released' (that's how they're able to keep them short). I even created a automatically expiring URL shortener cause I thought it was funny.
When someone clicks on the short URL, the URL shortener (tinyurl.com in the example above) promises to look up the long URL stored next to the short random string - and promptly redirect you to the location of that Chinese restaurant for your lunch meeting. And not some place unseemly - which has happened, more than once.
There are lots of problems with URL shorteners. I feel qualified to say this because I build 3 of them in the past 2 years (Culld.us, RE07.US, and a native WordPress hack, none of which are currently active).
At best - they make less usable URLs - because both the URLs shorteners domain name and the random string are meaningless (not to mention hard to remember) to people.
At worst - this obfuscation means every short URL clicked is more of a potential computer security risk than normal clicking around the internet.
A 3rd party URL shortener shouldn't be necessary to make Google's Map URLs shareable. Same goes for any other website - URLs can and should be constructed to be reasonably short, human readable, guessable, and accountable. URL design is one of the most under-appreciated aspects of website usability (as is scrolling).
"URL shorteners are cheap hacks apologizing for poor content-management-systems"
For the past 6 months or so - Twitter has been the only real reason to use a URL shortener. Facebook and other services are now doing a better job of handling long URLs. Many people and companies use URL shorteners as hack for not having a good web site statistics package. Additionally, Twitter has made noises like they're going to default to their own URL shortener in the near future - a move which will promptly shorten the already tiny lifespan of other URL shortening services.