...more recent posts
I'm not sure it will work, but this is an incredible idea in the "what really simple thing that could make tons of money has no one thought of yet" sort of way: Vidoop Secure
Vidoop's engineers (led by a CTO who is ex-Microsoft) have developed software that finally improves upon the leaky "user name + password" method, replacing it with a process of image recognition based on a grid of pictures displayed on the screen.That's really brilliant. Again, I'm not sure it really solves a pressing enough problem, and getting people to change the way they log in to sites might not work no matter how clever it is. But damn, that's clever.
But here's the really clever part: Vidoop will monetize the process by selling the images in the grid to advertisers for product placement. Instead of seeing a generic car in the image grid, consumers might see a Ford (F) Mustang, or a Prius (TM) . Instead of a cuppa Joe, they might see a tall Starbucks (SBUX)....
Here is how it works: When you register on a new site, you're asked to pick three categories. Suppose you choose cars, planes and beverages. When you log in, Vidoop's image grid pops up with a display of 12 images, pulled at random from Vidoop's database. You never see the same combination of images twice - but there will always be a car, a plane and a drink.
Inside each image is a letter or number, also randomized. The letters and numbers displayed in the car, drink and plane act as a pass code for that single login. Since images and characters are chosen at random, no two logins are ever the same. This curbs the riskiest kind of hacking, says Sontag: "It is impossible to keystroke-record this," Sontag says.
I what is possibly huge typographic news for the web in general, the latest WebKit nightlies now support the CSS @font-face rules.
Attempt at a short explanation: WebKit is the open source engine that powers the Safari browser (but also Opera, Shiira, and web browser in the Nokia S60 platform.) A "nightly" means the very latest version supports this (with new versions compiled every night,) but not yet the latest stable version (so the version with @font-face support isn't shipping yet, but because it's open source you can go and download it if you're brave.) And finally the CSS @font-face rule is a CSS rule that allows web designers to embed custom fonts in a web page. If the local computer doesn't have that font-face it will go to the supplied URI and download the font so it can render the page correctly.
If that doesn't sound like a big thing to you then you're not a graphic designer.
The reality check here is that only TrueType fonts are supported (that's not so bad actually,) and, of course, only WebKit is supporting this standard so far, so you really can't count on this working when designing for the web at large. Still, you can use it, and your pages can look amazing in Safari (or incredibly bad if you're a bad designer I guess,) and then just fall back to Helvetica or some other boring font-face in other browsers.
A List Apart has a good overview of @font-face.
Obviously I've been following and thinking about Adobe and their plans for web development. At the same time I've chosen a different route, with the open web standards of HTML, CSS, and javascript. Adobe Flash and Flex and AIR are some seriously cool tools that give you access to very rich features and, comparatively, a lot of speed. These two different paths are obviously in competition (if not economic, at least for developer hearts and minds,) but they are also closely related. Adobe has clearly been moving to make javascript a first class citizen in it's environments (for instance, you can build AIR apps with all javascript and zero actionscript.)
And this makes me wonder about Tamarin, which is an open source project that is Adobe's contribution to Mozilla. The basic point is to make javascript really fast. Which is great. And great for Adobe since they are now leveraging javascript in their development world.
But I wonder if they are rethinking their decision in light of the progress that projects like EXTjs have made building a development framework on top of pure HTML, CSS and javascript. Sure it will never have all the rich features of the Adobe environments, but some constraints are not always a bad thing (especially where those constraints force you to use the native widgets people expect to see on the web, and to build regular web pages that work the way people expect.) Plus the technology is all open and free for the developer. But there is a real issue, and that's speed. EXTjs (as well as any of the others like jQuery, YUI, prototype/scriptalicious, etc...) apps are slow compared to their rich Adobe conterparts. Really slow in some cases.
In the future, no doubt, this won't matter so much. Our computers will keep getting faster. And then there is Tamarin out there on the horizon ready to supercharge javascript 2. Which brings me back to my question. Why would Adobe want to contribute Tamarin? Seems like a radical speed up of javascript is going to make EXTjs et al much more competitive with Adobe's projects.