NatanYellin.com

As promised, here are the completed slides from my presentation at the GNOME Summit. Alternatively, you can view the slides online via Slideshare.

At the GNOME Summit, Owen suggested the following:

When trying to decide on a language for applets/widgets, just about everyone will suggest their own favorite language along with reasons why that language is appropriate. However, one thing that needs to be considered is choosing nobody’s favorite language- Javascript.

Owen, I see your point but have to disagree. One of the key purposes of an applet/widget framework should be to allow new and inexperienced developers to easily write their first GNOME application with the smallest learning curve possible. Because of all the people familiar with it, Javascript is an appropriate language, but so are Python and C#.

Before I focus on the advantages of using multiple languages for applet development, I’d like to review a few of the key philosophies that drive GNOME Development:

1. Software should be easy and simple to use for new users.
2. Software shouldn’t have a large learning curve.
3. Different pieces of software for the same platform should use consistent interface elements and share design decisions. Users shouldn’t need to learn new skills in order to use new applications.

When these same philosophies are applied to development and placed in a GNOME specific context their implications are:

1. There should be GNOME frameworks that allow developers to easily write applications, even if they have no prior experience with GNOME.
2. Developers shouldn’t have to learn many new skills in order to develop their first GNOME application. When possible, they should be able to use their existing knowledge from other platforms.
3. Different pieces of software for the same platform should use the same technologies. A developer working on one GNOME application should be able to quickly jump in and contribute to a fellow GNOME developer’s application without needing to learn anything new.

The implications of 2 and 3 are problematic and contradictory. If we allow developers to jump into GNOME Development using all of their existing skills (including intimate knowledge of languages and toolkits), how can we still create a united platform that uses one set of standard and familiar GNOME technologies? More importantly, how can we create a platform with an interface that’s consistent for users?

The solution that’s been followed for the past 11 years is a simple one- Wherever giving developers extra freedom will not hurt the user experience, freedom should be given. In other words, development in multiple languages is fine, but using multiple toolkits is not fine.

This strategy has worked amazingly well. There are a wealth of applications that have been written in C, C++, Python, Mono, and a few other languages. If GNOME had begun with an ironset rule that applications may only be developed in C, we would still be in the dark ages of desktop development with all development done by a few hardcore C junkies. Heck, even if applications were allowed to be written in one “high level” language like Perl- or even the fledgling Python of 1997, for that matter- we would still never be where we are today. All of the goodness that has come out of Mono- and most likely everything that uses pygtk, as well- would have been lost in the curves and twists of a what-if history of GNOME.

The reason GNOME is so diverse and powerful today is because of it’s flexibility with regard to languages and even technologies. We’ve always embraced the new and hot, most recently with Clutter. We’ve also always allowed developers to use as many of their existing coding skills as possible. We’ve taken in developers from just about everywhere- Windows, Mac OS X, the Web, etc- and they‘re the reason that GNOME rocks so much today.

Owen, I’d love to support simplified Javascript applets/widgets, but I can’t imagine doing so without still supporting other types of widgets. There are no statistics regarding how many developers come to GNOME from other platforms, and whether most of them come from web development or desktop development. The one fact is that we do have developers from both ends of the spectrum, and our job is to get as many of them as possible involved with GNOME development. A framework that will alienate half- or even a quarter- of them is not the right answer.

I’m blogging from the GNOME Boston Summit. There are some neat projects being demoed, but more on that in later posts.

I just gave a last minute lightning talk on the problems with GNOME for people who want to begin developing. It went extremely well, and we’re hoping to have a full break-out session later.

I’ll upload the slides later, but the quick summary is that no one who tries to begin developing for GNOME actually succeeds unless they have prior knowledge.

Yeah, it’s really that bad.

There have been a lot of neat discussions going on at the GUI hackfest over the past few days. A lot of it is now available on the wiki, so be sure to check it out.

Following the trend:

I’m at the airport waiting for my flight to New York and then Boston. I’ve already been through airport security and got questioned on the names of my siblings, language, school, etc. etc. and in only another few hours, I’ll be attending the GNOME User Experience Hackfest- my first open source event of any kind.

The hackfest was arranged by Owen, Federico, and Vincent and will be taking place at the Novell/Ximian office in Cambridge. The goal, as Owen and Vincent explained, is to come up with polished ideas that will drive GNOME desktop development for the next two years. There’ll be discussions on a whole range of topics from applet frameworks to semantic desktops to eyecandy and usability and everyone is encouraged to suggest other new ideas.

Following the hackfest, I should be able to attend at least two days of the GNOME Boston Summit. This will also be a first for me, and I’m excited about the possibility to meet even more people that I’ve only met online until now.

It’s almost time for boarding and I’d like to get a quick bite to eat, so I’m going to end here. Based on the list of hackfest and summit attendees, I’m certain that excited and perhaps only half-comprehensible updates will follow over the next few days as ideas form and contagious excitement catches on. Even if you’re not attending the hackfest, be sure to follow GNOME Planet and let us know what you think.

Quick note to everyone attending the GNOME Boston events: After working things out with both the Foundation and school, I finally booked my tickets and I’m also going to be able to attend the summit following the hackfest.

There’s been some discussion lately on the Ubuntu Art mailing list about a new icon set. The icons themselves are spiffy, but what caught my attention is that some of the mockups went beyond the traditional icon metaphor. Take this mockup that Thorwil presented in a recent blog post:

The mockup puts aside the traditional view that folders are interesting things and of themselves and instead focuses on the contents of the folder.

How much farther can we take this? Folders that tell the user what’s inside of them? File managers with Google Maps-style zooming interfaces that let you zoom in and out on your content? Why not? Once you’re willing to abandon the “a folder icon should look like a folder” attitude then the possibilities are endless.

Now, I’m not claiming that all that will make the user’s life easier. However, there is room for improving interfaces by playing with traditional metaphors and improving them without scaring the user away.

Here’s the mockup I promised. There’s a copy without notes below.

I’ve been invited to the GNOME User Experience Hackfest in Boston, and I’m going! (Thanks to the GNOME foundation who offered to cover the expenses.)

One of the main topics of the hackfest is collaboration throughout the desktop. Universal Applets 0.1 should be out by the time that the hackfest begins, so it’ll be a good opportunity to get some feedback and share ideas with the rest of the community.

Anyway, thank you again to the GNOME foundation for making this possible! I’ll see some of you in Boston!

You’ll need at least Universal Applets revision 495, but developers can now add image-menus to their own screenlets with only a few lines of code.

It’s still buggy and missing a lot of features, but as of revision 469 check out the following:

$ melange --replace &
$ /usr/local/share/screenlets/SidebarUA/SidebarScreenlet.py &

$ /usr/local/share/screenlets/Meter/MeterScreenlet.py --server=Sidebar
$ /usr/local/share/screenlets/DigiClock/DigiClockScreenlet.py --server=Sidebar

Also, drop me a comment if you know of any out-of-branch screenlets whose authors haven’t been contacted yet.