I’m at the NYC Indie Web Camp this weekend at the beautiful New York Times office in Manhattan. Tantek Çelik joined my team at Mozilla about six months ago to work on various Web Standards initiatives that we push forward on the Firefox Platform team. Although our bread and butter is Web Platform Rendering, Tantek is also passionate about advancing user-sovereignty to enable authorship outside of proprietary corporate silos (see POSSE.) I tagged along with him this weekend to learn more.
The Indie Web movement is in the midst of an exciting creative stage. There are people hacking on the building blocks and other folks dogfooding the code. At this point, I’m in the latter camp, looking to solve 2 problems that I have with my 3 web sites:
- junglecode.net – this blog for stuff about various things that I do with the geeks I hang out with (dare I say, my network.)
- junglecode.com – a site to catalog the products I make that happen to also pay my bills.
- junglecode.org – a site to describe non-profit activities (music and other hobbies) that I engage in. I haven’t found much time to write about this stuff lately.
Problem 1: When I first decided to split my online life into 3 top-level domains, I thought it would help organize my efforts into those 3 top-level buckets. It turns out that, in practice, I’ve just split my online persona into 3 sites in various states of intermittent activity. I’d like to try and organize the 3 buckets so that I can post content in any category (org,com,net) and have the posts go to the right site, while still aggregating on this blog. Fortunately, I met Jeremy Zilar this weekend and he works on the 200+ Blogs for The New York Times. My 3 site problem dwarfs in comparison to what the Times has to scale. I’m loving all the brainstorming going on this weekend.
Problem 2: I’d like to make a few bucks on these sites without the usual ad-generated methods. It’s not that I’m above receiving advertising revenue, I just think my audience is a very narrow slice of the geek population that is also very good at not clicking on ads. I would instead like to sell them my stuff. I might sell a single sweatshirt or an extra torque wrench that I happen to have lying around. I’d like to do this in an Indie Web way as I am, in effect, inviting you to a virtual private garage sale (VPGS?) I’m looking into various Web Payments solutions to do this.
I’ve added the IndieWeb plug-in to my WordPress sites so I can send and receive various notifications over IndieWeb protocols like WebMention. I expect to hack on various bits of the solution to these 2 problems as I learn more. I’ll share the code here, in case others may find it helpful.
I’m also interested in extending the Web Platform to enable more Indie Web capabilities at the core of the Open Web stack. It’s really exciting and fun to work on this stuff. What else can we do to make it easier for user-authors to raise their independent voice?
My last two posts didn’t make it on to planet.mozilla.org due to a recent junglecode server move. I asked Robert Accettura to update the entries in the planet database so that server-side redirects aren’t necessary. This post is just testing those changes. It’s also a plug for Planet Mozilla, a most excellent public resource for the Mozilla community.
If you missed these two posts on planet, here you go:
Software Project Estimates: Go Fly a Kite!
Mozilla Platform Rendering in Asia
Building Open Source software presents challenges to engineers and managers that differ greatly from proprietary systems. Open Source doesn’t eliminate the need for proper estimates and the predictability of costs that accurate estimates bring. Open Specifications like the W3C web standards add additional complexity to the estimation process. How are you supposed to know how long a project will take, when the specifications are frequently modified by authors and editors who aren’t under your control?
An estimation method that I often use at Mozilla is based on the Niagara Falls Suspension Bridge project. The Niagara Falls Suspension Bridge was the world’s first working railway suspension bridge. It was over 800 feet long, which was a length that was difficult to accurately measure back in 1847, before bridge construction started. The rapid waters and 225-foot high shear cliffs made a direct crossing impossible. The bridge construction must begin by stretching the first wire across the violent stream.
The Niagara Falls Bridge project shares many similarities with a complex software project: multiple stakeholders, unknown scope, dangerous obstacles and difficult terrain. How do you start when you can’t see how far you need to go? In January 1848, fifteen-year-old Homan Walsh flew a kite from the Canadian side of the river and was able to crash the kite into a tree on the New York side. The kite string was used to pull a thicker line back to Canada, then a rope, then metal wire, and construction progressed until a temporary suspension bridge could be built.
The truth is that Homan had a very difficult time getting the kite to fly to the other side! Weather and other unexpected problems left him stranded on the Canadian side for eight days and several failed attempts. Despite the difficulties, his initial kite was essential to the larger goal. When I first talk to engineers about a new software project, I often get estimates that sound like “two or three months, if we’re lucky.” When I hear that, I ask them to go fly a kite.
A “Kite” is just enough code to learn just enough new information about the project so that intelligent estimates can be made. I should note that this code can be very flimsy (like a kite) but functional enough to illuminate the unknown. It’s important that the engineer understands that we will not be shipping the kite! The goal with the kite exercise is to come with estimates that are in multiple pieces of work that each span days or weeks. Estimates that are still measured in weeks may require more kites to break down into days.
Getting that first kite across the gorge can be a very exhilarating experience, and may be just enough motivation to continue the difficult path forward. As an example, a big bridge project for us is Vertical Text and the first kite looked like this. A second kite looked like that.
I’ve spent the last 3 weeks traveling in Asia for Mozilla and W3C business. On May 20 to 24, my team was in Taiwan for a series of meetings on Platform Rendering (Layout, Graphics, and Media.) It’s always an enlightening experience for me when I spend time with such a talented group of people:
The Mozilla Firefox Platform Rendering Team on location in Taiwan.
Going to Taiwan was a very special event. The local Taiwan office was awesome, and the local staff was very wonderful, taking great care of us while we were there. Beautiful and fast rendering requires a deep understanding of the underlying hardware, and if you’re serious about hardware, you eventually have to go to Taiwan. Meeting and working with the local Taiwan team was great. They’re so smart, and eager to learn about the Firefox Platform. We spent a lot of time getting them caught up on Rendering infrastructure, and various Mozilla-specific topics (Open Source, Open Specs, Code Review, etc.)
I’ve pasted the calendar we followed for the week, below. The links point to raw notes from the sessions (where available.) I apologize for the lack of context in some notes, as they’re meant for the attendees. They’re in this blog post to give you an idea of what the Rendering Team does when we get together in a large group every few months.
Taiwan Rendering Sessions
Last year, I wrote a blog post regarding Flash that generated a fair bit of discussion. Since then, the Research team at Mozilla has been working on solutions: https://blog.mozilla.org/research/2012/11/12/introducing-the-shumway-open-swf-runtime-project/
As the research blog states, “…Shumway is very experimental, is missing features, contains many defects, and is evolving rapidly.” If you’re a technical person who wants to help the current situation with Flash and the Open Web, please help us out.
The Gecko Layout Engine added Graphite Smart Fonts support starting in Firefox 11. The Mozilla Firefox documentation for Graphite is still under construction but already contains lots of useful information for Web Designers and Developers.
The number of people who will benefit from Graphite is the small subset of the population that reads and writes with lesser-known scripts that require complex ligatures and rules for glyph substitution. In other words, we expect this work will appeal to a rather small underrepresented percentage of the web who communicate using uncommon writing systems. Firefox fully supports OpenType for the majority of writing systems on the web.
The key benefit of Graphite is that it allows type designers to build in complex script handling logic into fonts themselves, rather than relying on an application library like OpenType to explicitly implement support for it. That’s why it’s so useful for display and layout of scripts that require features not available in OpenType. There’s a lot of overlap with OpenType and the format itself simply adds extra data to OpenType fonts (the glyph and metric data is the same).
Graphite allows fonts to embed rich programs that implement the complex rules that govern glyph behavior in relation to other glyphs in a text run. This rich API presents challenges in an application as widely-distributed as Firefox, especially in regards to security and integration with the rest of the text subsystems. We’re currently testing, validating and documenting the Graphite feature in Firefox. We’re interested in getting feedback from the Font Developer community to ensure that Graphite is expressive enough for complex writing systems. If you have experience with OpenType layout, we’d like to see similar layout functionality implemented using Graphite. We’re looking for examples that could include non-Latin script support (e.g. Arabic, Thai, Indic scripts) or Latin/Cyrillic/Greek fonts with extensive feature support. A symbolic “WingDings” font with complex layout rules could also be a useful example. Please reply in the blog comments if you are interested and available to help us test and verify Graphite’s Layout API’s.
I’m posting about Graphite because it’s another example of why working on Firefox is so different from working on anything else. We don’t optimize our actions to generate maximum revenue, we do things because we want to give the entire planet equal and open access to the web. Proper text layout and rendering for complex scripts enables free expression across communities who would otherwise not have a global voice. We think it’s well worth it in service of the greater good for an Open Web.
Paint Flashing is now in the official Release channel starting in Firefox 11. I posted a new add-on that let’s you enable Paint Flashing with one click: https://addons.mozilla.org/en-US/firefox/addon/toggle-paint-flashing/
This tool is useful for quickly inspecting how Firefox renders your web pages as it visually indicates how much screen area is being painted after the page layout is computed.The source code for the add-on is also posted.
One of the Gecko Layout & Rendering team’s main responsibilities is the continuing development of CSS in Firefox. I recently modified the CSS style system to allow nested rule parsing. This bug fix taught me a lot about the CSS parser and how styles cascade through the rest of the Layout engine. It took me a little while to set up a dev environment, understand the bug, write tests, get the code written, reviewed, and checked in. I now have a much better understanding of what it takes to move code through the Mozilla source trunk.
I suspect that there are other programmers out there currently lurking around the Mozilla community, intimidated by the scale of the source tree, and wondering where to start hacking on Firefox. I highly recommend starting with the Gecko Overview started by L.David Baron, Mozilla Principal Software Engineer, to help beginners understand the browser engine. Thanks, David!
As promised, I’m going to call out Firefox Layout & Rendering code changes that my team has been working on. This bug fix from Bas Schouten (as reviewed by Robert O’Callahan) was one of those light-bulb code changes that have really advanced my understanding of the Gecko Layout Engine’s graphics code:
This check-in implements “Paint Flashing”, a diagnostic tool that shows when the browser is invalidating (or repainting) a screen region that has changed. It’s very useful for diagnosing redundant (painting too often) or greedy (painting too large an area) invalidation. Both kinds of bugs are notoriously hard to find.
Paint Flashing will paint a random color (at 20% opacity) to indicate the “damaged” area of the screen that the browser is repainting. You can enable Paint Flashing by setting this preference to true:
My last post generated a fair bit of discussion around the true fate of Flash within Adobe. The original announcement from Adobe and the associated staff reductions had caused a lot of speculation within the Flash community. I should clarify some of my statements, especially the parts about the Flash Pro authoring tool and Flash Player.
All software follows a similar life cycle from 1.0 to a final version when it effectively becomes frozen in time. I didn’t mean to imply that Adobe is pulling Flash Pro from store shelves like salmonella-tainted spinach. A familiar pattern is to move software engineering to a low-cost geography like India or China as growth slows. This is not a bad thing, and actually lets the software have a long tail of maintenance and incremental feature work at a cost that allows it. The consumer can still count on that software being available for some time with support (usually from the same low-cost geography.) A handful of engineers will remain in the original geography to consult the new engineers as the hand-off occurs. The Flash Pro team in the US will have a handful of engineers left behind to manage the hand-off so, technically, the entire team is not getting eliminated at this time. Over time, the idea is to have your higher-cost engineers migrate over to your higher-growth projects. This is what occurred many years ago at Macromedia when Director moved offshore and the team moved over to working on Flash.
Last Tuesday’s announcements did not follow this pattern. Instead of moving the mobile Flash Player to a low-cost geography, it was discontinued outright. Instead of moving many affected Flash Platform engineers to the next high-growth agenda, they’re getting sent home. These events are what prompted me to write my last post as my friends at Adobe were blindsided by the whole affair.
I have a great deal of respect for the Adobe product managers who are trying to contain the damage and reverse the Elop Effect from the original announcement. It does seem like they were not made aware of the Tuesday announcement in advance. I sincerely hope they will be successful at affecting change within Adobe to keep Flash around for a good while longer.