The Platform UI team is participating in tomorrow's bug day. We have marked a couple of bugs with the "bugday" keyword, added contact information to the September 28 BugDay wiki page, linked to the "How to Contribute to Platform UI" page, and made available project set files for all of Platform UI and IDE.
Happy bug fixing everyone!
Thursday, September 27, 2007
Thursday, September 13, 2007
I'm busy building a new Platform
With all the recent talk about diversity and the Platform, I felt compelled to post some pictures of my backyard as well. I took a few photos today, well past the crack of dawn, at a time that I would have liked to wake up (unfortunately, my kids have to be at school at 8).
So what occurred to me is that the most important quality of a platform is that it earns the trust of its users and adopters. For example, trust that the platform will last for a long time, and that it is stable enough to support whatever you want to build on the platform. It may help when the platform is built by a diverse group of people, but diversity is not an end in and of itself. I for my part decided to not rush it, and to pay special attention to stability, which I hope you can see in the pictures.
Those bolts are half an inch thick, and four inches long. Overengineered, you might say, but down at the platform, it is important to set a high bar for anything that goes into the platform. Because we know the platform must not crush under whatever is built on top of it.
So I decided to build all of this myself without any outside contributions. However, I haven't figured out how best to build the roof yet. If you have roofing experience, I would like to know how you did it, and I might accept contributions such as shingles if you have some leftovers.
I almost forgot to talk about the other Platform I am working on. The Platform UI team is always open for contributions, and we are proud to have attracted several non-IBM committers. When I asked why they like being a Platform UI committer, one of the main reasons was that they learn a lot from us, and from just taking part in building a great platform.
If you would like to become a Platform UI committer too, my advice would be to pick one specific area you are interested in rather than scattering your efforts across all of Eclipse. This ensures that you will deal with one or two committers all the time, which helps building trust. (Remember, for platforms, it is all about trust). For example, pick RCP related issues, or editor management, or wizards, etc. Start by watching bugs in Bugzilla, and answering questions on the newsgroups, focused on that one area. This will get the corresponding committer's attention. Write an email to our mailing list with your intent to contribute, or if you are shy, send an email just to me. If we know about you and what you would like to do, we can start sheperding you towards becoming a committer.
I put some time into our wiki pages to lower the barrier. You might want to check out the new how to contribute page which is based on a similar page Brad Reynolds, one of our non-IBM committers, wrote for the data binding framework. To make it easier to find similar pages for other Eclipse projects or project components, I added a how to contribute category.
All of the above mainly applies to individuals who would like to contribute. If you are reading this from a corporate perspective, and you as a company would like to invest in or contribute to the Platform, you are welcome too! Write me an email and my manager will get back to you. ;-)
So what occurred to me is that the most important quality of a platform is that it earns the trust of its users and adopters. For example, trust that the platform will last for a long time, and that it is stable enough to support whatever you want to build on the platform. It may help when the platform is built by a diverse group of people, but diversity is not an end in and of itself. I for my part decided to not rush it, and to pay special attention to stability, which I hope you can see in the pictures.
Those bolts are half an inch thick, and four inches long. Overengineered, you might say, but down at the platform, it is important to set a high bar for anything that goes into the platform. Because we know the platform must not crush under whatever is built on top of it.
So I decided to build all of this myself without any outside contributions. However, I haven't figured out how best to build the roof yet. If you have roofing experience, I would like to know how you did it, and I might accept contributions such as shingles if you have some leftovers.
I almost forgot to talk about the other Platform I am working on. The Platform UI team is always open for contributions, and we are proud to have attracted several non-IBM committers. When I asked why they like being a Platform UI committer, one of the main reasons was that they learn a lot from us, and from just taking part in building a great platform.
If you would like to become a Platform UI committer too, my advice would be to pick one specific area you are interested in rather than scattering your efforts across all of Eclipse. This ensures that you will deal with one or two committers all the time, which helps building trust. (Remember, for platforms, it is all about trust). For example, pick RCP related issues, or editor management, or wizards, etc. Start by watching bugs in Bugzilla, and answering questions on the newsgroups, focused on that one area. This will get the corresponding committer's attention. Write an email to our mailing list with your intent to contribute, or if you are shy, send an email just to me. If we know about you and what you would like to do, we can start sheperding you towards becoming a committer.
I put some time into our wiki pages to lower the barrier. You might want to check out the new how to contribute page which is based on a similar page Brad Reynolds, one of our non-IBM committers, wrote for the data binding framework. To make it easier to find similar pages for other Eclipse projects or project components, I added a how to contribute category.
All of the above mainly applies to individuals who would like to contribute. If you are reading this from a corporate perspective, and you as a company would like to invest in or contribute to the Platform, you are welcome too! Write me an email and my manager will get back to you. ;-)
Thursday, July 26, 2007
Improving editor tabs is hard
I just ran across Aza Raskin's interesting usability puzzler about how tabs in Firefox should work. It is a very interesting read, especially some of the comments, and is directly related to the problem of how to improve editor tab management in Eclipse.
Firefox 1.5 had a single row of tabs that were visible all the time. Each tab shrunk equally as you opened more tabs than could be shown with complete titles. This works well for a small number of tabs, and degrades gracefully as you open more tabs. However, it does not scale to a large number of tabs - after opening twenty or so tabs, the space for each tab is just too small and users won't be able to tell which tab contains which web page.
Firefox 2.0 tried to solve this problem by only showing a limited number of tabs. Essentially, what you see is a scrolling window into the complete list of tabs. There are buttons for scrolling left or right, and a drop-down menu at the far right allows you to see the full list of open tabs as well as jumping to a particular tab.
Aza criticizes that the new tab behaviour is concealing information, and that it makes it harder to navigate between tabs because of the added UI complexity - i.e. the scroll buttons, the drop-down list. My mother tongue German has a useful composite word for what happened: "Verschlimmbesserung" - making something worse in an attempt to improve it.
Of course, his criticism applies to Eclipse as well. The drop-down menu in Firefox is comparable to the one in Eclipse which opens when you click the chevron, or press Ctrl-E. The scroll buttons do not appear in Eclipse - instead, it uses a logic which will show only the most-recently used editors. This appears to work for some users, but it also drives other users nuts (including myself) because it is practically impossible to predict what will happen to your tabs as you switch between editors. All in all, I'd say that Eclipse has at least as much added UI complexity as Firefox 2.0 over Firefox 1.5.
The Mozilla/Firefox developers are watching the conversation, and I would encourage interested others in the Eclipse community to do so too. I enjoyed reading the discussion in the comments, the proposed solutions, and even some cool mockups. Hopefully, I'll have some more time next week to write about the more interesting proposals for Firefox and what I think we can learn for Eclipse.
Until then, I will be using Vertigo, an extension for Firefox that shows tab titles in a vertical sidebar, to see how well it works for web browsing.
Firefox 1.5 had a single row of tabs that were visible all the time. Each tab shrunk equally as you opened more tabs than could be shown with complete titles. This works well for a small number of tabs, and degrades gracefully as you open more tabs. However, it does not scale to a large number of tabs - after opening twenty or so tabs, the space for each tab is just too small and users won't be able to tell which tab contains which web page.
Firefox 2.0 tried to solve this problem by only showing a limited number of tabs. Essentially, what you see is a scrolling window into the complete list of tabs. There are buttons for scrolling left or right, and a drop-down menu at the far right allows you to see the full list of open tabs as well as jumping to a particular tab.
Aza criticizes that the new tab behaviour is concealing information, and that it makes it harder to navigate between tabs because of the added UI complexity - i.e. the scroll buttons, the drop-down list. My mother tongue German has a useful composite word for what happened: "Verschlimmbesserung" - making something worse in an attempt to improve it.
Of course, his criticism applies to Eclipse as well. The drop-down menu in Firefox is comparable to the one in Eclipse which opens when you click the chevron, or press Ctrl-E. The scroll buttons do not appear in Eclipse - instead, it uses a logic which will show only the most-recently used editors. This appears to work for some users, but it also drives other users nuts (including myself) because it is practically impossible to predict what will happen to your tabs as you switch between editors. All in all, I'd say that Eclipse has at least as much added UI complexity as Firefox 2.0 over Firefox 1.5.
The Mozilla/Firefox developers are watching the conversation, and I would encourage interested others in the Eclipse community to do so too. I enjoyed reading the discussion in the comments, the proposed solutions, and even some cool mockups. Hopefully, I'll have some more time next week to write about the more interesting proposals for Firefox and what I think we can learn for Eclipse.
Until then, I will be using Vertigo, an extension for Firefox that shows tab titles in a vertical sidebar, to see how well it works for web browsing.
Subscribe to:
Posts (Atom)
Posts
