Thanks for the Bespin contributions; Eclipse, XWiki, and more

Chris Beard

4 responses

There’s nothing that humbles you quite like when you see people build on your work. Although a week hasn’t gone by since we introduced the Bespin project to the wider community, we have already seen contributions that have gone beyond our expectations.

Boris Bokowski, of the Eclipse community says it best:

Within a few days, 30,000 people logged into their public server, 400 people joined their discussion group, about 50 bugs were filed, several of them with patches, and many articles, blogs and even a Wikipedia entry were written.

We wanted to highlight Boris himself. Along with Simon Kaegi, he managed to accomplish something we think is very cool indeed, and all in a couple of days. He took Eclipse and paired it with Bespin. What does that mean? He took a headless Eclipse, implemented the Bespin Server API and went above and beyond the API to get data from Eclipse back to Bespin.

Take a look at the integration in action:

bespin-eclipse

Here Eclipse is sending back errors and warnings about the Java source file being edited. This is great news for Java fans and beyond (as Eclipse supports many languages and platforms these days).

Then we have Jerome Velociter who kindly spent his Saturday integrating Bespin with the open source XWiki project. He added an “Edit with Bespin” button on Wiki pages, and then when you are done and save, it goes back to XWiki.

Both the XWiki and Eclipse work is exactly the kind of thing we were hoping for with the Bespin project. Having just enough code out there for us all to collaborate, but not too much of a formed product that has anything set in stone.

We also want to thank the other contributors that have been hanging out on irc, emailing the newsgroup, filing bugs and ideas, and of course contributing code.

We have been hard at work getting more and more information out there, from roadmaps to known issues to help on how to contribute code. We don’t just want the coding to be done in the open. We want the entire discussion to be open, and this will of course include design decisions, so expect to see design documents on the Wiki as key features come up in the community. The goal is for this project to be your editor.

— Dion Almaer, on behalf of the Bespin development team

Ubiquity 0.1.6 and Release Scheduling

Chris Beard

As we’ve mentioned before, Ubiquity 0.2 has fairly broad, visionary goals that won’t be fully satisfied for some time. So we’re going to be pushing its changes to the 0.1 line at more regular intervals as we continue to develop it.

By “pushing its changes” we mean that we’ll effectively be disguising our work-in-progress 0.2 as a 0.1.x release. For instance, Ubiquity 0.1.5, which we released about a month ago, is essentially the same thing as 0.2pre7; similarly, Ubiquity 0.1.6 will basically be the same thing as 0.2pre13, only with our more experimental features—such as locked-down feeds and python feeds—disabled by default and unadvertised on Ubiquity’s front page.

There’s a couple reasons for this:

  • Ensuring that the general public is using the same codebase as testers and developers means that our code gets to be used by “the real world” more quickly, and means we’ll know about bugs closer to the time that they were introduced into the software.
  • Releasing new public updates at a regular interval is a direct way of letting our users know that Ubiquity is still alive and kicking, and getting better all the time.
  • We can get feedback from the broad public more quickly, so that if we’re really going the wrong direction with something, we can know about it before we’ve invested too much time and effort into it.

So we’re aiming to release a new public update to Ubiquity at least once every two weeks.

Things you can do to help

Ubiquity is a community effort, and we welcome contributions!

  • Testing. Please try out the release candidate and bang on it! Try it out on every operating system that’s convenient for you to try it out on, and on every version of Firefox too (3.0, 3.1 beta, or 3.2 alpha). Any comments to this post about where it works or doesn’t will be very appreciated.
  • Release Notes Documentation. The 0.1.6 release notes can always use more help; please feel free to edit that page and fix a TODO if you enjoy technical writing, and leave a comment here or on IRC if you have any questions. Keep in mind that the wiki tracks all changes, so even if you mess up, we can always revert the changes. Experimentation is good!
  • Ubiquity Tutorial Documentation/Testing. Feel free to try out the user tutorial or the author tutorial with the release candidate and make sure everything still works. Regardless of the outcome, post back here to let us know what you found!

Thanks for reading this. If you have any questions, please don’t hesitate to reply to this post or poke us on #ubiquity on irc.mozilla.org.

This post was originally posted on Atul’s blog at toolness.com. If you have any comments on it, please leave them on the original post.

Mozilla Labs Meetup – Thursday 2/26

Chris Beard

3 responses

It’s time once again for Labs Night, our monthly meetup to discuss Labs projects, your projects, and the Open Web. Our February session will be next Thursday, 2/26, 6pm at Mozilla’s office – 1981 Landings Drive, bldg K in Mountain View, California.

We are excited to welcome Edwin Khodabakchian, developer of Feedly, a Firefox extension which weaves twitter and Google Reader into a magazine like experience. Edwin will be giving an overview of Feedly Streets, a integration framework/micro service bus they have built inside Firefox to simplify the development and maintenance of real-time mashups. He will be discussing some of the key Streets concepts, as well as the list of integrated services – Google Reader, search, Gmail, twitter, etc. Edwin will also be talking about how Streets can simplify the development of Ubiquity commands.

As always, we will hear progress updates on various active Labs projects and would love to hear from you! Get involved with a Labs project. Get feedback on your own projects. There will be plenty of opportunity for discussion and hacking. And of course, pizza 🙂

If you are in the Bay Area we’d love to see you next week!  Please RSVP here so we know how many to expect. And starting this month – Labs Night London! If you are in London, please check out the first Labs Night across the pond. Folks will be meeting from 10:30am – 12:30 at Waterstones Piccadilly. Get more details and RSVP here.

Redesigning the Labs website: we need you

Chris Beard

11 responses

Mozilla Labs was created to give the community a safe and welcoming place to develop, research, talk about, and play with new and crazy ideas. Labs is all about creativity, community, experimentation and collaboration, and we’re striving to build a world-class showcase of open innovation for the Web.

Since its inception, Labs has helped further establish Mozilla as a leading source of Web innovation, and now it’s time to step it up to the next level. As a growing community, we’ve started dozens of experiments since Labs first came together, but we want to start thousands. We’ve grown to thousands of participants, but we’d like to welcome tens of thousands more.

Thousands of ideas, projects, and experiments being developed and refined by a community over a hundred thousand strong. We know what an ambitious vision this is, but we also know that it is both vital, and possible.

To achieve this, Labs must undergo a major evolution of its own, and one of the first projects we’re undertaking is to rethink, redesign, and redeploy the Labs website. In the grand Labs tradition, we’ll be doing this in an open, incremental, and experimental fashion. We’ll be playing with new ideas and tools, keeping what works, throwing away what doesn’t, and iterating on what’s promising.

And we need your help.

Just as Labs works to harness the intelligence and creativity of its community towards developing new technologies and ideas, we want to harness that incredible creative power to create a virtual space that will support the goals we hope to achieve over the next year.

What does a site look like that helps us generate thousands of ideas, and supports projects created by a community numbering tens of thousands? How would you build it? What tools should it include? How can it encourage the growth of such a strong and vibrant community?

We’ve already started thinking about and playing with some ideas and possible tools, but it’s all fairly rough since we’re still very early on in the process. You can check out what we’ve got written up so far over on the Mozilla Wiki.

The web needs to evolve. Mozilla has always believed that evolution happens most effectively when it happens in the open, and when everyone is welcome and able to participate. This is what Mozilla Labs exists to achieve, but we need your help, your ideas, and your participation.

Don’t feel like you can’t participate until you’ve answered every question here. Labs isn’t about polish. If you could make one suggestion right now, what would it be? You can leave a comment here, or in the Labs forum, or email me privately. I’m really excited about this project, and to hear how you can help us build an even more generative, open, and community-based Labs website.

— Deb Richardson, on behalf of the Mozilla Labs team

Introducing Bespin

Chris Beard

91 responses

As we strive to evolve the Open Web as a robust platform for application development, we believe in the potential for web-based code editors to increase developer productivity, enable compelling user experiences, and promote the use of open standards.

Today we’re launching Bespin as a project within our Developer Tools Lab to focus on this exploration.

Just as Mozilla enables massive innovation by making Firefox open on many levels, we hope to do the same with Bespin by developing an extensible framework for Open Web development. We’re particularly excited by the prospect of empowering Web developers to hack on the editor itself and make it their own.

Overview

Bespin proposes an open extensible web-based framework for code editing that aims to increase developer productivity, enable compelling user experiences, and promote the use of open standards.

Based upon discussions with hundreds of developers, and our own experience developing for the Open Web, we’ve come up with a proposed set of features along with some high-level goals:

  • Ease of Use — the editor experience should not be intimidating and should facilitate quickly getting straight into the code
  • Real-time Collaboration — sharing live coding sessions with colleagues should be easy and collaboratively coding with one or more partners should Just Work
  • Integrated Command-Line — tools like vi and Emacs have demonstrated the power of integrating command-lines into editors; Bespin needs one, too
  • Extensible and Self-Hosted — the interface and capabilities of Bespin should be highly extensible and easily accessible to users through Ubiquity-like commands or via the plug-in API
  • Wicked Fast — the editor is just a toy unless it stays smooth and responsive editing files of very large sizes
  • Accessible from Anywhere — the code editor should work from anywhere, and from any device, using any modern standards-compliant browser


View Introduction to Bespin

The Initial Prototype

As part of this announcement, we’re also releasing an early experimental prototype to demonstrate some of the concepts of Bespin and the possibilities that it opens up.

Bespin 0.1

  • Initial prototype framework that includes support for basic editing features, such as syntax highlighting, large file sizes, undo/redo, previewing files in the browser, importing/exporting projects, etc.

webkit-editor-medium

Bespin 0.1 Running in Firefox 3.0

Screenshots of Bespin 0.1 running in modern, standards-compliant browsers

All of the source code underlying the Bespin experiment is being released as open source software under the the MPL.

Get Involved

Mozilla Labs is a virtual lab where people come together online to create, experiment and play with Web innovations for the public benefit. The Bespin experiment is still in its infancy and just getting started. There are many ways to join the team and get involved:

— Ben Galbraith and Dion Almaer, on behalf of the Bespin development team

Ubiquity’s Python Feed Plugin

Chris Beard

A few weeks ago I wrote about Ubiquity Feed Plugins, which are basically just a way of separating the user interface of subscribing to a new feature from the implementation of the feature itself.

As I’ve written about before, one of the things I’ve missed about the Mozilla development environment is its support for the Python programming language. Aside from being humane and having a great community, it has functionality that could complement the Mozilla platform quite nicely. So we’ve whipped up a quick proof-of-concept Python Feed Plugin for Ubiquity to explore this possibility.

Here’s a really simple command feed written in Python:

def cmd_sample_python_command(ubiquity):
    ubiquity.displayMessage('Hello from Python %s.' % sys.version)

cmd_sample_python_command.preview = 'a sample python command!'

For anyone who knows Python and has read the Ubiquity Author Tutorial, this should be fairly self-explanatory. The ubiquity argument is just passed in to the command execution function to make unit testing as easy as possible.

As with any Ubiquity feed, the file containing the above code needs to be referenced in the <HEAD> element of a web page:

<LINK REL="python-commands" HREF="sample_command.py">

In this case the python-commands value of the REL attribute is what tells Ubiquity to process this feed using the Python feed plugin.

Visiting the web page containing this tag results in the same subscripton panel that shows up with any page that has a Ubiquity command feed. Because Python code executes at the same privilege level as default Ubiquity feeds, the Python feed plugin really ought to display the same warning page that default Ubiquity feeds show when the user clicks “Subscribe”; but because this is just a proof of concept, we skipped that implementation and currently only allow Python feeds to be used when they already exist on the user’s local filesystem—in other words, when the feed is at a file: URL.

The first time an end-user subscribes to a Python command feed, they’re presented with this non-intrusive message:

What happens behind-the-scenes is a bit more complex: Ubiquity uses virtualenv to bootstrap a sandboxed Python virtual environment inside the user’s profile directory. It then uses easy_install to install jsbridge, and then sets up a “feed server” process on the user’s system, which Ubiquity communicates with over jsbridge to execute Python code:

Pretty Frankenstein, but it works on OS X and Linux. Because Windows doesn’t come with Python built-in like the other two operating systems do, we’ll have to bootstrap it first, which we haven’t gotten around to yet.

So, if you’ve got OS X or Linux and like Python, feel free to play around with this; a sample Python command feed is included with the latest Ubiquity beta. If this is something that seems interesting to you, we’d love to know—you’re welcome to leave a comment on this post, drop us a line on the ubiquity-firefox Google Group, or say hello on #ubiquity on irc.mozilla.org.

This post was originally posted on Atul’s blog at toolness.com. If you have any comments on it, please leave them on the original post.

Concept Series: Phones and OSs

Chris Beard

6 responses

Since the launch of the Mozilla Labs’ Concept Series, we’ve had hundreds of people join in a shared exploration of design directions for Firefox, the Mozilla project, and the Web as a whole.

Responding to the call for participation, Billy May has been taking a look at what a phone might look like in this context. What would the ultimate web phone look like? What would give it Mozilla DNA? He’s put up an interesting throw-away “Open Web Concept Phone” as a Blackberry meets interactive OLED keyboard.


Open Web Concept Phone by Billy May

In a similar vein, Adaptive Path’s contribution to the Concept Series, Aurora, explores what a Mozilla phone and OS might look like; taking the concept of Mozilla Lab’s Weave to the extreme, letting the Web be the unifying agent between computer, mobile, and wall-sized interactions.

Aurora Concept by Adaptive Path

While Mozilla doesn’t have plans to produce an OS or phone hardware at the moment — this doesn’t mean that either are out of scope for Mozilla Labs and that’s the point of the Concept Series. Everything is on the table.

This is just the start and we’re excited to be working with people from around the world in a shared exploration of new ideas.

Weave Client API Documentation

Chris Beard

We talk a lot about Ubiquity being easy to extend, what with the ease of writing your own commands and so on. But did you know that Weave is also built to be extended?

Weave isn’t limited to just syncing those types of data — cookies, history, tabs, etc. — which have support built-in. It has a client API which allows new sync engines to be written and plugged in. A sync engine implements some logic for reading, writing, and updating a data type; the Weave core handles the networking, encryption, and synchronization algorithm.

We’ve recently written up a Wiki page of Weave client API documentation, which explains how to write and install a new sync engine. We hope that having this API documented will inspire the community to experiment with extending Weave to synchronize new data types.

Ubiquity Parser Documentation

Chris Beard

We’ve just added a page of documentation about the Ubiquity parser to the Mozilla wiki. It explains the algorithms used, with lots of examples and links to particular functions in the source code. It will be of interest to anyone who wants to hack on the command-line interface of Ubiquity, to try out new features or to make the parser smarter.

There are still a few TODOs where we need to fill in some details, but we hope what’s there will be useful to someone. Let us know if there’s a particular feature/class/function that you’d like to see further documented or explained.

Labs Update – January 2009

Chris Beard

5 responses

aboutlabs_newsletter_masthead

January 2009

Concept Series

Design Challenge

This month we announced the first of a series of Design Challenges. We’re inviting design-focused students from around the world to develop new ideas & prototypes for the future of the Web. Learn more

Design Review

Alex Faaborg and Aza Raskin posted another edition of their Design Review podcast.

Concepts of the Month

  • Liyan Chang from MIT explores several interesting concepts for improving the Firefox UI in this short concept video.

  • Maureen Hanratty and Ian Tadashi Moore from UMich have created Arclight, a Flash animation that proposes a UI for a touch-screen kitchen table.

Honorable Mentions

Useful, interesting or cool sites that we’ve come across this month.

  • iPlotz – A useful tool for creating mockups and wireframes.
  • Twiddla – A web-based meeting space with team whiteboarding and the ability to mark up websites, graphics, and photos.
  • idealist – A site for creators and designers to post their ideas and gather community feedback.

Experiments

Personas

Suneel Gupta provides an update on Personas.

Prism

Work continues on the plan to uplift a Prism-like feature into a future version of Firefox. You can follow the early specification work on the Mozilla Wiki.

The Prism experiment and platform itself will continue in its exploration independent of this effort. If you’re new to the concept of site-specific browsers, be sure to check out the Prism for Firefox add-on.

Snowl

Myk Melez provides an update on Snowl.

Ubiquity

Jono DiCarlo posted a series of blog posts exploring a new approach to verbs in Ubiquity, culminating in a proposal for new Overlord Verbs.

Blair McBride put together a high-level look at information storage in Ubiquity.

There is also now a Ubiquity command development tutorial.

Weave

Work progresses toward the 0.3 major update with full support for Fennec. Account registration has re-opened and you can now sign up for a Weave account at https://services.mozilla.com.

Jono provides an update on what’s up with Weave and the changes coming in Ubiquity with the proposed introduction of Overlord Verbs.