...more recent posts
Excellent news: Jobs announces native 3rd party SDK available for iPhone and iPod Touch development in February.
Let me just say it: We want native third party applications on the iPhone, and we plan to have an SDK in developers' hands in February. We are excited about creating a vibrant third party developer community around the iPhone and enabling hundreds of new applications for our users. With our revolutionary multi-touch interface, powerful hardware and advanced software architecture, we believe we have created the best mobile platform ever for developers.Nice. That's exactly what I wanted to hear. I was beginning to worry they were thinking they could do it all themselves.
There are a few details that could still make this slightly less than perfect, but we won't know until February. I don't mind the wait, I just hope it is as open as possible. In any case, great news that Apple still gets it.
The broadest claims in Amazon's one-click patent have been struck down. Score one for the side of reason.
I've taken a part time job - supposedly 20 hours a month - at a fairly large magazine website. Basically I'm tweaking CSS and HTML with a little bit of javascript fixing along the way. Not exactly my strengths, but I think I'm good enough now to get the job done. Eventually they want to do blogs and other things that are a better fit, so hopefully it will morph into that eventually. In the meantime I'll at least have a little bit of standardized income. Living job to job is hard on the brain.
I'm going in this afternoon for a meeting, but mostly I can work from home.
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.
Felix Salmon makes the economic case for full rather than partial RSS feeds. Amen. You might also just make the don't needlessly harass people trying to read what you write case, which I guess is what his economic case boils down to.
I'm still not on board, but Adobe is building some impressive web development tools. Their latest release preview (release some time next year) is Thermo, a graphical editing environment aimed at bridging the gap between old style (photoshop) designers and web coders.
You just import a photoshop mock-up of a web page (what can now be more and more thought of as a web application user interface,) and Thermo understands all the layers and provides a 'convert artwork to...' command which automatically converts, say, a dummy text input field from the mock up into a real text input field (or button, check box, combo box, date picker, color field, etc...)
Sounds good for big shops with more graphic know how than web knowledge. Not sure I want all those people being able to compete with me (and it's not clear that Thermo will actually let them and/or if it will just end up enabling a lot of half baked web apps in a Visual Basic sort of way,) but I have to admit that Adobe is cranking out a lot of cool sounding tools.
Destination Moorestown. Due in the second half of 2008, this Intel chip is slated to bring the power of todays desktop computers to your portable devices.
The article also has an interesting post script on the inevitability of the x86 architecture.
WebRunner is a simple XULRunner based browser that hosts web applications without the normal web browser user interface. WebRunner is based on a concept called Site Specific Browsers (SSB). An SSB is an application with an embedded browser designed to work exclusively with a single web application. It's doesn't have the menus, toolbars and accoutrement's of a normal web browser. Some people have called it a "distraction free browser" because none of the typical browser chrome is used. An SSB also has a tighter integration with the OS and desktop than a typical web application running through a web browser.Could this be an open source Adobe Air (which used to be Adobe Apollo if you've been following along here) competitor? I'm intrigued.
Here are some introductory posts from the creator: site specific browsers, webrunner, using webrunner.
I'm having a hard time pinning this part down though: "An SSB also has a tighter integration with the OS and desktop than a typical web application running through a web browser." Specifically, how much access to the local filesystem do you have? Does it support drag and drop of files into / out of the application?
I'd love it this turns out well since I really like the direction Adobe Air is taking, but I'm nervous about getting on board with an all Adobe technology. And, of course, this sort of solution only makes sense for a really specific problem - but it just so happens I have one of these problems. I'll dig more and follow up in comments.