Coding In Paradise

Turbotax and Intuit Just Lost a Customer

noreply@blogger.com (Brad Neuberg) — Mon, 13 Apr 2009 03:58:00 +0000

I've been a huge fan of Turbotax for years, including it's maker Intuit. I've always considered Intuit a master at making customer-friendly and usable software, and putting the end-user first. I've used the online Turbotax to file my returns for about the last decade, always happy with the result.

This is why I was especially surprised this year to see what must basically be price-gouging by Intuit. In years past I ran my own business and therefore paid for a much higher priced option. Now that I no longer work for myself I need to use a lower-priced version (the price difference is significant). Turbotax and Intuit give you a way to _upgrade_, but no way to downgrade. In fact, you have to literally delete your account and create a new one (with none of your years of tax return info carried over) in order to choose a lower priced Turbotax option. Here is their official answer in the help section:

"Can I Switch Back to a Lower-Priced TurboTax Online?
Updated: 1/22/2009
Article ID: 2659

Once you've started preparing your tax return with TurboTax Online, you can upgrade your TurboTax Online product to Deluxe, Home & Business or Premier to take advantage of the extra features and tax guidance available in those products. After you've upgraded to one of these versions, your tax information will transfer to the upgraded version automatically. However, to switch back to a lower-priced version, you'll need to start a new return with a different User ID, as there is no option to switchback to the previous version once you have upgraded your product.

Important: If you decide to start over in a new return with a different User ID, you will not be able to transfer previous year's returns over to the new account."

This is so a conscious price gouge. Especially in this economy where folks job situation can change it's especially surprising.

Congratulations Intuit! You've turned a loyal decade-long customer into someone now looking for other options. Yes, I'm going to pay the higher price this time because I don't want to lose my data and am running out of time around my taxes, but don't expect to see me around next year. I tend to be a pretty loyal customer, but this is so blatant that it surprised me.

Has anyone else run into these issues?

SVG Has A Posse... and his name is Doug Schepers

noreply@blogger.com (Brad Neuberg) — Thu, 02 Apr 2009 08:56:00 +0000

One of the great aspects of working with the SVG community has been meeting some of the cool folks inside of it. I got a chance to meet one of these people, Doug Schepers, recently. Doug is great and alot of fun. He got involved with SVG a few years ago and then spent thousands of dollars out of his own pocket in order to join the W3C as an individual and influence its direction in a positive way. Now he is fully helping to define and steward SVG as a W3C Member, such as with the recent CSS + SVG work going on to use CSS in order to apply SVG effects that Safari submitted.

Doug is like the posse for SVG, making sure it goes in good directions. This inspired me to mockup that SVG has a posse, with Doug's image:

I wrote it in SVG of course, using Inkscape. Click through it to see the SVG file. This is of course based on the famous Andre the Giant Has a Posse posters by Shepard Fairey.

So Moved - And the Pursuit of Happiness Blog - NYTimes.com

noreply@blogger.com (Brad Neuberg) — Sat, 28 Mar 2009 05:00:00 +0000

So Moved - And the Pursuit of Happiness Blog - NYTimes.com: "The 4th biggest city in Brazil, 2.5 million strong, votes by direct ballot on the city budget. The city provides training and the budget process and some tens of thousands participate. As a result they've eliminated hunger and illiteracy. Why not NYC and Omaha and LA. Let's get busy and spread the word. And just in case you're skeptical, keep in mind that the idea of electing leaders would have seemed quite absurd not all that long ago in history!"

Absolutely fabulous graphical blog entry on that page as well.

Good Quote on Innovation Vs. Standardization

noreply@blogger.com (Brad Neuberg) — Thu, 26 Mar 2009 01:00:00 +0000

Ajaxian: 3D APIs are coming to the Web in force: "...it's completely silly to say that browser vendors have given up on advancing the open web through standards. For one, they're doing that in W3C right now, but what they do in TKG and in a number of other places (e.g. OMTP) - just because you haven't heard of them doesn't mean they're not building standards - is also that. The open web is being advanced through standards more now than ever, and I think we've now more or less figured out the experiment-specify loop in a way that makes the ancient innovation vs standardization debate antiquated."

Garfield: 'Chaos Scenario' Has Arrived for Media, Marketing - Advertising Age - News

noreply@blogger.com (Brad Neuberg) — Mon, 23 Mar 2009 21:03:00 +0000

Garfield: 'Chaos Scenario' Has Arrived for Media, Marketing - Advertising Age - News: "For sheer poignancy, though, it's hard to beat The New York Times. With a $400 million May debt payment approaching like a runaway cement truck, the Times is selling 75% of its shiny new headquarters. More alarmingly, it has suspended its stock dividend and borrowed $250 million at usurious rates from Mexican oligarch Carlos Slim, whom a Times editorial not long ago condemned as a 'robber baron.' And if not Slim, who, Gazprom?"

After newspapers die, regional TV and radio next + possible plan for newspapers

noreply@blogger.com (Brad Neuberg) — Fri, 20 Mar 2009 23:15:00 +0000

Lots of gloom and doom these days around the newspaper industry. Here's a bit more gloom and doom for regional TV and radio.

I think we will see the death of regional TV networks soon, with probably a destabilization of the big three TV networks into a new model. I think regional radio will last a bit longer, just because most TV is consumed in the home whereas radio is consumed while mobile. Centralized broadband into the home will hasten the crumbling of regional TV, whereas the cellular networks can't stream digital radio well currently. However, the recent rapid acceleration of advanced smartphones like the iPhone, Android, etc. are accelerating the growth, speed, and general affordability of cellular data networks, making regional radio probably the third thing that will fall. As soon as we see cars that have digital radio receivers that tap into the Internet we will know the end is nigh on that front. I would expect to see them show up in high-end cars first, like the Lexus.

Here's one thing the big newspapers can do (I don't think regional TV or radio can do anything -- I think they are doomed, though they have probably 5 to 8 years):

1) Attempt to accelerate the commoditization and availability of magazine sized, full-color eInk displays. These are rapidly entering the marketplace, but color displays are probably 5 to 8 years out. If you can get the price of color down faster with a Manhattan style project, this could give you a platform necessary for high-quality ads. The tricky thing is you need to drive mass commoditization in the next 3 years, as that seems like the timeline for newspapers these days unfortunately.
2) As I mentioned above, digital cellular networks/Wifi are already falling in price pretty fast. Help spur this trend along; I predict that in 3 years digital data plans will be mainstream and quite fast.
3) The most important part: have a common billing platform and device subsidization program so that users can subscribe to newspapers on the eink devices without having to have many of them.

In all likelihood the cellular carriers themselves would become that common billing platform, doling out devices such as these. However, the carriers are kinda dinosaurs when it comes to innovations around these things unfortunately, so it will probably either be Apple or Amazon that becomes that common billing platform + device manufacturer. If only a consortium of newspapers could have made it to that point sooner...

The "Wierd" Programming Language

noreply@blogger.com (Brad Neuberg) — Thu, 19 Mar 2009 02:03:00 +0000

Somehow stumbled on this while Googling for something else:

Wierd - Wikipedia, the free encyclopedia: "Wierd is a graphical esoteric programming language developed by Chris Pressey, Ben Olmstead, and John Colagioia, in 1997...In Wierd, there are only two symbols: [Whitespace] and everything else. Non-whitespace characters are followed in lines (starting in the top left corner, going southeast), and instructions are given by every turn made to the right"

Re: SVG Feedback on HTML5 SVG Proposal from Robin Berjon on 2009-03-11 (public-html@w3.org from March 2009)

noreply@blogger.com (Brad Neuberg) — Wed, 18 Mar 2009 08:58:00 +0000

Re: SVG Feedback on HTML5 SVG Proposal from Robin Berjon on 2009-03-11 (public-html@w3.org from March 2009): "For one, one very important use case for SVG is inside an HTML document. That implies that SVG should look as natural and as local as possible, ideally completely, inside HTML. Furthermore, there is a shift in the type of people who use SVG. When it was only XML geeks and people who understood mobile constraints some things could be asked of the SVG constituency that are different from what can be asked from Joe PHP Hacker On A Deadline. Joe's smart but in a hurry, and anyway being smart he's also lazy. If it doesn't Just Work like HTML, then whipping out Flash, while annoying, will be simpler. Finally we are getting to a situation in which an implementer can grab a specification (or a library) that'll give him interoperable parsing in an HTML context. XML is a fine option for syntax-level interoperability, but it's not the only one and SVG has no reason to be married to it. SVG isn't about XML, or even syntax, it's about sassy, sexy, wicked cool graphics that make you go wow."

SVG Feedback on HTML5 SVG Proposal from Doug Schepers on 2009-03-10 (public-html@w3.org from March 2009)

noreply@blogger.com (Brad Neuberg) — Wed, 18 Mar 2009 08:48:00 +0000

SVG Feedback on HTML5 SVG Proposal from Doug Schepers on 2009-03-10 (public-html@w3.org from March 2009): "These are some of the opinions of the SVG WG on the topic of SVG-in-text/html, for consideration by the HTML WG. The opinions of individuals within the SVG WG differs; some favor a pure-XML approach, and some are more predisposed to a looser syntax, but in general, this is the state of our group consensus."

The Overton window

noreply@blogger.com (Brad Neuberg) — Thu, 12 Mar 2009 23:44:00 +0000

Overton window - Wikipedia, the free encyclopedia: "The Overton window is a concept in political theory, named after its originator, Joe Overton, former vice president of the Mackinac Center for Public Policy. It describes a 'window' in the range of public reactions to ideas in public discourse, in a spectrum of all possible options on an issue. Overton described a method for moving that window, thereby including previously excluded ideas, while excluding previously acceptable ideas. The technique relies on people promoting ideas even less acceptable than the previous 'outer fringe' ideas. That makes those old fringe ideas look less extreme, and thereby acceptable. The idea is that priming the public with fringe ideas intended to be and remain unacceptable, will make the real target ideas seem more acceptable by comparison."

JavaScript/Ajax Bootcamp

noreply@blogger.com (Brad Neuberg) — Tue, 03 Mar 2009 05:17:00 +0000

My friend and colleague Matthew Russell is putting on a JavaScript/Ajax Bootcamp that looks awesome; I wish I was in Atlanta so I could drop by and check this out! Take a look at it:

"JavaScript/Ajax Bootcamp:
Javascript/Ajax Bootcamp is designed specifically for anyone who wants to learn how to build advanced web applications, whether a novice to the arena or an experienced developer who needs to modernize his/her existing skill set.

This course uses the Dojo JavaScript Toolkit, but the skills learned can be used with any of the standard JavaScript libraries.

Upon completion of JavaScript/Ajax Bootcamp, the student will:

Be able to demonstrate extensive knowledge of DHTML (JavaScript, HTML, and CSS)
Understand the Dojo Toolkit with emphasis on building slick, interactive, advanced web applications
Understand how to use Dojo's powerful JavaScript standard library as protection from the bare metal of the browser
Be able to create custom widgets that work on all of the mainstream browsers
Be able to put Dojo's extensive collection of accessible and internationalized turn-key widgets to work
Understand how to use Dojo's build system to minify and consolidate JavaScript files and templates so pages load lightning-fast
Be able to write good unit tests for web apps -- even interactive ones -- and be able to effectively test in all mainstream browsers
Understand how to animate content and perform 2-dimensional drawing in web appliations -- all without Flash!
Have a library of tips and techniques for production settings"

Make sure to check out the Syllabus as well on the page which looks really cool.

The Two Central Questions Confronting EOT Web Fonts

noreply@blogger.com (Brad Neuberg) — Thu, 26 Feb 2009 01:26:00 +0000

There's a big debate happening about EOT vs. TTF fonts for the web. I see there being two central questions:

If EOT was the right approach, why haven't we seen any deployment by users, developers, or font vendors, even though it's been available for 10 years across 80% of the installed base of the Internet? It's been a failure, for users, developers, and the font foundries themselves who have made no money even with the pseudo-DRM scheme that EOT currently has. It's time to try something new, and TTF is that new way.
Why should fonts be treated differently than any other resource on the web? We currently don't have access controls for JavaScript files, HTML, images, text, MP3 files, etc., leaving that to legal mechanisms and technical systems out of band. One out of band solution to this is to use the HTTP Access Control spec; a font foundry could require you to use HTTP Access Control plus your TTF file through a legal contract. I already go through having to follow legal contracts when I use commercial stock photography, for example, or a Creative Commons image in a presentation or web site.

Chris Wilson is right that neither EOT or TTF are standards of any kind; they are both defacto standards, with the CSS Web Font mechanism being the real standard that all browsers now support. However, until the EOT camp can come up with answers to the two questions above (EOT has had 10 years -- why no adoption? and Why should web fonts be treated differently?) the debate about TTF versus EOT is over, with TTF having the clear verdict on the direction to move forward.

Killing the Golden Goose

noreply@blogger.com (Brad Neuberg) — Wed, 25 Feb 2009 19:10:00 +0000

Alex Russell: "The [mobile phone] OpCo's fear anything they don't own. They'd rather kill the golden goose than have an open market in golden eggs from which they'd be the
main benefactors. They're deathly afraid of becoming "dumb bit pipes"
(although that's exactly what they are). As a result, they're driven
to distraction by any hint of openness that isn't strictly in their
favor, leading them to become *stupid* bit pipes. They've made
generation after generation of walled-garden play with no discernible
positive outcome other than to continue to lock up users thanks to lax
regulation (in the US).

Competition is changing the dynamic slightly. The device vendors
loathe the OpCo's (and vice versa). They're only in this shotgun
marriage due to the oligopolistic economics of how devices are sold
and who sells them (at least in the US). But a little bit of
competition by folks with different motivations (Apple, Google, etc.)
is changing things in favor of the handset vendors."

ADC - Fundamentals Of SVG

noreply@blogger.com (Brad Neuberg) — Tue, 24 Feb 2009 18:35:00 +0000

Nice new article on the Apple site around using SVG with Safari 4; sums up some of the nice reasons to use SVG, including drastically smaller size and better image quality, with some cool demos of it on the iPhone:

ADC - Fundamentals Of SVG: "The advantages for using SVG for graphing and visualization applications are clear. Not only is it more efficient in terms of file size to use SVG, it also scales better, looks cleaner, and is easier to build because libraries are not required to create the XML. If what you want to do is create charts and graphs to display data quickly on the iPhone, SVG should be one of your tools of choice."

Shirky: The Semantic Web, Syllogism, and Worldview

noreply@blogger.com (Brad Neuberg) — Mon, 23 Feb 2009 20:01:00 +0000

Shirky: The Semantic Web, Syllogism, and Worldview via Sam Ruby: "There is a list of technologies that are actually political philosophy masquerading as code, a list that includes Xanadu, Freenet, and now the Semantic Web. The Semantic Web's philosophical argument -- the world should make more sense than it does -- is hard to argue with. The Semantic Web, with its neat ontologies and its syllogistic logic, is a nice vision. However, like many visions that project future benefits but ignore present costs, it requires too much coordination and too much energy to effect in the real world, where deductive logic is less effective and shared worldview is harder to create than we often want to admit."

Bug 478665: HTML5 spec without all the new features

noreply@blogger.com (Brad Neuberg) — Mon, 23 Feb 2009 19:06:00 +0000

An interesting discussion is happening on Mozilla's bugzilla about subsetting HTML 5, kicked off by Robert Sayre:

Bug 478665: HTML5 spec without all the new features via Sam Ruby: "Robert Sayre: I often say there should be an HTML5 spec without all the invention. I used my spare time today to press the delete key for a bit. I'm just using this bug to keep track...

My document is roughly 1.7MB at this point. Ian's version is about 2.6MB.

I'm sure there are many dangling references. In particular, the removal of
WebForms2 is not complete. Here is a list of changes I've made so far:

1.) Cut most of the introduction. Use one similar to HTML 4.01.
2.) Eliminate most of the conformance requirements section. It was very
repetitive, sometimes contradictory, and contained enough loopholes to make it
ineffective.
3.) Remove Communication Section
4.) Remove Command APIs
5.) Remove Drag and Drop API
6.) Remove Datagrid API
7.) Remove Structured client-side storage
8.) Remove Undo history
9.) Remove Rendering
10.) Remove "Things that you can't do with this specification..."
11.) Remove Time microsyntax in preparation for deleting all features that
depend on it
12.) Remove DOMStringMap and dataset
13.) Remove video and audio elements, media elements, source element
14.) Remove MathML and SVG sections from Embedded Content
15.) Remove figure element
16.) Remove img element examples and alt text guide. Author's guide would be
good for this.
17.) Remove section, nav, article, aside elements
18.) Remove header/footer element
19.) Remove "headings and sections" and "creating an outline"
20.) Remove time element
21.) Remove progress and meter elements
22.) Remove the mark element
23.) Remove details and datagrid elements
24.) Remove command and bb elements
25.) Remove DOM Feature Strings
26.) Remove "Features defined in other specifications"
27.) Remove "Common conformance requirements for APIs exposed to JavaScript"
28.) Remove DOMTokenList and relList and classList
29.) Remove "Common Grouping Idioms"
30.) Remove the dialog element
31.) Remove the output element
32.) Remove hyperlink auditing (ping)
33.) Remove autofocus attribute
34.) Remove sandbox and seamless
35.) Remove registerProtocolHandler, etc
36.) Remove hidden attribute
37.) Remove Constraint Validation
38.) Remove History section"

Ian Hixie:

"HTML5's scope description is here:
http://www.whatwg.org/specs/web-apps/current-work/#scope

Basically, it's about taking the Web platform forward and making HTML5 suitable
for more document and application types, merging the HTML, XHTML, and DOM HTML
specs into one coherent design.

It's hard to review your document without a better sense of where you're
heading (for example, where you're heading determines whether or not having the
rendering section is necessary). From the way you responded to the questions
above it almost sounds like it's just "HTML5 with Rob Sayre's pet peeves
removed", which is probably not the most useful document! I think there is
definitely a need for a document that is either HTML4-done-right or
HTML5-without-new-features. I'm not sure it makes sense to have a mishmash,
though."

Me:
I agree with the idea of making HTML 5 smaller; however, it feels like Robert is cutting out all the good stuff. I want an HTML 5 that lets me embed video; tells me how to use SVG in normal HTML; gives me better semantic elements like ARTICLE; gives me client-side storage; let's me throw away the Really Simple History library I wrote by giving me proper Ajax History support; let's web apps be first-class citizens with protocol handlers; helps the web to compete with Flex by having a first-class datagrid element; etc. Let's not throw the baby out with the bath water :)

I do have to say, though, that if this becomes essentially HTML 4.1 + Canvas as someone proposed on the bug, I think it will be a failure unfortunately. We need to learn from the XHTML experience: if you don't have significant new features or a compelling set of needs to adopt a spec, it will not have significant adoption just because it 'cleans things up' as an HTML 4.1 spec would do.

Moving past last call for HTML5 from Ian Hickson on 2009-02-19 (www-archive@w3.org from February 2009)

noreply@blogger.com (Brad Neuberg) — Mon, 23 Feb 2009 03:50:00 +0000

Moving past last call for HTML5 from Ian Hickson on 2009-02-19 (www-archive@w3.org from February 2009): "Realistically speaking, we'll never have complete consensus on everything in HTML5. At the simplest level, there are contradictory opinions on the very fundamentals of the work -- some people want error handling defined, some don't; some people want a schema, some don't; some people want APIs defined, some don't; the list is long. So consensus -- unanimity -- isn't an interesting goal. The next step down in terms of opinion-based progress is majority agreement, and I am confident that with the exception of things that need changing and will be changed in time for the next milestone, we have a majority agreement on everything in HTML5. Majority agreement in a self-selected community like an open working group is worth less than it would appear, though, because there is a selection bias: only people who are interested in both the technology and in standards development are going to take part. In the W3C working group, there is a further bar: we only allow people who are willing to put up with an inordinate amount of bureacuracy (to join) and noise to be part of the group whose opinion is measured. Statistically, therefore, the opinions of the working group almost certainly don't match the opinions of the whole Web community."

Crossing borders: JavaScript's language features

noreply@blogger.com (Brad Neuberg) — Sun, 22 Feb 2009 20:23:00 +0000

Crossing borders: JavaScript's language features: "In this article, I'll explore the features of JavaScript that make it so wonderfully attractive:

* Higher-order functions. A high-order function is one that either takes functions as arguments or returns a function. This feature lets JavaScript programmers manipulate functions in ways that the Java language can't.

* Dynamic typing. By delaying binding, JavaScript can be more concise and flexible.

* A flexible object model. JavaScript's object model uses a relatively uncommon approach to inheritance -- called prototypes -- instead of the Java language's more common class-based object model."

Joyeur: Open, Loving, Just Workingness: The Smart Platform and Javascript

noreply@blogger.com (Brad Neuberg) — Sun, 22 Feb 2009 20:13:00 +0000

Joyeur: Open, Loving, Just Workingness: The Smart Platform and Javascript: "JavaScript is the natural language for the cloud, it's been existing in a sandboxed virtual container (the browser) for over a decade. It's had to use services (for data persistency, file access etc), its event messaging is the internet. If the Cloud is the Internet OS, then JavaScript is its language (nothing else comes to close to natural fit and breadth)." (Simon Wardley)

New Coworking Book Out + Google Tech Talk on Earth-Like Exoplanet Detection Posted

noreply@blogger.com (Brad Neuberg) — Fri, 20 Feb 2009 21:31:00 +0000

Hey folks, I've been super quiet lately. I'm either posting on Ajaxian these days or mostly hunkering down coding the SVG toolkit I'm building.

Two cool things: there is now a coworking book out, called "I'm Outta Here!" (I originally started coworking). Buy it now or check out the blog.

Also, I invited Travis Metcalfe, an astrophysics researcher, to give a tech talk at Google recently entitled "Sounding the Stars With Genetic Algorithms" on his unique work involving earth-like exoplanets. The tech talk is now up on Youtube.

Facebook Targeting Googlers With Special Ads

noreply@blogger.com (Brad Neuberg) — Wed, 17 Dec 2008 00:47:00 +0000

LOL, Facebook is targeting Googlers with specific ads:

Another Googler told me they saw something similar on their Facebook page.

Fixing the Web, Part I

noreply@blogger.com (Brad Neuberg) — Mon, 17 Nov 2008 22:37:00 +0000

We've made major progress on the web since 2005 and the rise of Ajax. JavaScript toolkits like JQuery, Dojo, and YUI have expanded what we can do with web browsers and increased our productivity, while dynamic high-profile web sites have legitimized using DHTML and Ajax. The rise of web browsers like Firefox, Safari, and Chrome have done a huge amount to help revive the web and web applications. Developers such as all of us in the Ajax community have shown that it's possible to do things with the web cross-browser that no one expected, including Comet, cross-browser vector graphics, and more.

However, even with all of the amazing work the last few years, the web has some very serious foundational issues that we need to solve or else it's game over. In the next year or two we will begin to hit the limit of what we can achieve with clever JavaScript tricks (I've literally made a career out of this browser black magic). As an industry we've put off having to solve some very serious issues. Unfortunately the bill is going to come due soon, and if we don't take action, solve these issues, and push the web in a new direction some other possibly much less open technology will take over the bulk of new development.

We need to do something about this. This blog post is part of a new, semi-regular series called Fixing the Web. The goal is to highlight these issues, identify potential solutions, and have a dialogue. I don't claim to have the answers for the situation we are in. However, I do know this -- if there is any community that potentially has what it takes to solve these issues I believe it's the Ajax and JavaScript communities, which is why this is a perfect place to have these discussions.

To start, I see four areas that are broken that must be fixed:

1) Make developing for the web much easier and more powerful. There are gaping holes in the web that need to be fixed. Examples include:

Layout - layout needs to be _much_ easier. We need real, kick-ass, drop dead simple layout. You shouldn't have to be a CSS wizard to get multiple columns, for example.
JavaScript++ - JavaScript needs to evolve for programming in the large and medium.
Bling - Browser's need much better native multimedia support, real vector graphics, and _fast_ (really fast) animation
Tooling - We need much better open web tooling support, such as IDEs.

2) Solve the standards problem. The web standards process is broken. There is a real disconnect between developers needs and the W3C's standard setting process, creating a dangerous power and leadership vacuum. We need to come up with better mechanisms for creating standards, as well as organizations that can help manage them.

3) Solve the distribution problem. Both Gears and Yahoo BrowserPlus are attempting to address this area. There is just a sheer mass of inertia on the web. It doesn't matter if you have the most amazing standards, developer tools, etc. if they aren't in enough places to do anything. This problem can also be re-framed as 'Solve the Internet Explorer problem', because the other browsers are pretty damned good at getting things out there -- IE is the mass that blocks any positive forward web progress. IE 8 is a start, but at the end of the day it's not doing enough. This is also linked to how hard it is to do web development, since you have to be a wizard to know the potholes or do crazy workarounds.

4) Solve the innovation problem -- There is a saying in politics that you create ideas so that you can draw on them when there is a crises, such as we are seeing now. Much of the innovation on the web has surprisingly happened by Flash, with some by Silverlight lately -- when we get excited about being able to do video on the web, which is great, that's a pretty sad indictment of the open web 'owning' the future. We've got to have better mechanisms for stamping out potential futures and innovation that can then compete, the successful ones turning into standards. Mozilla has done a good job of this with the web "concept cars" type work they've been doing.

What do you see as the major areas we need to address? Expect to see the issues above, and others, discussed in future blog posts in this series.

[Disclaimer: I work for Google. However, this opinion piece is my own and does not represent an official stand of Googles]

How Flash Can Integrate With The Open Web

noreply@blogger.com (Brad Neuberg) — Mon, 17 Nov 2008 21:05:00 +0000

[Big giant usual disclaimer: These are my own thoughts and opinions and not those of my employer]

Dion just put up a great post on how Adobe can join the Open Web by open sourcing Flash. I agree with him, and just wanted to add to the conversation a bit.

I've actually been turning this idea around in my head as well. It might surprise you since I'm an Open Web Advocate, but I like Flash. I've always tried to be non-ideological in my work. Flash has done good things and created a great deal of innovation. Adobe (and Macromedia before it) has always been good about evolving Flash forward, including making ActionScript more like JavaScript, embracing markup language development, open sourcing Flex, and more. I'd like to see Flash continue to evolve into being a core part of the Open Web. This would be good for Flash and good for the Open Web.

As Dion points out open sourcing Flash is one big part of making this happen, but another huge aspect would be to have Flash and Flex integrate better into the web stack and be less of a 'black box' on the screen.

Here are some suggested ways to make Flash & Flex more a part of the Open Web -- these are just suggestions. The important point is to integrate Flash and Flex more deeply into how the Open Web works:

Cross-Platform Standards
No Vendor Lock-in
Anyone Can Innovate
Powerful, Universal Clients
Open Source Implementations
Mashable, Searchable, and Integrated

Some possible ways to achieve this; I acknowledge these won't necessarily be the easiest for Adobe to do, but it would be extremely powerful if they did:

Directly push Flex and ActionScript to the browser and Embrace View Source

Right now Flex and Flash work by compiling everything you do down into a small, binary SWF file. This has some obvious advantages, mainly that it allows the Flash player to be simpler and not have a full interpreter in it (for example, ActionScript doesn't support eval because there's no way to dynamically execute script at runtime). Back when bandwidth was more constrained it also had the advantage of smaller file sizes and less latency when fetching multiple files.

These were good reasons for their time. However, things have changed. We now have much higher broadband penetration, and the Flash player doesn't have as strong size constraints (though I do agree you want to make sure the size stays small in general -- I've always liked the size constraint Adobe has around their player versus Sun with the Java VM).

At this point, Flash should start working like the web itself: Flex should be pushed right down to the browser and rendered there, with the ActionScript fetched just like SCRIPT tags. In addition, View Source should be on automatically and hooked into the browser's View Source. If I browse to an MXML page and do View Source, I'll see the MXML Flex markup for it. I could also then see the mx:Script tags and view their source as well.

Why this is good:

View Source is a good thing. It's helped to propel the growth of the web itself (and the Ajax community which has benefited hugely from it's existence). It's similar to how YouTube and Flickr made the default option for sharing be public and experienced massive growth -- this made things grow faster versus Snapfish, for example, which made everything private by default. If someone wants to keep their source private they can obfuscate their source just like we do today with JavaScript. View Source should always be on (you can't turn it off) -- just obfuscate your source if you don't want it.
No compile phase -- the dev experience would become similar to working with HTML and JavaScript today.
Over time, human readable textual formats have won -- SMTP, HTML, etc. Binary formats are better on paper (and are better in practice many times), but the simplicity of working with textual formats when creating software is just so much easier and is generally worth the efficiency tradeoff. Imagine simple PHP scripts that can just generate MXML, for example -- much easier than trying to emit a binary SWF file from PHP.

Integrate With Bookmarking and History

Flash should implement the HTML 5 History interface and should deeply integrate with the browser's bookmarking and history. I know there were some earlier efforts to have Flash have bookmarking machinery, but its buggy, no one uses it, and it doesn't work very well.

Don't Be Afraid of the Browser

AIR is really cool when you want to build desktop applications using web technologies. However, the browser doesn't need to be routed around as if it were a source of damage, which is what AIR essentially does. Personally I'd rather see Flash deeply embrace the browser itself and expand what can be done there, similar to Gears -- I want the web to grow into the desktop, not have the desktop grow into the web. Flash developers generally see the strengths of the browser as weaknesses, when they shouldn't:

The browsers chrome is your friend -- I know you want to get rid of the URL bar and the back and forward buttons for your application, but users depend on this consistent UI. Users spend far more time navigating across many sites than your particular application -- UI consistency in the browser is a good thing. AIR jettisons the browser and loses this -- Flash should expand what web applications can do within the browser itself instead.
Sandboxing is good - the fact that web applications have limited trust is a feature, not a bug. AIR throws away the sandbox, making it hard for users to effortlessly experiment and try new web sites. Instead, Flash should adopt what Gears and HTML 5 are trying to do, which is to expand the sandbox in a safe and consistent way.
Users don't want to download applications, they just want to visit URLs - In AIR I have to download an application. Instead, users would rather visit web sites (though having a nice icon on your desktop is a good thing, similar to the Gears Desktop Shortcuts). I'd love if Flash allowed me to drop shortcuts on my desktop to web apps that live at URLs (and which might have cached code locally for performance like the Gears LocalServer, though this would be transparent to the user). However, again, the growth of the web has shown that the ease of simply navigating to URLs (and the safety because of the sandbox) drives huge growth.

Essentially I'm arguing that Flash should grow outwards from the browser keeping the above characteristics, and that AIR should go away. Sorry about that -- I know AIR is cool and nifty engineering, but I personally don't see it within the trajectory of the web. Let's expand what web sites and web applications can do, not try to turn every web site into a downloadable application. I bet the number of web sites you visit is at least an order of magnitude larger than the number of applications you have on your desktop.

Hyperlinks Are Your Friend

Hyperlinks are essential to the web, navigation, and searching -- it's the Hypertext in HyperText Markup Language (HTML) after all. Flash should embrace linking into the resources that are internally present (such as targeting particular parts of an MXML document). I'm not saying XLink is the way to do this, but perhaps one could mix in an attribute onto an MXML element (or the equivalent of a div and span in some inline text in an MXML element) that makes the element a targetable anchor. Or even better, just automatically make everything targetable:

http://example.com/my_flex_app.mxml#find(Some Text)

The line above would simply find the first occurrence of 'Some Text'. If there are multiple occurrences you can simply choose which one, starting at 1 rather than 0; for example, to target the second occurrence of 'Some Text', you would do the following:

http://example.com/my_flex_app.mxml#find(Some Text)[2]

This is good for search engines, for SEO, and for users. Again, this is just like View Source -- make things linkable by default.

Embrace REST and Readable Remoting Protocols

The Flash remoting protocols are interesting and a nifty piece of engineering. You've got AMF which is essentially a binary RPC protocol, and then you have things like RTMP which lie above this and which can efficiently intermix multiple streams of multimedia to ensure that no channel get's 'starved' if you are doing multiple collaboration or mixing streams together -- nice work. Again, however, this is a case where local efficiency is the enemy of broad adoption. Binary protocols make sense in some cases, but its much better to sacrifice the efficiency of binary protocols for the integration possibilities of textual protocols.

Flash should embrace REST (and if it must have RPC, just do XML-RPC) and layer higher-level protocols above these as HTTP-based protocols. Yes, you're going to sacrifice some efficiency, but it's just much easier for someone to throw up a PHP or Rails based backend that can setup things through REST, spit out some XML-RPC, or do multimedia through something like Jabber.

Embrace SVG

Yes, I know you are creating your own vector-graphics markup language, and I know you just published a long editorial on why SVG wasn't perfect for your needs. I hear what you're saying, but reading through the list it seems like minor errata rather than really good reasons. It seems more like the developer really wanted to make their own thing -- I understand that, it's always more fun to roll your own thing.

SVG's not perfect -- standards never are (and neither was TCP/IP or SMTP versus the competition, BTW). But SVG is actually pretty damn good, and the baseline of support has gotten strong the last year across Firefox, Safari, Chrome and Opera. In the next two years I think we'll start to see SVG emerge as a real tool in most web developers toolkits -- Flash should embrace this. Go ahead and add what you need to it (innovation is okay), but support the core standard itself. It's going to be a little different than the other MXML it's mixed in with, one of the issues you raise, but global systems like the web tend to sacrifice some internal consistency in support of evolvability.

Bonus point: Support the Canvas tag as well, including Web fonts (TrueType, not EOT).

Integrate with HTML and CSS

Yes, HTML has been sitting on its butt for awhile, but things like HTML 5 are starting to make things exciting again, and the work Safari and Firefox have been doing around CSS Effects are really powerful (and really easy for developers to use).

This can be a two-way integration. MXML has some cool ideas around layout, for example, that would be nice to push into HTML, while it would be pretty nifty to start being able to mix HTML and MXML together in some way and styling MXML using CSS. This might also include having one of the open source browsers integrate MXML and aspects of Flash into the layout engine itself. More thought needs to happen around the best way for these particular technologies to integrate.

Make Friends with HTML 5 Video

It would be pretty cool to simply open source and patent-unencumber the FLV format into HTML 5 as the default codec for the HTML 5 Video tag. I might be dreaming (and a bit off about FLV -- I don't know it's technical details deeply), but it never hurts to dream...

Support Both Documents and Applications

The web is good at documents (and with the addition of Ajax relatively okay at applications), while Flash is okay with applications, and not good at documents. The interesting thing about the web is it's actually a spectrum:

Documents <------- Hybrids -------> Applications

What we really need is a technology that can easily adapt along this continuum, creating documents, hybrids like Facebook and MySpace, all the web to full-blown appliations like Gmail and Buzzword, perhaps merging the best ideas of Flash and the HTML web stack. Mark this one as a research area.

Start Working with the W3C and IETF (and/or the Open Web Foundation)

Yeah, I know, working with standards bodies can be a pain. However, it would be pretty cool to have alot of the work happening in Flash flowing into the W3C and IETF (which I know has been happening around Adobe's ActionScript work, but not other aspects). If you want a lighter weight process, you should check out the Open Web Foundation's way of working, which is based on things like OpenID, OAuth, etc. which are a bit more pragmatic than the standards bodies we have today.

Conclusion

At the end of the day Adobe is a tools company, a really damn good tools company actually. Doing the above should allow Adobe to continue creating powerful tools that help authors and content creators while expanding the size of the market they can target.

The above list was just a suggestion to kick things off. The real focus is on having Flash integrate into the web stack better itself (and evolving both Flash and the web stack themselves into the future).

How do you see this happening?

Making XML Namespaces Simpler

noreply@blogger.com (Brad Neuberg) — Mon, 20 Oct 2008 08:43:00 +0000

As I've been playing with XML a bit more lately due to the SVG work I've been doing, I've been amazed yet again that XML namespaces are so complex. Why didn't they just standardize on prefixes like 'svg:' instead of long URLs? I stumbled on a great editorial on how the XML web could be refactored to allow this; its probably too late, but the ideas in here are good:

XML Namespaces Don't Need URIs

"The decision to identify XML namespaces with URIs was an architectural mistake that has caused much suffering for XML users and needless complexity for XML tools. Removing namespace URIs altogether and simply using namespace prefixes to identify namespaces would make it easier for people as well as software to read, write, and process XML."

Backwards Satanic Lyrics.... With Quicktime!

noreply@blogger.com (Brad Neuberg) — Tue, 19 Aug 2008 20:19:00 +0000

I accidentally just discovered a strange keypress in Quicktime: if you press Command-Left Arrow while watching a movie, it will play in reverse! I was watching a video in my browser, and accidentally pressed this thinking I would jump to the previous page in my browser's history, when instead everyone in the video started talking backwards! Maybe I can use this to find those supposed satanic lyrics in various music songs...