Pathfinder Blog
Topic Archive: Firefox Extensions

Developer’s Notebook: Find computed styles in IE, Firefox, Opera or Safari

At my recent Web 2.0 Expo talk, I exhorted developers to get comfortable outside the Firebug/Firefox safety zone. By rotating between Opera, Safari and even IE as our primary development environments, we can really get to know those browsers - and perhaps learn to utilize their non-standard features. Switching things up, however, can inhibit productivity until you learn your way around each browser's tools.

To that end, I offer these step-by-step instructions for finding computed styles in all four A-grade browsers. I chose the display of computed styles as my "debuggers are cool" use case because it's an obscure but useful feature for CSS debugging. Most of the time I can debug styles by looking at my debugger's snapshot of the current cascade for a given element. But sometimes that's not enough. If I've assigned a value of "inherit" to the font-family of an element, then the cascade snapshot won't tell me what font is actually applied to that element. (Not being a designer, I often can't tell the difference between various sans-serif faces, especially at small sizes.) Luckily, computed styles can give me the information I need.

As these examples demonstrate, debugging tools have come a long way in the last couple of years. Let's make the most of them for all of our UI-layer needs.

Internet Explorer 8 and DebugBar

500

IE's JavaScript debugging tools have finally matured, but its CSS ones lag behind. Even IE8, with its built-in debuggers (under Tools > Developer Tools), won't show you computed styles. Luckily, Jean-Fabrice Rabaute has crafted DebugBar, an plugin for Internet Explorer 5+ that adds all sorts of useful tools. Install DebugBar, fire up your version of IE and choose View > Toolbars > DebugBar to make the plugin visible. Then click the "DebugBar" icon in the resulting toolbar to open the DebugBar sidebar. You'll see two tabbed panes, one below the other. Choose the "DOM" tab on top and the "Comp. Style" tab on the bottom. In the upper pane, you should see a target icon with the caption "Drag target on document to find element." Drag the icon anywhere on an open web page and you'll see computed styles for the corresponding element in the bottom pane of the sidebar.

IE8 DebugBar

Continue reading »

Getting semantic and DRY with microformats and Radiant CMS

Microformatsinaction
I can now cross Microformats off my list of "technologies whose value I recognize even though I've never had the chance to use them in real life." Last week I created three hcards for the new Pathfinder website, one each for our Chicago headquarters, our New York office, and our head of sales. Now, if you've got a browser plug-in that can parse microformats, you can import our contact information directly into Outlook, Apple's Address Book or your PIM of choice.

A little background

Microformats, for those who don't immerse themselves in grassroots front-end technologies, are at the core of what's become known as the "semantic web." The basic idea is that by adopting a set of standardized markup patterns, we can create websites that are more easily parsable by both humans and machines. More from the "About microformats" page:

Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns (e.g. XHTML, blogging).

The most popular and best-known microformat is the hcard, an HTML implementation of the standard vCard format used to store and exchange address and personal information in a wide variety of software applications. If vCards are basically electronic business cards that can be imported to or exported from your contacts manager, then hcards provide the same functionality in the browser.

Continue reading »

Keeping up with Firefox 3: The agony and the ecstasy of full page-zoom

I've been playing with the page-zoom feature in Firefox 3 Beta 3. Thanks to the hard work of the Mozilla folks, Firefox is now the third major browser (behind Opera and IE7) to support this feature. (Safari, of course, supports page zoom on the iPhone but not yet on the desktop.) I don't know whether to be elated or annoyed.

A little background: For years, browsers have allowed users to scale the font-size of any web page using built-in browser controls. The text would get bigger, but other page elements wouldn't. Increasing your font size wouldn't affect the layout of the page at all. If sites weren't careful about how they built their CSS, absolute positioning and fixed-width elements would conflict with the zoomed-up font sizes. The result wold be pages where the main content was readable, but navigational and chrome elements looked grotesquely distorted or in some cases disappeared into the seams of the CSS (see photo below).

New York Times homepage scaled to 170%

Continue reading »

More on Safari and the new Gmail upgrade

Over the weekend my Gmail finally got upgraded to the new version. (I know, I know, a week is hardly a long time to wait for a slow-rollout Google feature. But I'm impatient.) I have to say, the history and back-button support is AWESOME. It's funny that Gmail warns you in a huge red banner to disable Firebug. I, of course, kept it enabled and immediately began digging through the DOM of the new UI. As usual, most of the JavaScript is so obfusticated that it's hard to tell what's going on. Still, it's interesting to dig through layers and layers of iframes and nested divs and see how much DOM hackery is involved. Looking behind the scenes at any commercial-grade webapp is like taking a tour of a sausage factory.

Luckily, I have a strong stomach. I'm going to make it a weekend project to really dig in and learn how they're handling their history support. In a previous post, I wondered why the new Gmail is only available for Firefox 2 and Internet Explorer 7. Given my own experiences with Safari's history object, I shouldn't be surprised. With bookmarkable URLs and history management so central to the new Gmail UI, no wonder Safari has been left in the cold; it's simply too buggy in this regard to receive A-grade support. Safari users have been complaining to Google that it should fix Gmail for Safari even with the old UI. I think those complaints should be lodged at Apple, not Google.

Picture_1_3

P.S. Sure enough, leave Firebug open in Gmail for any length of time and your Firefox will slow to a crawl. My FF has been crashing a bunch this week, but I'm not sure whether it's Gmail or Firefox's own latest updates. Commenters, am I the only one seeing this?

Songbird 0.3: Why aren’t Ajax folks more geeked about “the Firefox of media players”?

Songbird, the open-source, Mozilla-based media player, received its 0.3 "developer pre-release" on Oct. 30. The UI hasn't changed much since the 0.2.5 "developer preview," but things continue to evolve under the hood. Better yet, the documentation and demos keep getting better. Check out the developer center for information about using XUL to build add-ons or using the JavaScript API to integrate your webapp with Songbird's media player.

If you've yet to experience Songbird, a little background is in order. The project is run by Pioneers of the Inevitable, a Bay Area company founded by veterans of Winamp and the Yahoo! Music Engine. Building on Mozilla's XULRunner platform and the VLC media player, Songbird aims to unite a web browser, a media jukebox and an online media player into a skinnable, extensible, open-source application. At this stage, the app is a long way from challenging the likes of Windows Media Player, let alone iTunes. But as it grows, it promises to cultivate the same kind of fervent user and developer communities as Firefox, Thunderbird and other Mozilla projects.

Picture_1

I first became aware of Songbird via a Boing Boing post. I'm surprised it hasn't generated more noise in the various Ajax feeds and news sources. With all the excitement about specialized browsers and desktop webapps, from Mozilla Prism to Google Gears and Adobe AIR, it seems like Songbird would be earning a lot of buzz. Maybe I'm just not hanging out at the right water coolers.

As an Ajax developer and huge music nerd, I'm looking forward to playing with the JavaScript API. It promises seamless integration between webapps running in the Songbird browser and the media player itself. Imagine iTunes, but instead of a built-in browser that only supports the iTunes store, you've got a Firefox clone that plays well with music vendors, P2P networks, MP3 blogs and any other internet music resource. Visit a music mag, for instance, and see all of its featured downloads automatically show up as a playlist in the media player (as in the Hype Machine example above). Visit an online music store and experience an iTunes-esque purchase experience. Indie-music brands such as eMusic and the aforementioned Hype Machine have already gotten on board. To see Songbird's API in action, compare these sites in Firefox and Songbird.

Songbird's add-on ecosystem is cool, too, especially for long-time Firefox developers. They can adapt existing add-ons with just a few tweaks. (GreaseMonkey, for instance, has already been ported.) But Songbird's API allows for more radical innovation than Firefox's add-ons. Instead of simply adding context menus and pop-up dialogues, you can rewire the entire UI of the media player. One example on the developer site shows how to replace the single play/pause button with individual play, pause and stop buttons. That's a trivial example, but a telling one.

I'm already salivating about the cool stuff I'll be able to do with add-ons:

Tag-parsing madness

Imagine Doug's AppleScripts for iTunes ported to XUL. Like a lot of people, I'm obsessive about my meta tags, and I can't wait to use JavaScript regexes to bend them to my will en masse. I'm also hoping that Songbird will record all of its meta data in the music files themselves instead of socking some of it away in the music library. With iTunes, if you decide to rebuild your library in another player - or even in a different iTunes installation - you lose things like star ratings and play counts. It's a real bummer.

Huge libraries

The flat XML database in iTunes scales horribly. Get above about 100 gigs of music and performance slows to a crawl. This problem has only gotten worse with the bloat of Cover Flow, Quicktime integration and all the other features I don't need. I have 450 gigs, most of it ripped from my huge CD collection, and I've had to separate it into four separate libraries (using Libra) just to get decent performance. That sort of defeats the whole "any song at any time" promise of the MP3 era. Enter SQL Lite, which is how Songbird stores its own media library. I've got high hopes that a relational-database back end coupled with open-source how-to will make Songbird the media player of choice for folks with enormous libraries.

Interface freedom

iTunes and its Smart Playlists are all about endless, automated mixes. But I'm an old-school mix-tape guy. At the end of each year, all of my friends usually get a four-CD retrospective of the year's best tracks as compiled by me. But with iTunes, it's excruciating to build a "source" list of possible tracks for these multi-disc epics, then slot the tracks into individual discs and experiment with sequence. You can only view one playlist at a time, so every time you decide to move a track from one playlist to another, it's a multi-step operation. Imagine an interface where I could see my "source" list and all of my target lists at once, and where drag-and-drop defaulted to a "move" operation rather than a "copy" operation. With XUL and JavaScript, I'll be able to build any specialized interface I want and swap it in for Songbird's default UI.

Sure, most of my needs are pretty specialized, but I hardly think they're unique. And that's the point of an extensible, open-source player. You're free to build the features YOU want to see and share them with others like you. That's a lot more productive than griping over at the iLounge forums about iTunes's shortcomings.

I know Songbird isn't the only open-source, component-based music player out there, but it is the only one that's drawing on the power of the Mozilla Foundation. Firefox has shown how disruptive the Mozilla community can be in the browser market, which, like the music-player market, is dominated by a single product. Songbird may not topple iTunes any sooner than Firefox topples IE, but it should provide a powerful alternative and perhaps put some competitive pressure on the folks in Cupertino. It was extremely shrewd of Pioneers of the Inevitable to hitch their wagon to Mozilla's. I'm definitely going along for the ride.

Songbird links

Songbird posts

Technorati Tags

Mash Note: Foxmarks bookmark synchronizer

All bookmark sync utilities are not created equal. Plenty of browser add-ons promise to keep your favorites in sync across computers, while Del.icio.us and its ilk host your links up in the cloud. For my money, though, if you're a Firefox user with a serious bookmark habit, nothing beats the free browser extension Foxmarks.

I'm the first to admit that I've got a problem with my bookmarks - all 3,000 of them (and counting). I do tons of research for this site and my other writing gigs. When I come across something useful, I hit Command-D automatically. (I'm just as bad with clippings in my RSS reader.) Every once in a while, I do a clean sweep: reading, filing, purging. But until I've extracted whatever piece of knowledge I need from a particular link, I want access to it from all of my workstations and Internet devices.

Foxmarks1

That's where Foxmarks comes in. When you set up an account and install this free Firefox extension on multiple computers, it keeps the bookmarks in sync across machines and backs them up to the Foxmarks server. When you bookmark something at home, then want to refer back to it the next day at the office, you're golden. And when you're away from your own workstations - say, in an internet cafe or on a mobile device - you can hit My Foxmarks, the webapp version of the service.

The Foxmarks browser add-on gives you some fairly coarse-grained control over how and when syncing occurs. If you set your preferences to sync manually, or only on shutdown, you may get stuck answering a series of dialogs as the server parses your changes. My recommendation: Enable automatic synchronization in the background. In earlier versions of the service, the sync dialogue would hijack your browser and hog your CPU, especially if you were digging around the browser's "Organize Bookmarks" screen. Such performance problems have now been reduced, if not eliminated.

As for My Foxmarks, it, too, has improved over time. The current interface uses the YUI and Ext libraries for a seamless, desktop-like Ajax experience. The UI offers both a folder-tree view and a paged grid view; you can access individual bookmarks' details from either view. There's even an iframed preview pane that can show you the target of a bookmark without leaving the Foxmarks site. And, of course, there's a scaled-down mobile version. All in all, it's a slick, well-designed experience.

Foxmarks2

Of course, there's always room for improvement. I find the built-in Firefox bookmark manager cumbersome, buggy and annoying. I'd love to see the Foxmarks team position My Foxmarks as a powerful, intuitive web-based replacement. To get there, they'd probably need to add inline editing, a more customizable interface, and perhaps integrated tagging. A trash bin for deleted bookmarks would also be pretty cool, as would the ability to batch-delete bookmarks without constant confirmation dialogs. Most browsers' internal bookmark managers - and most social bookmarking services - don't offer a very efficient or useful UI. It would be great to see somebody get it right.

I have no idea whether such features are in the cards, but Foxmarks's developers aren't resting on their laurels. Just yesterday, they announced a beta of Foxmarks 2.0, which promises to offer:

  • Major changes on the server side, including much more efficient syncing.
  • A nice tweak to the syncing process so that it preserves favicons across computers.

Pretty sweet!

Technorati Tags

IBM’s CoScripter: Greasemonkey for non-geeks

Think of all those annoying step-by-step processes you must learn and memorize to go about your daily online business: logging onto your bank site to check the balance on your savings account; filling out a tedious form; ordering prints of your digital photos. The elements of the UI are easy to understand, but the process itself differs wildly from site to site.

Now imagine a Greasemonkey-esque add-on that not only automates those processes, but shares the automations with everyone else. All you have to do is write the instructions in plain English, let your browser record the steps in real time, or search the existing archive for somebody else's previously recorded automation. Sold yet? Good, then meet CoScripter, a new Firefox add-on from IBM.

Alex Faaborg over at Mozilla Labs sums up CoScripter thusly:

What do you get when you mix one part automation, one part natural language interpretation, two parts programming by demonstration, and three parts online collaboration? If you stir all of these research areas together and toss in some XUL, you get one of the most innovative extensions for Firefox: CoScripter.

Jon Udell has kicked off a pretty interesting discussion of CoScripter as a mash-up of social networking and domain-specific languages. But I'm most excited about the technology for its grassroots potential. Like microformats, CoScripter has the potential to evolve into an "accidental standard" that proves the enduring power of the Open Web. I can foresee a future in which site owners coach newbies about their interfaces by releasing CoScripts instead of publishing big chunks of step-by-step instructional text. Of course, the technology's future ecosystem depends on how IBM licenses it. One less-than-promising sign: the onerous registration process and EULA I had to endure before downloading the add-on.

Nevertheless, as of this writing, 190 CoScripts have been submitted. Lots of them seem fairly limited in scope, but I'm sure that will change as the community grows and the technology matures. The add-on's handy Sidebar interface displays the "editor's picks" for most useful scripts. I'm particularly fond of Add your phone number to the national do not call list.

I wrote two of those 190 scripts myself, and my experiences highlight the strengths and weaknesses of CoScripter as it's currently implemented.

First off, I tried to automate the process of logging into popular blogging engine Vox and starting a post. The tutorials
helped me figure out how to parameterize private data such as email
addresses and passwords into a locally stored "personal database." That way, I can write scripts that work for me, then share them with anybody who sets up similar key/value pairs in their datastore.

The plugin did a pretty good job of recording my steps as I interacted with the browser. (Users of the open-source Selenium QA framework will feel right at home.) But the recording engine totally ignored my interactions with Vox's password field. Even after I manually scripted this step - in CoScripter's eminently simple natural-language syntax - I couldn't get the sequence to work. Still, I've saved it (Login to Vox and Compose Post) in the shared repository. Perhaps a smarter Vox user than me could get it running? Here's the source code:

      
       
  • go to "http://www.vox.com/"
  • enter your "vox login" into the "Member sign in"'s "Email:" textbox
  • enter your "vox password" into the "Member sign in"'s "Password:" field
  • click the "Sign In" link
  • click the "Compose Post" link

      
   

Next, I tackled something much simpler: Read La Dolce Musto. I love this Village Voice column, but I always have to hunt for it on the busy homepage of NYC's alternative weekly. There's no landing page for columnist Michael Musto, and the site's layout changes weekly. My simple, two-step script hits the homepage and activates the first instance of the writer's name as a link. It worked for this week's issue, but I'll have to wait till next Wednesday to make sure it doesn't bomb out once the homepage rolls over.

Again, the source code:

      
       

      
   

Given how difficult I found it to get a moderately complex script working, and how trivial my actual working example is, I can't say that CoScripter is going to set the world on fire immediately. Password fields seem to be a problem, and there's no ability to use conditional structures. I'd love, for instance, to be able to write a script that goes to Vox, logs me in only if I'm not already authenticated, then begins a post. It would also be great if I could build in timers, such as "wait x seconds," so that Ajax interactions or other slow-moving changes in state could be accommodated. I mentioned Selenium before, and its powerful syntax for writing test scripts seems like a model for future development. If CoScripter's engineers can expand the power of their DSL without losing its simplicity and ease of use, this add-on seems likely to earn a wide and enthusiastic user base.

[Thanks to the awesome Lamda the Ultimate for the original tip.]

The awesome state of JavaScript development tools

Dietrich's post on the depressing state of IE develpment tools got me to thinking about the generally wonderful state of JavaScript tooling. Compared to just a few short years ago, we've got a wealth of productivity-enhancing browser add-ons, TDD frameworks and static-analysis tools at our disposal - most of them open-source. For those who want to get their hands dirty writing POJ, this is a golden era.

Like most developers, my code circa 1998 was filled with commented-out alert() statements. I spent way too many hours cursing IE4's inability to report accurate line numbers in its error dialogs. I relied heavily on Netscape's built-in debugger. Within a couple of years I had graduated to a primitive logging utility that spawned a separate browser window and output messages into it using simple DHTML. At the time, it seemed like a huge advance.

Then came the Firefox era, with its host of disparate add-ons. You could edit your CSS in the sidebar, selectively disable JavaScript and CSS, inspect the DOM .... Once again, the possibilities seemed endless. Now, thanks to Firebug, most of my grab-bag of browser add-ons are gone. Firebug is so powerful and wide-ranging that the only other add-on I use regularly is the venerable Web Developer Toolbar. Yahoo's new Firebug extension YSlow adds some really useful optimization benchmarks to the suite. When a plug-in begins to spawn its own plug-ins, you know you've got a winner.

I'd be interested to know, though, what kind of process UI developers use to debug their JavaScript. Most of us are using similar tools, but how are we using them? (That's an invitation to jump in on the comments, folks.) Every UI person I know develops prototypes in Firefox and Firebug, crossing his or her fingers that there won't be too many implementation-specific issues to tackle in the other browsers. Many rely on a logging utility - heir to that long-ago popup window - to grind away at any such browser bugs.

But beyond that kind of hunt-and-peck debugging, have we arrived at an industry-standard practice for client-side code maintenance? Who's doing true TDD with one of the flavors of JsUnit? Who's using Selenium to test their entire webapp in the browser? Who's picking apart the details of their syntax with Douglas Crockford's JsLint? Who's busting out Fangs or another accessibility test tool on a regular basis? The tools are out there. It would be interesting to know who's using them, and how.

When you're banging your head against a wall trying to figure out why a certain DOM element won't return the same node type from one browser to the next, it's easy to see why there are a hundred competing Ajax frameworks promising to solve all your cross-browser issues for you. Let's just remember how far we've come - and how important it is for real-deal UI developers to maintain the skills that they've honed for over a decade. The more trust we put in frameworks, the more helpless we'll feel when our code fails and we've lost the ability to figure out why.

That’s so 1999

Lots of trees (and pixels) have given their lives over the past 10 or 12 years to fuel the endless debate about graceful degradation, progressive enhancement and the separation of style and behavior from content. The web standards movement has gained traction by boiling the argument down to one simple assertion that geeks can sell to suits:

If you're in the business of hawking something - vintage hockey memorabilia, advertising impressions, "Harry Potter and the Deathly Hallows" or even plain old editorial content - then you should probably build web sites that make it as easy as possible for as many people as possible to give you their money...

... even people who can't or won't enable JavaScript in their browser/phone/whatever.

It astounds me that we still have to belabor this point in 2007. But a random sampling of large commercial websites reveals that even the big players haven't yet taken this lesson to heart. United Airlines, Sears, Expedia and Amtrak, for example, fail in various subtle or spectacular ways when you disable JavaScript or employ a user-agent without it.

(If you're using Firefox, just install the Web Developer Toolbar, use the Disable menu to turn off all JavaScript, and load one of these sites.)

When you load United's new(ish) multimillion-dollar booking engine sans JS, you get a search form with empty date dropdowns and a bunch of links and buttons that don't work. Sears.com is even more insidious. With a little bit of work, you can get some products into your cart. But when you click the checkout button, nothing happens.

Once upon a time, most commercial sites would at least use a <noscript> block or a server-side browser sniffer to warn you that their sites required JavaScript to function. That's how Amtrak does it today. So does Expedia:

Expedia1_4

"To enable great site features that are currently disabled, simply make a few adjustments to your browser settings ...." And what, pray tell, qualifies as a "great site feature"? Apparently, the ability to search for flights at all:

Expedia2_2

I can understand how a start-up like Kayak - with its innovative Ajax UI - can afford to demand a modern, scriptable browser. That will all change when they have a mature business model. But a travel behemoth like Expedia?

Look at the biggest successes of the eCommerce gold rush. Amazon, eBay, Yahoo and Google just plain work on all sorts of user-agents. Often, they offer separate interfaces optimized for mobile or assistive devices. Disable JavaScript on these sites and you can shop, search and browse to your heart's content. How can a site like Expedia not emulate them? Last time I looked, travel was a low-margin, high-volume business. Even if you're throwing away only 1 percent of your business, that's still a _lot_ of wasted revenue.

I'm also at a loss to explain how what's left of our pathetic national passenger-rail service can afford to squander potential customers by requiring them to use a technology that opens up untold security holes in the browser used by the majority of the planet.

Most places, I'm the biggest JavaScript dork in the room. I'm writing on a blog called Agile Ajax, for god's sake! But I still expect my favorite sites to work when I'm stuck on a Windows machine whose network admin has ratcheted up the security to absurd proportions. When I borrow a pal's iPhone, with its five-second script timeout, I expect to be able to do _something_ on the sites I visit. Ditto when I'm on a tediously slow connection on a laptop overseas.

I don't mean to pick on these sites. Heck, in a former life I worked for one of Expedia's competitors, and our site failures in non-JS environments were often of the silent but deadly variety. Even earlier, I was a contractor at United itself, and I'd sooner page through my junior-high yearbook than look at the still-live JavaScript code I wrote for them. Back when I was at Reflect.com, a now-defunct customized-cosmetics emporium in San Francisco, I used to generate the entire homepage with JavaScript, just because I could. I was having fun learning the language.

That was then, this is now. Jeffrey Zeldman's "Designing With Web Standards" is in its second edition. Any number of blogs, articles and books spell it out for even entry-level developers exactly how they can architect web applications that benefit from all that JavaScripty, Ajaxian goodness without turning away users who can't or won't partake.

We have the tools. We can do it. When we don't, it's a deliberate choice. The next time you're gathering requirements for a consumer eCommerce application, sit down with your client in front of a zippy new Vista PC running IE7 with JavaScript disabled via the security settings. Then try to buy some slippers from Sears, or a hotel room from Expedia, or a ticket from United. I don't think you'll have much trouble selling progressive enhancement as a fundamental part of the solution you're building.

Alert: Security Update for Firebug

Joe Hewitt has released a security update to his excellent FireBug Firefox addon.

About an hour ago I received word of a 0-day security exploit that has been discovered and reported. I have just released a new Firebug (version 1.03) with a fix for this bug, and I recommend that everyone install it as soon as possible.

The update has been published to addons.mozilla.org, so you can get it by updating Firebug from the Firefox Add-ons window. Alternatively, you can install the update using the big orange button on the getfirebug.com home page.



Technorati : , , ,

Firefox Extensions and AJAX - A Model for Web 2.0?

Let's face it, cross site AJAX is a real pain. If you're going to provide your components as a service, sort of like Google maps, you're task is not impossible yet still challenging. If you want to mash up your app with other services at the browser level, you've got to proxy those services. Put any way, it's a pain. How to simplify creating truly powerful, cross-site AJAX apps?

Greasemonkey showed the way, demonstrating how you could manipulate pages with Javascript. Book Burro was one of the first AJAX/Greasemonkey hybrids that allowed you to search for a book at your favorite online book merchant, then click on a semi-transparent drop down menu and see book prices at competing retailers. The magic of AJAX! Book Burro has since made the transition from Greasemonkey script to Firefox extension in its own right.

Another example of this curious Firefox Extension/AJAX hybrid caught my eye the other day: MyStickies. This extension will allow you to insert AJAX-DIV stickies onto any web page. The extension handles this insertion and also includes a Javascript library via a Javascript file from mystickies.com and another via chrome://mystickies/ for the behavior.

stickies.png

The sticky location is persisted to the mystickies site where you can also use a webapp to search, manage, etc., your stickies. It's a direct manipulation bookmark that doesn't reside just on your local computer.

Now I happen to think mystickies is pretty cool, especially if they implement some of the features on their roadmaps, like sticky sharing (how web2.0!). But what interests me here is the application architecture. Firefox Extension plus AJAX = a service that can be applied across other web sites. There is clearly a limit to this opportunity -- you have to really like a service and truly, how many of us are willing to keep 20 extensions running, each of which hogs a piece of browser toolbar realestate? Many of these players are already planning IE, Safari and Opera ports.

What shall we call this thing? Browser Extensions and AJAX? BEJAX?

About Pathfinder

  • We design and build extraordinary applications for companies looking to make the next great idea a reality.
  • learn more

Topics

WordPress

Comments about this site: info@pathf.com