Rebranding the Firefox Installer

Updated files for Firefox 2.0.0.9 are available here.

One of the other extensions I've written is the Rebrand extension. This extension allows you to rebrand Firefox to whatever you want just by installing an extension. A question I often get asked by people that use this extension is whether or not it is possible to rebrand the installer. This post will provide instructions on how to rebrand the Firefox 2 installer. In particular, we are going to create a new customized setup.exe that can be used with the instructions in this post. Basically you unpack the installer and simply replace setup.exe with the new one we will create.

The installer for Firefox 2 is based on the Nullsoft Scriptable Install System so first we need to install NSIS.

To actually customize the installer, we need the original files that were used to create the installer. I have packaged the files from a non branded Firefox 2.0.0.5 for you. That means the files show "Bon Echo" instead of "Firefox" and the images are just a globe (no Firefox). You can download them here. After you download the package, unzip it into a directory and we're ready to go.

Here are the files we'll need to change.

  • license.rtf - This is the license agreement that must be agreed to by the user during the install. You'll need to replace it with your own RTF file containing a license. If you do not want or need the user to agree to a license agreement, you can comment out the line:

    !insertmacro MUI_PAGE_LICENSE license.rtf

    in installer.nsi.
  • branding.nsi - This file contains most of the text changes you'll make, including name of your browser and your company.
  • wizHeader.bmp - This image is at the top of right of every page in the installer.
  • wizWatermark.bmp - This image is on the first page of the installer.
  • defines.nsi - This file contains some version specific strings, so it will need to be changed as you move to different versions of the Firefox source code. It will also need to be changed if you change the name of the executable.
  • version.nsh - Unfortunately the installer folks didn't do a good job of keeping branding strings just in branding.nsi, so there are a few miscellaneous things you might want to change here.

Now that we've customized the files, it's time to build the installer. To do this, we'll use one of the tools that came with NSIS, makensis.exe.

makensis installer.nsi

If we did things correctly, the result of this command should be a new setup.exe that contains all of our customizations. You can test this immediately by just running setup.exe and seeing if it contains your customizations.

There's not a quick and easy way to integrate this setup.exe into the Firefox packaging, so for now my recommendation is to unpack a Firefox 2 installer using 7-Zip and simply replace setup.exe with the new one you just created. Once I get the information on manually repackaging Firefox, I'll post it.

Note that this is a new process I've just put together, so please let me know if I've missed anything or if you have problems.

Firefox Enterprise Working Group Update

Fixed Eastern time - sorry about that.

I wanted to give an update on where we are with the Enterprise Working Group. We're planning our first call for Wednesday, July 25 at 10:00am Pacific, 1:00pm Eastern, 17:00 UTC. Here's the meeting details:

  • 650-903-0800 or 650-215-1282 x91 Conf# 280 (US/INTL)
  • 1-800-707-2533 (pin 369) Conf# 280 (US)

Please don't feel like you need to be involved in an "enterprise" in order to participate. We're expecting folks involved in enterprises, education institutions, and more.

Each of the calls will be organized around a central theme, with the primary goal being to simply communicate information and document that information, in the hopes that people inside and outside the group can learn from our experiences. For the first call, the theme is going to be "Experience" and I'm hoping to get people to talk about what their experiences have been so far, not just with deploying Firefox but with communication around Firefox within their organization, including convincing people that it's important. The theme of the next call (in approximately two weeks) is going to be "Wishlist" and we'll talk about what people see missing from Firefox for enterprise deployment. If you definitely want to speak about your experience on the call, you can email me in advance at ewg@kaply.com with your name and a summary and I'll make sure you can share your experience. That will help things move along on the calll

Our plan on the calls is to allow for completely anonymous participation with regards to the company/institution for which you work. We understand that there is the potential for sensitive information to be shared, so no one is required to share their affiliation on the phone call or in any documents produced by the Firefox Enterprise Working Group unless they choose to do so. We will probably come up with some generic way to categorize companies like based on employee count or something like that, primarily so that companies with similar deployment situations can work together.

The wiki is going to be hosted at http://wiki.mozilla.org/Enterprise. We'll also be starting a blog specific to the group.

We look forward to your participation!

Incidentally, we already have someone that will participate in the Firefox Enterprise Working Group that is blogging. Check it out here.

Writing User Scripts for Operator

I think the APIs in Operator 0.8b have settled down enough that I can start to document how to write user scripts. Note these user scripts are for Operator, NOT for Firefox 3. How things will work in Firefox 3 hasn't been decided yet. And I am working very hard to make this the final API for Operator 1.0.

What are Operator User Scripts?

Operator user scripts are user added pieces of JavaScript that can enable additional functionality within Operator like new actions for microformats and RDF, as well as adding new microformats. Examples can be found on the Operator User Scripts page. User scripts are added to Operator by opening Options and selecting the User Scripts tab. You can then select a user script that has been saved to your local hard drive. People have asked why I don't allow user scripts to be installed directly from the web similar to Greasemonkey scripts. There are two reasons. First, the code to do that detection is licensed under GPL, so I can't just take it and put it in Operator. Second, Operator user scripts operate with the same security privileges as an extension so they can pretty much do anything they want. That's not something you want to install in a drive by situation.

Writing a User Scripts

I'm going to have separate pages for the user script documentation, rather than using posts. The first one is here - Creating a Microformat Action User Script (Basic). As always, I appreciate feedback, especially from folks that have already written actions. And speaking of actions, we have some new ones to add to the list:

Enjoy!

Operator 0.8b is Available

I have made a beta of Operator 0.8 available. Continued thanks to Elias Torres for the RDFa support.

Operator 0.8b adds a much requested feature - an operator icon on the location bar. It's not perfect yet, but it is there. Also, I updated the action API a little bit to allow for the naming of actions as well as having actions act on multiple properties in a microformat. For instance, in the past, the "Goto web page" action only worked for the first URL in an hCard. Now it will work for all the URLs.

The other big fix in this release was that there were cases where sorting/removing duplicates didn't work correctly. For action developers, I added the ability to have multiple translations of an action in one action. I'll document that soon.

All the caveats from Operator 0.8a apply, so please read them.

Please report bugs here.

Have fun.

New Actions for Operator 0.8

I know I've been slacking on posting information on how to create actions for Operator 0.8. I've been tweaking the API a little bit, so that's why I've been hesitant. Operator 0.8 beta will be very soon, and then I'll post a tutorial on creating actions.

In the mean time, I have been working with a few folks to get their actions working on Operator 0.8.

  • The Minimap Addon gives you a suite of built-in maps and mapping tools for your web browser. And it also supports integration with Operator.
  • Egon Willighagen is using RDFa combined with an Operator action to allow for searching PubChem from the Chemical Blogspace. More information is available in his post.
  • Søren Johannessen has updated his actions for the Danish Blogosphere for Operator 0.8. You can read about them and download them at microformats.dk.
  • Pelle Wessman has updated his actions for the Swedish Blogosphere for Operator 0.8. You can read about them and download them at http://pelle.vox.nu/.
  • Charl van Niekerk has created actions for the African Blogosphere for Operator 0.8. You can read about them and download them at http://blog.charlvn.za.net/.

And I've been adding/updating some of my user scripts. These include support for the license microformat, as well as some improvements to species.

Incidentally, the improvements to the action API will NOT break actions already written for Operator 0.8. The improvements include the ability to translate your actions into other languages, the ability to customize the name that appears for your action in the Operator dropdowns and the ability to have multiple items in the action menu for something that appears multiple times in a microformat. For instance, in the past, even if an hCard had multiple web pages, there was only one action that opened the first web page. Now an action can detect the multiple web pages and display unique action names for each of them.

Stay tuned!

Floods in Central Texas

I don't tend to post personal stuff on my blog (yet), but I couldn't resist this one. Around SXSW I posted some pictures from the back of my house showing the river when it was low:

and swelled from the rain (which it looks like most of the time now since we've had good rains here lately):

Here's what it looks like today:

You can check at the video at KVUE here and here.

They did their flood updates from my back patio.

Firefox in the Enterprise: Part 2 - Benefits

Before I get started with this post, I wanted to let people know that I am working with representatives of other companies to form an Enterprise Working Group for Firefox. The goal of this group will be to work together to document enterprise requirements and either create extensions or submit patches to Firefox to meet these requirements. We hope that anyone interested in Firefox in the enterprise will join us. We'll be having our first meeting in the next few weeks.

In my previous post I talked about obstacles to the enterprise adoption of Firefox, but it wouldn't be fair to talk about obstacles without talking about the benefits. We all know the benefits to Firefox users, like tabbed browsing and pop up blocking, so this post is going to focus on enterprise specific benefits. Obviously there are many more benefits beyond what I'm covering here. I'd love to hear your opinion in the comments on this post.

Extensions

Extensions are a great way to add genuine business value to Firefox. Within IBM, for example, we have extensions like Koala that can be used to automate business processes, or extensions like Tommy! which take our corporate directory to the next level by integrating other services like blogs. We have an extension available that uses the Firefox password manger to enable single sign on to IBM domains. And of course we have the CCK to produce IBM customized versions of Firefox. We have also seen Greasemonkey used to add business value. For instance, one of our support teams uses a Greasemonkey script to prefill fields in a web application that would normally have to be done with every problem report. The result can be seen in real time savings for support calls.

And these are just few. I haven't even mentioned some of the other extensions that add IBM specific toolbars or enhance our ability to search our corporate directory. So what does this mean for your business? There are probably areas where a simple Firefox extension or Greasemonkey script could greatly enhance the experience of your employees. It's definitely something to keep in mind.

Customization

I really can't say enough about the customizablity of Firefox. Because most of the user interface code is written in JavaScript and can be modified via extensions, I have been able to do some extensive customization. I've had schools approach me about things ranging from removing history or bookmarks to disabling access to preferences. I have been able to accomplish all of this through the use of extensions. If you have specific needs around browser customization, whether it be locking down the browser, or perhaps a kiosk, Firefox can be customized to meet that need.

Web Development

My experience has shown that Firefox has become the web development platform, even for organizations that use Internet Explorer internally. The extensions available for Firefox, like the Venkman JavaScript Debugger, the DOM Inspector, Firebug, and the Web Developer extension make web development much easier on Firefox. And there are even more extensions to benefit the web developer.

Open Source

There are some Firefox benefits specifically because it is open source. You can replace the existing update infrastructure with your own so updates are served from your servers. If you have questions, you can access developers directly. When you open a bug, you can keep up with the status and even choose to fix it yourself. You have access to the source code for debugging problems. You can build your own browser with patches that you want if it comes to that.

Open Standards

By using Firefox, you are encouraging the use of open standards and protocols, and helping to keep the web open.

Summary

That's all I have for now. I know I've only scratched the surface here. Please comment as to additional enterprise benefits. And stay tuned for more info on the Enterprise Working Group.

Firefox in the Enterprise: Part 1 - Obstacles

I've been thinking a lot about Firefox in the enterprise and I wanted to capture some of my thoughts. This two part article will first cover obstacles to enterprise adoption of Firefox (with some possible solutions) and then cover specific benefits to Firefox in the enterprise.

Before I get any complaints, I am aware that there are large enterprises that are already using Firefox (including IBM). I believe that most of these are supporting Firefox as a secondary browser as opposed to switching to Firefox as the primary browser. Also, I'd love to open up more discussion on this subject, so please comment and correct me if I'm wrong.

Introduction

As Firefox gains marketshare, there comes a point where increasing that marketshare depends on the adoption of Firefox in large enterprises. This article investigates what type of issues arise when supporting Firefox in a large enterprise, and what can be done to solve those issues.

The primary areas I will address are:

  • Release Lifecycle
  • Service and Support
  • Business Value
  • Third Party Applications
  • Intranet Applications
  • Deployment issues

Release Lifecycle

Simply put, the current Firefox policy of supporting prior versions of Firefox for six months after the next release is just too short, especially considering the time of year when new versions of Firefox are typically released. Many companies only deploy new software once or twice a year, and the process to get that software deployed takes many months.

I know of a company that deploys software once a year, in September. In order to be a part of that deployment, you have to start piloting your application in June. If this company wanted to move from Firefox 1.5 to Firefox 2, they would have had to pilot it in June, for deployment in September. This means that they would have had an unsupported browser for over five months.

In addition, Firefox so far has been released in the fourth quarter (Firefox 1 was release in November, Firefox 2 was released in October). If you work in IT, you know that new software does not get deployed in November, December, or even January. So three months of the six month Firefox support cycle was simply a wash.

Either Mozilla Corporation needs to step up and extend the lifecycle of Firefox to one year, or some enterprising company should take this opportunity to provide better release lifecycle for Firefox.

Service and Support

When a piece of software is an integral part of a company's business, it is imperative that they have someone to call when they have problems. "Open a bug in bugzilla" or "we accept patches" are simply not good answers when companies are experiencing problems. Certainly companies can staff developers that can build and deploy custom versions of Firefox, but this is the exception, not the rule. In addition, companies that have their own internal help desk need training on how to support Firefox.

This problem is more difficult to solve. Mozilla's role is not to provide one on one support for customers. This is, however, an excellent opportunity for someone to step in and provide enterprise level phone support for Firefox, as well as to create education modules to train internal help desks.

Business Value

Every organization is in business to provide value to their customers. For a publicly traded company, it's about shareholder value. For a nonprofit, it might be about reducing overhead so that more donations can go to their primary cause. Unfortunately, it is difficult to show that supporting two browsers or switching to a completely different browser adds business value.

While I don't have a good solution to this problem, it is worth noting that, for many companies, the move to support Internet Explorer 7 will be just as much work as supporting Firefox. From that perspective, the best way to increase business value
would be to move towards an internal infrastructure that uses open standards so that dependencies on particular platforms are diminished. In addition, if a company ever wanted to move to a platform where Internet Explorer was not available, using open standards would make it easer to move.

Third Party Applications

When most of us surf the web, we don't tend to find a lot of web pages that simply don't work in Firefox. This problem has mostly been solved. Companies, however, use third party applications that may or may not work in Firefox. While the current version of a lot of these applications may work with Firefox, older versions of these applications are deployed in many companies with no plans to upgrade in the foreseeable future due to cost (see Business Value above).

There are a few ways to solve this problem. First off, third party application providers should provide free or low cost upgrades to companies that have software that doesn't work with Firefox. Secondly, when purchasing third party applications, companies should ensure that the software they are purchasing uses open standards. Finally, application vendors should ensure they are using open standards to create their applications so they don't lock their customers into a particular browser vendor.

Intranet Applications

Third party applications aren't the only place where support for Firefox can be a problem. What tends to happen in companies is that internal applications get written, deployed, and then forgotten about. In addition, because it might take years to write an internal application, by the time it is deployed, it might be designed for an older browser. Fixing these applications can be some of the most difficult problems to solve, due to lack of funding and even lack of interest by the developers.

Your company should have policies in place to ensure that internal applications are written using open standards so that they don't depend on a particular browser. In addition, when applications are created, it is imperative that funding be set aside so that if problems are encountered with a particular application in the future, that there is a way to get the problem fixed.

Deployment issues

One of the main things I've tried to do in my job is help with deployment issues. In addition to working on the CCK, I've worked with some smaller entities to deploy Firefox using things like the Firefox Release Repackager. But these things simply aren't enough. Companies already have existing deployment infrastructures using Tivoli or Microsoft Active Directory. In addition, the types of customizations that a lot of entities want to do are outside the scope of the CCK.

While there are third party solutions that provide a customized Firefox to use Active Directory and Microsoft installers, there needs to be more work in the community to make Active Directory support and Microsoft installers an integral part of Firefox. While Firefox developers do not want to make MSI the primary ship vehicle for Firefox, work could be done to make the MSI installer on par with the Nullsoft Installer. In addition, there needs to be more of an ecosystem around customizing Firefox for certain types of deployment.

Closing Comments

So there you have it. Some quick thoughts on enterprise deployment. In the next installment, I'll talk about the benefits of Firefox in the enterprise, and in particular some things we've found out inside IBM. As always, I'd love to here your thoughts, and if I've missed anything.

Operator 0.8a is Available

I have made an alpha of Operator 0.8 available. Special thanks to Elias Torres for the RDFa support.

My primary goal with Operator 0.8a was to attempt to finalize APIs for both Operator and Firefox 3. What I actually ended up with is very similar to the APIs I created with the very first version of Operator. You can see the microformats API for Firefox 3 here (looking for feedback). I'll be documenting the action and microformats API more completely in the next few days.

New features in this release include:

  • RDFa support (view only - there are no actions yet)
  • Unified actions architecture - actions are no longer specific to a microformat
  • Support for Address microformat to allow some actions (like map lookups) to be more granular.
  • Better support for iframes/frames/nested documents
  • Debug mode uses X2V for hCards and hCalendars
  • Support for non HTML documents
  • Bug fixes galore.

One feature I removed that I know people will complain about is the ability to have custom names for the actions. If I get enough complaints, I'll put this back.

IMPORTANT NOTE: This release uses new preferences so it will wipe out your old prefs. This should be the last time that happens. I also changed the location of user scripts so it won't pick up your old ones (they won't work anyway).

If you want new user scripts, check out: http://www.kaply.com/weblog/operator-user-scripts/

If you have user scripts you want to quickly port to Operator 0.8, please send them to me and I'll help.

Please report bugs here.

Have fun.

Where is the next version of Operator?

You might have heard from Elias Torres that we have RDFa working in Operator. You might also be wondering where that version is.

Basically I've been working very hard to finalize the APIs so that I can get things ready for Firefox 3. You can take a look at them here. The ironic part is that I've actually gone back to the way I wrote Operator the first time in terms of how microformats and actions are added to Operator. I'll be documenting this soon. And if you wrote to any of my other APIs, I'll work with you to move things to the new model.

So what do you have to look forward to in Operator 0.8a?

  • RDFa support
  • Unified action architecture (actions on the toolbar aren't specific to microformats)
  • Support for non HTML documents
  • A final architecture for actions and microformats so people can start coding to it
  • Debug mode displays X2V output
  • Export All available in "Microformats mode"
  • Lots of bug fixes

Stay tuned. Just some fine tuning and we're good to go.