Worst. Form. Ever. · 294 words posted 05/09/2006 06:55 PM

Brian Eno and David Byrne released My Life in the Bush With Ghosts twenty-five years ago. A newly packaged and remixed CD is now in the stores, along with a promotional website.

As befits a nostalgia project, the registration form is a throwback to bad-old-days of the late 90s, when designers often put flash gimmickry ahead of helping the user accomplish the task at hand. This form isn’t just awkward; it’s actively hostile.

That’s a shame. Once registered you can apparently download tracks from the album to remix under a Creative Commons license. But I couldn’t get past the form.

Seriously, who builds junk like this anymore?

Comment

* * *

From the Archives: Joshua Davis Interview · 52 words posted 02/24/2006 09:07 AM

This month’s Wired Magazine profiles Joshua Davis, a designer who creates beautiful, randomized works of art with ActionScript.

The Wired profile will be posted March 2. In the meantime, you can read the since1968 interview from August, 2002, in which Mr. Davis discusses creativity and commerce, sharing code, and his artistic response to September 11.

* * *

180: That Patent Application Doesn't Say What You Think It Says · 1023 words posted 02/23/2006 07:10 PM

You’ve heard about it by now: the US Patent and Trademark Office issued Patent 7,000,180 (hereinafter “180”) on Valentine’s Day, granting some wicked licensing mojo on internet moving thingies to a previously obscure web design shop named Balthaser.

I say “wicked licensing mojo” and “internet moving thingies” because no one seems to have accurately described what the patent actually covers. Here’s Information Week’s take:

A patent has been granted to a relatively unknown California Web-design firm for an invention its creator says covers the design and creation of most rich-media applications used over the Internet. The patent holder, Balthaser Online Inc., says it could license nearly any rich-media Internet application across a broad range of devices and networks.

Potentially tens of thousands of businesses—not only software makers employing its business processes but companies offering rich-media on their Websites—could be subject to licensing fees when they use rich-media technology over the Internet.

The patent—issued on Valentine’s Day—covers all rich-media technology implementations, including Flash, Flex, Java, Ajax, and XAML, when the rich-media application is accessed on any device over the Internet, including desktops, mobile devices, set-top boxes, and video game consoles, says inventor Neil Balthaser, CEO of Balthaser Online, which he owns with his father Ken. “You can consider it a pioneering or umbrella patent. The broader claim is one that basically says that if you got a rich Internet application, it is covered by this patent.”

Zeldman simply calls it a patent on AJAX.

In other words, two groups would have to pay licensing fees to Balthaser under the alarmist reading of 180: anyone who distributes rich media1 over the internet (example: Basecamp, Gmail, etc. etc.), and anyone who sells a tool to create RIAs (example: Adobe/Macromedia, Microsoft).

But I’m pretty sure that’s an overly broad reading of what 180 actually claims. As with most patent applications, 180’s language is turgid and obfuscatory. That’s not really the fault of Balthaser and its legal team; it’s just how the game is played. But if you can wade through the muck, you’ll find a detailed description of how the “invention” is actually intended to be used.

Background: when an enterprising young man files a patent in hopes of bottling the magic2 he must include at least one example of a specific embodiment of his invention. The specific embodiment requirement forces the junior achiever to articulate how his abstract concepts will actually be put into practice.

Here are the specific embodiments contemplated by 180:

In a specific embodiment, the ability to create rich-media applications may be purchased by the user. Specifically, the user may purchase the right to use rich-media applications created on the host website, the right to design and create rich-media applications on the host website, or both. The user may also purchase the right to use more services by paying a different fee.

In a specific embodiment, the user may construct a rich-media application by using rich-media components including navigation elements, backgrounds, images, headings, sound files, text, windows, animations, e-mail clients, calculators, stock tickers, clocks, menus, movie files, and production types. Production types are customizable rich-media templates for performing specific operations such as presentations, resumes, catalogs, reports, user manuals, magazines, newspapers, photo albums, cartoons, websites, shows, movies, and invitations. The user may also upload components from other Internet locations for use in rich-media applications by listing the location of the component and the file type of the component. Applicable file types may include JPEG, MPEG, GIF, animated GIF, TIFF, EPS, PNG, SWF, MP3, and WAV. The user may be limited to a subset of all possible file types that may be uploaded depending on the level of service for which the user has paid.

In a specific embodiment, the user may create and access a customer account for the purpose of creating or modifying a rich-media application. Specifically, the user may access account and project information or save, close, delete, publish, or preview a project. The user may also create, insert, delete, save, or modify a scene of a rich-media application or add, access, edit, copy, paste, or delete components.

That’s just a sampling, but what becomes clear upon reading the specific embodiments in their entirety is that the patent is intended to cover a web interface for creating, editing, and hosting rich internet applications. The patent does not contemplate a desktop GUI, nor does it cover rich media created by a desktop GUI and hosted on your own server. The images accompanying the patent application seem to support this reading: by and large they’re site flows or database diagrams for setting up accounts and creating/saving/serving your rich app from a database to the web.

In other words, if you’re Microsoft and you hope to move a future version of Visual Studio onto the web so designers can use a web interface to create a web application, this patent may give you pause. Also, 180 might cover a web WYSIWYG app like Google’s new page creator.

I could be reading the patent incorrectly: remember, the language is defined to befuddle, not enlighten. And I’m not your lawyer. But if you’re Adobe/Macromedia and you sell Flash Professional 8 (a desktop GUI for creating rich media)—or if you’re a designer who creates rich media with a GUI and uploads it to the web—or if you write and host apps like Basecamp or Gmail—this patent says nothing to you about your life.

1 The patent specifically covers Flash, Java, MPEG movie files, and several other rich media formats. Curiously, the patent omits SVG. Even more notable, the patent doesn’t mention XMLHttpRequest, the foundation for “AJAX,” which dates back to the release of Internet Explorer in 1998, three years before patent 180 was filed in 2001.

2 I’m not making this part up. Here’s what Neil Balthaser said in the Information Week article: “My mom saw me struggling, and one day said, ‘Why don’t you figure out a way to bottle up that Balthaser magic and let people purchase the bottle and do it themselves?’ It was one of those whacks on the side of the head. ... I started to work on an early prototype.” That scamp!

Comment

* * *

Writeboard: Version Control and Diff for the Masses · 177 words posted 10/02/2005 10:36 PM

37Signals has quietly released Writeboard, a simple collaborative writing application. (I say “quietly” because as I write this Sunday night, I don’t see an official announcement. Expect hysteria by Monday morning.)

Solution Watch and tech crunch have detailed write-ups, but two features are of note to developers: Writeboard includes simple diff and version control, and both are supported so intuitively that they need no explanation, even to non-programmers.

As you edit and save your document, Writeboard automatically keeps track of your versions (see the screenshot). Switching versions is as simple as clicking a link. And diffing is as simple as checking the boxes for two versions and clicking “Compare.”

Strangely, Writeboard uses Textile as its markup language. I’ve used Textpattern for more than a year so I type textile much faster than HTML, but I have yet to come across a single non-technical client who actually uses textile for markup.

I get a Unix vibe when using Writeboard: think small pieces, loosely joined. It’s not a grand application, but what little it does, it does very well.

Comment

* * *

ColdFusion MX 7 Now Has a Mac OS X Installer · 110 words posted 09/28/2005 08:54 AM

Until now, if you wanted to run ColdFusion MX on OS X, your best option was following Sean Corfield’s excellent Installing ColdFusion MX on Mac OS X. Sean’s tutorial is great (thanks Sean!), but requires that you muck around with java config files—something you might not find worthwhile for a language you’ve never tried.

With the new ColdFusion MX 7 Updater Macromedia has made it as easy to install ColdFusion on OS X as it is on Windows. It’s free to run CFMX as a development server. If you’re a Mac developer and you’ve been put off by the old, unsupported installation, now is the time to check out ColdFusion MX.

Comment

* * *

Let's call it Web 1.5 and Shake on it · 674 words posted 08/10/2005 09:52 AM

Here’s a tip that Web 2.0 isn’t all it’s cracked up to be: Salon breathlessly profiled 37signals—and spent as much time talking about Ruby on Rails and Ajax as it did discussing how Web 2.0 can actually help end users.

Never forget that Salon announced its IPO in 1999 without bothering with such trifles as, say, how they planned to make any money. To be fair, this was 1999 and everybody was behaving stupidly with money. But that’s just the point: Salon drinks the Koolaid. It is a follower of trendlets, not a maker of them.

Right on cue, Web 2.0 had a hiccup. As Airbag notes:

As I write this in the last twenty-four hours the much hyped Web 2.0 hasn’t exactly lived up to it’s AJAX Ruby-Railed star power like I would like it too, like I would think it should. These applications that I use to do business have been kaput — completely unreachable for one reason or another.

Which is to say, I can’t drag and drop my to-do lists if I can’t access my to-do lists. Web 2.0 won’t live up to the hype until it supports occasionally-connected clients. Here’s a workflow to dream about:

  1. Make updates to milestones in Basecamp.
  2. Store the information locally in case I’m not close to a WiFi access point, or if the Basecamp server is on the fritz.
  3. My client and Basecamp have a chat whenever I’m next connected and my updates are made automagically.

Before we truly reach Web 2.0, let’s posit three requirements:

OK, I cheated. Those bullet points, in slightly different language, come straight from a Macromedia marketing page for Central, its early attempt at supporting Web 2.0. (Curiously, when Central was released in 2003, the phrase du jour was “Internet 2.0”). In hindsight, it’s easy to see that Central was ahead of its time. Still, its adoption never took off the way Macromedia hoped. Why did Central fail? I’d suggest two reasons:

First, Macromedia wrongly assumed the people want to accomplish tasks on their desktops instead of in a browser. The success of Basecamp shows that people don’t care where they work, as long as they can get the job done. If I have a choice between opening my browser—almost any modern browser on almost any modern computer—or installing an application such as Central, I’ll take the browser almost every time.

Second, Central never achieved the mindshare that AJAX/Rails now has, and the applications suffered for it. In short, developers failed to imagine what was possible with Web 2.0 applications. Look at the prototypical Central app: Central Developer Chat. What’s the point? What could it possibly do that iChat, or Fire, or any number of dedicated chat clients can’t do significantly better? Is chat even Web 2.0?

Finally, let’s add another bullet to my list of Web 2.0 requirements:

This requirement highlights why desktop installations will never achieve Web 2.0 status: users don’t want to be bound to a single vendor, single machine access point before retrieving data. Flash 8, with its near-universal installation base and new support for local file access, might sidestep that requirement because people can still use the browser of their choice.

Where does that leave us? On one side, with a vendor who released a product that was clearly ahead of its time (even if I didn’t understand why at the time) but demanded desktop lock-in. On the other side, a clever set of open APIs with mindshare to burn but no easy and robust way to support occasional connectivity.

Once again, it’s an exciting time to be a web developer, but boosterism won’t get us to the promised land. When we have widespread, vendor neutral support for occasional connections, then and only then we’ll have Web 2.0. Until then, let’s call it Web 1.5 and shake on it.

Comment

* * *

The NY Times on Mapping Email Patterns · 133 words posted 05/22/2005 10:40 AM

Detail of Patterns in Corporate Chatter Gina Kolata of the New York Times reports today on finding patterns in corporate emails: Enron Offers an Unlikely Boost to E-Mail Surveillance.

With access to large bodies of email, scientists hope to spot and map patterns of interaction:

For example, would they be able to find the moment when someone’s memos, which were routinely read by a long list of people who never responded, suddenly began generating private responses from some recipients? Could they spot when a new person entered a communications chain, or if old ones were suddenly shut out, and correlate it with something significant?

The article includes a map generated by Dr. Carey E. Priebe and Youngser Park of Johns Hopkins University (see detail above). The patterns generated are similar to Marcos Weskamp’s popular Social Circles mailing list mapper.

Comment

* * *

Love and Yearning Interview, Part 2 · 1287 words posted 10/15/2004 12:33 PM

Detail from Love and Yearning In the fall of 2003, the Freer Gallery of Art and Arthur M. Sackler Gallery exhibited Love & Yearning, a collection of illustrated Persian manuscripts. John Gordy, Head of Digital Media, and Jacqueline Bullock, Web Producer, designed a kiosk and website around one of the manuscripts, “Haft Awrang,” (or “Seven Thrones”).

Last summer they gave me a tour of the galleries and talked about their production processes. In the first part of the interview, we discussed the planning, storytelling, and goals of the exhibit. In the second part, below, we talk about the choice of technologies. Many thanks to John, Jacqueline, and the rest of the staff at the Freer and Sackler for their time.

Databases

The Freer and Sackler galleries use The Museum System (TMS) database to track their collections. I asked John about using a database for the Love & Yearning exhibit.

John Gordy: We didn’t use a database for Love & Yearning; it’s only 28 pages. For some online collections, we do an extract from TMS, which has 50,000 to 60,000 records. We only want the few of those that have been approved for public access. We’ll do an extract that pulls a few thousand records and puts everything in a flat Access table. That way, when I have the Access table I can work with it on my desktop. We may bump it up to SQL Server, but it still will be one flat table.

Our museum tends to be more about interpretation rather than presenting mass quantities of information. So in the same way it just wouldn’t make any sense to invite a visitor in and let them roam around the collection storage—they wouldn’t have any idea of what they were really looking at—we want to encapsulate the stuff we’ve got and put it in groups. It’s thematic, it’s got narrative text with it, and that contextualizes it. So that leads us away from doing large scale database projects.

Working with Flash

Love & Yearning uses Zoomify to magnify Flash images at a very high resolution. I asked John and Jacqueline how they selected their technogies.

John Gordy: We originally started looking at Zoomify when it was using Java. It was a nice idea, but it wasn’t giving us imaging gratification, so it wasn’t something we wanted to use. But the first Flash version was interesting, and the second Flash version was up to speed and really worked. When I saw the first demo at a FlashForward in San Francisco, at the same time I was thinking about what Massumeh [Dr. Massumeh Farhad, Chief Curator and Curator of Islamic Art], had said: “I really want to get into the details.” It was a perfect fit, and perfect timing.

So the choice of technology changes depending on the exhibit. Each curator will present me with a challenge, depending on what they’re interested in, and I will look in the bag of tools and come up with whatever I think might work.

since1968: Stepping back from Zoomify for the moment, let’s talk about the choices of Flash, Java, or—let’s be crazy—SVG, it’s an option. David Rumsey does Japanese maps for UC Berkeley that are breathtaking. He uses a proprietary Java applet called “insight” that lets you zoom in on the images. There’s another viewer called MrSID from LizardTech that many libraries use to show Fire Insurance Maps in great detail. How did you choose Flash?

John Gordy: Part of the reason for using Flash is I’ve been using it for so long that I feel comfortable with it. It’s also nice to have so many developers out there working in something. The reason I didn’t use those other two products is I’d just never heard of them, whereas Zoomify, everybody uses it.

The nice thing about so many people using a tool is there’s always code out there, and so when I wanted to create custom buttons and tools, it was pretty easy. ActionScript is easy to read in a way that Java is not, and the code behind Zoomify is very easy to use. Detail from Love and Yearning And also, I have to say, the guy who runs it, David Urbanic, he’s just so nice. I would email him, and the first time I emailed him I had been banging my head against the wall trying to do something. He said “try this,” and sent me code. He’s just super friendly, and ever since then, when I’m working on a project I’ll show him things as I develop it and he’ll suggest ways to do it.

So that’s the reason for Flash. I’m sure other tools have their own communities.

I’m very conscious of the fact that we’re part of the Smithsonian, and I want to make sure a good number of people can see what we’re showing. In fact, we talk about using Flash all the time, but 99% of our site is HTML: straight HTML, very accessible using CSS, making sure it’s easy for people to read it with any sort of reader they may have. I wouldn’t put vital information like dates, times, and directions in Flash.

A few years ago there was a lot of QuickTime on the site. There’s less and less now. But now, if you want to present video it makes more sense if you want to do it in Flash.

since1968: You used the same code base for both the kiosk and the web site, but did you have to use a different wrapper for each?

Jacqueline Bullock: Most of it was redesign because we lost physical space on the web.

John Gordy: Yeah, we had to design the layout a bit differently. We had put in scroll bars to accommodate the text, which of course you don’t really want to do on a touch screen. But the time it took for the webification was a week or less.

We started out with the kiosk version. The code already worked, the zoomify was already written. I did have to go in and slightly tweak each coordinate for the web.

Jacqueline Bullock: The kiosk resolution was 1600×1200. It was so nice designing for that.

since1968: Is there a Smithsonian design standard? Every site under the Smithsonian banner must follow a certain set of design guidelines?

John Gordy: Think of it as a garden of wildflowers. You want them all to have their own personality.

Jacqueline Bullock: Air and Space is not going to have the same flowers as we are. There aren’t too many restrictions: you have to have the privacy act; you must link to the main Smithsonian site; and there are restrictions on how you can use the logo.

John Gordy: These are not big restrictions. That being said, if I were to redo our entire site in Flash 7 player that would be a problem. But before it would ever cause an issue on an institutional level, there would be an issue in house.

since1968: Will you be able to use code from this interactive in future projects?

Jacqueline Bullock: The hope is that this would be a prototype for other manuscripts. We really wanted to see if this is a model that we could then put in other manuscripts and use, to have a library in our own format.

since1968: So the hope is you’ll have a website and kiosk already built, and drop in a different set of graphics and text. Is it that level of templating?

Jacqueline Bullock: It never really is for us; we’re always trying to reach a higher level of quality. More than templates, this project added another tool to our repertoire.

We want the Flash interactives to be able to stand beyond the exhibition. When the exhibition goes offline, we want to make sure the interactives are still pertinent and interesting.

Comment

* * *

Review: The Flash Anthology · 305 words posted 09/27/2004 06:17 PM

After two years and several paid projects, I still feel like a newcomer to the Flash community. It’s easy to forget that the Flash work I do—extending web applications with data-centric Flash littleware—is a small subset of the skills traditionally emphasized by Macromedia, especially prior to the introduction of MX 2004: animation, sound, and text effects. My first reaction when I see a cool effect is “how did they do that?”

The Flash Anthology: Cool Effects & Practical ActionScript, by Steven Grosvenor, fits the bill nicely. (Disclosure: two years ago I was one of the technical reviewers on a Lisa Lopuck title to which Mr. Grosvenor contributed). The Flash anthology is published in a “cookbook” format and divided into task based chapters covering the basics of Flash.

For example, the chapter on animation includes a tutorial on using random movement to create subtle effects. One of the book’s strongest chapters is “Video Effects,” which includes an incredible video wall tutorial, as well as a hand-rolled scrubber and strategies for isolating moving elements to reduce the overall size of a video clip.

Two minor complaints: first, some of the examples run slowly on my G3 iBook. Granted, my laptop isn’t a workhorse, but it’s only two years old. And second—as with so many other publishers recently—SitePoint has printed the book in relatively low contrast gray scale, but still charges $39.95. That’s a hard decision to defend in a book dedicated to visual effects. (I’ll devote a separate article next week to the printing decisions publishers are increasingly making).

Other than that, The Flash Anthology from sitepoint is a solid title, and worth a look, especially for Flash programmers who would like to extend their skills to animation and video. If you can code XML.sendAndLoad() in your sleep but fear the Timeline, this might be the title for you.

Comment [1]

* * *

Flex Review on Digital Web Magazine · 31 words posted 09/23/2004 01:13 PM

Digital Web Magazine has published my review of Flex and Flex Builder. The short version: Flex rocks, but Macromedia will have to overcome a mixed track record with server-related products. Link.

Comment

* * *