Done

Mozilla Labs: Prospector - Find Suggest

• Closed a memory leak (issue #9).
• Clearing the suggestions when switching tabs (issue #8).

Mozilla Labs: Prospector - Speak Words

• Closed a memory leak (issue #16).
• No longer removing last typed char and suggestion when delete is pressed (issue #15).
• Bug fix when pressing delete after pressing left/right (issue #11)

Scriptish

• Supporting @run-at (issue #10).
• Supporting @delay (issue #100).
• Adding a newline to the end of every script now because missing it caused some scripts to no longer work (issue #104).

User Scripts

• Wrote a very simple script to add the old "Downloads" link to a GitHub repository's main menu, and removes the new dump "Downloads" button (userscripts.org script #8870)

[More]

Well I started this week working on Scriptish, but I felt that I needed a break after working on it nearly every day for the past few weeks, so I spent about half the week working on a few other things.

Mozilla Lab's Prospector add-ons, which they announced two weeks ago, caught my attention and I started doing a little hacking on one of them; after spending some time using 2 of the currently 4 prospector add-ons I can tell you that I really like them, because they each focus on solving a single, particular, searching UX/usability issue in the context of the browser, and they're restartless!

Done

Scriptish

• Released Scriptish 0.1b5 on the 19th.
• Replacing the status bar icon with a frequently requested toolbar menu-button (It's a button & a drop-down menu), which is added to the add-on bar when Scriptish is installed for the first-time, or when Scriptish is upgraded from a version less than or equal to Scriptish 0.1b5.
• Added a ID field to the new script window.

GitHub Flavored Markdown

• Created some GitHub spice for compare urls (issue #9).

MDC

I noticed that there wasn't any documentation on em:bootstrap on the page describing install manifests, so I added something basic with a link to more information.

Mozilla Labs: Prospector - Find Suggest

• Performance tweaks.
• Bug fix when using the find bar on a blank page, which causes an error to be thrown (issue #1).
• Sorting words with equal frequency alphabetically (issue #3).
• Changing the regular expression used to split words (issue #4).
• Requiring words to be 3 characters or longer (issue #2).
• Making the suggestion limit a user preference (issue #7).

[More]

For a long time now both user script authors and Greasemonkey users have wanted Greasemonkey to be able to update user scripts. In absence of this feature user script authors have resorted to rolling their own code to do the updating, which has lead to a minefield of problems ranging from simple javascript errors to causing long downtimes on userscripts.org. Besides the obvious risks that third-party user script updaters have of not working, over using bandwidth, and harming the uptime of important websites, there is also a variability of design and usefulness which means it's hard for a user to know things that they should know, like:

1. Which of their installed user scripts are update-able?
2. Which of their installed user scripts have updates available?
3. Where will they be notified of updates for there user scripts?
4. What do they need to do in order to update a user script?
5. How can they disable updates for a user script?

Hopefully it's now plain to see why a user script engine must update user scripts, and yet none that I know of do. Greasemonkey for Firefox does not. Google Chrome runs user scripts natively, but also does not update them. Those two engines are by far the most popular, but there are a few others, all of which do not update user scripts..

Well late last year I started discussing this feature with Olivier Cornu for his fork of Greasemonkey which he called Webmonkey. Months later I decided to start a Greasemonkey fork of my own, which I call Scriptish. Then, as this year went by I discovered Mozilla's plans for the new Addon manager and the stars seemed to align.

So a couple of days ago I finally got around to implementing user script updating in Scriptish, and released the feature in Scriptish 0.1b4 last night; now I'd like to discuss it a little bit for those that are interested.

User Script Updating in Scriptish

@updateURL

You may specify a URL for Scriptish to check for updates using the @updateURL metadata block key. The @updateURL must be a secure url (ie: starts with "https://"), otherwise it will be ignored.

The optional use of ".meta.js"

To save bandwidth, and improve response times, you may optionally provide a ".meta.js" version of your user script as the @updateURL, which should be the same as the user script, but only containing the user script's metadata block. If you provide a @updateURL that ends with ".meta.js", then Scriptish will check then ".meta.js" file for updates, and download an update from the same url where ".meta.js" is replaced with ".user.js".

The option to use the download URL as the update URL if no @updateURL was provided.

If you go to the options window for Scriptish you will see a preference which allows you to use a user script's download URL as the update URL if there was no @updateURL defined; this option is turned off by default.

Using ".meta.js" by default from userscripts.org

If the update URL that should be used to check for updates is a userscripts.org URL, then the ".meta.js" version of the user script will be used by default.

The GM_updatingEnabled constant

All versions of Scriptish that provide user script updating will include a GM_updatingEnabled constant in the user script sandbox, this means that if you are a user script author that has implemented a updater for your script already, then your code can check if this variable is defined and equal to 'true' before attempting to check for updates.

Conclusion

A user script engine that updates user scripts has been long desired, so I'm proud to introduce the feature for the first time in Scriptish, and I hope you give it a try!

My favorite browser extension for quite a while has been Greasemonkey (GM), I loved how simple it made customizing the web with JavaScript (JS) which allows all users to both filter out the crap that site owners try to provide us (ie: ads, share links, suggested junk) and add new useful features anywhere you that wish. Greasemonkey allowed us to customize the waves as we surfed the web, as well as making a few modifications to the board, and I loved it for that.

Some problems arose with Greasemonkey though, because it was built for Firefox (FF) 1.5, and even the latest GM version (0.8.6) claimed to support 1.5, which meant that Greasemonkey the GM maintainers did not want to introduce new features that would not be available in FF 1.5, and they did not want to take advantage a of newer version, like say FF 3.0's JavaScript Modules (JSM), which would allow GM to use much less memory and improve performance when a user is using multiple windows, and on startup because less JS would need to be loaded at startup.

The good news for GM is that with the next major release, 0.9 (which contributors including myself have been working on for quite some time now) is that the minimum version of Firefox that Greasemonkey will support will be FF 3.0, which means it can now take advantage of the benefits that FF 3.0 offers, finally. The trouble I found while trying to contribute to GM is that the maintainers don't really want to alter the code base, they're actually seem to be fine with doing the minimum necessary and bug fixing for the rest of the future, at least that is how it seemed to me after writing quite a few patches which were rejected, either outright, or by degradation (meaning I would have to basically redo everything, on crappy architecture, because they've sat on their hands for so long). Patches such as using JSM, reg exp @includes, @icon, and a few more.

So the reason that I decided to bypass Greasemonkey and start working on a fork, which I now call Scriptish, is because I was tired of beating my head against a wall, I wanted to have and use the Greasemonkey that I always wanted asap, so I'm making it now. I've always enjoyed working with others, and I hope that I can convince some GM contributors to start working on Scriptish in the future.

Scriptish

Scriptish is a fork of GM, you can think of it as a superset of Greasemonkey, it can do whatever GM does, and more. Some of it's new features are:

• @author - displayed to users in the addon manager
• @contributor - displayed to users in the addon manager
• @homepage or @homepageURL - displayed to users in the addon manager
• @icon or @iconURL - Include a icon for your user script which is displayed in the addon manager and for notifications from the script.
• @screenshot - displayed to users in the addon manager.
• @match - a include pattern introduced by Google Chrome user scripts.
• @noframes - a simple way to prevent a user script from running in iframes.
• GM_worker - use a Worker within user scripts.
• GM_notification - send a Growl style notification to the user.
• GM_setClipboard - save data to the clipboard from a user script.

Other changes include major reorganization of the internal code, using JSM, in a way that only loads code into memory that will actually be used, by loading the req'd code the first time that it is going to be used. I was also able to remove a bunch of legacy code, because Scriptish will only support Firefox 4.0 or higher for the moment.

Give it a try!

If you'd like to give Scriptish a try, then you can download Scriptish here. If you want to get involved here are some links for you:

• GitHub: http://github.com/erikvold/scriptish
• Mailing List: http://groups.google.com/group/scriptish
• Issue Tracker: http://github.com/erikvold/scriptish/issues

I hope you like it, I'll be working on it for the next few months at least, pretty hard I imagine; I'd like to make it restartless, and implement user script updates & communication asap. If you think you'd like to open it up and hack on it, then please do!!

Something that I don't think many web developers and extension developers seem to be picking up on, but yet some are, is what I'm calling webxtending, which is providing APIs that allow their users to extend their website/webapp or extension with a browser extension. To illustrate this idea take the Gmail-Greasemonkey API, this is a front-end JS API that a user script can easily access to be notified of Gmail's custom events, change state variables, and perform actions with the Gmail interface (afaik the api used to work, and some parts do not work at the moment). This was a wonderful idea because it allowed user script authors to save a lot of development time, also maintenance time, and write more cpu efficient scripts. Furthermore I imagine such a API would be extremely useful to internal development, it would at least reduce the chance of sloppiness.

Webxtending doesn't always mean providing a Javascript API though, it often simply means writing semantic code by using microformats, and structuring the markup in a logical manner, taking into account how others may want to change the UI, and making those changes as easy for them to make as possible. This means using the id attribute even when you don't need it, because others may, but it also means thinking carefully about every facet of the structure. XUL overlays used in Firefox extension development are a good example of this structural extendibility idea.

Webxtend is a gold standard quality requirement, if your website or browser extension is not webxtendable then it's not gold standard quality. =p

Every web developer knows that their site should work when the site's users disables JavaScript, but I constantly find this principal is violated when it is simple thing to obey. When web UI developers violate this principal it shows an extreme laziness and a failure to understand good practices on their part; this can greatly worsen the user experience. So, I'd like to articulate what I'm going to call The Principle of JavaScript Illumination which is an idea I haven't seen articulated yet, but that everyone knows in their gut they should do, and yet I hardly ever see this principal adhered to in practice.

Definition

The Principle of JavaScript Illumination is a simple one, if some user interface element will not work when JavaScript is disabled, then have JavaScript add the element.

Implications

If you have a user interface (UI) element that uses JavaScript, then make sure there is a default functionality that will work when JavaScript is disabled. If the UI element cannot work at all without JavaScript, then you should make JavaScript add the element, this way if JavaScript is disabled then the user will not see UI elements that will not work, causing a bad user experience.

Examples

Facebook Chat

When you log in to Facebook with JavaScript disabled, the chat widget is displayed to you on the bottom right of the screen, but it doesn't do anything, it's completely useless to you and it's just in the way, so why the heck is it displayed to the user?

Kampyle

Kampyle provides some widget code for anyone to put on their site which adds a "Give Feedback" button to the bottom right of the user's screen, which the user can click on to give feedback for the site. The trouble is, when JS is disabled, or when the user uses NoScript to block assets from the kampyle.com domain, then the button doesn't work (see ROIRevolution's site for an example of this), so why the heck is it displayed to the user?

Conclusion

Be a good web citizen, and a smart web developer by obeying The Principle of JavaScript Illumination, because it's the right thing to do and because you're users will thank you for it.

Three days ago Google announced it's release of Goo.gl a url shortener which is more reliable and trust worthy (to a user) than other services such as tinyurl.com, tr.im, bit.ly, etc.

Now I think all web publishers should maintain their own url shortener which only they can create urls for and control, for example I bought the domain evold.ca, and use the subdomain r.evold.ca as my url shortener. I primarily use this domain to shorten urls to my other domains, like erikvold.com, but I can and do occasionally use it to create short urls for domains that are not mine. As a user, when I see a blog post that I want to share, I first check if the publisher has published a short url for the page, which any smart web publisher does, but for the other web publishers (the majority atm) I have to create a short url, which I can now use Goo.gl to do.

The problem is that Goo.gl does not allow users to use it to shorten links directly. Currently, the Google URL Shortener is only officially available via the Google Toolbar and FeedBurner.

Well, I noticed that this problem was solved yesterday by a Google Chrome extension called goo.gl shortener. Amit Agarwal drew my attention to this extension in a blog post he wrote yesterday, where he pointed out the important javascript parts needed to create goo.gl short urls. So I took this information and opened Goo.gl up with a userscript, a ubiquity command, and a jetpack to help everyone create short urls with Goo.gl, check them out!

This is just a last moment idea inspired by the movie Starship Troopers which flashed in to my mind a couple of days ago as I was thinking about Jetpacks for the Jetpack for Learning Design Challenge. It is primarily a Microformat/Link Type proposal for rel-info with some ideas and prototypes demonstrating how it could be used.

Abstract

When you are reading something on the web there are usually pages which exist elsewhere on the web that would provide background information, and further reading if you desired to dig deeper into the subject(s) you are reading about. Sometimes some of those pages are linked to from the article you are on, but often the link wouldn't make sense in the context of the content, and using a link tag isn't very useful to a user, so the link is not made.

I propose a rel-info link type, even if just as a Microformat, for 'a' and 'link' tags to provide a link to context-sensitive information.

With rel-info a user can read more about the Movie that was discussed at Netflix or IMDB easily for example, because the publisher (or a script the user subscribes to, more on this later) provided a rel-info link which the user can easily find and follow with a Jetpack, Firefox extension, or some other browser extension.

Proposal

When rel-info links are provided on a page browser extensions can easily extract them from the page, which can lead to a large number of use cases, of which I am sure I have only just scratched the surface. There is another side to this coin however which is that there are a large number of ways that rel-info links might be added to a page.

Let's explore the latter case, first the person who published the page could add rel-info links, but then browser extensions could add rel-info links, they could also search for and remove rel-info links. A user could subscribe to a person's or institution's suggestion feed or script which adds and/or removes rel-info links to pages, along with using a AI based browser extensions to add rel-info links.

When the rel-info links are going to be consumed there are some other interesting possibilities, for example a browser extension could filter the links by a HTML 5 'data-topic' attribute by keeping a list of topics that the user dislikes or likes, the domain could also be used for filtering. A browser extension could allow the user to mark pages as read so that they are removed from pages in the future as another example.

Prototypes

To test this link type out with a Jetpack I first had to add it to some pages, so I decided to write a couple of UserScripts to do this demonstrating how they can be dynamically added to pages by anyone even users themselves. The first userscript was to add the rel-info link type to IMDB links, and another to add the rel-info link type to Wikipedia links.

If you install the above UserScripts then you should find rel="info" or rel="... info" on your IMDB and Wikipedia links. Once you have done that you can check out and install the "Would You Like To Know More?" Jetpack. This is a slidebar Jetpack, and when you open this slidebar the focused tab is then scanned for rel-info links, if any are found then they are displayed in a list for you to choose from, if you click one of the provided links a new tab will be opened for the new page.

These UserScripts and the Jetpack take advantage of HTML 5 'data-' attributes, by adding a 'data-source' attribute to the rel-info links added on the userscript side, which the jetpack was written to check for and display if found. This is an example of how HTML 5 'data-' attributes can be used with the rel-info link type which I propose to create more interesting results.

This userscript removes all CSS that is only for media="print", and makes the media="..screen.." into media="...screen..., print" so that what you see on the screen is what you will get for your print out of the page.

The Unpleasantry:

Currently if you print a webpage (or go to print preview) you may notice that most sites do not look the same as they do on the screen when you try to print one of their pages. This is because the page has CSS specifically designated for media="screen" which is different than the CSS they use for media="print".

The Alleviation:

Once you install the "Remove Print CSS (WYSIWYG)" UserScript there will be a Greasemonkey menu command that you can use called 'Remove Print CSS' which removes the media="print" CSS and makes the media="...screen..." CSS media="...screen..., print" CSS, which means that the same CSS used for your screen will be used when you try to print a page.

[More]

Librivox is an amazing website that I have been watching for a number of years now, and it helped me out enormously in those awful required Art classes I took while at UBC. Now the site is far more interesting to me as I have some time to read what I wish, and because I find listening to audiobooks, and switching to reading every now and then to be the most efficient way for me to digest a non-technical book.

Librivox is basically just a repository of free audiobooks that were made for free by volunteer netizens like you and I. All you need is a computer with some recording software which is ubiquitous at this point, in fact the iPhone Voice Memo app (which is also available for the iPod Touch) is a great way to do this from the comfort of your favorite chair and couch.

Remember not to be an dick! OK please.