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.

 

VillainousStyle is a drawing library for defining a visual style from a chain of individual drawing instructions. Each instruction modifies the drawing context to perform common operations; such operations include shadows, fills, borders, and shapes. It allows for multiple style sheets which can be used to theme an application in multiple visual contexts. VillainousStyle sits on top of CoreGraphics, and does not use WebKit for rendering at all. It is a fork of the VSStyle and VSShape classes, originally from the Three20 project.

Stylesheets

VSStyleSheet is an abstract superclass for a set of styles. Subclass it and add methods for each style you wish to add. You will likely want to create a protocol for your styles to implement, to ensure that your stylesheet implements all the necessary styles.

There is a global stylesheet, which can be thought of as the "active" stylesheet. Call +[VSStyleSheet setGlobalStyleSheet:] to change the active theme, which will fire a VSStyleSheetChangedNotification. When that gets fired, you'll want to tell your views to update their styles and redraw.

Styles

Styles affect drawing and positioning. Most will affect the next VSStyle objects in the chain.

  • Fills
    • VSSolidFillStyle - Fills the current shape with a solid color
    • VSLinearGradientFillStyle - Fills the current shape with a gradient between two colors
    • VSReflectiveFillStyle - Fills the current shape with a glossy-style gradient between two colors
  • Borders
    • VSSolidBorderStyle - Draws a border around the current shape with a solid color
    • VSBevelBorderStyle - Draws a beveled edge border for a 3D effect around the current shape
    • VSFourBorderStyle - Draws a border around the current shape with four colors, one for each edge
  • Shadows
    • VSShadowStyle - Draws a shadow behind content with a given color, blur, and offset
    • VSInnerShadowStyle - Draws a shadow inside the content with a given color, blur, and offset
  • Positioning
    • VSBoxStyle - Adds a margin or padding to the content area
    • VSInsetStyle - Adds edge insets to the content area
  • Content
    • VSTextStyle - Draws text inside the current shape
    • VSImageStyle - Draws an image inside the current shape
    • VSMaskStyle - Clips the drawing area to an image mask
    • VSShapeStyle - Clips the drawing area with a VSShape object

Shapes

Shapes affect the fills and borders, but do not clip the content styles.

  • VSRectangleShape
  • VSRoundedRectangleShape
  • VSRoundedLeftArrowShape - a rounded rectangle with a left-facing arrow
  • VSRoundedRightArrowShape - a rounded rectangle with a right-facing arrow

Future Ideas

  • iPhone static library
  • Cappuccino library
  • File-based stylesheets that can be read/written from VSStyleSheet objects
  • GUI builder for styles
  • More styles!

Status:

Active

 

This one is for all of those developers out there who scoff at JavaScript. This is a working neural network algorithm in JavaScript used for ripping apart CAPTCHA images (in this case, from Megaupload) and deciphering them. This is really sophisticated stuff, and even though Megaupload has some pretty easy CAPTCHAs, this should be pretty easily adaptable to other CAPTCHAs.

 

The new WhiteHouse.gov web site went live at exactly noon. It's got a blog, RSS feeds, and is powered by jQuery.

, , ,    Tags
 

There's been quite a bit of misunderstanding about what Palm's new WebOS is, versus what it isn't. So I'd like to dispel some of the questions surrounding it from the information I've been able to find on it. There isn't much I was able to find (not surprising, as the thing was just announced today), but we can draw some conclusions from the information.

From Web Apps to Widgets

Many people will respond with derision at the fact that applications in WebOS are built with HTML, CSS, and JavaScript; given the state of most web applications today, this isn't hard to understand. However, the biggest reason web apps are crap compared to their desktop equivalent is that web apps have no integration with the host OS. Which means that web apps have a tough time dealing with multiple OS windows, the clipboard, and offline access.

When Apple released Tiger, they shipped with it the popular Dashboard interface. Inside were miniature applications which were also written with HTML, CSS, and JavaScript. There was a slight difference, however; Apple included the means to integrate the Dashboard with JavaScript. One example is how a Dashboard widget will display its settings via a smooth, GPU-accelerated 3D animation where the 2D widget flips over. This is possible because Apple included JavaScript hooks to perform this animation. But the core tools were just the same - HTML, CSS, and JavaScript.

The Mojo Framework

WebOS applications are much more sophisticated than Dashboard widgets, and certainly more so than regular web applications. This is because WebOS includes a set of tools for creating apps, called the Palm Mojo Application Framework. This, at its highest level, is conceptually similar to Cocoa Touch on the iPhone; it provides common functionality to all applications. It's what will provide all the common code on the device, from data manipulation of stuff like your calendars to the whizzy animation effects you'll see throughout the interface. It's the reason that, in most iPhone apps, the scrolling behavior feels exactly the same.

So, from what I can tell, the Mojo framework is an implementation of all of these ideas, using JavaScript as the programming language, and using HTML5 and CSS for drawing to the screen. Despite there being very little information, they do mention the following features on the developer website:

  • apps are installed and run on the device,
  • apps are designed to be multitasked and run in the background,
  • apps have full access to gestures and the touch screen,
  • apps can use a Growl-esque system to display user notifications,
  • apps will have access to sqlite databases for data storage (part of HTML5), and
  • apps can exchange data via a common messaging mechanism.

The Performance Argument

"But won't it come down to speed?" Yes, it will. However, WebOS is based on WebKit, and likely is using the latest enhancements from the SquirrelFish project. There is a battle royale going on right now between the developers of WebKit, Firefox, Chrome, and Opera for fastest JavaScript interpreter, which means that JavaScript is only going to get faster and faster.

Why go with JavaScript? It provides a low barrier to entry; nobody really needs an SDK to write apps. It makes it very easy to sandbox apps, as the underlying operating system is still invariably written in some form of C, and JavaScript provides no way to break that barrier. And many other reasons, which I talked about last year before the iPhone SDK came out.

tl;dr: JavaScript is just a language. Palm used that to build a system for making applications. They're nothing like web apps.

 

This is big news, because WebOS is supposed to be their big SDK, and it's all based on WebKit. This means their JavaScript engine will probably be JavaScriptCore (with the enhancements from the SquirrelFish project).

 

The interface looks to be pretty snappy, although there was a little lag when they were doing web browsing. Here's hoping that gets ironed out before release.

 

I'm dying to see a video of this in motion. Their new developer platform appears to be very similar to Dashboard on the Mac; apps are written with CSS, HTML, XML, and presumably JavaScript.

 

I totally agree with Chris on this one. We are only now getting to the point where users are being exposed to significantly more complex web applications. Atwood is arguing against innovation in that space; I say embrace it.