Skip to content

Audible DRM issue

I hit a very annoying issue using Audible.com on my Mac with iTunes and my iPhone. I thought I’d document it in case others hit it.

Setting the Stage

I got a MacBook Pro in early 2009. I buy audiobooks from Audible.com and store them in iTunes. From iTunes I sync the audiobooks to my iPhone so that I can listen to them while driving, cleaning, etc. The audiobooks are DRM-protected (urgh), so the first time you try to play an audiobook in iTunes it asks you to enter your Audible user ID and password. It then validates your Audible user ID and password and verifies that you have purchased the audiobook file. Once you have authorized your Audible.com account in iTunes, you never have to enter your Audible.com user ID and password again. Also, once you have authorized your Audible.com account in iTunes, you can sync audiobooks to your iPhone.

The Symptoms

Recently IBM got me a new 2010 MacBook Pro for work (thanks IBM) so I gave my 2009 MacBook Pro to my wife. So that I wouldn’t have to set everything up from scratch, I backed up my entire 2009 MacBook Pro to an external drive using Time Machine and then restored this configuration onto the new MacBook Pro. After a couple of hours of data transfer both ways, my new MacBook Pro was a clone of my old MacBook Pro, or so I thought.

Unfortunately I realized quickly that something was wrong with my Audible.com audiobooks. The first symptom was that none of my Audible.com Audiobooks were on my iPhone. I tried to play one in iTunes and it asked me to authorize my Audible.com account. This was a surprise because I would have expected the Time Machine backup / restore to have made this unnecessary (since my iTunes configuration was already authorized), so I typed in my Audible.com user ID and password, hit sync, and sure enough the ebooks synced successfully to my iPhone.

Later that week I noticed that the audiobooks had disappeared from my iPhone again!

The Bug

To make a long story short (too late), after some experimentation and support discussion with Audible.com, I discovered the following steps to reproduce the problem.

  1. Start iTunes
  2. Double-click an Audible.com audiobook
  3. iTunes prompts you to authorize your computer for your Audible account by asking you to enter your Audible.com user ID and password
  4. Enter Audible.com user ID and password and successfully authorize
  5. Sync iPhone
  6. Audiobooks copy successfully
  7. Close and re-open iTunes
  8. Sync iPhone
  9. Books are deleted from iPhone

Basically anytime I closed iTunes, my Audible authorization was lost. This indicated that authorization was succeeding but was not being persisted to disk. I sent the steps to reproduce to Audible customer support.

The Solution

As I suspected, it was a persistence problem. The Audible support person pointed me to the file /Library/Preferences/com.audible.data.plist (a Mac property list file) where (apparently) the Audible / iTunes code persists your Audible authorization information (I peaked in the file and it contained a single ‘data’ property whose value was 4 KB of encrypted something or other). Interestingly, even though I’d at this point authorized my Audible account in iTunes many times this week, the file’s date stamp was from last year, indicating the file wasn’t getting updated and thus my authorization went *poof* whenever I closed the iTunes application and its process died.

The Audible customer support rep first suggested to check the file’s permissions to make sure that my user account was authorized to modify the file. No problems there – I had read/write access to the file. Her second suggestion was simply to close iTunes, delete the Audible property file, open iTunes and reauthorize the computer. I did this and sure enough when I reauthorized the computer, a new property file was created with the current time as the timestamp and I was able to close and re-open iTunes without having to re-authorize.

Lessons Reiterated

This experience reinforces two software principles I already believed.

  • DRM sucks ass
  • Data persistence is hard

Solution Proposal

I sent the following suggestion to the Audible.com support person:

Thank you <redacted>. It’s working now.

FYI, it was not a permissions issue – the permissions were correct. I had to delete the com.audible.data.plist file and restart iTunes / reauthorize Audible to create a new version of the file.

I suspect this is related to my restore from Time Machine on to a new computer. I would suggest your engineers who work on the Mac iTunes integration test this case:

1. On a Mac, authorize to read Audible content via iTunes

2. Backup a Mac onto Time Machine

3. Restore from Time Machine onto a new Mac

4. Attempt to play Audible content

I’m not sure what the ideal behavior is (e.g. just working or requiring a single authorization of the new machine) but I know what should not happen is what happened to me :-)

Thanks again for your help.

- Bill

2010 03 05 Bill Higgins Uncategorized Comments (0) Permalink

AppleScript to resize Safari for recording a YouTube HD video

Occasionally I need to produce YouTube HD videos showing me doing something in a web browser. Up ’till now I’ve had to painfully, manually resize the browser window to 1280×720 so that the video didn’t get unnaturally shrunk or expanded by my screencast rendering software. Tonight I figured out a way to automatically resize my browser window to the exact dimensions using AppleScript.

Here is the magical incantation:

tell application “Safari”

activate
set the bounds of the first window to {0, 0, 1280, 720}

end tell

Run this application in AppleScript Editor (/Applications/Utilities/AppleScript Editor) and your browser will be the perfect size for recording movies. You can save the script to a folder for later reuse.

Tagged , , ,
2010 02 28 Bill Higgins Uncategorized Comments (1) Permalink

Jazz extensibility evolution

Shortly before winter vacation, an IBM colleague contacted me to learn more about how extensibility – particularly web UI extensibility – works in the IBM Rational Jazz Platform on which I work. After typing up my response I thought it might be interesting to a broader audience so I’ve reposted it here (with some minor tweaks for clarity). Note that some but not all of the links below require Jazz.net registration (sorry).

—–

Hi <redacted>,

You are correct that as of Jazz Foundation 1.0.x (shipped this year), one contributes “viewlets” (a Jazz-specific widget mechanism comparable to OpenSocial Gadgets and iWidgets) to Jazz Dashboards via a server-side Eclipse extension point.

However, the Jazz extensibility story is more complex than OSGi bundles and Eclipse extension points. I will explain this below, with the assumption that you are interested.

Original Extensibility Mechanism Based on Bundles and Extension-points

When we first started the Jazz server work in 2005 we made a design decision that the Jazz server would be based on Java/OSGi and you contribute capabilities to the server by adding additional OSGi bundles. I’m guessing you’re very familiar with this architecture; it’s of course very similar to the Eclipse workbench except instead of contributing actions and views (e.g. to implement a Java IDE) you contributed web services and data definitions (e.g. to implement a bug tracking system). We went so far as to enable this style of programming for Dojo-based Ajax code so that developers could add “web bundles” and have the Jazz Web UI framework discover and surface their web capabilities in the Jazz Web UI. The Dashboard viewlets are one example of an extension-point-based extension. There are other extensions also enabled by extension-points (as in Eclipse, this extensibility model is open-ended).

Shift Towards a RESTful Architecture

Around 2007 we came to the conclusion that the “extend the server” model wouldn’t enable us to achieve our broad goal of “enabling integration of heterogenous tools across the software lifecycle”. There were several blocking problems with this architecture. I will list a few below:

We came to the conclusion that the RPC style service APIs were too fragile over time and would make it difficult to allow for independent upgrades of different tools in an environment containing many tools.

We could only support a narrow range of technologies (i.e. OSGi-ified Java and JavaScript code built on top of our server architecture). This limitation is readily apparent when you compare it to something like OpenSocial Gadgets or iWidget where you need only specify a gadget/widget URL to achieve integration.

This caused us to take a step back and ultimately decided to use the REST architectural style to achieve integration across tools. For instance this year we enabled several integrations between our Requirements Composer, Team Concert, and Quality Manager products using RESTful protocols and APIs. For an example of these integrations, see this video on Jazz.net that demonstrates how we use REST and Discovery to drive linking and “picker” integration between two tools.

Implications of RESTful Architecture on Extensibility Model

The shift to the RESTful architecture left a gap w/r/t extensibility. I.e. how do we meet extensibility needs if we can’t assume a homogeneous OSGi/Java/JavaScript-based programming model? The solution we came up with was something that we generically call “Discovery” (an overloaded term, I know). Basically each tool in a Jazz environment has a single “root services” document that describes the basic capabilities of the tool and has pointers to other documents that contain more details about a specific service. You configure tools to know about each others’ service documents, and from there they can discover and (if appropriate) consume each others’ capabilities using spec’d protocols (as opposed to physically installing code from Tool A within Tool B’s environment).

For instance, we have a “viewlet provider” service type that announces that the tool in question has viewlets that can be embedded in Dashboards. Here’s an example of how it works:

  • Tool A has Jazz Dashboards capabilities
  • Tool B claims to be a “viewlet provider”
  • Tool A is configured to connect to Tool B (this includes specifying Tool B’s root URL and configuring an OAuth consumer / provider relationship)
  • Tool A is now able to host Tool B’s viewlets in its Dashboards

The interesting thing about this is that Tool A and Tool B could be implemented in wildly different ways… e.g. OSGi/Java vs. PHP.

* As an aside, we are currently working to deprecate Jazz Viewlets and adding the ability to host iWidgets and OpenSocial gadgets in Jazz Dashboards. This is in plan for 2010.

Going Foward

Even though we have moved to a REST-centric architecture, OSGi and Extension Points are still important, but less so than they used to be. We will continue to ship and use the OSGi and Extension Point-based Ajax frameworks and building blocks for the near future, but our major development investments and the Jazz SDK’s focus will only assume fundamental web technologies like HTTP, HTML, JavaScript, and CSS and provide optional higher-level frameworks around emerging web standards like OAuth and OpenSocial.

I hope this was useful for you.

- Bill

2010 01 03 Bill Higgins ajax
jazz Comments (0) Permalink

Knuth on email

Don Knuth: Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things.

2009 12 19 Bill Higgins qotd Comments (0) Permalink

ebook love

I used to read a lot of tech books, like a an hour or two a day. Several years, several promotions, two kids, and one deteriorating eye later, I realized I wasn’t reading much anymore. The combination of work commutes / Audible.com / iPod helped me keep up with novels and non-techy non-fiction, but I still had trouble keeping up with tech books.

Luckily, tech publishers are starting to publish more and more ebooks. Here’s some of the good and bad points of reading tech ebooks.

Tech Ebooks: The Good

  • My Macbook Pro’s multi-touch trackpad makes it very easy to zoom and scroll so I end up with huge font that I can read without glasses from several feet away.
  • I can carry all of my ebooks on both my computer and iPhone.
  • Publishers like O’Reilly and Pragprog have relatively mature ebook stories; DRM-free, mobile integration, and available in both computer-friendly (PDF) and mobile-friendly (EPUB) versions and notification for free updates of new printings.
  • I can quickly search across all ebook content using Spotlight and quickly open ebooks using Quicksilver and Preview.
  • They’re significantly less expensive than their dead tree counterparts and you can acquire them instantly vs. a trip to the bookstore or, more likely, a two day wait for an Amazon Prime delivery.
  • Using Dropbox you can easily replicate your ebooks across all of your computers while easily staying under Dropbox’s 2GB free account max.

Tech Ebooks: The Bad

  • Can’t (ethically) lend to friends; can’t give away when done with a book.
  • I have a 1st gen Kindle I never use. While I love the selection, price, and integration with Amazon.com, I hate the hardware design, the user experience, the $@#! DRM, and the fact that I can’t (easily/legally) view the books on my computer. Don’t buy a Kindle.
  • The selection of ebooks is relatively small vs. all books I’d want to buy. For instance, no How Buildings Learn ebook (though I’ve sent the publisher an email on this).
  • Many ebook-selling publishers still insist on using DRM. This is stupid. As the argument goes, honest people like me will gladly pay for quality IP and a good user experience. DRM-selling publishers: please learn from O’Reilly and Pragprog.
  • You need a different account for each publisher. Luckily password management apps like KeePassX simplify this, but it’s still a pain.

Tech Ebooks I’ve Recently Bought

Now, for your reading pleasure, are the ebooks I’ve bought in the past few months (updated 25 Oct. 2009).

2009 08 17 Bill Higgins Uncategorized Comments (0) Permalink

detecting that you're in an IFrame

I hit a JavaScript issue recently that stumped me. I’m trying to detect if the code I’m running is in an IFrame or not. It seems like the safest way to determine this would be the following comparison:

if(window !== top) {
   var mode = "frame";
}

‘window’ of course is the global object in which your code is running. If you’re running in a frame, your window object is actually a child in a window hierarchy. ‘top’ refers the to the top-most window in the hierarchy. Therefore if window and top are the same, then you are in a top level page; conversely if they are different, then you are in a frame (or iframe).

This works great on Firefox but on IE, the window !== top expression never evaluates to true. That is, even if you’re the top window, ‘top’ and ‘window’ aren’t considered equal. I’m not sure why this is. My current fallback code is this:

try {
    if (top.location.href !== window.location.href) {
        var mode = "frame";
    }
} catch (e) {    
    // if you're in an iframe in a different domain, the top.location check
    // results in a security exception
    mode = "frame";
}

This code has two problems:

  1. There’s a small possibility that you could have the a frame with the same URL as the outer page. This is very unlikely because there’s no scenario I know of where you want to nest a page, but it’s still a latent bug.
  2. You have to deal with the exception in the cross domain case. Not a big deal but unclean.

I’m curious if anyone has a better solution for detecting whether or not you’re in an IFrame.

2009 04 09 Bill Higgins ajax Comments (1) Permalink

frameworks and building blocks

Between early 2006 and early this year, my team at IBM Rational and I built a framework for component-based Ajax development for use in the Rational Jazz platform. The framework’s capabilities aren’t the focus of this entry, so I’ll just list some of them briefly:

  • A nice component model based on OSGi bundles and the Dojo module system
  • Request-time “building” of many fine-grained JavaScript files into monolithic files for faster download based on the introspected relationships between the files – i.e. no developer effort required for fast code loading other than writing good application code
  • Making a subset of the Eclipse extension registry available in the web page and queryable via JavaScript APIs modeled off of the org.eclipse.core.runtime extension registry Java APIs, allowing for open-ended extensibility using the Eclipse extensibility model
  • A simple framework for demarcating UI states that made the back button, history, and page titles work seamlessly within the Ajax page, even when a user gesture resulted in crossing a component boundary (e.g. loading and displaying a new virtual “page” from a different component)
  • Dynamic, transparent loading of missing code in response to a user gesture that required it

We did a fairly good job of keeping our Ajax framework decoupled from the rest of the Jazz Platform both for the purpose of design cohesiveness but also to allow for possible future use by teams who weren’t building full-blown application lifecycle management applications like Jazz SCM or Iteration Planning.

Over time, other IBM teams heard about some of our capabilities and saw the positive results in our Rational Team Concert web UIs (1) and contacted us to explore whether they could make use of our code in their products. Each conversation went like this:

  1. We gave a demo and talk about the capabilities and architecture of the framework
  2. The other team said “that’s really nice, that’s really useful, that would be great to have”
  3. The other team said “we’re not sure we want to live within your framework, we’ll get back to you”
  4. The other team didn’t get back to us

Initially this didn’t really bother me – after all my job was to deliver the foundation for our Jazz web user interfaces, not to create a general purpose Ajax framework for IBM, but as I’ve thought about it more over time and seen this anti-pattern from other teams and other frameworks, I’ve decided that we should make a conscious effort to make our useful functionality available as simple building blocks (in the form of libraries) and then provide frameworks that layer on top of these building blocks.

Let me take a step back and explain what I mean.

A library is a set of reusable functionality where your application uses parts of the library as necessary. For instance, most programming languages have a library for creating and manipulating dates. Frameworks also provide functionality to the application programmer, but instead of the application programmer making simple function calls, the framework runs the show and calls into the application at well defined hook points. For example, GUI frameworks provide ways to wire up code to run in response to users clicking on buttons.

Both the library and the framework provide useful functionality intended to make the application developer more productive. Though it’s dangerous to make a general statement, it feels to me that the big difference between the two is that frameworks generally provide more power, but require you to make a bigger commitment to the framework’s way of working, while libraries provide generally less power, but make few (if any) demands about how you structure your application.

What’s unfortunate is when you’ve got some useful bit of functionality that could be made available as a simple library but it’s only available in the context of a framework. This is where we were with our Ajax framework. This stuff is too abstract, so here’s an analogy: Imagine that you heard about a new refrigerator which provided every feature and characteristic you ever dreamed about having in a refrigerator. The catch however was that you couldn’t just buy the refrigerator – you had to move into a house on the other side of town that included the new refrigerator. After about 10 seconds of thought you realize that even though it’s the fridge of your dreams, you’re sure as hell not going to move into a new house across town in order to get it. This situation (switching back to software from refrigerators) is shown in the diagram below.

Useful building blocks locked inside a framework

Useful building blocks locked inside a framework

My recent realization (which seems obvious in hindsight) is that the useful functionality provided by frameworks and libraries need not be mutually exclusive. For instance, in our Ajax framework’s dynamic build system, rather than requiring applications to run within our framework to enjoy this capability, we could have created a simple callable library to perform dynamic optimization on a set of files, and then created a framework that simply used this same library. This approach is shown in the diagram below:

Useful building blocks used by a framework but also available independently of the framework

Useful building blocks used by a framework but also available independently of the framework

Over the past month or so we’ve been refactoring our Ajax framework to extract the useful building blocks into simple callable libraries and making the framework proper smaller by delegating to these libraries. We’ve done this in the hopes that our code will be useful to other IBM teams but as a result of the exercise, we’ve gained a deeper knowledge of our software and the software’s quality has improved as we’ve decoupled the framework aspects from the building blocks aspects.

Going forward, it’s my intention that our team will generally start with building blocks first and then consider if we should provide some higher-level framework that uses these building blocks. I only wish we had taken this approach from the beginning but you know, live and learn.

Footnotes

1) You can see our Jazz web UIs built on top of this framework in the development section of Jazz.net if you register.

Updates

Changed “other than writing good code” to “other than writing good application code”

Tagged
2008 10 10 Bill Higgins ajax
design
jazz Comments (9) Permalink

the awkward url-uri terminology dance

As my dear colleagues Simon Johnston and James Branigan have mentioned in various blog posts, on the Jazz project that I work on, we’ve (finally) fallen in love with the web/REST story. Because of this, we spend a lot of time in technical conversations using the standard REST alphabet soup vocabulary you’d expect – HTTP, XML, JSON, REST, URL, URI, etc.

One funny thing I’ve noticed is that there’s a certain conversational dance that goes on when the topic of URLs/URIs come up. For 99.9% of the web developers out there the distinction between “URL” and “URI” doesn’t matter, as the Wikipedia entry on URL points out:

In popular usage and many technical documents, [URL] is a synonym for Uniform Resource Identifier (URI).

However, some people who are a bit more pedantic than others care about the distinction (not me!) and tend to use “URI” in favor of “URL” when talking about REST stuff. People who are a bit new to the REST stuff on the other hand tend to use “URL”, since this term’s a bit older and a bit better known.

I’ve observed that when a REST newbie talks with one of the REST pedants, the newbie says “URL” while the REST dude uses “URI”. But as the conversation continues the REST n00b eventually uses “URI” – essentially deferring to and adopting the more knowledgeable person’s terminology.

I’ve also observed that when I talk with one of our REST dudes, if I continuously say “URL” (usually out of spite – I’m KIDDING!), they usually eventually start saying “URL”, I think just to bring more harmony to the conversation and because they realize that the distinction isn’t that important – probably simple mirroring at play.

I think in a future experiment, I will use the opposite term of whatever the other person (newbie or pedant) uses and as soon as they adopt my terminology I’ll switch back to the other term, and see what happens.

Should be fun.

Tagged , , ,
2008 07 09 Bill Higgins Uncategorized Comments (4) Permalink

from Windows to Ubuntu

Well, as we mentioned over on the Jazz Team Blog, my Jazz teammates and I just shipped Rational Team Concert 1.0, the first GA product built on the Jazz Platform. More on that later.

Since I’ve been working on what became Rational Team Concert for the last three years, I’ve gotten into quite a groove with regards to the technologies that I use and how I use them. But there were a couple of things I didn’t like and I promised myself that I’d fix them once we shipped and I could spare a few days of being less than 100%.

Chief among these “things I’d like to change when I have the time” was my use of Windows XP as my operating system. For quite a while I was happy to use WinXP – mainly because I knew how to use it and IBM’s internal set of applications are optimized for Windows XP users. And when I say “optimized” here I mean in the sense of lack of barriers – available, tested, and supported.

But after the past couple of years as I got more into web development, I started to experience some pain as a WinXP user because it seems like most of the interesting web technologies are optimized for Linux or Mac users, and for Windows users there’s usually a short appendix in the doc that says “If you are unfortunate enough to use Windows, the following has been said to work…”

So the day after we declared bit freeze on Team Concert, I downloaded a Ubuntu ISO CD image, burned that, backed up my data, then formatted my hard drive and installed Linux.

The remainder of this entry I’ll write in Steve O’Grady Q&A format so I don’t have to think in full paragraphs :-)

Q: How did the installation go?
A: It was truly easy. Just insert the CD, restart my Thinkpad, and let the Ubuntu installer do its thing. The last time I tried to install Linux was probably about 5 years ago and I remember it asking me all kinds of questions for which I didn’t know the answer. I don’t even recall Ubuntu asking me any questions, and if they did they must have been trivial because I don’t remember them.

Q: What was your first impression of the user experience?
A: I was really impressed. After installing just rebooted, logged in, and I was in a windowing system which was very easy to understand. The top panel has three simple, logical menus (Applications, Places, System), shortcuts to key programs, then the right side of the top menu has iconographic shortcuts to some important system applications (networking, sound, date time, system control). The bottom panel just lists the open programs and has some other miscellaneous controls related to desktop management (minimize all windows, switch between desktop, etc.)

My biggest takeaway on the window manager user experience is that it seems like they’ve taken care to strip out as much low-value cruft and redundancy as possible, so that you’re left with a small set of orthogonal, useful controls.

Q: Any problems?
A: There were two sets of problems: 1) Finding and learning the Linux equivalent for simple Windows programs like Notepad and Paint. 2) Getting IBM stuff to work that was mainly developed and tested for Windows and/or Internet Explorer web browser. To get over these humps I bought a license for VMWare and spent much of my first week within a Windows XP virtual machine. Luckily VMWare’s networking worked much better than I remember it working, so between VMWare and the Windows XP image with VPN and Lotus Notes, I could get basic things done like work email from home.

Luckily my Jazz colleague Matt Lavin has been using Ubuntu for over a year, so he was able to help me learn how to do some basic but important things like connect my system to the internal Debian package server.

I’m still having problems using Open Office vs. Microsoft Office. When I modified a Powerpoint file in Open Office, it ended up getting mangled back in Powerpoint. I’m not sure who’s fault it was, but it sure was frustrating. I may look into running emulated MS Office on Linux.

Q: Why Linux instead of a Mac?
A: Because I already have an iMac that I use a lot at home and also I have a very nice laptop from work (Thinkpad T60p) so I didn’t see the point of junking it and spending $3,000 for a new PowerBook.

Update: Added an additional question and answer below

Q: IBM provides a standard Linux distribution (Client for eBusiness, or C4eB) based on Redhat Linux. Why did you instead use a custom Ubuntu install?
A: Several reasons:

  1. I didn’t know such a distribution existed. Though I had been meaning to switch to Linux for quite a while, I never seriously researched it, and the final decision to switch and the actual switch happened over the course of about 3 hours on a random Saturday afternoon. As mentioned before, it was incredibly easy to find, get, and install the latest Ubuntu.
  2. I was influenced by some friends and colleagues in the development community (particularly the web development community) who strongly recommended Ubuntu.
  3. One of my goals is to learn more about Linux, so I don’t mind some of the pain of making things work.
  4. Even if I had known about it, I probably wouldn’t have used it, because in my experience, internal IBM standard distributions install way more software than I actually need, which is understandable since they need to provide a generally useful package for lots of people. I’d rather just install the stuff I need for development and then non-optional “I work at IBM” software such as Notes and the AT&T Network Client.
Tagged ,
2008 06 29 Bill Higgins personal Comments (3) Permalink

RIA weekly podcast and errata

Last Friday I did an RIA weekly podcast (mp3) with Michael Coté of Redmonk and Ryan Stewart of Adobe. This was a fun and interesting experience. Fun because I like Coté and Ryan a great deal and enjoy talking to them and interesting because of the subject matter and also because it was the first podcast I’ve ever done.

There were a few things I said in the podcast for which I’d like to provide a bit of extra context, because it’s difficult in the podcast format to provide a great deal of context.

Network Transparency and Latency

At one point in the podcast, I talk about Jazz’s early RPC-style web services and say something along the lines of “This is great for the Java client developers because they essentially get network transparency, which is awesome except for the latency.” This is sort of like saying “Not paying income tax is great, except for the eventual fines and imprisonment.” RPC-style interfaces that strive to provide network transparency have the unusual problem that they make remote connectivity too easy for developers. The result, which is almost a cliché, is that developers design applications which are way too chatty and which work fine on local area networks (the environment in which they are developed) but fall apart in wide area networks (the environments in which they are deployed). Later, in the clichéd scenario, the developers learn about explicitly designing the “stuff” that travels over the wire to provide a good balance between the needs of the application and the realities of the network.

Sometimes you just shouldn’t make things too easy. Like you shouldn’t put the car’s ejector seat button where the toddlers can reach it :-)

Why We Didn’t Consider Flash as the Basis for the Jazz Web UI Infrastructure

At another point, Ryan asked me if we ever considered Flash and I said something along the lines of “Well we didn’t select Flash because it wasn’t as ubiquitous as the standalone browser” but after saying this I remember Pat Mueller telling me recently that Flash is the most widely deployed web client technology when you compare it against particular browsers (i.e. browsers in general are more widely deployed than Flash, but Flash is more widely deployed than any particular browser like Internet Explorer or Firefox). So though my memory is a little fuzzy, I believe the reason was that just as a general principle, we didn’t want any core Web UI application functionality depedning on a particular plug-in; for instance, the user shouldn’t require Flash to create a bug report. Another factor was that this was early 2006 so Flash was probably not as ubiquitous as it is today. Yet another factor was our later principle that “look like a normal web page” and some examples of Flash violate this (i.e. the big box of Flash in the middle of the page, or overly ambitious site welcome screens). But I have to say, my thoughts on Flash have really changed over the past two years, because I’ve seen some incredibly useful, subtle applications of it. I can’t think of a particular example, but I know a couple of times some page on Amazon.com had a really cool little visual effect and sure enough when I right-clicked it turned out to be a little Flash app seamlessly embedded in the page. So using Flash in tactical ways where it can provide a powerful but non-jarring user experience is something I would like to explore in the future.

Meeting with the WebSphere Application Server Folks

At one point early in the interview Coté mentions that we hung out and got drinks in Austin one night and I mentioned that I was down for a meeting with some WebSphere Application Server folks and it was also a good opportunity to meet with Coté which is why I accepted the meeting. Listening to the podcast, I feel bad about how this came out because in reality the WebSphere App Server folks were doing us a favor by taking a day off to review the security architecture of Jazz.net and indeed they pointed out both important security and scalability issues. The missing context is that I hate work travel (I repeat hate) because I have two toddlers and they just grow too much and we miss each other too much when I travel without them. So the only time I travel for work is if I really need to be there in person (like if I’m speaking at a conference) or if I can accomplish more than one goal with a single trip. If not for the chance to both do the Jazz.net review and meet Coté, who in my opinion (don’t blush Coté) is both a cool guy and important industry analyst, I would have probably called in.

Innovation vs. Standardization

At another point in the podcast, I mention a blog post by Alex Russell of Dojo where he talks about standards not saving us and encourages browser vendors to provide non-standard innovative features. I think in the podcast I may have come across as “standards don’t matter”. In fact I think standardization is important to build the applications of today but agree with Alex and that the future won’t be invented by standards bodies.

Finally…

Otherwise I agree with everything I said :-)

2008 02 18 Bill Higgins ajax
design
meta Comments (1) Permalink