Adobe is finally putting an end to Flash Player. They’ve announced they’re stopping development of the mobile Flash Player, which is where the future of tech innovation is heading, and the writing is on the wall for desktop Flash Player as well. This is a good thing for a myriad of reasons, both technical and political.

However, it is important to remember that Flash drove much of the innovation on the web as we know it today. When Flash was conceived over a decade ago, the web was a glimmer of what it is today. Creating something visually impressive and interactive was almost impossible. Flash brought the ability to do animation, sound, video, 3D graphics, and local storage in the browser when nothing else could.

Without Flash, MapQuest would not have been able to provide maps for years before Google did in JavaScript. The juggernaut YouTube would not have been possible until at least 2009, four years after its actual launch. Gaming on the web, which has been around as long as Flash, would only now be possible a decade later. Flash enabled developers to create rich user experiences in a market dominated by slow moving browser developers. Even in 2011 Flash exists to provide those more powerful apps to less tech-savvy people who still use old versions of Internet Explorer.

Flash Player itself seemed like a means to an end. Macromedia, and then Adobe who acquired them, sells the tool that you use to build Flash content. Thus, Adobe’s incentive was not to build a great Flash Player, but a pervasive one that would sell its tools. Its technical stagnation provided a market opportunity for browser developers to fill in the gaps that Flash provided. As a result it has a huge market dominance in tools for building rich apps for the web, tools HTML5 lacks.

This puts Adobe in a unique position. As HTML5 continues to negate the need for Flash Player, Adobe has the tools for implementing Flash within HTML5, and the market eager for those tools. Hopefully this move signals that Adobe will be moving in this direction. Because the web DOES need great HTML5 tools for people who aren’t savvy in JavaScript, especially for the people who used Flash to do it previously.

HTML5 offers developers the ability to build high-performance, low-power apps and experiences. Browser innovation has never been faster; Apple, Google, Microsoft, and Mozilla are all competing to bring the best new features to their browsers in compatible ways. But they’re just now filling in many features Flash Player has had for years. Adobe can harness this to help build a better web, and few others can. Hopefully they seize this moment.

Twitter recently introduced a feature on its website called “Who To Follow”. This feature presents you with a list of people you aren’t following already, but who are active in your social graph. However, I happen to be very proactive in finding new people to follow through a variety of means, and have no need for Twitter to point it out to me. I thought it was a bit obnoxious to see, especially considering both of my first recommendations were people I had blocked.

This Safari extension removes that box from the Twitter homepage, whether you have it turned on for you or not. It’s a simple CSS stylesheet that sets display:none on that box. You’ll never have to see it again.

You can download it here. I’m still a bit new at Safari extensions, but it should auto-update in the future if I ever release an update.

Update 9/18/2010: Follow Freely 1.1 has been released, with support for the new Twitter web client. It also fixes the issue where Safari would constantly say there was an update available.

I finally got around to fixing my Chyrp installation, so I can resume my bloggingness. I still quite enjoy Chyrp, so I’ve upgraded it to 2.0 final and am back to using it again. I’ve made some changes that will hopefully improve the experience.

First, I’ve removed the ability for people to post comments. Very little good comes of enabling comments; rather, they attract spam and drive-by comments which are unproductive. Most people who do respond will do so via Twitter.

Second, the auto-posting to Twitter is still going to happen. However, many people were understandably annoyed when I would post a link to the blog, and the auto-tweet would post a link to the blog, needing to click another link to get to the actual content. I toyed with the idea of framing the link content, but popular opinion says that it’s a greedy and inappropriate thing to do. Instead, I made the following improvements to ensure that links cross-posted will be a little less awful:

  • text posts and project announcements will link to the blog,

  • link posts will have a direct link posted,

  • photo posts will be direct-linked where possible, but will link to the blog if there’s no direct link

  • video posts will link to the blog, because YouTube is full of idiots

Third, I’ve created this site design after a couple months of working on it, named Cream. It’s meant to be extremely minimalist and to emphasize the page content. It’s nearly complete, and will be open-sourced when it’s done.

URL Shrink is a new OS X tool with a very simple purpose – converting URLs to shorter permalinks on various web services. As the internet has matured, and services like IM, IRC, and Twitter have forced us to write shorter messages, it was clear that a system was needed that was as ubiquitous as Quicksilver.

For now, the main service of URL Shrink is just converting a URL that is on the clipboard, although this will be expanding over time (including things like a system text service, a command line client, a Quicksilver plugin, etc.). To do this, there is a keyboard shortcut (option-shift-space) which will convert the URL in the background to a tiny URL using one of the services provided. If you’ve selected one as your favorite, it’ll choose that one. For example, I’m personally partial to is.gd, so all the URLs that are processed by URL Shrink on my machine go through is.gd.

At a low level, URL Shrink is a system where multiple shrinking engines can be added. It was designed to be extremely easy for developers to write just a little bit of code to integrate with other web services, including private URL services. For information on that, see the project page below.

URL Shrink is licensed under the BSD license. I encourage its adoption within other applications; I’ll be adding .framework and .a targets for building this into Mac and iPhone apps respectively. Indeed, the project was born out of the URL shrinking capacity of another app I’m working on.

I don’t know how true or untrue this rumor is; personally, I’m leaning against it. However, it’s prudent to mention some recent events around SproutCore, the JavaScript framework Apple uses to write the MobileMe web apps and the MobileMe Web Gallery.

Apple has recently made a large commit to the SproutCore project on GitHub, which was stuck getting clearance from Apple’s higher-ups for awhile. Here’s a post from Charles Jolley briefly talking about their 1.0 march, dated 12/5/2008.

I haven’t personally taken a look at what the changes in Bitburger (the name of Apple’s branch) entail, so I’m not sure they’re more geared towards developing an application like anything in iWork. Just food for thought.

I’ve just finished moving from WordPress to Chyrp, which aims to be something like a self-hosted version of Tumblr, which should give me flexibility to extend the blog to do things like integrate web services. Since I don’t write full-on blog posts as frequently, I’d like to get in the habit of writing smaller posts, as well as sharing links and videos.

There are different categories for different types of posts (links, videos, texts, etc.). Each has individualized RSS feeds; just add “/feed” at the end of the URL and magic should happen.