Browser Add-ons, Mozilla, Mozilla Firefox, RSS, RSS Ticker

Major RSS Ticker Update Coming: What You Need to Know

RSS Ticker has been an alternative to Web-based feed readers since 2006, displaying feed updates directly in users’ browsers. It hasn’t seen significant change in a while, but some of the internal Firefox code used by RSS Ticker has changed enough that in order for it to remain functional in Firefox 22, its entire architecture would have to change. That’s a lot of work.

RSS Ticker

I didn’t want to abandon RSS Ticker’s users (especially with the shutdown of Google Reader imminent, already leaving one less feed reading option), but I also couldn’t dedicate the time to completely rewrite the add-on and keep all of its features. So here’s what I’ve done:

RSS Ticker has been completely rewritten. This has given me the opportunity to use the knowledge I’ve gained in the last seven years of programming to improve the overall design of the ticker and to restructure the code to play nicely with the new Firefox APIs.

What hasn’t changed? RSS Ticker will still scroll your feeds in your browser. You can still choose to put it at the top or bottom of your Firefox window. You can still exclude specific feeds. You can mark as read, mark feeds as read, open in tabs, open all in tabs, etc. You can temporarily disable the ticker. You can change the ticker speed, smoothness, and direction. You can hide the ticker automatically when it’s empty.

What has changed? In order to continue supporting RSS Ticker, I’ve had to drop a number of features. Here are some things you can no longer do with RSS Ticker:

  • Manually refresh the feeds.
  • Specify how often the feeds should refresh.
  • Randomize the order of the ticker items
  • Limit the number of items per feed
  • Display items that have already been read
  • Show unread items in bold
  • Manually limit the width of ticker items
  • Customize the context menu

I know some of you liked and used these features. I’m sorry I had to remove them, but it was the choice between removing them or abandoning the add-on altogether.

A few features haven’t been removed, but they have been changed (a.k.a. “improved”):

1. All of the remaining options (six of them, down from a total of 37) are displayed inline in RSS Ticker’s section of the Add-ons Manager.

RSS Ticker Options

2. If you want to temporarily disable the ticker, just uncheck it in the View > Toolbars menu.

Disable RSS Ticker

3. To remove a feed from the ticker (but not from your bookmarks), right-click on it in the Bookmarks Manager and uncheck “Show in RSS Ticker.”

Show a feed in RSS Ticker

This new version will be available in a couple of weeks after some more testing, but if you’d like to test it early, leave your e-mail address in a comment or ping me at chris@efinke.com and I’ll send you a copy.

Standard
Browser Add-ons, Mozilla, Mozilla Firefox, OPML Support, Programming

OPML Support updated for Firefox 20

I’ve just published an update to my OPML Support Firefox extension for the first time in three years. The extension previously added an OPML button to the toolbar in the Bookmarks Manager, but as of Firefox 20, the button disappears because of a change to the way that the Bookmarks Manager’s toolbar is assembled. Version 3 of OPML Support moves the Import OPML and Export OPML options into the existing Backup/Import button’s menu.

opml-menu-mac

Thanks to the OPML Support users who alerted me to the problem via email and in the comments here, since I don’t often have occasion to check whether my buttons are disappearing.

Standard
Mozilla, Mozilla Firefox, TubeStop, YouTube

Adopt an Add-on: TubeStop

Notice: TubeStop was discontinued on December 25, 2012 and is no longer supported.

I’m no longer going to be updating TubeStop, a Firefox extension I wrote that disables autoplay on YouTube videos. I don’t have the time or the inclination to keep up with YouTube’s HTML changes.

TubeStop has been around for about five years, and it has 17,000 users. It was the first browser extension that made it possible to disable YouTube’s autoplay feature (if you don’t count the all-purpose Flashblock), and it gained notoriety in 2007 for inadvertently stripping ads from YouTube videos.

If you’d like to adopt this abandoned add-on, let me know, and I’ll transfer ownership of the extension to you on Mozilla Add-ons. If nobody wants to take over development, I’ll shut it down and the void will be filled by one of the other anti-autoplay extensions on AMO.

Standard
Browser Add-ons, Feed Sidebar, For Sale, Mozilla, Mozilla Add-ons, Mozilla Firefox, RSS Ticker

Firefox Add-ons for Sale

The time has come for two add-ons, RSS Ticker and Feed Sidebar, to find new owners.

Since I started developing add-ons for Firefox, I’ve written at least forty different extensions: some for personal use, some as a freelancer, and some as the primary function of my full-time employment.

In order to free up more time to pursue new ideas and projects, I occasionally need to either retire or transfer ownership of add-ons that I wrote of my own volition. Some of these, like TwitterBar and FireFound, were retired by executive decision. Today marks the first time that I am attempting to actively sell the rights to some of my add-ons.

Allow me to brag about these add-ons

RSS Ticker and Feed Sidebar are my two most popular add-ons, and they’re fully functional in the most recent version of Firefox.

RSS Ticker Screenshot

Both of them have been featured as “featured” or “recommended” add-ons Mozilla Add-ons multiple times, and both maintain healthy usage by a dedicated base of users not interested in Web-based feed readers.

RSS Ticker averages 39,000 daily users and has been download 1.3 million times. Feed Sidebar averages 21,000 daily users and has been download over 900,000 times. The two add-ons are unlikely to have overlapping users.

RSS Ticker is the first Google result for firefox ticker. It is also the first result for rss ticker and feed ticker.

Feed Sidebar screenshot

Feed Sidebar is the fourth result for firefox feeds and firefox feed reader and number two for firefox feed. It’s number one for feed sidebar.

Both of these add-ons would be excellent footholds for a Web-based feed reader to attract users who prefer to consume news directly from their browsers; they would be equally beneficial for content-oriented sites to push recommended feeds to users via the already-integrated “Featured Feeds” feature in both add-ons. (Both extensions regularly check a list of “Featured Feeds” and suggest these feeds as subscriptions to their users.)

What do you get if you buy?

If you buy either of these add-ons, I’ll:

  1. Transfer ownership of the add-on(s) to you on Mozilla Add-ons.
  2. Redirect the add-on pages on my blog to the pages of your choosing.
  3. Forward any feedback e-mail I receive regarding the add-ons indefinitely.
  4. Add you to my Christmas card list.
  5. Be a good guy in general and offer free consulting and advice related to the add-on(s) for as long as I can.

If you’re interested in purchasing either or both of these add-ons and taking over their development, e-mail me at chris@efinke.com.

Standard
AutoAuth, Browser Add-ons, Feed Sidebar, Interpr.it, Links Like This, Mozilla, Mozilla Firefox, OPML, Programming, RSS Ticker

Interpr.it now speaks Mozillian

My browser extension translation platform, Interpr.it, is now able to parse locale files from extensions for Firefox, Thunderbird, SeaMonkey, or any other Mozilla-powered program, and it can likewise generate Mozilla-compatible locale files. The interface for translation is the same as the one for translating Chrome extensions, but when the locales are downloaded via the API, the files are returned in the format in which they were originally uploaded (either DTD files or Java-style .properties files).

This is most obviously introducing a competitor to Babelzilla, the only major site offering a translation platform for Mozilla extensions. Babelzilla is a functionally sufficient solution for translation (I’ve used it without much issue for almost six years), but I’m moving away from it for two reasons:

  1. Translation/localization is a problem that I’d like to understand better, and I find the best way to understand a problem is to try and solve it yourself.
  2. I think that the experience of localizing an extension (or developing a localizable extension) can be better, and I have the hubris to think that I can be the one to make it better.

In the spirit of putting my money1 where my mouth2 is, I’ve moved five of my Firefox extensions (AutoAuth, Feed Sidebar, OPML Support, RSS Ticker, and Links Like This) from Babelzilla to Interpr.it.

If you are interested in trying Interpr.it, upload your extension (either using the Web form or API), and let me know how it works for you.

  1. For extremely small values of “money.”
  2. For extremely large values of “mouth.”
Standard
anyMail, Mozilla, Programming, Thunderbird, Toby

anyMail

Unlike most of my posts, this one isn’t about some new software I’ve written; it’s about some old software I’ve written.

In 2002, like any other college student out on his own for the first time, I decided to write my own e-mail client.

What – you haven’t written your own e-mail client? You will. As a complement to both Letts’ Law (“All programs evolve until they can send email”) and Zawinski’s Law (“Every program attempts to expand until it can read mail.”), I propose Finke’s Law: “All programmers will write their own mail client (and later regret it).”

I named my webmail client Toby and used it as my primary client for three years; once it was stable enough for other people to use, I started publishing updates on SourceForge (back before GitHub became the new SourceForge). Toby was my first legitimate open-source project.


Toby Web Mail, in its heyday, Outlook Express was a big influence. Also, the Pokemon cards were my brother’s.

In 2004, I needed a few more credits to finish my degree in Computer Science, and I opted to do an independent study under Joseph Konstan. (Professor Konstan was one of the only profs at the University of Minnesota at that time who had some involvement in Web software; the other one that I knew of was John Riedl, who was already the head of the fledgling Software Project class that I was a part of, which is a topic for another post.) For my project, I decided to refine my mail client, using IBM’s Remail prototype as a roadmap.

Over that semester, I rewrote Toby and branded it as anyMail. I don’t remember why I called it anyMail, but it was probably because it could connect to any IMAP or POP3 mail account. Clever.

Some of the features I planned on integrating into anyMail were inspired (read: stolen) from the very-new (at that time) Gmail; specifically, labels (instead of folders), the concept of “archiving”, and an entirely AJAX-based system for loading messages (although at that time, the term “AJAX” hadn’t been coined yet). However, one feature that I beat Google to was my own version of Priority Inbox. From my project proposal:

I intend to implement: [...] Automatic sorting of incoming mail into different categories, such as read, unread, un-replied to, messages from people the user has replied to in the past, messages likely to be spam, messages from people in the user’s address book, etc. I feel that one of the largest areas for improvement in current Web mail clients is that of automatic information sorting and presentation.

(Of course, I wasn’t the first to ever think of this concept. Microsoft has prior art dating to the late ’90s.)

A concept I implemented from IBM’s Remail was thread arcs. Thread arcs are a way to visually represent a conversation using circles and arcs:

The hollow circles are messages sent by the user; the solid circles are replies. Clicking on a circle loads the corresponding message. Neat, but not terribly useful.

As far as I know, I was the only person to have implemented thread arcs outside of the Remail prototype at that time. They’ve gotten around by now; there is even a Thunderbird add-on that generates them.

So, fast-forward to a couple of days ago, where I had blissfully forgotten about the hundreds of hours I spent writing code to parse multipart e-mail. I was searching through my e-mail for something unrelated, and I happened across a conversation between myself and Rob Malda; I was applying for a job at Slashdot, and I had sent him a link to anyMail as a part of my application. The URL was dead, so I did the reasonable thing: hunted down a copy of the source code, upload it to that server, and get it to work.


Here goes nothing.

And it did work! After ten minutes of creating the necessary database tables and an email address to use for testing (I didn’t want to inadvertently wipe the contents of an important account – I trust my code, but I don’t trust trust it), I logged in and had a working instance of anyMail before me:

I played around, sent and received a few e-mails to confirm functionality, and was mostly pleased with how well anyMail held up.


The only flaw I found was that attachments didn’t get sent. That might be a misconfiguration my Web host though.

This was amazing to me. The last time I used anyMail, it was in Firefox 1.0, and it still works in Firefox 11 and Chrome Umpteen, without the benefit of a JavaScript library like jQuery doing the heavy lifting of cross-browser compatibility. It was also written in an environment with PHP < 4.3, and ran mostly without issue under PHP 5.2.

The other thing that surprised me was how consistent my coding style has been over the last eight years. Even though I was shocked and appalled by the gaping security holes (XSS, CSRF, and SQL injection issues were all present) and disgusted by the number of synchronous XHR calls, I was pleased to recognize the code as mine. I don’t specifically remember writing it, but I can tell by the formatting, variable names, and structure that it was formed by my hand.

I spent a few minutes cleaning up the code — some basic protection against XSS and SQL injection — and uploaded it to GitHub. I don’t expect anyone to use it (and I hope nobody does, at least not without modification), but I’m keeping it around so I can look back on it and learn from my mistakes. But hey, if you need a class to generate thread arcs in PHP or an email client that works in Firefox 1.0, you know where to look.

Update: Toby is no longer supported. I recommend using RoundCube Webmail instead.

Standard
Browser Add-ons, Flock, Mozilla, Mozilla Add-ons, Mozilla Firefox, Mozilla Firefox for Mobile, Netscape Navigator, Software, URL Fixer

URL Fixer Has Been Acquired

URL Fixer, one of the first add-ons I wrote for Firefox, has been acquired! It is now being managed by the team at URLFixer.org.

URL Fixer was inspired in 2006 by this Firefox bug report. Since then, it has been a featured add-on on the Mozilla Add-ons Gallery, it was one of the first add-ons to be compatible with Mobile Firefox, and it placed in the Extend Firefox 2 contest. It used to be compatible with both SeaMonkey and Flock (remember Flock?); its functionality was included in Netscape Navigator 9, and it was at one point under consideration to be included in Firefox 3.

URL Fixer has also been the subject of several experiments: it was the source of the statistics I used in my examination of what people type in the address bar, and it was the add-on I used to test the feasibility of selling a freemium browser add-on.

The new team in charge of URL Fixer recently released version 4, which you can install without needing to restart Firefox; I’m looking forward to seeing what other improvements they make and in what direction they take the add-on. Please note: support questions should no longer go to me; please send them to info@urlfixer.org.

Standard
Browser, Google Chrome, Ideas, Internet Explorer, Life, Mozilla, Programming, Safari

An API for Browser Screenshots

What do the following screenshots all have in common?

From Amazon’s Cloud Reader Installation:

From the University of Virigina’s guide to setting proxy settings in Firefox:

From HootSuite’s TwitterBar acquisition announcement:

From Tecca’s Guide to Internet Explorer:

That’s right: they all include portions of browser chrome. (Chrome 13, Firefox 3, Firefox 4 for Windows, and Internet Explorer 9, I believe.)

What else do these screenshots have in common? They will all one day be out of date (if they aren’t already). As soon as Google modifies their extension installation dialog, or Mozilla changes their proxy settings tab, or the Firefox address bar gets a new background color, these screenshots will no longer accurately represent the interaction through which they’re meant to guide the user.

A Modest Proposal

I propose that this problem of stale browser screenshots could be alleviated by the creation of a Web service that exists solely to serve semi-dynamic screenshots of browser chrome. Allow me to explain with examples.

The Amazon screenshot above could be replaced with a call like this:

<img src="http://browsers.foo/addons/installation?highlight=confirm&w=460&h=60" />

Or the TwitterBar image could use this URL instead:

<img src="http://browsers.foo/toolbar/?include=url-bar,icon&icon=http://foo.com/hoot.png&highlight=icon" />

(Note the idea of being able to merge existing images into the screenshots.)

The IE add-ons dialog screenshot could just as easily call this URL:

<img src="http://browsers.foo/addons/tracking-protection?browser=ie&version=9&highlight=easy-list" />

The API would automatically use the user’s user-agent to determine what browser, version, and platform to show in the screenshot (although these could also be specified manually, as seen in the IE example). If images from the exact current version aren’t available, the most recent version could be used instead.

I think that with a couple dozen high-resolution, high-quality screenshots of the various windows and dialogs in each major browser version on each major platform combined with metadata defining the position of key elements in those screenshots (e.g., the home button, the address bar, the History menu), 90%+ of the browser-specific screenshots on the Web could be replaced by calls to this service.

What do you think?

Is this a solution in search of a problem, or is it a legitimately useful idea? I think it would be worth its development costs just for organizations like Mozilla or Google to use in order to populate their help documents with screenshots that would always be up to date. Tell me what you think in the comments below.

Standard