LFY: How did you get started with computers and when did you realise that it was Free Software development you're really interested in?
AS: I got started with computers originally in elementary school. The school I went to was part of a government project here in Canada and so even though it was only the early 1980s, we already had a class set of personal computers — a mix of Apple IIs and PETs, as I recall. In Grade 2, without having enough to keep me busy and interested, my teacher had me put into the computer programming club at the school where for a few hours a week I could write (simple!) code in BASIC on the Apples and PETs. My family did not have enough money to buy a computer (in fact, I wouldn't get one of my own for another eight years), so I heavily relied on school resources.
That was how I discovered the Internet in 1990 along with the idea that computers were more than number crunchers and glorified typewriters — they were the most sophisticated and amazing communications device ever conceived. That discovery led me to decide not to pursue studies in physics (my first choice) or neurobiology (a close second) but to go into computing instead.
As for Free Software, I discovered Linux in 1994 a few years after I had cut my professional teeth on SunOS (later Solaris) where I'd used several GNU tools. However, it wasn't until much later when jobs for closed, proprietary and absolutely inferior products started dominating the market that my mind started turning towards systems such as Linux. By the mid-90s, it was very easy to find work programming applications for Windows; UNIX had become mostly a server-side phenomenon and WindowsNT was set to challenge even that. I found this turn of events extremely discouraging: I did not want to work on such frail and poorly designed systems such as those that Microsoft or Apple came out with, but I could see a future where that was all there was. Thinking about it, I decided that only systems such as Linux with their low cost, commodity hardware support and high reliability had any chance of averting such a disastrous future for my industry of choice.
After taking a year off to pursue other interests, I returned refreshed and energised to the programming world and made a conscious decision to build a career working on Linux systems. Initially, I had to not only win programming contracts, but simultaneously sell the clients on using Linux instead of their other choices.
During this time I immersed myself in the philosophy behind Free Software and found that it resonated deeply with my own beliefs when it came to living on this planet that we share with billions of other people and trillions of other forms of life. Eventually, the pragmatic reasons I had for using Free Software, were augmented by philosophical ones.
LFY: Can you share with us your role in the KDE project, especially with respect to the KDE 4 development cycle?
AS: My role in KDE 4 has been to help create a vision and build consensus around the direction we move in, communicate that consensus both within and outside the project, maintain direction in various efforts and work on the new desktop shell, Plasma. So while I was spending a good amount of time writing code in KDE's libraries and the new Plasma desktop, I also did things such as coordinate and host meetings with the artists to help keep the Oxygen project (icons, application look, sounds, mouse cursors, etc.) on track. A lot of my time in KDE 4 was spent on these coordination and communication issues. I can't count the number of words I wrote or the number of miles I flew in aeroplanes towards that end. The other 'a lot of my time' was spent writing code.
LFY: When did you first start chalking out the plan for the new version? Can you share with us some memories of those early brainstorming sessions and who all were involved?
AS: The first discussion that I can recall about what would end up becoming KDE 4 (though back then, we didn't really know that was what we were really talking about) happened at the KDE World Conference in 2004.
I had several discussions during the two weeks I was in Germany for the event that ended up becoming reality in KDE4. We discussed what would eventually become Phonon, our new multimedia framework. The first inklings of Plasma were mooted, and we even discussed search and metadata extensively. While Strigi/Nepomuk were not a direct result of the discussions about search, I believe that if we hadn't publicly discussed these issues then Strigi and Nepomuk would not have found their way into KDE4.
We also discussed usability and accessibility, and decided that we needed a new human interface guidelines (HIG) document and to really push for broad accessibility.
Over the next couple of years we continued to outline areas where the Free Software desktop and KDE in particular was not doing well. These discussions were spirited, exciting and forward looking. Common themes emerged, such as how to abstract platform specifics out and wrap them in ways that application developers could easily use them.
All of these things have either come true or have begun to come true in KDE 4 today. These early discussions were inspiring and will continue to keep us coding for years.
As for who were involved -- it would be easier to mention who wasn't involved, since KDE is not a top-down project; we don't have a design committee that tells others 'below' what to do or when to do it. Instead, we have groups of people that take personal ownership for different parts of KDE and as a community we discuss and decide our directions. Virtually nobody who wrote code for KDE 4 was excluded from even the earliest of discussions.
LFY: So the main idea/purpose behind KDE 4 that came out was...?
AS: There were three main points:
KDE had to be more beautiful and usable than anything else out there. Our goal was to exceed even Apple in this regard.
We had to create a technology foundation that we could rely on for the next decade, and which would travel well from desktop to laptop to media centre to mobile device. On top of this foundation, our applications would shine with functionality.
KDE needed to be portable in the extreme: across Linux, BSD, Solaris, Windows and Macintosh; it also needed to be even more friendly to applications from other projects so that their software worked perfectly with ours (and vice versa).
LFY: KDE 4.0.x, as we understand it, is not the full offering as some of the essential tools are still missing. Please tell us what can we expect from version 4.1. Will it be a full substitute for the 3.5.x series?
AS: In many ways, 4.0.x already surpasses what is available in 3.5. However, you are correct in that in some ways it doesn't. KDE 4.1, however, will be ready for usage in production environments. Absolutely mission-critical environments may wish to wait until 4.2 to let more bugs settle out and the feature set grow even further, but 4.1 will be good enough for most.
LFY: The UI is what the user interacts with. That's why we believe Plasma plays an important role in KDE 4. "To take the desktop as we know it and make it relevant again" was the set goal for Plasma. So, what's Plasma today and what's coming up?
AS: Right now Plasma exists in two overlapping worlds: there is the technology built into the underlying libraries, and then there is the Plasma desktop built on top of it that the users see. Right now the Plasma desktop is very traditional in its presentation: panels at the edge of the screen, icons listed on the desktop layer, etc.
This traditional presentation was done out of pragmatism: we need to build a comfortable bridge from what people are used to today to what they will be using tomorrow. So we start with the 'today' bit.
However, the framework underneath this is much, much more powerful than just the traditional desktop presentation of icons and panels. In fact, there is no concept of a panel or a desktop in this underlying system. The fact that we can provide a traditional experience on top of it is really a testament to its power and flexibility.
Where we are going, however, is a system where your devices— desktop, laptop, tablet, mobile, media, etc—are not islands cut off from the world. By providing easy ways to create and share objects -- called 'widgets' -- between devices and people, each person will be able to create sets of these widgets that are specific to their goals and activities.
In fact, you can have as many different sets as you wish and switch between them. These widgets may communicate with each other over the network, can reach deeply into the local system, the Internet or connect with other people via their online identities to create an experience that more closely matches the human one.
Rather than artificial-feeling interfaces where menus jump in and out of existence, that require mastery of multiple mouse buttons, that restrict what you can put where and how, Plasma lets you change the size and location of items (drag something from a panel to a desktop; zoom out and put it somewhere very different; bring everything momentarily on top of your document windows, and then send it back behind them) and tries to present things in a natural 'organic' way where things move, rotate, etc, much more like real world objects.
By letting anyone extend the desktop with a few lines of scripting and providing access to search, hardware, media and more, Plasma will enable people more and more to customise and design their computer abode just as they would the contents of their house—to fit their life.
While today's systems tend to restrict people in what they can do while ignoring the increases in storage space, devices, networking or identity, Plasma has these as core design motivators. It's like moving out of a small apartment designed completely by someone else and where nothing could be changed or move around much, into your own house where you are in complete control. The CEO of a global Fortune 500 company sitting at his desk does not have the same requirements as a teenage girl sitting in her bedroom listening to music; Plasma is the first desktop built to actually respect that concept.
Apart from that, Plasma technologies run nicely on the new generation of smart phones, can easily be tuned down without any coding to work on network-centric devices or on low-end hardware, and can be used to power things such as media centres. Plasma travels across the user interface world much as the Linux kernel does across the hardware world.
What's really interesting is that not only is Plasma being used to create a desktop shell, but other applications are using Plasma to create new user experiences. Amarok2 is using it, for instance, to improve the music experience, while the educational application, Kalzium, is providing widgets that you can place outside of the application itself to teach students about chemistry.
Other applications using Plasma technology was not one of my original visions for it, but now that it is happening, it seems only obvious and natural.
We understand that it's very difficult to introduce a desktop environment that’s a new concept. You have to make the users (both current and those new to KDE) feel at home. We all know how tough it is to let go of things you are used to for years. Tell us how the developers address this.
What we've done is build into Plasma a lot of future potential. We'll be unveiling this potential one step at a time over the coming releases and years to transform what we have now into what we want to achieve.
So in 4.0 we offered a traditional listing of icons on the desktop, pulled straight from the Desktop folder in the user's home directory. In 4.1 we are removing these icons and offering a way to list 'any' directory you wish within an area on the desktop. You can click and drag to define the area the icons are allowed to occupy, you can have as many of these areas as you wish showing as many different folders as you'd like ... eventually you'll be able to switch to a listing versus an icon view, collapse the listing into a small icon (to later be expanded when you need the contents of those files again), etc.
In this way we can slowly march users from features they are familiar with to new ways of doing similar things.
We are introducing new features slowly, but with confidence. In 4.0 we introduced the desktop toolbox, which you can hover over to get at common actions instead of having to right click all the time. We also introduced the basics of zooming, as well as rotating and resizing objects. In 4.1 we are introducing the ability to create sets of objects, sorted into categories we call 'Activities' and which you can use zooming and panning to switch between. So, for many of the new features we layer one on top of the other.
Of course, this is only relevant for the desktop and laptop. For other kinds of devices, we don't have to contend with these pre-conceived notions and have much greater latitude to usher in new ideas.
LFY: Was there a separate usability and UI design team who contributed to some of the design mock-ups or did you developers yourselves draw up the plans? How does one go about implementing these interface idea mock-ups into actual software interfaces?
AS: There is no single answer there. I'm personally not only a developer, but also an interface designer, so I kind of sit on both sides of that fence. However, in general it's a collaboration: artists, developers and usability gurus work together to come up with ideas. Everyone adds to the concepts, we mix them about, try different experiments, do research, etc, until we have some feature targets. But instead of just one group behind it, you'll find the fingerprints of the entire team on the final result. This does not devolve into chaos; however, we work towards consensus and proof of ideas. Sometimes, we try multiple ideas out simultaneously and then discover through actual usage which ones are better.
So the creation and implementation is often an iterative process: discussions will happen, someone will write some code, various individuals will look at it (either by compiling it into a runnable program, by watching video of the application in action or looking at still screenshots) and provide feedback, ideas, etc, and it all starts over again.
LFY: You mentioned Oxygen before, the theme that replaces Crystal, and I have to say it's awesome! Can you tell us how the Oxygen theme initiative got started--a little bit about the team, artists and the goals that were set?
AS: Oxygen started at a small invitational meeting we held in Berlin, Germany about three years ago, called the Appeal Meeting. We invited usability, artwork, software development and project management specialists for several days of intense thought and planning. One of the outcomes was a new look and feel for KDE4, one that was 'breathtakingly beautiful'. The idea of a 'breath of fresh air' and 'breathtakingly beautiful' fused to give the art project its name: Oxygen.
The artists set about defining a colour palette, art style guides and incorporated a lot of usability thought. For instance, it was decided that icons used to represent actions, such as in toolbars or menus, should be simple and have a less saturated colour palette so that they weren't distracting. We discussed ways of making the software more hospitable to advanced icon concepts as well. This marriage of art, usability and software got Oxygen off to a compelling start.
As the project continued, it grew to include not just icons but also the look of all the buttons, menus, windows, etc, on the desktop -- mouse cursors, sounds, desktop wallpapers and various pieces of artwork seen in applications, on our websites and more.
The core team has been made up of Nuno Pinheiro, Ken Wimer, David Vignoni, Riccardo Iaconelli and Casper Boemann, though many, many more have contributed art and code.
I'm very proud of what Oxygen has produced and continues to produce. It has some of the best artwork in the desktop world today, bar none.
LFY: After a couple of years of heavy development, we believe that many of the goals that were set before starting off have been met. In your opinion, on what counts was the project unable to implement the goals and where could issues have been addressed better?
AS: For the goals we didn't achieve in 4.0, it's just a matter of 'when' rather than 'if'. Many of our goals are very ambitious and will take quite a bit of time and effort to achieve. But it is important to have such goals otherwise you come to your destination quickly and have nowhere left to go on your map.
So our goals of pervasive contextual search data that is tied into identity (both yours and your associates’) is something that we have started to achieve with Nepomuk, Strigi and even KRunner (the replacement for the 'Run Dialog' in KDE 4). However, today Nepomuk is only starting to get features surrounding identity that we can start to drive the social aspects with, and Dolphin (the KDE 4 file manager) is one of the few applications to support Nepomuk thus far. We've identified many more applications that should be using it, and so we're seeing developments such as the Akonadi groupware infrastructure starting to tie into Nepomuk.
Where we could have done better is in communicating the long-range nature of some of our goals. However, not only is every single bit of every single one of our goals still possible, but we have pathways laid out to each of them. As we get closer to achieving those ends, we'll be sure to lay more down for ourselves. But we are very careful to build achievable goals, even if they are often very ambitious.
LFY: The Debian project has announced that Lenny (the upcoming Debian version) will offer KDE 4.1.x by default. How's the response from GNU/Linux distributions in general?
AS: It's been very good. We have been receiving a lot of patches from our downstream partners and the Linux distributions have been racing to include KDE 4 before each other. 2008 is going to be an exciting time.
LFY: Trust me, for users it's even more exciting. Finally, can you share with us the plans for KDE 4.2.0? Would it be a simple maintenance release or will further new features be introduced in it?
AS: There will be even more features, more work on stability and performance, etc. Right now, we are focussed on 4.1, however, so we haven't started defining the 4.2 feature set.
-- Atanu Datta, The LFY bureau |
