On Personas and themes
Update #3
The AMO team has posted a much better clarification of where we are now.
Update #2
It’s fairly clear that I have used some language that caused some people to assume this to be a final and official decision, which it is not. We have not committed to any final resolution for anything in this space. We have made a decision to explore this direction for the future, but to declare anything final or official is extremely premature from anyone at this time. Further, to take anything I write on this blog as an official statement, and not an expression of my personal opinions and intent, is generally going to be wrong.
—————-
Theming is hard. I’ve spent a huge number of hours tweaking and polishing the default themes across platforms, for six years or so. It’s not a great system, and is really daunting to many people. It’s also fragile, as every time we add a new button, or relocate it (i.e. the Go button), all themes must be updated to continue to work. Extensions are worse, in many cases, given API compatibility issues on top of the ability for UI changes to break overlay points (given that I work primarily on Weave these days, this part hits very close to home). We have a lot of great extensions and themes, but developing these requires a lot of ramp-up time and technical ability, and ongoing commitment to maintaining these across versions. We already know from our users that incompatible add-ons are a significant factor in opting out of updates. Effectively, this means ongoing creativity in the add-ons space is constrained to those with the time and inclination to learn a complex system and the desire and commitment to actively maintain the projects for years.
The Personas and Jetpack projects were experiments designed to make extending the platform easier, and dramatically reduce the overhead involved in version updates/UI changes. We knew from the beginning that we would have to trade off truly limitless customizations to produce a more stable API/pseudo-API, but we felt that was worth it to achieve our long-term goals for the project. To compete and lead in the browser market now, we want and need to be able to move faster, and not have our hands as severely tied by add-on compatibility. We also want it to be safer to run with addons, and less disruptive to increasingly longer-lived and more complex browsing sessions. All of these requirements meant major technology changes, and some sacrifices.
This is a strategic product decision, intended to grow our developer ecosystem and broaden the scope of potential developers as much as possible, and deliver a much better user experience with customizations across core application updates. Deprecating the old systems in favour of the new systems is a required part of the strategic plan, because it is not enough to simply build a better system, we must migrate our users and our developer ecosystem to that system to reap the benefits. That does mean, in effect, that we are discriminating against the old systems, and I am personally at peace with that.
We do understand that not everyone invested in the current technology stack will be happy with the change in focus, for a variety of entirely logical reasons. However, there is consensus among those guiding the product that this is the direction we need to take to remain competitive and flexible in the long term. It isn’t an easy decision, but we firmly believe it is the right one, and we will continue to work towards improving the capabilities of Personas and Jetpacks until they are powerful enough to provide the user experiences we need them to provide.
Update, since it seems clear people aren’t reading the comments:
A few generic comments:
Limited is relative to “you can literally do anything.” Jetpack is aiming for a really broad capability set, so that the vast majority of extensions can be reimplemented using that API, with all of the wins that entails. I personally don’t think we’re anywhere near the point where we can look at the old-style extension model and claim it’s not needed anymore. But the goal is to drive everything that can be moved to Jetpacks to that model, because it’s a better model for users and developers. That does mean a lot of APIs need to be implemented still, and we’re working on that. Whether in a couple of years we are willing to say that the old model is well and truly unnecessary is crystal ball gazing at best.
Other apps will need to figure out what they want to do. One of the original design goals for Jetpack’s API was something that other apps can implement and extend. Very little of the UI APIs are app-specific, so integrating Jetpack into SeaMonkey or Flock or anything should not be especially terrible. If it is, we’ve done something wrong, and bugs should be filed against the API design.
As for the “copying Chrome again” comments, we’ve been talking about a Jetpack-like model long before anyone knew what they would do. There’s certainly a lot of overlap, but it makes very little sense to not design a stable and secure add-on API model for add-ons. Anyone aware of the significant pains involved in getting users to upgrade (as many of the core Chrome people will be, given their history with Firefox) would want to build a model along these lines.
Much of this is a direction, and we’re not going to get there all at once. We want more add-ons, and users, using a stable API, so that we can upgrade users faster and with less pain for everyone. How we get there, and how we handle the edge cases, is not set in stone, by any means, only the direction and the need to move in that direction are concrete. If Jetpack isn’t capable enough, file bugs and request functionality. Or even better, write a JEP and an implementation. If there’s a sane way to do lightweight icon sets with Personas, file bugs, make suggestions, or even write patches. These things are all possible, all in scope for how we do things. There’s no free lunch, but we’ll try to help where we can.
As much as I’m excited in hearing the focus is moving to the newer, easier, lighter-weight JetPack and Personas, I’m equally interested in the transition plan and what things look like in a year for all three/four customization approaches/platforms.
January 9th, 2010 at 6:13 pmI have been following the Personas part of this question for a good deal of time. One thing I have noticed– I have yet to read anything that would suggest that Mozilla has done any customer research to see if the customer base really has a desire for Personas.
That said it is a fine extension that has it’s uses.
January 9th, 2010 at 6:19 pmWhat about the ‘light-weight’ theme approach covered by ShareBird (lighter than traditional themes, but heavier than personas)? I just converted all 11 of my themes over to this methodology as it allows me to just edit/modify the portions of the default theme that I wish, instead of repeating and duplicating every element of the default theme. With one jar file (containing only 11 css files and my images) I can cover Firefox, Thunderbird, and SeaMonkey. Also, in the future if something gets changed in the theme API, or I failed to theme a button/control/etc then instead of the theme breaking, it just displays that element from the default theme.
I feel this is a much better approach to theming, rather than Personas (which as far as I can tell, only provides background images on the toolbars).
Find out more information at the following location:
January 9th, 2010 at 6:35 pmhttp://forums.mozillazine.org/viewtopic.php?f=18&t=1472225
We’re definitely interested in expanding the capabilities of Personas, though the how is to be determined. Personas right now can control background images, font colors, accent colors, and titlebar color (on Mac), the logical next step is specifying toolbar images somehow.
January 9th, 2010 at 9:45 pmI think before ‘traditional’ themes are ditched in favor of Personas, there definitely need to be ways to modify toolbar images and tabs and whatever else. If it can only do background images, font colors, accent colors, and titlebar color (on Mac) — then Personas either seem to still be alpha/beta quality or they are a step backward from ‘traditional’ themes.
Please take a moment to examine how I did the ‘light-weight’ version of my Nemesis theme. The one file works on Firefox, Thunderbird, and SeaMonkey. And I’m only overriding things from the default theme, nothing more. Anything not explicitly specified by me is inherited from the default theme. You could go so far to think of this ‘light-weight’ theme as nothing more than a bunch of userchrome.css rules and some images that modifies the default theme.
http://www.spuler.us/temp/nemesis.jar
January 9th, 2010 at 10:25 pmNotice that when I’ve proposed the “light-weight” approach for themes I was not meaning them as substitute for “heavy-weight” themes:
http://www.tudobom.de/articles/yatt/
Actually we have two ways to skin the application, the substitution method from existing skin packages (the “heavy-weight” approach ) and the override method from existing skin packages (the “light-weight” approach I’ve proposed, the same principle from userChrome.css customization with the enormous advantage we have, being able to “switch” themes).
So, a theme author can opt for one or other method:
“heavy-weight” – If a developer needs more power, more possibilities, if the UI proposals go deeper in the application’s appearance. Of course knowing that this method means more work, high risk to get “broken”, etc… There are many developers who use to track changes on Firefox (and Thunderbird as well) and are able to fix their themes in a matter of hours: http://forums.mozillazine.org/viewtopic.php?f=18&t=1418995 and http://forums.mozillazine.org/viewtopic.php?f=18&t=975065
I, e.g., use to work in a daily basis on my themes.
“light-weight” – This approach has not the same possibilities like the other, but is capable to build very good themes, a bit easier to write and with very small files. It has less risk to get broken. Aaron has done an excellent job migrating all his themes to this approach.
I guess these approaches are only possible for XUL based interfaces, because of the big advantages from a system according to the OOP concept of separation between content and appearance.
This is indeed a very powerful system that makes the difference comparing to other browsers.
So, both approaches can live very well together with Personas, providing a powerful high level of customization. Themes and Personas together give our users the capabilities to customize the full appearance of the browser.
Give the power of customization to our users.
January 9th, 2010 at 11:51 pmAccording to Metrics blog, 67% of Firefox users do not have any add-on. Why Mozilla does not update them automatically (like minor releases)?
January 10th, 2010 at 12:23 amI find the extensions aspect much more interesting than the themes one. As with themes, it’s not clear to me that a limited API can be as abstract as needed but powerful enough to be and stay significantly ahead of competitors. Contrary to themes, that’s a huge risk, not only idealistically (empowering users…), but strategically, because extensions are the main reason why advanced users say they stick with Firefox. I can’t remember having heard any other reason. And unless I’m missing something, advanced users are still the most important distribution channel for Firefox.
I’m afraid this could lose Mozilla more than users opting out of major updates. Making sure most extensions are ready when we release a major update is a constant struggle, but it may well be worth it.
January 10th, 2010 at 3:37 amWhat are you thinking!????? Kill Firefox’ powerful customization capabilities and I shall find another browser. The infinite customization is one of my primary reasons for using Firefox (the other being the bookmark system Places). If you kill this, I have no little reason for staying with Firefox.
January 10th, 2010 at 7:57 amI fully support Personas and Jetpack as *alternatives* for the traditional system, but I never imagined that they would replace it. In my opinion, this is a serious error of judgment and will cost Mozilla dearly if implemented.
For example, my Firefox is currently running with Aero Glass, tabs on top and a Firefox 4.0 inspired theme. This is only possible because Firefox is so customizable. Not having the ability to have Aero Glass would cause me to abandon Firefox immediately, as the default theme is so ugly on Windows 7/Vista – and Mozilla doesn’t seem to be able to implement Aero Glass properly (even though numerous extensions do so already). But thanks to the powerful extensions system, that isn’t an issue.
Personally, I don’t really see the problem. There are plenty of addons and themes available, and this misguided attempt to create more will cause some of the very useful addons currently available to be impossible to implement.
Please, please, don’t kill Firefox’ customization capabilities. It is what makes Firefox so special.
I love the focus on extending the platform with lighter interfaces that are less painful for updates and easier to to customizations with. I have three problem with the current things though:
January 10th, 2010 at 8:45 am1) Both personas / “light-weight themes” and Jetpack are completely Firefox-centric in UI and implementation, those developing them seem to not regard that we have a platform for more applications than Firefox alone. There should be clear ways/plans on how to make other Mozilla-based applications work with them.
2) The syntax of Jetpack still seems too complicated for the casual customizer who doesn’t have intimate knowledge of the Mozilla platform (why need XPCOM syntax?), from what I read (haven’t used it, I’m not into add-on development myself, only into project management).
3) I think we should not deprecate the full, more powerful mechanisms, but implement both lightweight and full mechanisms on the same level, bot in the core platform. If the lightweight mechanisms are so much better (i.e.e implemented right), they will get a tremedous storm of adoption, and updates will be less painful as the percentage of full themes/extesnsions will be lower, but we also would not doom full-blown extensions and themes, some of which are quite successful. We should care not to dumb down or platform, but to extend it – if the new mechanisms are that good, they will get broad adoption by being supported as equals.
You can do pretty cool lightweight theming without touching actual theme code.
I’ll point to all the themes we’ve done with Brand Thunder (http://brandthunder.com/gallery)
Brand Thunder stuff changes background images, toolbar buttons, tab images, etc., all without installing a theme and with dynamic switching once the extension is installed.
January 10th, 2010 at 10:21 amSounds like copying Chrome again …
Much of what keeps Firefox invaluable for me are complex extensions like Adblock Plus, Zotero, ScrapBook, FoxyProxy, etc. All 4 are invaluable for me, Zotero and FoxyProxy more so than the other two. Are such extensions at all possible with Jetpack?
January 10th, 2010 at 10:45 amCould you write a more concrete statement please? “Deprecating the old systems” and “change in focus” are fairly unspecific. What exactly are you going to be doing and when?
January 10th, 2010 at 10:53 amIf Mozilla just tries copying Chrome (look at the Fx4 theme mockups, which are about functionality, and not just looks; and now this), they’ll end up doing it worse than Google does. Why don’t they focus on the stuff that Firefox can do better than Chrome?
January 10th, 2010 at 10:54 amI agree that personas and themes should be the least of our worries. I would rather investigate whether or not the extension system, including the installation and update framework, can be imagined preserved on the XULRunner core while disabled in the Firefox product. If not, this development will certainly nail the coffin of “Mozilla the platform” permanently shut. As far as I can tell, Personas and Jetpacks do not demand author knowledge about traditional development disciplines such as XUL, XBL and CSS. Since the planned changes will essentially convert Firefox into a marginally slower version of Google Chrome, I can easily imagine these technologies to be phased out over time. Especially when the alternative is to migrate towards XBL2, which I was personally rooting for.
To me, the Firefox shell embodies a core of Raistlin-like powers. That’s why I use it on a daily basis. If I want to play with toys, I shall choose a shiny new one, so I cannot help but to view this development as an error in judgement of catalysmic proportions. Or an elaborate practical joke, I am still not sure.
January 10th, 2010 at 11:38 amA few generic comments:
Limited is relative to “you can literally do anything.” Jetpack is aiming for a really broad capability set, so that the vast majority of extensions can be reimplemented using that API, with all of the wins that entails. I personally don’t think we’re anywhere near the point where we can look at the old-style extension model and claim it’s not needed anymore. But the goal is to drive everything that can be moved to Jetpacks to that model, because it’s a better model for users and developers. That does mean a lot of APIs need to be implemented still, and we’re working on that. Whether in a couple of years we are willing to say that the old model is well and truly unnecessary is crystal ball gazing at best.
Other apps will need to figure out what they want to do. One of the original design goals for Jetpack’s API was something that other apps can implement and extend. Very little of the UI APIs are app-specific, so integrating Jetpack into SeaMonkey or Flock or anything should not be especially terrible. If it is, we’ve done something wrong, and bugs should be filed against the API design.
As for the “copying Chrome again” comments, we’ve been talking about a Jetpack-like model long before anyone knew what they would do. There’s certainly a lot of overlap, but it makes very little sense to not design a stable and secure add-on API model for add-ons. Anyone aware of the significant pains involved in getting users to upgrade (as many of the core Chrome people will be, given their history with Firefox) would want to build a model along these lines.
Much of this is a direction, and we’re not going to get there all at once. We want more add-ons, and users, using a stable API, so that we can upgrade users faster and with less pain for everyone. How we get there, and how we handle the edge cases, is not set in stone, by any means, only the direction and the need to move in that direction are concrete. If Jetpack isn’t capable enough, file bugs and request functionality. Or even better, write a JEP and an implementation. If there’s a sane way to do lightweight icon sets with Personas, file bugs, make suggestions, or even write patches. These things are all possible, all in scope for how we do things. There’s no free lunch, but we’ll try to help where we can.
January 10th, 2010 at 11:50 amBut the thing is with Jetpack, there will be APIs for everything *you Mozilla people can think of*, whereas with the current extension model, you can do almost *anything*. The great power of extensions comes from the fact that the best extensions are those that implement things *no one was thinking of*. What I mean is if you push people into Jetpacks, they will be fundamentally locked into the set of APIs you provide, thus limiting the creativity and the possibilities. The truly wonderful extensions are those that do things you wouldn’t think of, and those extension can’t be Jetpacks.
January 10th, 2010 at 12:12 pmThe reason I’m not interested in personas right now is that they don’t let change the toolbar buttons and tab icons. The defaults on Linux look extremely ugly. Customizing the background of the UI is not as important.
The reason I keep using Firefox instead of moving on to faster browsers is that they don’t have Firebug, Ablock , NoScript and even Stylish, Web Developer Toolbar and Live HTTP Headers. If those extensions can be ported to Jetpack, good. If they won’t, well, they’ll be ported to some other browser (Chrome is working on extensions) and I’ll move with them.
From the comments I read it seems that I’m not alone thinking along those lines. I hope that the Mozilla team will take their users’ requirements into account. Personas and Jetpack look good, but don’t remove Themes until we can do icons in personas and don’t remove extensions unless they can be ported to Jetpack.
January 10th, 2010 at 1:02 pmIf your changes force me to look at ads Firefox gets uninstalled.
It is as simple as that!
January 10th, 2010 at 1:27 pmIf I lose the ability to run AdBlock and NoScript then I have no reason to use Firefox and shall cease to do so.
January 10th, 2010 at 1:30 pmI know this can be annoying, but I have to agree:
I use Vimperator, which pretty do everything: replaces some of the UI, accesses local files, changes the webpages, implements new keybinds, etc.
January 10th, 2010 at 1:36 pmIf it can’t be re-implemented in Jetpack, Firefox becomes useless.
If it can, I don’t think Jetpack is that useful in keeping “safety” and stability.
End users aren’t always looking for the best technical solution. We don’t understand or care about the coding foundations. I’m also of the mind that if AdBlock and NoScript died, I would be so irked I’d choose another browser – even if it was inferior. Others may be tied to Vimperator or something else. Firefox has gotten where it’s at because of the add-ons in spite of the claim that most people don’t use them. Somewhat geeky folks adopt Firefox and use add-ons and recommend it to their friends who don’t use add-ons. That’s my guess on how Firefox distribution has unfolded. The 33% of people that use add-ons are disproportionately influential, I would guess.
January 10th, 2010 at 2:01 pmAnyway, it’s just a browser. Kill my favorite add-ons and I’ll must move on. No huge thing.
First of all let me say that I’m a user, not a programmer. I’m currently running Firefox as my default browser because it is stable and provides add-ons for all my needs. Should a future version drop these capabilities, I’ll switch to another browser (Chrome or Safari) in no time.
January 10th, 2010 at 2:07 pmAnything that improves security is a bonus.
January 10th, 2010 at 2:08 pmIf “deprecated” means “still supported by the code but not anymore pushed by the Public Relations department” then it’s OK for me: I can supplement a lack of PR advertising by good old word-of-mouth.
If it means “to be phased out and removed from the code of _all_ Mozilla-family products within a year or two” then it’s wholly different. There exists some great extensions out there, both by Mozilla (DOM Inspector, ChatZilla, Venkman, Lightning, Provider for Google Calendar, SeaMonkey Debug & QA, …) and by third parties (Adblock Plus, MR-Tech Toolkit, keyconfig, HTML Validator, Live HTTP Headers, Tabs Menu, Duplicate Tab, Tab Mix Plus, …), and it is that riches of possible customizations which, IMHO, made Firefox, Thunderbird, SeaMonkey and Sunbird (to name those I know) immensely superior to their competitors. Doing away with all that riches in favour of lightweight (and, therefore, much less poweful) add-ons would, I think, be a fatal error.
If Firefox does away with them but (as the post by Robert Kaiser above seems to imply) SeaMonkey continues to support them, then for me it’s Bye-bye Firefox Hello SeaMonkey, and I have a kind of hunch that I wouldn’t be the only one.
January 10th, 2010 at 2:38 pmHmmm…
“We already know from our users that incompatible add-ons are a significant factor in opting out of updates.”
Shouldn’t this tell you how much users are dedicated to add-ons and how critical they are to user experience?
So the problem is that add-ons obstruct users’ adoption of updates, so let’s get rid of add-ons. Think about what was said above and you get a logic that goes ‘hey, let’s get rid of add-ons’ is then equal to ‘hey, let’s get rid of users’.
Chrome has passed Safari in usage in less than 2 years, while Safari’s usage share is still growing. That’s huge. Keep up this sort of thinking and Firefox will be next. I don’t want Chrome, I want Firefox – the Firefox I’ve come to expect. A ‘brand loyal’ UI and non-extensible functionality is not the Firefox I’ve come to expect – it’s the Internet Explorer I’m used to. I don’t think I’m alone in this thinking.
January 10th, 2010 at 2:42 pmYour follow up comment (comment 15) really helped removed a lot FUD that came with a post that didn’t present a whole lot of details, but presented scary words like deprecate. It might worth to update the post so that it doesn’t get lost in the comments.
I haven’t worked with Jetpack, so I won’t badmouth the idea. Probably like many other extension developers, I thought of Jetpack as being a toy extension. Something to make generic extensions easier, and it’s power being somewhere between a bookmarklet and an add-on. But this is path Firefox is taking in the future, it deserves a closer look for sure.
January 10th, 2010 at 3:08 pmIf firefox removes extensions it will be forked in order to keep them. Removing extensions is a dealbreaker.
January 10th, 2010 at 3:17 pmFirefox without his fantastic add-ons is useless for me. The Add-ons are the mine goal
January 10th, 2010 at 3:21 pmof Firefox. The extendibility make Firefox unique. I love Firefox, and I use it
sins ever. What i see you attempt to create a new MS Bowser. We don’t need
a browser like this.
I think there are lot of users out there, whit the same opinion like me.
I hope you think about a little bit more in which direction the future
development goes. The hart and constantly work of 1000s of Add-on and Theme developers says clear what the user wont.
I’m not really sure where the idea of “killing addons entirely” came in. We’re talking about an unlimited unstable model vs. an extremely broadly capable and stable API. That difference is hard to explain to non-technical people, but the idea of dropping top add-ons just seems so suicidally stupid that I cannot understand why people think we’re going to do that. Hopefully the updates to the main post will clarify enough, but if not, please feel free to ask me questions.
January 10th, 2010 at 3:44 pmThis blog post seems rather vague and an odd way to announce something of this magnitude. If support for current extensions is going to be dropped, then talking of a direction and change of focus is rubbish. A “direction” isn’t good enough – there should have been a detailed roadmap before the decision was made, which apparently happened months ago.
I’m hoping the plan is actually to push development towards Jetpack while leaving in place support for existing “old-style” add-ons. Doing anything else seems foolish, creating the biggest possible obstacle to people upgrading from whatever version drops support for add-ons, and working against what are apparently the goals…
January 10th, 2010 at 3:45 pmWell, now my previous comment (written before the updates, and before reading comments) looks really stupid
January 10th, 2010 at 3:48 pmThis wasn’t an announcement, but a detailed roadmap just isn’t really how we do things… we’re really going to just keep iterating until we think it’s right, and that’s IMO better than trying to nail down a bunch of details before we start, since we’re usually wrong anyway once we get into it…
January 10th, 2010 at 3:56 pmI think this whole Jetpack/Personas debacle is happening because there is not much detailing to those outside of the small circle of driving developers. The comments in this blog and the fact that a multi-paragraph reply was needed to clear the intent of the multi-paragraph blog entry says a LOT. In addition to all of this, there’s an ongoing conversation in the NewsGroups about replacing all hints to the old stuff now knowing well enough that there is no visible path forward to those wondering why signs should now point to much less capable technology in the browser.
If Personas will standardize Theming, then it should atleast get up to par with the current system before replacing all signs to the old stuff. The same goes for Extensions.
January 10th, 2010 at 3:57 pm@Mike: Yes, you *are* killing addons. A broadly capable set of APIs that will allow the “vast majority” of extensions to be implemented is *not* the same thing. And Personas is even more ridiculous. They are what Chrome has. Firefox currently allows you to do *anything* you wish – even things Mozilla had never thought of. That of course brings a certain learning curve, but as I said I see no problem in the two systems co-existing. But killing the existing extensions and theme system is simply wrong. Jetpack is like Chrome extensions – if I wanted that, I’d be using Chrome. But I happen to like the ability to change Firefox’ UI as I please (see my previous comment). And of course, JetPack, I’m sure, is making heavy use of those features as an extension right now. How would projects like those be done with no extensions?
January 10th, 2010 at 4:25 pmFirefox is widely known for the ability to customize it. It is one of the core ideas of Firefox. Ripping this out will harm Firefox and harm its users. Most users may not use any addons (or very few), but those who do are responsible for much of Firefox’ current success. Should you fail those users, you will lose many more users. The most useful addons are generally those that are most heavily integrated with Firefox – and thus make the maximum use of the freedom, which the extensions system allows, and which JetPack does *not* allow.
I’m SO dissapointed about the movement around the future of Gecko’s extendability and usability. Firefox always was something, that was easy to use and with a bit more brain, also extendable and customizable. I’ve moved several people from their MSIE daily bread to Firefox, and they never really noticed the change apart from the sub-minded move from “the blue E” to a “red icon”.
I’ve started to use Firefox as my primary browser even before the final v1 was released, and I’m still using it now. I’ve got to note, that it’s HIGHLY customized and extended by others AND my own extensions. I’ve started totally from scratch, with a basic (ok, maybe a bit advanced) JavaScript knowledge and a few years of experience in web development (JS, HTML and ofc, a bit of PHP, as it was (and probably still is) the start-up platform for a web developer). That’s it. With this, I’ve managed to create my own first simple extension that converted a selected timestamp on a page to a date. After that, another simple extension followed. And after that, guess what, a COMPLICATED one was developed by me, which worked perfectly, and still works, though now, it runs a SQLite db instead of dynamic loading from web.
I don’t really think, that I’m an average Firefox (Thunderbird, Komodo, name it) user, nor do I think I have the guts to be a core Gecko developer. I just want to note, that as an average web maker I was able to create a SIMPLE extension. Noone helped me, I’ve had only XULPlanet and the whole Net to search for examples and solutions. At the beginning, XULPlanet was totally enough. The today’s developer.mozilla.org couldn’t be more retarded for people who want to start creating their own extensions. For in-deep processes like creating a file, using registry, creating and using Storage structures, … these are complicated things, that need to be understood in order to create extensions which would use them.
Anyway, the whole point of my post is – look at addons.mozilla.org. Do you see tens of addons? Or hundreds? Nope. There are THOUSANDS, my god. But look at them. You could cut off half of them and noone would notice. Why? Because most of them are totally indifferent. A green theme, that replaces 5 main toolbar buttons. Another one from the same developer, just pink. Red, blue, purple, orange, yellow, … and you’ve got 10 addons. Yes, I’m gonna use the word again – retarded.
Now with Jetpack and Personas, this word is coming up to its excellency in meaning. Themes are becoming Toolbar backgrounds and Addons are becoming One-way-used-5-lined-scriptlets. Don’t get me wrong, it’s fine with me that the users can change their toolbar backgrounds or create their scriptlets. But turning THIS into the default state – for me, all hell would break loose. Every single “developer” would flood the addons ecosystem with their own FANTASTIC … what … dog picture on toolbar?
Apart from that, one of the addons I created, has transformed into a VERY complex web content management and administration tool, completely running on XUL/XBL/JS. And that is not the only case of complex xul-running system that would need to be re-developed and its functionality re-routed using “simple” interfaces for dumbasses that wouldn’t use it anyway.
Final thougts – ok, I can live with Personas and Jetpack being merged with the browser. But please, pretty PLEASE – don’t change what’s already working and ALREADY better than any html platform. This would only create a mess, and drag Firefox and other Gecko based software to idiocy-level software, which won’t have a chance to fight the ones, which were created on this level.
Build a software that a fool can use, and only a fool will use it. Suvate.
January 10th, 2010 at 4:31 pmYou people are absolutely nuts if you reduce access to every nook and cranny of firefox. Open source projects that have found some traction in the marketplace are starting to get stupid. You cannot win against hugely financed proprietary systems by mimicking them. Your only ace is being able to survive doing what the proprietary products CANNOT DO. Focus on what the vendors CANNOT offer, where they are unable to go because of their business requirements. Firefox Extensions are exactly the right kind of differentiator. Keep em WIDE OPEN and all powerful, or you will fight on the bad guys terms, without their resources, and you will lose. Mozilla project looks like a barely-managed mess from the outside, please let me tell you. Why not just clean up the developer docs, reduce the mozilla-websites sprawl and cruft, spruce up all the obsolete and conflicting documentation. You want to be the “Number One Browser”? Who cares. Be the BEST browser first and foremost and Don’t forget where you came from.
January 10th, 2010 at 4:54 pmMike Conner, Mozilla is a community and not a your average for profit company. You cannot just say there is a consensus amongst those guiding the project to change the current add-ons structure and expect the rest of the community to accept your decision. Over the years people from the community have created and participated in campaigns to make what Firefox and Mozilla is today ( all for free might I add). If you and “those guiding the project” decide change something about Firefox without input from the community,the death of Mozilla Firefox as a fully open project would lie on your heads. A word to the wise is enough.
January 10th, 2010 at 4:59 pmWhile I can understand the intentions of Jetpack and Personas to provide a stable UI to make developer less difficult, my concern is Mozilla is focusing on too much on adding functions to Firefox instead of stabilizing the browser and improve webbrowsing. Whatever doesn’t fit in those categories should be left as extensions only instead of added as a core feature of Firefox.
Jetpack and Personas are currently too weak to replace existing systems, so leave them as extensions until they’re more polished for the spotlight in the future. Personas though is already integrated with 3.6. It should be backed out come 3.7 and left out until it’s more capable.
January 10th, 2010 at 5:03 pmDeprecation does not mean “going away soon” in this case. It means “not the recommended way of developing add-ons” and “not what we’re going to evangelize to new add-on authors.” Any discussion of _removing_ functionality is vastly premature, and anyone claiming we will do that are creating their own FUD. First, the new systems need to mature.
@Asbjørn: just because we’re pushing the vast majority of add-ons to a stable, reliable model doesn’t mean we will automatically drop old-style addons. In the same paragraph you quoted, I stated that whether the API is rich enough to drop the old system in a couple of years is anyone’s guess, so to say that we’re killing current addons now is simply wrong, and misleading.
@Silent Watcher: If we weren’t listening, we wouldn’t blog, we wouldn’t respond to newsgroup posts, blog comments, or private emails. However, listening does not always mean doing what vocal people want. It’s a tough balance, and sometimes we don’t get it right, but we’re trying to find solutions that work for as many people as possible. Not everyone will like that, but we’re entirely committed to working with the community as much as possible. Please feel free to contact me directly if you think there’s other examples where we can do better.
January 10th, 2010 at 5:42 pmThen, what is happening now is not a deprecation of themes but a “depreciation”.
January 10th, 2010 at 6:04 pmWhy Personas doesn’t allow the use of a third-party theme now, if it did on the past?
Why is there a link on FF 3.6 Add-ons > Themes saying “Get Themes” pointing to the “Get Personas” site?
Why still not exist a link on the “Get Personas” site pointing to the Themes Section on AMO, as was said two months ago in the bug that has implemented this “Get Themes” link?
Oh!! I’m glad I was able to post the comment above…
I’ve tried to post this after comment #6 and twice again after, but I was unable to get my post showed here. Maybe now “killing” the URLs.
Now is a bit out of context, but, anyway:
Notice that when I’ve proposed what I’ve called “light-weight” approach for themes I was not meaning them as substitute for “heavy-weight” themes:
hxxp://www.tudobom.de/articles/yatt/
Actually we have two ways to skin a XUL based application UI, the substitution method from existing skin packages (the “heavy-weight” approach ) and the override method from existing skin packages (the “light-weight” approach I’ve proposed, the same principle from userChrome.css customization with the enormous advantage we have, being able to “switch” themes).
So, a theme author can opt for one or other method:
“heavy-weight” – If a developer needs more power, more possibilities, if the UI proposals go deeper in the application’s appearance. Of course knowing that this method means more work, high risk to get “broken”, etc… There are many developers who use to track changes on Firefox and are able to fix their themes in a matter of hours: hxxp://forums.mozillazine.org/viewtopic.php?f=18&t=1418995 and hxxp://forums.mozillazine.org/viewtopic.php?f=18&t=975065
“light-weight” – This approach has not the same possibilities like the other, but is capable to build very good themes, a bit easier to write and with very small files. It has less risk to get broken. Aaron has done an excellent job migrating all his themes to this approach.
So, both approaches can live very well together with Personas, providing a powerful high level of customization. Themes and Personas give our users the capabilities to customize the full appearance of the browser.
Give the power of customization to our users.
January 10th, 2010 at 6:10 pmIsn’t having a tab called “Themes” that does not actually contain Themes and having the actual Themes stuffed under Extensions just a little bit, I don’t know… confusing? I’m no programming expert but I cannot Imagine that it is that difficult to add a tab to the Add-ons panel called “Personas” with a little masked fox icon. Maybe completely ditch the “Get Add-ons” tab and simply add a link at the bottom of each tab for a “Get…”. So you have an Extensions tab with “Get Extensions…” at the bottom, a Themes tab with “Get Themes…” at the bottom and a Personas tab with “Get Personas…” at the bottom. There you go, problem solved! And you don’t even have to pay me for that one, it’s on the house.
All of your arguments against traditional themes are completely hollow and everyone in the community knows it. ShareBird’s Lite theme system allows us to create very basic themes that can be compatible with every version of Firefox from 2.0 up. I’ve even got one that’s only 23KB. So that takes care of compatibility issues unless for the next 5 years unless Mozilla decides to arbitrarily change the names of the basic theme elements. The argument that themes are slow to update is largely perceptual because sometimes themes get stuck in the AMO Sandbox for months at a time, appearing to casual users to not be compatible with current versions of Firefox. The solution for that is simple as well. Extend a little bit of trust to your theme authors and give us the ability to decide when our themes are ready to come out of the Sandbox. Sure, the first time should be moderated but after that, what’s the point in every single incremental version being Sandboxed? Especially now that there is an automated check system in place? Is the only answer really to just ditch the entire system?
January 10th, 2010 at 7:16 pmDon’t Throw The Baby Out With The Bath Water.
I use Firefox because of the extensions and features please be very careful not to destroy the things you value the most.
>…it is not enough to simply build a better system, we must migrate our users and our developer ecosystem to that system to reap the benefits.
I do admit to being conflicted…
I have made a concious effort not to become stuck in my ways and so at least try any new ideas you guys have, rather than a NO to any change
This has served me well… the “Awesome Bar” I thought I would hate and demanded a change in behaviour… but surprisingly I love it.
I checked out Persona and although I had thought ppl who messed about with Themes were “odd” its actually good for a laugh!
So I am willing to give you the benefit of the doubt but you need to be very careful.
extensions are not a small thing and changing to jp would be a revolution not evolution.
Wishing you all well.
January 10th, 2010 at 7:35 pmI’m speaking here as an addon developer of multiple extensions, occasional AMO editor, occasional participant in m.d.extensions and occasional mozilla bug reporter and patch-writer.
You got a perfectly fine platform and try to destroy that by reinventing the wheel, but this time adding some more edges and restricting the use to only some approved streets.
Software development is and always will be hard. It’s not like Basic or Cobol made things that easy that every regular guy could suddenly program great applications.
There is no silver bullet[1].
I spend the last month or so explaining to my addon users why I/we do not intend to support Chrome: because it is far too inflexible and far less powerful compared to the mozilla platform[2].
And now I have to read that that less-powerful system will be the way of doing things on mozilla as well, at least in the long run.
Yep, you’ll be killing some of the more sophisticated addons in the long run. And no, this isn’t FUD, you basically said this yourself. You intend to remove the old system once the jetpack-like system is “mature” enough (whatever that means).
You’ll be killing those addons by limiting the power and flexibility of the platform itself and by forcing authors rewrite otherwise good code, something that will take a lot of time and effort not every author will be able to provide.
You are recreating more specialized APIs to replace more general ones. This effectively will make the extension system less flexible.
And those specialized APIs might (and I’m pretty sure will) cause a nightmare for cross-application support in extensions. Firefox, Thunderbird, Sunbird, Songbird, Seamonkey and all the others will then only provide specialized APIs which will require specialized addon code, hiding away the more general APIs which would require far less cross-application-compatiblity code.
You are shifting away resources from the existing system to the new jetpack-like stuff instead of even wholeheartedly attempting to improve upon the existing one.
You already have (had[3]) things like FUEL, xpcomutils.jsm, netutil.jsm. It would be pretty easy to provide even more helpful js modules, even with a stable API.
As for compatibility issues, the track record is quite miserable there, but mainly because of mozilla and not third-party addon authors.
Just look for example how messed up things got with JSON: First providing a js module in FX2, then providing nsIJSON in FX3, then providing a native object in FX3.5. But unfortunately there never was a compatibility layer. It wouldn’t have been too hard to adopt json.jsm to provide that compatibility layer, but instead that module got dropped. Now I can either write my own compat-layer or download a third-party compat module Myk generously provides instead of using a supported, well maintained official method.
So stop bitching about compatibility issues with the existing system, because as a matter of fact most would have been avoidable but weren’t because of some short-sightedness.
The need for stable APIs can be solved with the current system.
You want to replace install/chrome manifests with some jquery like syntax. Mostly a change in syntax. New features could be easily added to the existing formats as well.
You want to replace xul/xul overlays/xbl with html. Both require time to master, and frankly in most cases I consider XUL the better alternative, because it is aimed for real, native-looking UI. How many theme-havoc (with non-default themes) will there be because authors will start to use jetpack ui-html like regular html instead of ui-xul like, well, ui-xul?
I’m not generally against implementing Jetpack/Personas.
Might be a good addition actually.
But a very, very bad replacement.
I’m bewildered and upset by this announcement!
[1] http://en.wikipedia.org/wiki/No_Silver_Bullet
January 10th, 2010 at 8:13 pm[2] http://www.downthemall.net/latest/no-google-chrome-support/
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=536504
Are you kidding me here?
This just reeks of PR spin. And yes, I have read the comments…thanks for the snarky post update there.
You started off this post talking about sacrifices, and major changes to the technology stack, and how hard it would be to give things up but it needs to be done. Discriminating and deprecating. Then the backlash immediately kicked it and there was massive backpedaling and damage control, although I noted that your wording was carefully chosen to indicate that eventual deletion was inevitable but not immediate.
Firefox needs less, not more. This is correct. But limiting the add-on capabilities and restricting to a subset of functionality in the hopes of encouraging users to update to new versions isn’t where the cruft is. We use Firefox because of the add-ons and the wide range of control that gives us over customizing the browser and doing our jobs better. Ask any professional web developer how he or she would feel using Firefox without the Web Developer Toolbar, Firebug or GreaseMonkey. IE offers some similar options using a limited API and you know what? Those options SUCK.
Maybe this is all premature. Maybe we are all upset over nothing. But you yourself said that it is too early to tell one way or another. Maybe Jetpack will implement a perfectly wide API and we’ll have all our add-ons as we know them, or even better. Right now that is a very, very big unknown, and until we see something in the wild that answers the unknowns with certainty there will be static and anger because not only are you messing with something that helps us do our jobs better, you’re messing with something when there is no quality, viable alternative. Chrome is getting there, but it’s not there yet.
Given the organizational attitude and subject presentation in this post, if a suitable alternative existed, I would be gone, and I would encourage anyone who would listen to follow.
January 10th, 2010 at 8:19 pmThanks for the info Aaron. It’s very interesting.
Robert Kaiser makes some great points and his #3 suggestion is the best imo.
I can see some of the positives of Personas (and love them) for end users such as being able to very easily preview Personas and apply them, but since Personas aren’t thorough and global themes, they won’t appeal to those who are really interested in, and serious about customization. Look at the popularity and use of theming software and sites like Stardock and WinCustomize.
Even if support for toolbar images is provided for Personas, it would just be like pimping out the exterior of a car and not doing anything with the interior. Personas will be very successful primarily because Mozilla is promoting and integrating them into Firefox, but Themes would be too if they were heavily promoted which they never have been. Extensions have, but Themes on AMO don’t even appear in the Categories list, it’s in the Collections list and at the bottom of that. You’d think that they’d be in the Appearance section, but they’re not. And when you view Themes, half of them aren’t even compatible.
I’m not an accomplished add-on developer, but I’m very familiar with what it takes to write themes and extensions and there’s much more involved with and work done developing themes. Most “official” Mozillians use default themes (judging by their screenshots) so that could be one reason why Themes don’t get too much attention.
Jetpacks rock, no doubt about that, but again, I see them appealing more to casual Fx users and not so much power users which isn’t a bad thing at all, I just think that there’s room for Robert’s suggestion and getting developers to learn or adapt to an entirely new system is going to be a tough sell. We’re all lucky that they do what they do free of charge as it is.
About add-on updating, the older, more popular and most used ones are (just about) always kept up to date so that shouldn’t be the reason for mass amounts of users not upgrading Fx despite what some sample feedback might say. For the add-ons that aren’t updated that people hold out on and that don’t upgrade Fx because of, those are mostly flash in the pan ones that are the biggest issue. The ones where a developer’s add-on becomes massively popular and they decide not to update it and maintain it for whatever reason (usually because of time constraints and real world issues). There’s a long list of those but more often than not, new developers will take on, or adapt that add-on but not in time for the latest product release.
A few solutions for that would be;
Developer’s who have no plans on maintaining their add-on(s) for the next Fx (or other) release should have their add-on(s) dropped from the recommended add-ons list.
Those developers should make clear that they’ll no longer be maintaining their add-on and encourage, and work with those that might be interested in taking over. A simple notice in the add-on’s description on AMO isn’t good enough. Other developers don’t see it.
Creating a new category in the AMO (and perhaps mozillaZine) forums plus adding AMO and Mozilla site promos to “Adopt an Add-on” wouldn’t be a bad idea at all.
When an add-on becomes incompatible with the most recent version of a Moz product, it should be moved to a new “Incompatible” Add-ons category where users have to implicitly choose to view them like they have to for experimental ones and not be made available through AMO’s general search. There are still add-ons that show up for Fx 1.
Providing some sort of extra recognition and perhaps an AMO award or badge for add-ons that are successfully upgraded to be compatible with the next Moz product release is a good idea also, and of course recognize the developers too. It amazes me how many developers there are that have consistently maintained their add-ons since the initial release (or soon after) of Firefox. Ed Hume, Mel Reyes, and Aaron to name a tiny few. They should get extra exposure and recognition and an award/badge type system would show end users that they can count on their add-on being available and compatible in the future.
As far as I’m aware, there isn’t any means of communicating directly with individual developers to both remind them to prepare their add-on for the next product release, and find out if they’ll be bothering to update it all. There’s a few blogs and newsgroups, but there should be a newsletter and survey that goes directly to developers. If they don’t plan on maintaining their add-on(s), then they should be encouraged to add it to the Adopt an Add-on thread (or have it added on behalf of them, I’ll volunteer to do it). The Add-on Compatibility Reporter is a great step but not a comprehensive solution.
“This is a strategic product decision” – “It isn’t an easy decision” “This wasn’t an announcement”
Aren’t you announcing a decision?
“Deprecating the old systems in favour of the new systems is a required part of the strategic plan” – “we must migrate our users and our developer ecosystem to that system” – “Whether in a couple of years we are willing to say that the old model is well and truly unnecessary is crystal ball gazing at best”
Don’t they contradict each other? If the current system is to be phased out and you are in favor of dumping it and are “discriminating against the old systems”, how do they remain necessary?
I’m aware of and greatly respect those who are “guiding the product”, but what about those who are powering it and its success such as veteran add-on developers (like Aaron, Mel and others)? Have they been consulted and asked for their opinions and feedback? Are they ready and willing to migrate to a new system? If not, that’s when we’ll lose the great add-ons that are helping to retain Fx users, and sometimes barely retaining.
January 10th, 2010 at 8:40 pmThe issue of staying backward-compatible is one of the glaring weaknesses of PC platforms. If you want to do it right, go see what IBM has been doing on the mainframe for the last 40+ years. A properly-coded program that ran on OS PCP in 1966 will run on the latest hardware and Operating System. Adding lots of new features and capabilities to both hardware and software didn’t preclude compatibility, although I’m sure it cost IBM some bucks to maintain that compatibility. (And those who call the mainframe a dinosaur should remember that the human race has only been around about 150 thousand years and dinosaurs were around about 1000 time longer).
January 10th, 2010 at 9:15 pmRay, IBM has hundreds of thousands of employees. Mozilla has a couple hundred full-time and a couple thousand part-time contributors. Assuming that perpetual backward compatibility is the right thing because a company with hundreds of thousands of full-time employees can do it some of the time is assuming a lot.
January 10th, 2010 at 10:09 pmI don’t really care much about Persona’s, but am interested in seeing where Jetpack ends up. I’ve always personally kinda thought JetPack came out of one person (Asa I think) saying (paraphrase), “I think FF’s javascript API’s should look like this, and so that’s how they should look.” I personally don’t find it all that much easier or better by any means, beyond the whole “no restart required” stuff. I think you’d get just as far with if you added a “restart-required” field to install.rdf and maybe some script registration in chrome.manifest.
In fact, with a quick overlay to write some “default” code, and a few little code hooks to make it easy to add toolbar or statusbar buttons from Javascript, and you’ve got most of what I’ve seen from JetPack so far. Guess what I’m saying is that it seems like a simple GUI for creating simple extensions could do most of what Jetpack is doing while actually expanding the market for extension writers beyond “People who are willing to learn scripting and XML languages” and even beyond JetPack’s “People who ware willing to learn scripting languages” to “People who are using Firefox”.
January 10th, 2010 at 10:10 pmI’ve been theming for Mozilla products since before Firefox ever existed. I started theming the Mozilla Suite with release 0.9 (May 2001) and have kept up with it along the way.
I’d hate to have to drop my themes in favor of something that can just change toolbar backgrounds and text styles.
January 10th, 2010 at 10:20 pmHi all,
Nick from the Add-ons team here. I just wanted to jump in and provide some additional info. First off, Jetpack shouldn’t be considered a wholesale replacement of the existing add-ons platform, but rather a preview of what’s coming next. We started this project early because we wanted to learn what our developer community wanted by starting small and building out capabilities based on feedback.
The goal is to provide a sane transition to a world with fewer browser restarts, fewer dependencies on platform versions, and faster implementation and reviews. So if you have an add-on with millions of users, you’ll be able to seamlessly switch your users to the new implementation. Nothing changes for them other than fewer restarts required on updates and your add-on should be easier to maintain and update. And if Jetpack doesn’t do what you want out of the box, we’re creating a platform where the community can add lower-level capabilities that get additional scrutiny before being shared with all authors everywhere.
Please get involved in the discussion at http://groups.google.com/group/mozilla-labs-jetpack/topics and help us build the future of Firefox Extensions.
January 10th, 2010 at 10:31 pmI am in complete agreement with those who are voicing their opinions here (and elsewhere) in opposition of this “depreciation” plan. Mike, I’m not buying the justification of this move and have to ask if anyone from within the corporate walls clearly recognizes the popularity of addons.mozilla.org. While there are those who favor Personas and Jetpack, certainly there are just as many if not more who favor themes and extensions. Mozilla’s attempt to please the user base by depreciating one method over another is only going to accomplish one thing — the depreciation of the user base.
January 10th, 2010 at 10:47 pmJust compare the “macro recorder” iMacros for Chrome and iMacros for Firefox addons and see how much more powerful the Firefox extension system is. The current Firefox extension system is GREAT, and it should be improved by working on the open issues (such as browser upgrading). Replacing it with a clone (more or less) of the Chrome system is like replacing a Mercedes with a bike. Just because the bike does have some advantages sometimes, Mercedes would not switch their business to bikes, would they?
January 11th, 2010 at 3:52 amLet’s not be coy.
Personas were not going to replace or eliminate themes.
The ‘get themes’ button will now go to the Personas page only?
Sure seems like that just cut off the theme pipeline at the neck. Thus, themes die.
So if Jetpack follows this same pattern, how long before extensions are something you have to dig for?
We don’t have to create FUD. Mozilla’s own behaviors are doing a good job of creating it without our help.
January 11th, 2010 at 4:20 amAs long as existing add-ons will automatically and seamlessly update to Jetpack versions when they become available, I’m happy.
January 11th, 2010 at 5:48 amNow it’s just hoping that all the add-ons I use are migrated by their respective authors. But I’m sure Firebug will be and that’s the most important one for me.
“The ‘get themes’ button will now go to the Personas page only?”
The “Get Themes” link in the Add-ons manager in 3.6 goes to the Personas gallery only.
I prefer to pose it as a statement.
So what will Themes be classified as? I mean if they can be depreciated any more than they already have been?
If the plans are to just do away with Themes as we currently know them, why not say so? I don’t see a migration here, I see elimination.
January 11th, 2010 at 5:57 amI was wrong when I said “Themes on AMO don’t even appear in the Categories list, it’s in the Collections list”. There isn’t a Collections list, the dividing line between Other and Collections threw me off, but Themes are still last on the Categories list. Three below Personas.
January 11th, 2010 at 6:02 amPerhaps this incident has simply been a misunderstanding….
But, the original blog post does talk of “strategic decisions” and “discriminating against the old systems” while acknowledging “not everyone invested in the current technology stack will be happy with the change in focus”, and asserting “there is consensus among those guiding the product that this is the direction we need to take”.
The original blog post did *not* say something like:
“There will be two ways to create extensions and two ways to create themes. They will co-exist for the foressable future. We will encourage developers to use the newer methods, as they will be more structured and more secure. However, we recognise that some add-ons will need facilities more akin with the existing methods. So the older methods are *not* going away any time soon.”
( though that seems to be the message now… )
To claim dissenters haven’t read or understood what was posted is incorrect. They read and understood the words that were presented.
The question of whether those words accurately represented the author’s intended message is another matter.
In fact, I suggest the author re-read his original post, and ponder the phrasing therein, before accusing anyone of “creating their own FUD.”
@Nick Nguyen
“And if Jetpack doesn’t do what you want out of the box, we’re creating a platform where the community can add lower-level capabilities that get additional scrutiny before being shared with all authors everywhere.”
erm…
and how are those “lower-level capabilities” to be added to Jetpack ?
By means of one or more extensions – that will themselves need to be downloaded and installed ?
Or by requesting APIs to be added to Jetpack ?
But as Jetpack is integrated into Firefox, that would mean adding code to Firefox itself, so what percentage of those requests will be rejected as WONTFIX ?
@Ken Saunders
January 11th, 2010 at 8:18 amI’ve been thinking along the same lines as yourself regarding “abandoned” add-ons. “Adopt An Add-On” would be more constructive than letting abandoned code linger.
( Well, that’s two of us who think it’s a good idea at least… )
You are fucked up if you do this. Instantly ppl will look for alternatives. We have internet you know. I have no problem, as a power user I always use the best solution. Chrome has speed, but it provides as much comfort as ryanair, safari is obviously a joke, opera maybe will be happy. They work hard, and i missed at least 2-3 release with them. As soon as you start kick your own community, you are history mozilla.
January 11th, 2010 at 9:10 amMike: “I’m not really sure where the idea of “killing addons entirely” came in.”
It’s simple. I’m a user, I don’t understand the technobabble about Jetpacks, Personas, APIs, whatever. I DO understand your blog is a rationalisation for what seems to be a complete and incompatible change to ‘extensions’, you clearly expect a lot of negative responses, something that isn’t the usual expectation if what’s being announced is fully compatible with what went before.
I thus put 2 and 2 together and read that Firefox 3.6 won’t have the same extension capability as 3.5.
January 11th, 2010 at 9:57 am@59 Robin
Your math is a little off then.
From a user’s perspective Firefox 3.6 features are a superset of 3.5, i.e. 3.6 has all of the features of its predecessor. The discussion here is about the long-term strategy for the Mozilla platform (Firefox 4.0 and beyond AFAIK).
January 11th, 2010 at 10:17 amI’m an Addon Developer for Firefox, and I’m really concerned about this. Let me put it this way: I put a lot of my personal time into developing some extensions that enhanced Firefox in cool and useful ways and by now, I’m pretty good at it.
If all of this work and knowledge is going to be wasted soon, not only me, but thousands of Firefox extension developers will be very disappointed and propably move elsewhere. By now, we have a choice.
Even the rumor that Firefox 4 might not fully support the old extensions could prevent me or others from developing extensions for Firefox.
But don’t think we would come back for Jetpack. It’s a matter of trust.
So, please – support Jetpack, but continue to support the regular Extensions as well. And by that, I mean to really support them, like you do now. Don’t hide them in some deep menu structures in the Addon Manager, and don’t mark them as deprecated.
January 11th, 2010 at 3:14 pmThe perception that Mozilla is “copying Chrome again” is because Mozilla is still behind Chrome on getting this type of API to users in a relatively stable release as a built-in capability of the browser.
I really hope Mozilla focuses more attention on getting Weave and Ubiquity in the browser as fast as possible, since Mozilla Labs is what can really differentiate Firefox from other browsers and leapfrog the competition. The integration of Ubiquity in a stable release would really be a “Wow!” / water cooler moment for many users.
January 11th, 2010 at 9:09 pmsucker
January 11th, 2010 at 10:48 pmMay I please call everyone’s attention to something posted today by Frank Lion in Firefox General on MozillaZine:
forums.mozillazine.org/viewtopic.php?p=8428425#p8428425
I found his perspective quite interesting, containing some enlightening facts and statistics that are pertinent to the discussion here.
January 12th, 2010 at 12:52 amDon’t brake what’s working. Extension is what led firefox to it’s current market share. You can ruin it all chasing the housewives interest.
January 12th, 2010 at 6:12 amVery nice information, but I thinkt that the read fox must be faster. The ather Browser are faster an when all plugins lost, then the user switch the Base.
January 12th, 2010 at 9:43 amYes, I support the posting of Endor.
This is just my interest.
I think I could, at worst, followed by Paolo …
That is all.
I am a normal user
January 12th, 2010 at 4:08 pmSo, is this the blog of a Mozilla Firefox manager (Mike Connor)?
Amazing, they’ve been hiding from the users (no contact or feedback) for years?
They’re still adding more and more features after adding more and more features?
They still haven’t fixed the speed, bugs, and broken display issues (try HTML 4.01)?
Now, they’re going to break their “add-ons” and all that developers have done?
It’s business as usual at Mozilla, a model of how dumb the “community” model is.
January 12th, 2010 at 11:10 pmThe addons is what saving firefox. Without it, it is just another below average browser.
January 13th, 2010 at 1:25 amWhen are the Mozilla folks going to realize Firefox’s ‘brand’ is not an appearance, it’s an experience? You don’t need to preserve it’s appearance with Personas, you need to preserve the user experience – of which themes are a significant part.
January 13th, 2010 at 3:43 pm“This is a strategic product decision,” might be one of the reasons why “people to assume this to be a final and official decision.”
If you are an writing a blog as part of your work for Mozilla you do have a responsibly to make sure your benties are clear. I think you need to apologise for the brewhaha this caused.
January 13th, 2010 at 6:05 pmI think you pretty much blew it with this.
Extensions are the ONLY thing keeping me using Firefox. Regardless of the long term plan or your intentions, you’ve created uncertainty about the future of extensions in Firefox and no amount of backpedaling can change that. I will no longer wear my mozilla add-ons shirt with pride.
January 14th, 2010 at 8:55 pmWhile I believe that Jetpack has actually managed to deliver where GreaseMonkey fails and that it’ll actually be able to move a lot of the simpler extensions over to Jetpack, I do still feel that it’s important to maintain the larger functionality set that XUL offers. Hopefully we’ll see 80% of extensions being done via Jetpack in the future with the other 20% done via XUL.
That said, Persona’s is a very curios decision. We’re most certainly moving in a direction where by it’s all about minimalism and as I know I’m stoked on the glass capabilities of my OS, thus I really can’t see myself opting to have a JPEG stuck over that. It seems like something kids would love and it’s easily marketable, but practical? That I’m not so sure off. I do know that the Firefox 4.0 theme I’m using is a godsend and I wouldn’t be a very happy bunny if it disappeared.
January 25th, 2010 at 1:38 pmNice API. Hope it will improve security!
–
Rotundo Pierluigi
February 11th, 2010 at 9:53 am