Great interview with the artist hamu.

Continuing a project I worked on during Mozilla Service Week, I’ve been working on my curriculum for a workshop I will be teaching in Nov for the first time. The class is called Where the Wild Things Could Be… and will be through the 826 Seattle writing workshop. It will have about 8 students that are 11-14 years old. The goal is to teach HTML. Hypertext Fiction, like the Choose Your Own Adventure book series, is a narrative with multiple story paths and endings. The web is a natural medium for this type of story. I’m hoping that teaching kids how to write hypertext fiction is a natural way to teach them how to create HTML. A major impediment to learning the basics of HTML is all the web publishing cruft:

Text editors Files FTP Hostnames and Hosting

All of this crap is an accident of history and seems like a big stumbling block, before you get to the juicy stuff of HTML, CSS, and JavaScript. The approach I’m taking is to create a web application that paves over these four problems. The student will have create a short page name and then get an edit box. This gives them a body tag and let’s them create from there. Saving the page publishes it. Linking involves using the “short page name” of another page in your HTML code. This workshop is only 2 hours, so I will focus on teaching hypertext fiction basics and the following HTML tags: A, P, UL, and LI. Students will use Sticky Notes and a whiteboard to coordinate the story and page flow. I’ve looked around a little for a web application, but nothing is perfect, so I’ll probably write my own. R.Y.O.H is a clever new project, but doesn’t allow HTML coding and it’s quite a bit different than my wireframes. Wordpress is too distracting. Wikimedia is close but doesn’t allow HTML and I don’t want to just teach wiki markup. Do you know of a good hypertext fiction web tool? I’m creating the curriculum online. I’d love feedback. I’ll post and link to more materials as I create them. Steal my work. Improve it.

Frédéric Wenzel has a great series of L10n blog posts going and there has been a lot of discussion of L20n work at Mozilla. I ping’d Fred to check in and share an idea with him… What if you could directly edit the copy on the staging server of a website and have it transparently save your changes in the background without messing with PO files, SVN access, etc You’d eliminate lots of problems that localizers have… and provide a richer, fun editing environment. Like any idea worth building… I found out it’s already been invented A few months back when I pitched this idea to Stas Malolepszy, he mentioned that Gandalf already thought of the idea and built a prototype. I’m realizing that this has been sitting in my TODO list for too long and I’m better off doing a brain dump in this blog post. Here’s my take on the idea: Design Constraints: Keep po files as the backing store Work as much as possible with existing gettext tools Use direct object manipulation for the UI - pick strings directly from page, see live updates Requirements: Let localizer view a web page and pick a string to translate Display an editor widget that sit on top of or beside the page Display the msgid and msgstr. In practice this is the English String and the Localized version. As they type, redisplay the page with their updated translation Provide a revert button Provide a save button. Save persists this string back to the po file server which commits the change to SVN. PO LiveEdit at 10,000 feet

PO Enhanced HTML – In PHP or other web code, instead of making calls to gettext methods, a set of wrapper methods would be used which add metadata to the HTML output. This would basically add the msgid to a span tag that surrounds the output of the msgstr. This would extra metadata wouldn’t affect the display, but would capture the semantics of a localized string. Old PHP code <p><?= _(‘Be the Difference’); ?></p> outputs <p>Fai la differenza</p> New PHP cde: <p><?= _w(‘Be the Difference’) ?></p> outputs <p><span id=‘md5_58cbc46092296cbe517d748685f52838’>Fai la differenza</span></p> PO Edit Client - This editor would use the msgid or some other token (such as the md5 hash of the msgid) from the enhanced html, to retrieve the information for an individual string and display it for editing. The comments, English translation, and Current localization string would be displayed. The editor would be aware of the current locale which is a page. It would be a live editor where changes would be reflected in the web page as you type. PO Edit Web Service – The server manages the collection of messages.po files for a web application. It’s provides read and write access to the PO Edit Client, one string at a time. It manages commits to SVN and conflict management.  Technology: So three are three components to build… PHP gettext wrapper libraries, which are pretty trivial and produce the enhanced metadata in the HTML, a Server and a Client which lives within the browser. Server Either a stand-alone python server using Stas and Zbigniew’s [https://wiki.mozilla.org/Silme Silme library], or integrated into an existing web based L10n tool like [http://en.wikipedia.org/wiki/Pootle Pootle], it would provide a REST web service for editing po files by locale and msgid. Client The client can be built as either: Pure JavaScript included from the page Addon – Firefox/Fennec Extension Pure JS has the benefit of working with any browser (Safari on iPhone, IE 6 in corporate dungeon, etc). It has the negative affect of introducing L10n only code that you wouldn’t want to push to production. It adds another integration point to every app. The Addon has the benefit of being totally isolated from the specific web application’s codebase, which makes for easier adoption. The client would have the ability to use the PO Edit WS without any same-origin policy limitations. Downsides are that it’s requires Firefox or Fennec and it is an extra step for localizers. Either way, a simple textarea will be a good start for a prototype. Localizers will be loosing any features of their current text editor (say POEdit), but they will gain rich “preview”. For a prototype, the addon route could be built out of an existing extension, such as Jetpack Slidebar or Ubiquity pageLoad command, since it’s a more rapid development env. Considerations: The devil is in the details, here are some design decisions. By default, does this introduce a new requirement for a L10n preview environment? Or is the web application in a testable state?  Adding String Metadata changes the web application and invalidates it for QA, unless you ship this metadata in the production version also. The ’right’ thing to do would be to introduce a localization step into the SDLC, but this might lower adoption. Or you could focus on making the implementation of the String Metadata really light weight, so it would have minimal overhead and not need an additional phase, since it could ship to production and other applications can invent new uses for this metadata. Exposing hard to reach state: Many strings are hidden behind a hard to reach sequence… such as error messages. A common practice in web app development is to expose every part of the app through testing hooks. Many large applications grow these features through time, such as allowing testers special query string parameters for each error condition to simulate the error. Another example is web apps with emails; provide urls so that each email is a click away w/o actually running through the registration process. These kinds of hooks would make translation easier and you’d have to list them somewhere so it’s easy to find them all. These become a requirement for a live web editor, unless you make the user jump through steps to reach all the states of the UI. Out of Scope(?) but on the Radar A real-time synchronization between the client and server would be ideal, so that multiple localizers could see who was editing a string and to reduce conflicts. Mike Morgan and Fred have suggested Bespin which is a freaking awesome idea. Wrapping up If we had a web based live editor for translating sites, this could be a huge win for localizers and the people of earth. Translating a website is one of the most painful and dangerous workflows I’ve seen. You know we have an amazing community, if they are willing to put up with the draconian toolchain we have today. Throwing everything out, is simply not an option, but if we can make a small evolutionary improvement towards a live preview edit workflow which hides revision control systems and text files… There are plenty of sticky corner cases and whiz bang features one can dream up, but I think building a prototype for this is a tractable problem. I did some brainstorming with Fred this morning and he had lots of other cool ideas and good observations on how this would work in practice.

Nothing earth-shattering here… but I wanted to capture some ideas that the webdev team has discussed in terms of how we share our code between projects and with the community at large. Of course 100% of our code is open source, but we want to do a better job of letting others use and contribute to our libraries. Screenshot of a typical project layout A typical project Let’s talk about a theoretical new project foomo which is the code behind Foo.mozilla.org. This project may reuse a couple libraries as well as host it’s own code. Let’s assume this is a project has the layout pictured to the left: In bin we have various Python and shell scripts which are executed via cron or CLI. These scripts depend on the config directory for configuration and the lib for libraries of code. I won’t focus on the bin part of the project, but it could follow the pattern below, but using a Pythonic packaging idiom. Let’s assume that the web directory houses a Kohana PHP project. Under the web/application directory there are typical these project specific directories: config, controllers, helpers, hooks, libraries, models, andviews. In addition to application, Kohana also provides modules and system directories. Let say that foomo project reuses a Mozilla WebDev PHP library barlib library it will be located under modules. system is where Kohana stores it’s framework code that is overridden by modules and application code. But how do we manage foomo and barlib codebases? Version Control The authoritative code repositories for this website would be in atleast two places. If we keep all the code for foomo under one project, say svn.mozilla.org/project/foomo, this makes it easy to deploy and manage. The mainline of application specific code would be changed from here. The second codebase is for the library barlib. The mainline of development would happen on github.com/projects/barlib. Let’s look at the source code layout of foomo and barlib to see how they relate. foomo's module directory contains barlib barlib's project layout So foomo’s web/modules/barlib on the left is a subset of barlib’s development tree on the right. A read only copy of this dist directory, heck even just a tarball distribution of it, comes from github and lands in foomo’s web/modules/barlib. As we want to enhace barlib, we work in that codebase on the right. barlib is it’s own project, so development includes running it’s tests, etc and then creating a release version to be imported back into foomo, on the left, as needed. Keeping the official repository for reusable libraries separate introduces some disadvantages, but is worth it. Disadvantages:

More complexity and administrative overhead Requires more discipline You have to manage dependencies between libraries and apps Increases development costs

Advantages:

Encourages Reuse Removes barriers for community contribution Makes QAing and releasing components possible

All Growed Up As code in foomo solidifies or another project wants to use chunks outside of just foomo, the various pieces of code can be pulled out into a module and moved from web/application to web/modules/<library name>. We’ll have to re-QA foomo after this code extraction, but we will gain the benefit of reduced development on the second project and anyone who needs it won’t have to pick through foomo internals to copy and paste the tasty chunks. If the second project is a CakePHP project, then all it will need to do is write CakePHP wrappers analogous to the very this Kohana specific layer of barlib. Everything Cannot Be Reused Not ever line of code can be reused. A lot of web development is about crafting a very specific solution. Localization, error handling, and coding conventions introduce challenges. That said, we should spend the extra time it takes to publish and integrate dynamite WebDev libraries.

I’ve posted in detail on the webdev blog about a project I’ve spent the last several weeks working on – the Mozilla Service Week website. It’ been a lot of fun with a great team and it was my first project at Mozilla that had marketing and QA. Please check it out and get involved with volunteering today. We had a brownbag lunch with Computer Technology Network today which was very timely. You can see the mozservice09 promo badge to the right and I’m also rock’n the persona on my browser.

Marketing's blog post on the Mozilla Service Week site.

Jetpack is a newly formed initiative and experiment in using open Web technologies to enhance the browser, with the goal of allowing anyone who can build a Web site to participate in making the Web a better place to work, communicate and play.

As with all Labs experiments, Jetpack is an open source project and everyone is welcome to participate in its design, development and testing.

Gecko 1.9.1 added support for several Mozilla-specific DOM events used to handle mouse gestures. These are special movements that can be made with a mouse or trackpad and can be interpreted to perform specific tasks.

Since MOBhat has so many steps to get setup, a Troubleshooting page would be helpful. The first common issue is people skipping the Ubiquity install step, completing the rest of the steps and then getting stuck or confused. I’m using Ubiquity behind the scenes, so it’s optional for the user to use the command line. Since I don’t have them invoke it, or describe it in detail, it’s an easy step to skip. The Troubleshoot link above detects if you’ve installed the MOBhat command feed. If not it displays an error and gives instructions. If Ubiquity had a <noscript> like mechanism, then I could detect if Ubiquity wasn’t installed earlier. View the HTML source of the page, the technique might be useful on your command feed pages. If so just add a pageLoad command like this to your command feed:

function pageLoad_detectNoUbiquity(){ var doc = Application.activeWindow.activeTab.document; var url = doc.location.href; var troubleshoot = "http://mobhat.restservice.org/welcome/troubleshoot"; if (url == troubleshoot) { jQuery('.no-ubiquity', Application.activeWindow.activeTab.document).hide(); jQuery('.ubiquity', Application.activeWindow.activeTab.document).show(); } }

A simple well executed "Share This" widget.

Wow, It’s been six months since I joined Mozilla. I’m super happy with the work, the team(s), and being closer to the Mozilla community. Working remotely hasn’t been an issue, I think for two reasons: Most of the webdev team is remote and Mozilla has been doing remote development for a looong time. But being remote does mean that many people only know you through a textual nickname. When I’m messing around with Ubiquity, ServerJS, or SocialActions communities, it’s a grey area whether I’m wearing my Mozilla hat or my Ozten hat. So that’s why I’m am Changing My Nick I’ll be logging into IRC as ozten instead of aking from now on. At the risk of confusing people, I think it’s worth it in the long haul♦. I am already ozten on some of the many Mozilla community user databases and it’s the nickname I use across the net. I’ll be updating my bugzilla email address to ozten.bugs (from mozilla.bugs.aking which was overkill anyways, but proves that I’ve hacked Java before). ♦ I don’t want to pull a make, where Dr. Feldman decided not to fix the whitespace issues of Makefiles, for fear of breaking his “dozens of users”. Goings On What have I been doing? Well not blogging on my personal site much… but that will change. No really, promise
Socorro Icon I’ve been working on:

Socorro UI - Mozilla’s crash reporting system, we’ve done several pushes

Prior Art - A repository for you to record facts about software that is useful for patent research, defending against bogus patent claims, etc. think wikipedia + creative commons for developers and lawyers. This is going into alpha and we are looking for partnerships with organizations with lots o’prior art already collected to seed the database.

Community Take Action Week - I’ve just started my first end to end project with marketing and QA around building a mini-site to promote volunteering and organizations that need tech help from the Mozilla community

CTAW Remote Bunker Outside of Work

I am also working on the last phase of my school / personal project. It will be launching soon, so stay tuned. It’s an experiment in adding “facets” to your “Lifestream”. It builds on top of Ubiquity and Firefox. I’ve help craft a UW extension program Foundations in Professional Software Development

Oh ya, and we’re remodeling our bathroom. So the last 6 months pretty much flew past. What’s it like inside the red beast? Your soaking in it — Madge

So although I work for Mozilla Corporation, which is housed within the Mozilla Foundation and the larger Mozilla community, very little of what we do is Sekrit Corporation info. Everything I write is checked into public code repositories. Our Wiki, Bugzilla, and IRC communications are open for you. In the first couple of months I was amazed to see that the ship really is steered by the community and an overriding vision to keep the web open to anyone. I’d have to say that the it’s part web developer and part public servant. This is a really great, and at times, a difficult thing, like any public service job. I hate to use the term community so many times in this post, but I think I’m learning a lot about the concept in action. Although I am young in my days at Mozilla, I feel like I made the right decision coming to work here. Here’s to the next 180 days!

Hello! We are mySociety – we run most of the UK’s best known democracy websites.

Using our services, 200,000 people have written to their MP for the first time, over 8,000 potholes and other broken things have been fixed, nearly 9,000,000 signatures have been left on petitions to the Prime Minister, and at least 77 tiny hats have been knitted for charity.

Bespin is the newest Mozilla labs project. It's aims to be a self hosted open web editor and is pretty freaking awesome.

FUEL is a JavaScript Library designed to help developers build extensions using terminology and interfaces that are familiar to them. FUEL is new in Firefox 3.

FUEL is about making it easier for extension developers to be productive, by minimizing some of the XPCOM formality and adding some "modern" JavaScript ideas. We want to start with areas that will provide the most benefit.

What I have been up to in Dec besides eating, visiting, and drinking

via Ethan, artzilla highlights browser based art. Horribly good aesthetic via myspace generation.

Linux Defenders and Defensive Publicaitons

oztenphoto

oztenphoto

Awesome! Just installed the first alpha release of Mozilla's mobile web browser. Some interesting UI tricks for small devices where you call "pull" the edge of the screen to revel chrome. Installable on desktop computeres even though it is targeted at the Nokia internet tablet and future phones. I was excited that they picked a snow owl or some kind of owl for this project but it turns out that Fennec is a Desert Fox.