You can see the RFP here: http://pythonorg-redesign.readthedocs.org/en/latest/

It’s taken me several years of false starts, other attempts (including skunkworks attempts), political and social discussions, and the hard work of many to make this come to fruition. Now, we can only sit back and hope that we see some amazing proposals from the community and others.

I sincerely hope this will be successful, and that we will see a modern, well designed Python.org that showcases not only the language, but the vibrant, open, welcoming and active community we are all part of. 

This MozCamp was filled with excitement about B2G and the many other initiatives Mozilla has going on. Beyond the product building we’re doing, there was a lot of energy and enthusiasm for growing the Mozilla community and building on the ideals that Mozilla stands for.

During MozCamp, I spoke with a few people about conferences in general. I think there’s a lot of room to make MozCamp and other conferences better than what we’re used to. These ideas are not new and didn’t originate with me, but they’re worth repeating.

The Format Today

MozCamp was structured like most other conferences that I’ve been to: a packed schedule with multiple tracks of presentations. You get interesting people presenting on useful topics. That’s not a bad thing, but I think it can be better.

If I’m going to deal with the hassle of air travel and spend days away from my family, I’d like to get the most I can out of that time.

A typical presentation slot is 30, 45 or 60 minutes. Of that, there’s maybe 10 minutes of questions and the rest is an “eyes-forward” presentation. I don’t think this is the best use of time. The unique thing about MozCamp (or any conference, for that matter), is that I’m physically there with the other people. The communications bandwidth is much higher. To use that bandwidth for one-way communication seems suboptimal.

There were other issues that I noticed as well:

1. Attendees at MozCamp had varying levels of English proficiency. This can make it hard for some to keep up with eyes-forward presentations from native English speakers. Plus, a whole day of constantly translating in your mind can get tiring… by the time the second day rolls around (after a possibly late night followed by soccer in the morning!), I would imagine that keeping focused would be difficult.
2. No slack time for checking email and having hallway conversations. The schedule was packed, leaving mealtime and snack time as the only times to talk (short of skipping sessions). Some of the evening activities suffered from high noise levels as well, eliminating that chance to talk easily.
3. No slack time also causes issues with schedule slip.. On Sunday, the Q&A session threw the rest of the day off by 30 minutes. That’s not surprising, since it was an interesting two-way communication sort of session… but it meant that the rest of the schedule needed to be pushed by half an hour and never got back on track (causing some sessions at the end of the day to be dropped).

The Two-Way Conference

I think conferences, including MozCamp, should try to become more “two-way”. One formula for a session could go something like this:

• “speakers” are more like “hosts” or “invited experts”.
• The expert prepares a page with links to background material and probably a presentation. This page should be available a couple weeks in advance of the event
• That page can also include some suggestions for areas that could benefit from discussion.
• That page could also have an etherpad or wiki associated with it to collect more ideas in advance (as attendees view the material).
• At the beginning of the session, the expert provides a lightning talk-sized intro and, possibly with the help of a facilitator, gets people organized to usefully talk about things or work on something

A parallel is the recent talk of “flipping the classroom”. The students watch a video outside of class and then use class time to work together or get help from the teacher.

Wouldn’t it be awesome if, instead of 50 minutes of eyes-forward presentation followed by questions, we had 5-10 minutes of organizing, level-setting and topic choosing, followed by 50 minutes of two-way communication?

Some unconferences go so far as to not even have predefined topics and time slots. I’m not going that far. I think that a little bit of structure with some constraints on time can help make the most of the time. Additionally, I have heard from some conference organizers that you can’t even get some companies to sponsor sending people to a conference without presentations from industry experts.

Boriss had a user experience workshop that followed a good format: she did a few minutes of intro followed by demonstrations of applying her UX research suggestions to projects that people were working on. William Reynolds told me that he also ran a workshop session on the topic of getting people involved with Mozilla. Individuals can take matters into their own hands this way, and I wish I had done so myself (there’s always a next time!). I’d like to see conferences that encourage and support this even more.

How can this format help with the problems I talked about?

1. the sessions spend most of their time in a two-way exchange between the “expert” and the participants, thus making better use of the bandwidth
2. when communication is two-way, there’s more opportunity to overcome language issues than when you have a presenter following a predefined outline. In fact, sessions that involve group discussion could possibly take place in the group’s native language. (Of course, if everyone involved speaks the same language, then there’s no problem. Some of the MozCamp sessions were held in Spanish… of course, that left me, and some of the Brazilians, out.)
3. More of the stuff that might get discussed on the “hallway track” can now get discussed by more people during sessions
4. Ideally, there would be a bit more buffer time to handle schedule slippage and sessions that are so good that people just don’t want to stop

I still find conferences valuable and will continue to attend them, but I think we can do better.

Firefox is very fast. In fact, Firefox and its competitors are so fast that most web developers only care about one aspect of web application performance: network access. Latency and the amount of data transferred are the biggest issues for most web developers. We’ll be working on providing insight into network access soon in Firefox.

Developers working on three sorts of web applications in particular are asking for deeper insight into what the platform is doing:

• games
• complex layouts involving large amounts of data
• applications that have features you’d traditionally associate with “desktop applications”

Each browser has different performance characteristics, and these developers need tools that give them hints on how to make their apps responsive on each browser. They care about things like garbage collection pauses, repaints and reflows and hot spots in their JavaScript code where the just-in-time compilers aren’t able to make the JS zoom.

Most web developers aren’t working on these kinds of apps, and we’re focused on building tools that are useful for the “most common tasks”. However, we want these kinds of applications to run well on Firefox. Firefox developer tools really serve two groups: the web developers who use the tools directly, and the hundreds of millions of Firefox users who are looking to experience the web in the best way possible.

I think that our focus needs to remain on building the best tools for the most common tasks. But we also need to accommodate these sophisticated developers. Fortunately, we have more options than just “build it” or “don’t”.

For a feature to ship in Firefox, it goes through a lot of work to ensure that the feature is of a quality that is ready to ship to many millions of people and in many languages. The developers building these performance intensive apps do not number in the millions, and they are capable of installing add-ons. Some are even willing to produce their own custom builds of Firefox, if that’s what it takes to get the performance data they want.

In my opinion, that’s the planning lever we need to pull here. We can try to get these developers the data they need, albeit in a rough form, in add-ons as soon as possible. Along those lines, Brian Hackett has made his JIT Inspector tool available as an add-on.

If you need help figuring out performance issues with your application in Firefox, get in touch.

I’ve been working on developer tools for a while now, and I’m really proud of what we are shipping in Firefox today and the new features that are right around the corner. Browser tools are one of the most important parts of a web developer’s toolbox.

But, there’s a lot more that goes into web development than the browser tools. The video above and the text that follows are some thoughts on the whole of the web developer’s experience.

Web development is great because the platform is so high level and dynamic. That makes it easy to get started. There’s a massive collection of libraries, tools, books, tutorials and more to help web developers get things done once they’ve moved beyond the first steps. In fact, there’s so much out there that it can be hard for someone getting going to decide how to go from idea to done. The riches of the web ecosystem are both a blessing and a curse. It’s more blessing than curse, but that doesn’t make it any easier for newcomers and, in some instances, for experienced developers that are moving into a new area or applying a new technology.

Mozilla’s non-profit mission is to protect openness and innovation on the web. We want to make the web better for everyone, and I think we’re in a good position to help guide developers from idea to published app. Doing so is especially critical for our Apps initiative.

To that end, Daniel Buchner and I will be looking beyond developer tools in our product plans to include the whole of the developer experience. This will first show up in an Apps context, but we’re going to look for ways to apply what we do more broadly.