Let us start with a screenshot from a well-known tech news site. Don’t click the Digg button — even though I know you want to — it won’t do anything:

So, what’s going on here? It’s quite obvious that:

• The current way multiple pages are handled in browsers isn’t doing its job well enough, at least not for the advanced users.
• There seems to be no one-size-fits-all when it comes to having multiple pages open at once, and an astounding number of add-ons to modify tab behavior.

When tabs first started appearing in browsers — Opera and Firefox being the ones at the forefront — the web (and computers!) were in a very different state than now. People were exceptionally happy to be able to have 6-7 pages open at the same time, and using only one window to do it.

Fast-forward to 2009, and a lot of users are pushing the limits of what browsers can handle with regards to how many pages they have open at once. There are significant memory and CPU costs to this new-found power — but nowhere is the problem more apparent than in the user interface. Different browsers deal with a large amount of tabs in various ways, from allowing multiple rows of tabs (Opera), to having pulldowns that list all available open tabs (Firefox, Safari). None of these approaches work that well, which is why Mozilla has been looking at alternative approaches to manage multiple pages for a while now.

Table of contents

Since this is a long post, here are some section links if you want to link to specific sections from your own content:

• If it ain't broke, don’t fix it
• Existing approaches
• A note about instrumentation
• Proposal: Some exploratory steps for Firefox
• For novice/intermediate users: Thumbnails reloaded
• For power users: Quicksilver, meet Firefox
• Testing the Power User UI, today
• Combinatorics
• How to participate in the discussion

If it ain’t broke, don’t fix it

We realize that tabs were the reason a lot of people switched to Firefox in the first place. The first thing people say when we indicate that we are looking into alternative approaches is usually “But I like my tabs. Please don’t take away my tabs!”

So, let us just state for the record: We don’t see tabs going away for a long time yet. They will be around in a form similar to the current one, because tabs work really, really well for most people. The large majority of users have no problem with tabs, and they are a very natural and elegant solution to the problem as long as you don’t push them too far.

What we do want, however — is to find a better solution for the users out there that are currently frustrated and unhappy about using tabs to manage a lot of pages. For the tabs case, let’s establish some very broad categories of users for the sake of this discussion:

Novice users

These are the users that currently don’t use tabs at all. These people are like my grandma — although a tech-savvy grandma, she only visits 4-5 sites, and has no use for tabs.

Intermediate users

These people are the users who are currently happy with the way tabs work. They typically work with 5-10 tabs open.

Power users

These users have a lot of tabs open — everyone has this friend that has over 100 tabs open in his browser, and never closes any page — she just forks off a new tab instead. Or maybe you are that friend.

Pardon the unimaginative names for these categories. They used to have more colorful ones, but then people would say “But my grandma…” — they just exist to frame the discussion.

Existing approaches

Of course — as the screenshot above told you — there is no lack of effort to try to make the situation around tabs better. Even Mozilla Labs is currently hosting their Summer ’09 Design Challenge: Reinventing Tabs in the Browser — and the previous Spring ’09 Design Challenge asked people to envision how browsing would look like with as minimalist a user interface as possible.

One of the add-ons for Firefox that has seen quite some uptake among power users lately is the Tree Style Tab add-on.

The reasons for its popularity are easy to understand, it fits the power user’s needs well:

• It lays out the tabs in a vertical fashion as a sidebar instead of horizontal, thereby maximizing the possible amount of visible tabs.
• It makes use of the horizontal space that more and more users have available due to the widescreen monitors now being the dominant standard for new screens. (Widescreen monitor shipments surpassed standard aspect ones in Q1 2006 for notebooks, for instance)
• It automatically groups the tabs based on where they came from, e.g. if you spun off a new tab from a Google search, it would become a nested tab like the Apple tab in the screenshot above. Currently, people use different windows, or colors, to group related tabs in other browsers — and use tab drag/drop between windows to accomplish the grouping they want. This solution is much more elegant.
• It makes it easy to navigate more tabs than will fit on the screen with a close-to-zero effort gesture: using the scroll wheel.

Another noteworthy approach is the way the SafariStand add-on for Safari handles tabs.

Some of the things SafariStand gets right are:

• Same as with the Tree Style Tabs plugin: It makes it easy to browse a lot of tabs, since you can use the scroll wheel if you have more tabs than will fit on the screen.
• Tabs are very visual, and easy to recognize.
• Tabs have a large click target.
• Most importantly, SafariStand has what we here at Mozilla refer to as partial thumbnails.

A full thumbnail screenshot of a page is not really useful in identifying the page, especially if the page is mostly text. By taking a screenshot of the upper left corner of the page (enough to grab the logo + some of the page title), a partial thumbnail becomes dramatically more useful in identifying the page you’re looking for. In the screenshot above, the Wikipedia page on “User Interface” is recognizable even if you had three other Wikipedia pages open.

To illustrate what the previous approaches get right, let’s look at what the Opera 10 beta does. It includes a similar way to view tabs, but there are a number of issues with this implementation compared to the others:

• Here you see a good illustration of why full-page thumbnails are less usable: The Wikipedia page couldn’t be distinguished from a different Wikipedia page in thumbnail form.
• By putting the thumbnails on top instead of on the side, they steal a lot of space from the content area — you already want to have the top part of the window be as slim as possible, which is why Chrome and — until recently — Safari 4 went to such lengths to use the window border for additional tab space: it gives you more space for the web page.
• One thing that can’t be seen here: If you add a lot of tabs, the thumbnails shrink their width to become unusable as a visual aid for finding the tab you’re looking for.
• Even if this implementation allowed you to scroll sideways by using the mouse wheel — instead of letting the thumbnails become 2 pixels wide when you have 40 tabs open — it wouldn’t have been something a lot of people would even try. Using the vertical scroll wheel to scroll horizontally?

As you can see, Opera tries a similar approach as a couple of the add-ons that already exist, but unfortunately missed out on a lot of the smaller details which make these add-ons work well.

And for the record — I’m a big fan of Opera, and have been for many years. One of my close friends even worked as their lead UI designer until recently. So I’m not picking on Opera here, it was just a great illustration for this discussion.

A note about instrumentation

Before we move on to some of the things we want to explore, a quick note on the research and statistics side of this:

Dealing with tabs is a case where more data on usage patterns would be very helpful. Luckily, the Test Pilot instrumentation project from Mozilla Labs is moving ahead with the aim of letting us instrument the browser to get some real numbers on how people use Firefox.

Using this tool, we could poll for useful numbers — like what the tab distribution is among our test pilot users: how many people use 2-5 tabs, 10-20 tabs, 50+ tabs, etc. I’m pretty convinced that not a lot of users have more than 5-10 tabs open — but of course the ones that have 50+ tabs are really the power users that switched to Firefox in the first place, and we should make them productive.

You can actually graph your own tab usage over time using the Tab Grapher, which is an add-on for Jetpack. So if you want to see where you fit on the scale of tab usage, running this extension could be an interesting way to find out.

Data is always good, and we’re looking forward to get a lot more of it in the near future, making it possible for all users to help us make Firefox better.

Proposal: Some exploratory steps for Firefox

As mentioned earlier, there is no obvious approach that will solve the shortcomings of tabs for every type of user. What we should do, is allow you to choose what type of handling you prefer, and seamlessly move between them — and/or providing natural transition points as detailed below.

Also, keep in mind that this is a smaller part of a much bigger picture that we will detail over the coming months when we start winding up for Firefox.next, now that version 3.5 is close to shipping. There’s much more to this proposal than is apparent from this first post.

For novice/intermediate users: Thumbnails reloaded

If the existing tabs interface works so well for the intermediate users, why should we even look into changing it? The main reason is that the people that fall into this midway classification are getting more and more demanding as users. They start using more tabs, and suddenly over half of them are in territory that we just a few years back defined as power users.

This means that we need a more graceful way to let tabs scale — or at the very least give people the option to opt into an interface like this, and make it as seamless as possible.

The ideal novice ⟷ intermediate interface would have the following properties:

• Give a good experience for the people who only use a few sites, and only a few tabs.
• Make it even easier than it is today to graduate from using one to using more tabs.
• Effectively make use of modern widescreen displays, but have an option for resolution-constrained displays too.
• When pushing up against the limits what the interface can handle, provide a way to scale to the next order of magnitude.

Of the solutions we have explored so far, a sidebar-based solution gives us an array of new options and possibilities.

It’s worth noting that for some people, the fixed sidebar approach doesn’t work — it takes away too much screen real estate. One solution for this could be the slidebar — note the L — concept that Mozilla Labs have been exploring as part of their work on Jetpack, also present in the current Fennec mobile browser UI. The basic concept is the same as with a normal sidebar — although it makes use of the screen edge to let you quickly slide out a panel with the content instead of having it visible at all times. This could be a great solution when you are resolution-constrained. Other similar solutions can be found in the Opera sidebar, which expands when clicked. In any case, there are lots of potential ways to make the sidebar temporarily hidden.

These wireframes explore a variety of functions:

• Starts out as an interface similar to SafariStand, with partial thumbnails in a sidebar as the main way to switch between open pages.
• Some conceptual similarities to a TV “channel picker” — novice users would probably just have their favorite sites in the sidebar all the time. It would open the page if not already open, and switch to it if it already is.
• Some indicators/buttons can be added to the thumbnails, like RSS icon and favorites — but we should keep it very minimalist.
• There’s a large, empty tab available that makes how to create new tabs very discoverable.
• The new tab also has an option to perform a search directly from the tab — turning into the search results page on activation.
• Once the number of open pages reaches a threshold where it doesn’t make sense to show partial thumbnails anymore, we transition to the favicon + title approach of Tree Style Tabs. This way, we make it easy to discover the next level of tab management.
• You can of course also choose to be in one mode or the other explicitly with a mode selector along the top.
• There’s a “filter tabs” kind of search box that allows you to narrow down the list of tabs based on title/content. 
• Similarly, you can opt in to the slidebar behavior for the sidebar if you are resolution-constrained. Tapping the side of the screen with the pointer will then slide out your page overview. This will probably be the default for small-screen devices like where Fennec operates.

Oh, and we haven't rendered the back/forward buttons, address bar, etc. in these wireframes — they would of course still be present. We have some changes to these areas that we will detail in coming articles, so we left them out of the wireframes to not confuse the issue.

One cool consequence of this is that open pages — “tabs” — and bookmarks can be the same thing for the simple use cases. Similar to the Mac OS X dock, it doesn’t care whether the application is currently open or closed. This is something we will talk more about in a later article, but to keep the discussion focused, we will leave it on the table for now.

We now have an interface that arguably scales down better than the existing interface for people like my grandma, as well as seamlessly transitions once you start pushing it beyond the range of 8-10 tabs.

For power users: Quicksilver, meet Firefox

A pattern that we have observed among the power users is a propensity to get rid of as much of the browser user interface as possible. They often hide all the toolbars, get rid of most of the buttons — all to get more space for the content, minimize distraction, and because they use keyboard shortcuts for almost everything. They are comfortable without any physical reminders of what the browser’s functionality is — they just want as much space available for their content as possible.

Another interesting pattern that you may have seen if you have used application launchers,^{1 1}Tools like Quicksilver or LaunchBar for the Mac, the launch/search interfaces in OS X (Spotlight) or Windows Vista, or any the various application launchers on Linux. you probably also know that power users are also comfortable keeping the knowledge that their file or application is somewhere on the computer, and care less about where it is actually located.

What this indicates is that:

• Power users like the UI to “get out of the way,” and be as minimal as possible.
• Power users are comfortable keeping the details of what pages they work with in their head, and don’t need UI for bookkeeping.

With this information in hand, we could imagine a power user / full screen interface similar to this:

• There is no UI until you press Ctrl/⌘-L to enter new URLs. No tabs, no buttons.
• Pressing Ctrl/⌘-L will bring up the address bar (of course there should be a way to specify a different shortcut like Ctrl/⌘-Space or similar)
• Existing open pages have an indicator next to them, and selecting them from the pulldown will jump to that tab instead of loading then in the current tab.
• There’s an easy way to open the selected page in a new tab.

With this, power users have a great UI for working with hundreds of pages open at once, and at the same time we have a nice UI for full-screen browsing — for TV or projection use.

Switching between open tabs would then work like this:

1. Bring up the address bar by hitting Ctrl/⌘-L (or a self-defined shortcut, or a gesture like the slidebar only along the top of the screen),
2. Start typing the tab name in the address bar,
3. The open tabs that match what you just typed will show up as the top results in the address bar pulldown,
4. Selecting an open tab will switch to it,
5. You open new tabs in the usual way, Ctrl/⌘-T.

How would you enable the Power User mode? There wouldn’t be a mode switch, you would just turn off the elements you didn’t want on the page. If you turn off the address bar, it would work in the manner illustrated in the wireframe.

Testing the Power User UI, today

To get a rough idea for how this works in practice — “browsing with no UI” — you are encouraged to test parts of this using the 3.5 version of Firefox:

1. Turn off all the toolbars in the View menu
2. Turn off the Status bar
3. Use Ctrl/⌘-L to enter new URLs, use Ctrl/⌘-T to open new tabs

What’s missing from the current version of Firefox that we should fix to make power user & full screen mode usable:

• You can’t currently turn off the tab bar. This should be possible.
• Full screen mode doesn’t work on Mac OS X. This needs to be fixed.
• When you use Ctrl/⌘-L to enter a new URL, the address bar lingers around after you have entered a URL, meaning you have to manually turn it off again. It should remember its state, and disappear if you already had it hidden. Update: This works in Firefox 3.5, but not 3.0 — although you get the tiny dialog version instead of the full-on AwesomeBar. Still, works great for experimenting in the meantime, and future versions will hopefully give you the full AwesomeBar.
• The address bar should match on already open tab names. This is huge. If we add this, suddenly you don’t need to care about where that tab with Slashdot went, you just start typing its name, and Firefox will produce it from the 200+ tabs you have open in your browser, and switch to it.

Combinatorics

Just so it is absolutely clear: you can pick and choose any variation of the capabilities mentioned above to suit your browsing habits.

• Power user, but like having a list of what you have open visible at all times? Close everything but the sidebar in collapsed mode to list your 200 LOLcat tabs.
• Want to set up a foolproof setup for the four sites grandma uses? Hide the URL bar and pin the four sites in the sidebar, and she can use it as a TV.

…and so on. As you can see, this adds some powerful new tools and abilities to your browsing toolbox.

How to participate in the discussion

At Mozilla, we welcome your participation, and we are certain that there are a lot of great ideas out there. While I personally don’t have comments enabled on my website for the same reasons as Alex Payne outlines on his blog, the best ways to participate are:

• Write up an article on how you think tabs in Firefox should work on your own web site. As long as you link back to my site and mention my name, I will find it, and read it. No, really. My previous employer was Google, that’s what we do — find things.
• Participate in the Mozilla Labs Summer ’09 Design Challenge: Reinventing Tabs in the Browser.
• If your comments are shorter, or you just want to add something to something that has already been written, you might want to post them in the dev.apps.firefox Google Group — also available in Usenet news group and traditional mailing list flavors.
• If you produce any mock-ups, wireframes or graphics related to this discussion, tag it mozconcept — on Flickr, Twitter or elsewhere — and we will see it.
• If you don’t feel like polishing up something to post for everyone to see — or just want to test my shiny new flame-retardant suit that I got handed by the Firefox User Experience Team as part of my welcome package — send me an email at limi@mozilla.com.

Thanks for listening! Looking forward to see what you will come up with to help us make tabs better in the next-generation Firefox.

Coming from a web application background, I have always had a strong and opinionated interest in web browsers, and know more than I really should about rendering engines, CSS implementation and all the other stuff that web developers struggle with every day. It’s not pretty, but the past two years have finally brought some real progress in this area.

On the end-user side of things, the web has evolved tremendously the past few years, but there are still elements of the interaction models that are fundamentally broken, and the approachability for people that are new to the internet — or are otherwise disadvantaged — isn’t as good as I’d like it to be. In the other end of the spectrum, all current web browsers struggle with scaling up their user interface to keep up with the most demanding power users.

With my new job at Mozilla, I get to put my efforts towards making the leading open source browser even better, and help advance the web, change the way people use the internet — and hopefully fix some of my own pet peeves along the way.

Another reason that I’m very excited about working here is that Mozilla gets open source. They get evangelism, and they get open standards. The chance to work with experts in these areas will help me advance both the Plone and Mozilla projects.

I don’t think I could have asked for a better fit, or a nicer group of people. I’m looking forward to the opportunity ahead of me, and I can already tell that it’ll be expanding my horizon in unpredictable and amazing ways.

I couldn’t be more excited about what the future holds.

Wow.

I had no idea that so many people were even reading this site, and was again reminded just how amazing the communities around Plone and Google are.

During the last 28 hours after announcing that I am no longer with Google, I have received:

• Over 150 email messages from friends and strangers expressing support and asking what happened, and what I’m doing next.
• Over 30 emails from former Google team members, and people from other teams saying “WTF, dude — I heard about your story, this is not supposed to happen at a place like Google. That’s f—ed up.”
• Four offers of job interviews with major companies in Silicon Valley — not counting the startups I have never heard of.
• Requests from five journalists from sites and magazines I have heard of asking me for comments. And no, I don’t think it's appropriate for me to discuss this with the media, even anonymously — but thanks for asking, you’ve all been very polite and respectful.
• Two invitations to have lunch at Google. I appreciate the humor in the middle of all this, guys.
• Countless IMs, IRC conversations, Facebook messages, and phone calls checking that I’m OK, that I can stay in the US, et cetera.

I’m humbled, and not just a little bit touched by all the support and attention I have received. I’m doing fine, I’m staying in San Francisco for the foreseeable future, and I have a lot of plans and options at the moment, and I’m excited to move on.

A special thank you to the people from the Google User Experience team for inviting me to their gathering in the Mission yesterday, discussing what happened, and what they can do to make sure it doesn’t happen again to someone else in the organization. You’re all amazing people, and I miss working with you already.

Unless something very unexpected happens, this will be the last message about my former Google employment to this site. Thanks for all the support, and if you have any questions, I’m happy to answer them.

For the past couple of years, I have been working as an interaction designer at Google in Mountain View, California.

Because of manager conflicts, I am no longer with Google. Their handling of the matter has been no less than astoundingly amateurish and highly unprofessional, but I won’t air their dirty laundry here — it’s not worth any more of my time.

Suffice to say, I’ll be surprised if they manage to hold on to their top talent in the User Experience division for more than a year or two. That part of the organization is slowly rotting from the top down, and people have already started leaving. The wasted potential is truly beyond anything I have ever seen in an organization that is otherwise really well run, and has its priorities straight.

I have had the pleasure to work with an astounding number of amazingly talented individuals at Google, and I will miss them dearly. And there are some truly great managers at Google — hopefully I have let them know — I just never got to work with them. To all the designers and researchers I worked with at Google: I really enjoyed meeting and working with you all, you taught me humility, data-driven decision making and overall greatness — please stay in touch. To all the managers that attempted to help resolve the difficult situation I was in: Thanks for the respect, kindness and energy to fight the good fight. Keep it up.

Google is a fundamentally sound company, they have their priorities straight, and they will do well in the foreseeable future. I had a great time there, but it’s time to move on.

Hello, Plone

So, what’s next? Less commuting. More time with friends. Taking care of my ill father. More sunny days outside. More music, travel, sports cars, and guitars. And, of course, Plone.

With the work going into the upcoming Plone 4 release, I’m more excited about the future than I’ve ever been. Some of the best developers I have ever worked with — including Google engineers — are working on the next-generation Plone, and it’s truly in a position to change the world of content management.

To me, this is the most exciting year in my life. I’m looking forward to spend my time doing what I love, work with the people I admire, and to live and breathe the best open source community on the planet. It’s like coming home.

Now, if you’ll excuse me, I have a week of sleep to catch up on. Let’s change the world, again.

We’ll pick as many as possible of the highest ranked questions and answer them at the end of the keynote. Now, go ahead and ask those questions you always wanted to have answered.

Ask your questions here!

Known from TurboGears — and more recently, his keynote What Django can learn from Zope — Mark Ramm was invited to the Plone Conference to discuss the Python ecosystem and how to expand reuse and collaboration between the different Python web frameworks.

I remember meeting Mark for the first time when Alan Runyan and I delivered the keynote at the Python Conference 2006 in Dallas. We had several great conversations during the conference, but our paths haven’t crossed since — mostly because I’m not really a Python coder, so we don’t attend the same conferences.

I’m looking forward to meeting him again, and I believe he has a valuable perspective on Plone, Zope, Repoze and WSGI that should be enlightening and interesting.

As usual when it comes to conferences, it’s the conversations over a beer after the day’s program is over that really count. We’re excited to welcome you to our conference, Mark!

If you’re in South America — especially if you’re in Brazil — I encourage you to check out the program for the conference.

My talk will be “The State of Plone and Lessons from Managing a Top 2% Open Source Project” — and will happen at 2:40pm on Friday Sep 19.

I’m also looking forward to meeting fellow keynote speaker Bruce Eckel, long-time Python advocate and author of the books “Thinking in Java” and “Thinking in Python.”

With the Plone Conference 2008 coming up on Oct 8–10, it’ll be a busy few months — but very exciting and fun.

So, it seems our secret leaked a little early. The upside is that I get to talk about one of the projects that I’ve wanted to tell you about ever since I started working here at Google.

There are lots of reasons why Chrome is interesting — being a new open source browser using the WebKit rendering engine is one of them — but the main advantage it has over other browsers right now is the V8 Javascript engine. It uses several impressive virtual machine optimizations to make it the fastest Javascript engine out there.

So, what all us techies out there want to know is of course: How much faster is it? Here are the results of running the browser-neutral SunSpider 0.9 Javascript benchmark on Windows:

• Firefox 3: 3733 ms
• Safari 4: 3406 ms (aka. WebKit nightly)
• Firefox nightly: 2609 ms (this should be with TraceMonkey enabled, but it’s hard to tell for sure)
• Chrome: 1814 ms

As you can see, it’s fast. Amazingly fast. Over twice as fast compared to Firefox 3, and not far from being twice as fast as Safari 4 too — or WebKit nightly, as the case is here.

The new Javascript engine in Firefox nightlies (TraceMonkey) seems to do well too, but Chrome still beats it if my setup is correct — I'm not 100% sure about whether it's enabled or not in the nightlies. When setting the javascript.options.jit.content variable, it crashes in the date format tests. I was using this build for my tests.

If you use Javascript-heavy apps like Gmail, it makes a world of difference.

I do know that for some reason, Safari is much slower running on Windows than on a Mac. The Sunspider benchmark running Firefox 3 against Safari 4 on a Mac shows Safari being much faster than Firefox, which is not the case on Windows. Oh, and I didn't bother running the tests on Internet Explorer — we all know it has the slowest Javascript engine in the business right now.

Other reasons why Chrome is interesting

Every tab and plugin is its own process

This means that a bad web page or a bad plugin (Flash, anyone?) can take down the entire browser. In the age of tabs and web apps, trust me — this is a killer feature.

It does really smart things to make browsing faster

Let me mention one: One of the things that makes browsing slow is that your computer has to ask the DNS every time you follow a link to a different site. Chrome starts doing these DNS lookups in the background while your page has loaded, making the next link you click on start loading instantly¹. ¹ Note that this is different from pre-fetching the page, and takes up a very minimal amount of bandwidth (DNS requests are very lightweight.

Offline Mode built-in

Chrome has Gears built-in, which means that several web apps from Google and others are capable of running even without an internet connection.

It will bring a new audience to the alternative browsers

Google has the ability to reach people that would never have installed Firefox — either because they don’t know that it exists, or because they want a browser that is more mainstream. Google is a name they trust, and thus more people will be running open source browsers.

Oh, and stay tuned for the Mac and Linux versions. They’re coming — I can’t wait to run Chrome natively on OS X. The Windows version is now live, you can download it here.

It’s all good.

Thanks to Juliana Tsang for helping me run some of the tests.

And this shouldn’t be necessary, but sometimes people seem to need it anyway: all opinions expressed on this site are mine, not Google’s. But you already knew that, didn’t you?

Apple has announced that the current focus for the next version of Mac OS X — “Snow Leopard” — is refinement, optimization and making it as light-weight as possible. As reported, most applications are significantly smaller in the Snow Leopard developer preview.

But you don’t have to wait for Snow Leopard to get that particular improvement — a free application called Trimmit can dramatically reduce the sizes of your current OS X applications today.

While setting up a new system, I decided to do some benchmarks and measurements to see what kind of difference Trimmit would make. Are the savings worthwhile? Do applications start faster or use less memory? Only one way to find out!

Trimmit’s Approach

What are the features that make Trimmit better than the alternatives? It optimizes application bundles — mostly doing stuff the developers should already have done — as well as removing unused languages and processor architectures. Specifically, it:

• Deletes junk files
• Clears resource forks
• Strips universal binaries
• Cleans out nibs
• Strips debug symbols
• Compresses TIFF images
• Removes unused languages

If this sounds familiar, you have probably seen other apps like Xslimmer and Monolingual that perform similar tasks. Trimmit outperforms them both — but isn’t quite as user friendly. A small price to pay — and irrelevant in practice, since you aren’t going to use it very often anyway.

The Results

What do the results look like? Quite spectacular. Popular apps like Mail, iChat and iCal end up a tenth of their original size.

The start-up time and memory usage from a freshly booted desktop for iPhoto, Mail and Safari before/after was also examined. There was no significant difference in memory usage nor in startup time — which is as expected, since OS X only loads the parts of the application it actually uses. So the savings only matter for disk space, not performance or memory.

These are just some commonly used apps — the savings are usually just as dramatic with other third-party software. And all those extra megabytes add up in the end.

Weight Loss Tips

• Not all apps can be trimmed: Adobe apps, Firefox, VLC, CSSEdit, Skype, and others won’t work if you trim them — consult the blacklist for a more comprehensive list.
• Always let it create a backup — it's the default setting — and make sure you test the newly slimmed version before you delete the original.
• Remember that you have to re-trim apps after they auto-update
• Trimmit performs significantly better than Xslimmer and Monolingual

Conclusion

Disk space is cheap these days, but there's really no reason that an application like Mail.app should take up 289 MB instead of a more reasonable 21 MB on your disk. Trimming your apps can easily free up an additional 2–5 gigabytes for your system in total, which definitely makes a difference for laptops with smaller hard disks like the MacBook Air.

Besides, how can you resist an application whose icon is Monty Python’s legendary Mr. Creosote?

Download Trimmit!

While talking to Hanno Schlichting earlier today about his fantastic efforts at fixing bugs and cleaning the Plone issue tracker — combined, the two of us have managed to resolve 250 bugs from the Plone 3.x maintenance release in the space of a few days — Hanno mentioned that he’d finally managed to unplug his TV for about two weeks after not having a TV for most of his life until the recent last few months.

It reminded me about the following excerpt from Clay Shirky’s speech on cognitive surplus — he’s talking to a TV reporter about his new book, and she asks him about Wikipedia:

She shook her head and said, ‘Where do people find the time?’ That was her question. And I just kind of snapped. And I said, ‘No one who works in TV gets to ask that question. You know where the time comes from. It comes from the cognitive surplus you’ve been masking for 50 years.’ So how big is that surplus? So if you take Wikipedia as a kind of unit, all of Wikipedia, the whole project — every page, every edit, every talk page, every line of code, in every language that Wikipedia exists in — that represents something like the cumulation of 100 million hours of human thought. I worked this out with Martin Wattenberg at IBM; it’s a back-of-the-envelope calculation, but it’s the right order of magnitude, about 100 million hours of thought.

And television watching? Two hundred billion hours, in the U.S. alone, every year. Put another way, now that we have a unit, that’s 2,000 Wikipedia projects a year spent watching television. Or put still another way, in the U.S., we spend 100 million hours every weekend, just watching the ads. This is a pretty big surplus. People asking, ‘Where do they find the time?’ when they’re looking at things like Wikipedia don’t understand how tiny that entire project is, as a carve-out of this asset that’s finally being dragged into what Tim calls an architecture of participation.

Now, the interesting thing about a surplus like that is that society doesn’t know what to do with it at first — hence the gin, hence the sitcoms. Because if people knew what to do with a surplus with reference to the existing social institutions, then it wouldn’t be a surplus, would it? It’s precisely when no one has any idea how to deploy something that people have to start experimenting with it, in order for the surplus to get integrated, and the course of that integration can transform society.

The early phase for taking advantage of this cognitive surplus, the phase I think we’re still in, is all special cases. The physics of participation is much more like the physics of weather than it is like the physics of gravity. We know all the forces that combine to make these kinds of things work: there’s an interesting community over here, there’s an interesting sharing model over there, those people are collaborating on open source software. But despite knowing the inputs, we can’t predict the outputs yet because there’s so much complexity.

I’ve been television free since I was 18 years old and moved to my own apartment. That’s part of the reason why something like Plone could happen, a 250+ company worldwide phenomenon. Hanno got rid of his TV when he was 20. He's the most prolific contributor to Plone worldwide.

Get rid of your TV. Change the world, don’t just sit and watch.

…or, as Hanno said: “If you want to be the best — act accordingly.”

In the articles Simplifying the content authoring experience, Improved handling of rich media and Composite pages, listings and content proxies, we have laid out an approach to radically simplify the content authoring experience in Plone.

We have in one fell swoop eliminated the need for:

• Collections as a separate type,
• Images as a separate type,
• Composite page types,
• Proxy (represent one object in two locations) type,
• Default pages,
• The need for a separate "Contents" tab,
• Folder as a separate type.

We have made it substantially easier to handle:

• Rich (“opaque”) media like video, audio and Flash,
• Content reuse, i.e. generating new content by reusing other content (example: book with 3 different audiences),
• Application-specific functionality like forms/polls/maps inside a page.

We have made it possible to:

• Share “snippets of Plone” (widgets) to other systems — blogs, iGoogle, Facebook — you name it.

…all while making the UI massively simpler and easier to work with.

And if that wasn’t enough, the infrastructure improvements can be done gradually over a number of small releases in the 3.x series, and then culminate in a Plone 4.0 or 5.0 where we make the entire picture come together in a coherent new user experience. And we mostly don’t need to invent new infrastructure, instead we can build on work done in the Plone 3.x releases.

Next Steps

Where do we go from here? I want you all to help with fleshing out the plan, as well as contributing code and testing resources to make this happen. The next steps will be:

• Identify which individual components are needed,
• Figure out which of them can be built in parallel, and which ones can potentially be included in the 3.x releases,
• Identify champions for the different areas,
• Schedule sprints for big-picture integration sessions.

We hope to have the first of these sprints at the Plone Conference 2008 — and I hope we’ll see you there! Everyone is welcome this time around, and we’re trying to set up a range of sprint tasks, so that developers of all skill levels can participate in different ways.

I hope you will join us in taking Plone to the next level!

If you haven’t read the introduction, part 1 and part 2 yet, please make sure you do so before continuing. Thanks!

…and now for the pièce de résistance:

It’s time to reduce the number of concepts and approaches in Plone. Now that we have the “widget” concept and the new editor capabilities, we have the tools needed to:

• Eliminate redundant types,
• Eliminate the need for a separate “Composite Page” type,
• Eliminate the need for a “Display” menu,
• Eliminate the need for a separate “Content Proxy” type,
• Eliminate the “Default Page” concept,
• Eliminate the need for a specialized “Folder” type.

I’d also like to get rid of the “Contents” tab, but let’s keep this out of this particular proposal for the time being, since that’s a separate discussion. Ideally, there should be a separate “batch operations” interface for batch edit/rename/move/workflow changes. This proposal can be implemented independently, however — and indeed there is currently a Summer of Code project called plone.app.batch this year, working on some of this functionality.

Eliminating redundant types

• “Image” as a content type usually doesn’t make sense in itself. One exception here is the “photo album” use case, but that’s usually not what we refer to when talking about images in Plone. By making the images work the way content editors expect them to, we reduce the complexity of creating a page with Plone, and in one fell swoop get rid of the need for add-ons like RichDocument, PloneArticle and a lot of other generalized "keep the resources with the content" products.
• “Collection” (aka. Smart Folder) does really not make any sense as a content type by itself either. It’s a stored search, meant to be used in a context. By implementing it as a widget instead, we free up the content editor to use it in more flexible ways.

Eliminating the need for a separate “Composite Page” type

Another way of thinking about the widgets system is that every page is essentially turned into a page with composition abilities similar to the existing third-party “composite page” types.

Thus, every page is a composite page, and can pull in resources from other locations — folder listings, searches, images, movies, forms — you name it.

Eliminating the need for a dedicated “Display” menu

The reason why the Display menu exists in the first place is to make it possible to have a specialized view of a folder. But usually, the listing in itself only gives you half of what you want — you may want a small blurb talking about what the listing contains, an illustration or even a demo movie to go along with the listing.

What is currently thought of as “folder listings” are really just a special case of a “listing” widget — plain folder listing or a stored search.

Eliminate the need for a “Content Proxy” type

By introducing a “Content Proxy” widget — and yes, I’m sure we can find a better name for it — one can construct a page composed of any other number of pages.

From the simple case of mirroring one page in a different location to the more complex case of, say, constructing a “manual for Plone integrators” composed of 15 FAQs, 30 how-tos and 5 tutorials that all live in separate locations.

Another way to look at it is that to create a content proxy, you create a page with a single widget that pulls its content from somewhere else — and this content can even potentially be external. Hosted in Google Docs? No problem!

Eliminate the “Default Page” concept

After all this, you can probably guess how we can get rid of the “Default Page” concept. Yes, by using widgets and the new way of doing layout, on a folder — or a page, if we get rid of the “Folder” type as outlined below. The composite page abilities in the new approach will be able to turn a folder/page into any type of listing — even a mirror of an existing page.

Technically speaking, if you look at the folder from a file system view like WebDAV or FTP, its “body text” will look like a folder with an index document inside, similar to how index.html works for HTML files.

Eliminate the need for a dedicated “Folder” type

This a suggestion where I’m still not 100% sure we can make it happen without any performance implications or other problems, but ideally I’d like to get rid of the “Folder” concept altogether. Currently, folders are used to create listings of content added to a particular area — and that’s just as easily accomplished by adding a “dynamic listing” widget. It can list content based on containment, similar to what a “Folder” does today, or based on a set of criteria, like the “Collections” do.

To me, it makes sense that all objects are “folderish” — to use the Zope jargon for this — but I’m sure there are some constraints and considerations that need to be discussed. This is by no means a necessary part of this proposal, but it would make the experience a lot simpler for the end-user if we could make it work that way. Hopefully the new, unified plone.folder implementation scheduled for the next major release of Plone will make this easier too.

Let's summarize what we have outlined so far.

If you haven’t read the introduction and part 1 yet, please make sure you do so before continuing. Thanks!

A little bit of history

The background for this approach comes from a concept Geir Bækholt, Martijn Pieters and others at Jarn came up with to help Trolltech support a seemingly simple use case: They had a centralized price list, and wanted to make sure that everything referencing price was always up to date when they were changed the numbers in a central location. They were using code templates do do this, which is not such a good idea, since it effectively removes things from the indexed content, as well as making things fragile by mixing programming logic and content. Predictably, none of the content editors in the site were able to keep track of this.

To solve the problem, they invented something they called “snippets” — small pieces of text that had a special class that made them replaceable by a transform-on-save. I’m not going to cover this implementation in detail, but the outcome is that they realized that this approach could support a wide range of dynamic insertion capabilities relevant to audio/video media and other “opaque” content formats in Plone.

Where this gets interesting is when we combine it with a couple of other concepts, namely arbitrary attachments and portlets.

Infrastructure: Arbitrary attachments and layout

Plone’s current notion of adding an Image object just to get an image into a page is a bit cumbersome. There are times when having a separate (i.e. end-user selectable) type for images makes sense, for instance in the “photo album” use case — but in the vast majority of cases, the user just wants to upload an image to use in a page.

In some cases, it may be desirable to use a centralized image repository, some of which may be pre-populated, but page editing is still the primary point at which the author considers images. What actually happens to the image when it is added isn’t really a concern to the user, and shouldn’t factor into how the UI works, which it currently does.

This problem is not specific to images. Adding a Flash animation or audio/video media files is no easier — quite contrary. From their experience with word processors and other desktop applications, the user expects to be able to embed files and resources directly into a document. Plone should make this as easy as possible.

The problem can be solved in a general, flexible way that makes it easy to create such attachments and lay them out on a standard page. The solution comes in three parts: widgets, editor integration and transformations.

#1: Widgets

A new type of “contextual portlet manager” is added that can keep track of portlet assignments annotated onto a content item. Unlike the existing portlet managers for the regular portlet columns, this portlet manager is never actually rendered directly, but it acts as a container for embedded portlets. Importantly, the new portlet manager has a particular marker interface so that specific portlet renderers can be used when a portlet is assigned to this particular type of portlet manager.

We call these “widgets”. New widgets are defined that support attachment behavior. These must have a view that can render it as a simple icon as well as a canonical rendering. This can be achieved by having different portlet renderers registered for different marker interfaces on the portlet manager and/or request.

Portlets of this type could include an image widget and a media object widget. Both of these would include UI to upload resources directly into the widget and way to traverse to the uploaded image or file.

Additionally, they can consult a global option that lets the user choose a folder to act a repository for all images or other assets, via a pluggable storage policy. This makes it possible to have a central image repository, even though (to the end user) it looks like he’s just adding images to his page.

#2: Visual editor integration

Kupu (or whatever visual editor we use as our core editor) gains the capability to manage such widgets directly. An add form that includes upload widget for the attachment widget may be shown directly inside Kupu. This can be made general enough so that other types of attachment widgets can show their own forms, although it is likely to require specific UI for images and media objects that use attachment widgets behind the scenes.

The important part: A widget is inserted into the body text by using an <img /> tag that renders the widget’s icon representation. For image attachments, this may be an actual full-size or thumbnail representation of the image, for Flash, it might be a more abstract representation like just an icon. It also includes the widget id stored in an HTML class or similar.

The reason we use an image for this representation is that it’s the easiest element to manipulate in an in-browser editor like Kupu. The user can drag the icon around the page however he wants, and on saving the page, the transformation layer takes care of converting the placeholders into the real widgets. If you try to use other HTML tag constructs for this, you quickly run into visual editor issues specific to the various browsers.

#3: Transformation

When the page is saved, a text transform looks for these special images and replaces them with the rendered representation of the relevant widget.

It should also be possible to optionally include attached items in the SearchableText of a content item, so it will return as a result if you search for a term included in the attachment.

Turning portlets into widgets, a note on terminology

The idea of “widgets” needs some more explanation, as well as some implementation-specific notes:

To make portlets more understandable and generic, we rename them to “widgets”. The implementation still refers to portlets, this is a UI change only. There are some behavioral changes that would make widgets more generally useful.

The main reason for the renaming is that “portlet” is very “jargon”-y — your mom certainly does not know what a portlet is. To add insult to injury, the Plone portlets implementation isn’t really what the rest of the world is talking about when they are referring to portlets — they are usually talking about the elephantine JSR-168 Java specification¹, so let’s eliminate that source of confusion once and for all. ¹To be fair to Plone, the JSR spec was still in its infancy when this particular part of Plone was named.

“Widget” is the term used by several web-based and desktop-based implementations of this concept, and people understand what they are at this point. “Gadgets” is another term that might be an alternative, but for the remainder of this proposal, I will use the term “widgets”.

On a related note, the intent is also to get rid of the notion of left and right columns (as well as the general separation that forces you into a certain layout at the moment), but I’ll save that layout discussion for a later point. It’s covered superficially in the technical explanation at the end of this part, if you’re interested. The short version is that everything becomes a widget (the search box, the navigation, breadcrumbs, logo, etc).

Demonstration & Notes

Movie showing the new way to handle rich media
(no sound, 5.5MB)

• Insert a Movie widget
• It allows you to Upload, Search/Browse an existing content object, or Embed from an external web site, potentially with some settings related to height/width, etc.
• For movies and audio, an add-on product suite like a stripped-down version of Plone4Artists could supply transcoding and metadata extraction for these types. Simple metadata extractors like EXIF (photo metadata) and ID3 (mp3 metadata) could be in the core, but we don’t really want to ship a full suite of video and audio converters by default.
• Right-clicking a widget and/or possibly clicking an information icon brings up the widget settings.

As you can see, this solves a lot of interesting use cases, and the potential new capabilities here can not be understated, it’s an incredibly flexible and powerful way of handling “opaque” content.

If you’re interested in the technical implementation details, continue reading — if not, you can jump directly to Part 3: Composite Pages, Listings & Content Proxies.

Implementation notes

Some implementation specifics from Martin:

• Some widgets are global. They are shown on all pages. This is not the same as assigning a widget at the portal root that is acquired everywhere. One use case here is things like promotions or site-wide information, but this mechanism can also be used to manipulate site layout (see below).
• There is a “Layout and widgets” control panel were all global widget assignments are managed. This includes site-global, group-assigned and type-assigned widgets.
• Global categories of widgets (assigned by group, content type or globally) can be blocked by location as they are now. This should show a visual representation of what gets blocked. It should be possible to block all widgets in the given category, or only some.
• When a contextual widget is added (i.e. one that is attached to a content item), it is for that exact content item only by default.
• A particular widget assigned to a folder may optionally be set to apply to items in the folder only, or to items in the folder and its subfolders. However, acquisition is not the default.
• Widget assigned to default pages behave as if they’re assigned to the relevant folder.
• A portlet manager can be associated with a layout grid. A widget’s position in the grid is annotated onto the widget’s assignment instance. This alleviates the need for multiple portlet managers that only serve to represent different areas of the screen.
• For this to work, there must be a more granular way of asking a portlet manager to render itself than the current approach which uses the structure: expression type in TAL. Most likely, this will just be a view with a function to render a particular grid cell of a particular portlet manager.
• Some widgets can only be added as site globals, never to groups, content types or content items. These are layout elements that fit into a global grid that includes the entire page.
• A convenience wrapper widget type makes it possible to wrap any supported viewlet into a widget. “Supported” here means that the viewlet provides a particular marker interface.
• By moving viewlet widgets around the site-global grid, it is possible to move the search box, say, from the top right hand corner to anywhere else on the screen.

With that out of the way, it’s time to move on to Part 3: Composite Pages, Listings & Content Proxies.

If you haven’t read the introduction yet, please make sure you do so before continuing. Thanks!

Over the past few weeks, I have done some experiments in simplifying the UI to make Plone less intimidating for newbies. A lot of these experiences are based on deploying it in a limited fashion internally here at Google. Generally, Plone is in a state now where most of the major areas of functionality is in place, so it’s time to look at it with fresh eyes — it’s not exactly Plone 1.0 when it comes to number of things you can click anymore.

I have built a clickable prototype of the new UI, since the best way to show you what the new editing experience looks like is to show it in action.

Note that while I’m using the NuPlone theme in this demo, the approach works equally well with any theme — this is about functionality, not looks.

Demonstration & Notes

Movie showing the new approach (no sound, 6.6MB)

• First we show the existing UI, and highlight the various features.
• Then we switch to the new proposed UI. The major difference is that interface usually only has one button — “Edit” — instead of the entire tabs/menu/button structure that was there in the earlier version.
• Adding content: Showing the simplified new add menu, notice how there’s fewer types. We’ll get to the rationale between these going away in the next parts.
• When we click the edit button, it does an async request and brings back the edit form inline. It turns out that making everything editable inline all the time is confusing users, and contributes significant amounts of visual noise.
• A number of interface elements and functionality has been moved to the edit screen. Sharing and History are now on the Edit screen, since they are usually part of the editing flow.
• Another common trait of these actions is that they are used only occasionally compared to the adding and editing of content.
• The “Advanced” menu handles everything that isn’t in the “Default” fieldset, i.e things like Effective/Expiry dates, ownership, copyrights, local workflows, etc. It also handles add-on screens that would sometimes show up as additional tabs in the old-style interface.
• Share, History and Advanced show up layered on top of the main content, lightbox-style when clicked — a modal window in UI terms. This reinforces that the metadata and functionality is a layer around the content. It’s not shown in the screencast, as it takes more time to fake than I have right now. Just imagine the existing fieldset implementation in a lightbox-style overlay, and you’ll get the idea.
• Moving on to the visual editor, we have collapsed down some less-commonly used buttons to a pull-down menu to make the interface as minimalist as possible. Not to worry, though: if you have certain things that deserve a dedicated button like — let’s say, heavy use of the “highlight” style — these can appear on the main toolbar too. Don’t let the super-minimalist button setup distract you at this point, it’s there to illustrate the concept.
• Most significant of the two menus is the “Insert” menu, which can insert a number of familiar and unfamiliar content components called “widgets”, we’ll get to these in part 2:
  • Tables
  • Widgets
  • Listings — both folders and dynamic searches (Collections)
  • Application functionality like Polls and Forms
• This is another one of the ideas that will Change Everything™, since there is no need for a dedicated Collection type anymore. If you want to mimic the current Collection behaviour, it would be a page with only the Collection widget in it. This is an example of how the widget idea starts simplifying everything in unexpected ways. I’ll cover this in more detail in part 2.
• Some things would be moved to the main edit screen, like tags and other elements deemed important enough to live there. Don’t pay too much attention to the UI on the tag field, it’s just an input box in this mock-up — of course it would have autocomplete in its final form.
• Workflow state has moved to the bottom of the form, as the natural action is to do some edits, and then submit the document as part of the editing flow. For people with the Reviewer role/permission, the idea is to add an additional pulldown on the view of the content too, so they don’t have to go to the edit screen to make state changes — in other words the same way as things work in the old-style UI, but limited to the power users that are reviewers.
• We show how you would submit the document for review, and Save it. The current thinking is that changing the state would show a review comment string field next to the pulldown, so you could enter an optional comment to go along with it.

Frequently asked questions and additional notes

What happens to in-line editing?

If there’s something that we have heard loud and clear from our integrators, in-line editing — aka. “click to edit” — doesn’t work that well with end-users, so we’ll disable it for general content authoring. Yes, I just admitted we were wrong the first time around.

Instead of trying to work around the problem of editing efficiency with “UI hacks” like these, we should attack the root of the problem, which can be done in much the same way, but with fewer moving parts. There are use cases — mostly specialized applications — where inline editing may be the right approach. This proposal just states that for the basic content authoring use case, it doesn’t add much — except for confusion, annoyance and visual noise.

Where is the current state shown on the view, since the menu bar is gone?

The current plan is to fold it into the by-line along with the publishing date and author info.

What happens to products that have defined custom tabs and/or menus?

Ideally, there are very few legitimate use cases for doing this, but I agree that some exist. I won’t call out which are gratuitous and which make more sense, but I’ll use LinguaPlone — Plone’s multilingual support — as an example of where it might make sense to add a new menu.

• Additional tabs end up as sheets in the “Advanced” edit page.
• Menus end up as pulldowns in the view UI (but are discouraged unless there’s a really good reason for them to live there).
• Single-item menus become buttons.
• A “Translator” role can minimize the UI noise, similar to how we could show the state-change menu for people with the Reviewer role to ease their day-to-day dealings with the system.

In sum, these changes to the user interface make it less cluttered, more efficient, and easier to integrate with custom layouts, as the only thing you have to find space for in a custom design is a button and a pulldown.

Next, let's look at better rich media handling in Plone.

The Strategic Planning Summit at the Googleplex in February 2008 challenged us to focus on “approachability” as a major design goal; a way to make sure integrators who try to put together a project using Plone will have a good first experience. I won’t go into that in great detail, but I believe Martin Aspeli’s article Pete and Andy try Plone 4 serves as a great primer for the kind of experience we’re reaching towards for our Integrator audience. If you haven't read it yet, please do.

But what about the people that will use those Plone deployments as their intranet, web site or collaboration space in the years to come? Don’t they deserve just as great an experience the first time they are introduced to Plone? Shouldn’t they be able to master the basics of Plone in about half an hour of tinkering, and be able to self-graduate to higher understanding of the system when they see the need for it?

Let’s skip the all rhetorical questions for which the answer is obviously a resounding “yes” — and let’s not forget that Plone was a revolution at the time, and enabled a lot of non-technical people to publish and work with content through their web browsers when few such solutions existed.

This was before Google Docs, Basecamp, mainstream wiki usage, and even before the word “blog” was something most people knew what was. Netscape 4 was still a viable browser, Windows 2000 was the new hotness, and Napster was teaching people the about the power of networks of people and media. Mac OS X and the iPod was just a glimmer in Steve Jobs’ eye, and Clippy from Word was the most widespread alternative UI for content authoring. People thought we were crazy to use CSS everywhere for layout, and a new project called Wikipedia asked if they could use our style sheet and layout, and we said yes.

In order to to understand this proposal, an appreciation of what was done in Plone from 2001 and up until today — versions 1.0, 2.0, 2.1, 2.5 and 3.0 — is useful. Painted with a broad brush, all those releases were incremental — in a UI sense, that is. The infrastructure went through great improvements, but the user interface just adapted to fit around the new concepts that were introduced, and the core usability approach didn’t change much. Sure, Ajax functionality, a visual content editor and other nice improvements were added, but the basic way of doing content authoring remained.

There are good things to be said for interface stability, and I’m really not proposing major changes in how you interact with Plone on a day-to-day basis, since it generally works well. Changing a few key elements can have profound effects on the overall approachability for the average Plone end-user, however. We can also make it easier for the power users who create and manage complex content layouts and rely on rich media like movies and audio to make their sites more compelling and rewarding.

This new UI approach is gradual in its implementation — “progressive disclosure” for you UI designers out there — but revolutionary in the way it makes things both simpler and more efficient and powerful at the same time. Rather than trying to separate the users into explicit "simple user" and "power user" roles, we make it easier to reach the things you use all the time, and push some of the functionality to locations where people can find them without interfering with the general content authoring. So it’s similar to — but more implicit and gradual than — the idea of a dedicated Power User role.

Whether the elements of this proposal end up in Plone 4.0, Plone 5.0 or Plone 3000, I don’t know. What’s important is that it’s possible to implement pretty much all of these things as incremental improvements in the coming releases in the 3.x series, as they make sense as smaller improvements by themselves — or don’t need to be visible until we flick the switch in a later version.

What can be improved?

Plone mostly works great, but there’s no reason to stop innovating! Some of the major areas I think should be improved — and are covered in this proposal — are:

• Rich media handling and dealing with anything that is not a simple page of text is harder than we’d like it to be. We want it to be equally easy to write content that consists of images, movies, audio and content embedded from other web sites.
• Composite pages — pages that pull content from a number of locations — is a hard concept to get right, usability-wise. None of the existing add-on products have supplied a satisfactory solution to this. No offense intended, of course — it’s a very hard problem, and people have done a great job exploring various different approaches to this.
• The content authoring process is currently very artificial — you generally need to make sure your images, audio or movies are uploaded to the system before you start writing. This is the opposite of how people usually think and work.

What are we proposing to do?

We suggest a set of changes that will make Plone easier to use, as well as reduce the complexity of (or getting rid of entirely!) the concepts of:

• Collections
• Images
• Composite page types
• Content Proxies (represent one object in two locations)
• Default pages
• “Contents” tab
• Rich media
• Content reuse

A tall order, for sure. Suspend your disbelief for a moment, and let me show you how! I know this can seem a bit overwhelming when taken in one sitting, but I want you to see the progression and thinking along the way — as well as the ideal end state.

Preamble and credits

This proposal is comprehensive and wide-reaching, but it’s not a result of me putting on my thinking hat for three months, retreating to my secret mountain hideaway with an unlimited supply of my favorite whisky and music. Although that does sound tempting, in reality it’s a result of great conceptual ideas from people like Geir Bækholt, Martin Aspeli, Benjamin Saller, Helge Tesdal, Danny Bloemendaal, Cornelis Kolbach, Duncan Booth as well as my fellow UI designers at Google — you know who you are! As usual, my role is mostly putting all these ideas together into a coherent whole, and hopefully I give their ideas enough credit and appreciation by proposing something that is more valuable than the sum of its parts, clichés notwithstanding.

So to anyone who has been involved in this discussion over the past couple of years — too many to mention, so I won’t even try to name you all — thank you for your great input and suggestions! Also a very special thank you goes out to Martin, who wrote the initial summary of the infrastructural description on his way back to London based on the description Geir and myself gave him a few hours earlier at the Planning Summit.

How to read this proposal

There are several ways to explain what this proposal covers, and Martin and Geir have helped me with the implementation specifications. If you’re mainly interested in how this will end up from the end-user point of view, I suggest that you read through the technical parts anyway — and ignore anything you don’t immediately understand. It will give you a fuller understanding of the screencast demonstrations and screenshots that follow.

I started out with two separate articles on how this would work, but realized that for our developers it’s all connected. In the interest of efficiency — and actually getting this published — you’ll have to live with the somewhat interleaved explanation for now.

It’s tempting to write a proposal that was five times as long trying to cover all the details that are touched on in this proposal, but then nobody would read it. So let me know what needs clarification either by contacting me directly or by posting to the Plone Core Developer list, and I will explain in more depth — and if necessary update the proposal to clarify when things are confusing or non-obvious. Most of the edge cases — believe it or not — have been thought through. At least we think so, but you are of course welcome to show us new ones.

It’s time for a revolution, it’s time to make Plone’s user experience more powerful, as well as making it simpler to get started! But enough pillow talk, let’s get down and dirty with Part 1: Simplify the Editing Experience.