Back in 1998 when I started using Linux, it was ugly.
In those days you installed it by inserting around 40 floppy disks into your computer and praying that one of them wouldn't be a duffer and make you have to start again.
After this lengthy installation process, you were typically presented with this not-entirely-intuitive interface:
darkstar login:
_
At that time, the dominant operating system was Windows 95, with Windows 98 just getting its wheels rolling ? and Linux's Wargames-esque vibe clearly didn't cut it for a modern generation raised on the GUI.
As our beardy friends in the Linux kernel world figured out how to get graphics cards working, more and more effort was going into producing a graphical environment that the world was familiar with.
This effort started with X ? the chunk of software that paints things on to your screen ? but it wasn't enough. To get a truly usable GUI, you needed a good window manager to work with.
Unlike the Windows world, X enabled you to run multiple window managers, and a plethora of wacky and wonderful attempts were made. Some were simple, some were more complex, some tried to emulate Microsoft's operating system and some were just bonkers. Amid this creative explosion, two graphical environments emerged as the clear popular choices: KDE and Gnome.
While both were fully functioning environments and great for users, they were essentially two different walled gardens with little crossover. Both solved many of the same problems, such as presenting ways to launch files and manage fonts, but each did its own thing in its own way. Things had to change.
While our community was growing, it was madness that two developers could be solving the same problem in two different ways. Fortunately, the situation was about to get a lot better.
Unifying the desktop
With more and more chatter about cross-desktop participation, the freedesktop.org project was announced as a desktop-independent place in which software could be developed to benefit any desktop that wanted to use it. The site provided a wiki, code hosting, email discussion lists, IRC channels and more.
It had a tremendous impact on desktops. A lot of software was created; some of it reached maturity quickly and solved real problems, while some projects got started but were ultimately never finished. Irrespective of which projects worked and which didn't, freedesktop.org also brought an important message: we should try to collaborate between desktops where possible. The message was popularly received and the desktop continued to evolve.
One of the most important pieces of software that came out of freedesktop.org was a unified messaging system. At the time, a key challenge desktop developers faced was how applications could communicate with one other; the web browser needed to communicate with the system keyring, the networking daemon with the icon in the panel, and so on.
KDE tried to solve this problem with a system called DCOP, which was an intuitive way for applications to send and receive messages to and from other applications. While DCOP worked well in KDE, it unfortunately didn't solve the wider problem between multiple applications across multiple desktops. And thus the D-BUS project was born.
D-BUS is, in a nutshell, a cross-desktop equivalent to DCOP. It provides a facility in which applications can communicate with one other via a common bus and using a common language. D-BUS went through a feverish period of development, ultimately became ratified as a freedesktop.org standard, and the technology was built into both the KDE and Gnome environments. This was a huge leap forward for the desktop, and another strong step in its evolution.
Refining the desktop
With all this cross-desktop work going on, we saw tremendous developments on the Linux desktop. Many of our long-suffering problems were getting addressed ? USB devices were plug and play, wireless networking was only a click away, printing was a breeze, software was simple to install; things were getting better. It felt like we were really becoming relevant, and we had something the competitors didn't: an incredible global community working together.
In the world of Ubuntu, we were doing our best to be at the forefront of delivering this innovation to users. We were taking open source software and integrating it, and our goal was to deliver this content in a way that solved real-world problems for people; be it getting your music player to work, getting online or whatever else.
Back in 2008, Mark Shuttleworth, the founder of Ubuntu, was keen to ramp up this innovation and focus in Ubuntu, so he founded the Ayatana project. The idea was simple: to recruit a design team and an engineering team, and build a set of user-interface enhancements and improvements defined by a strong sense of quality in design.
This was new for both Mark, the company (Canonical), and Ubuntu. We had had a long history of shipping and integrating software, but such a design-centric initiative was uncharted territory.
Ayatana
When Ayatana was founded, a comprehensive design team was hired by Canonical. The team came from a variety of backgrounds: many came from brand, graphic design, product development, interaction design and other walks of life.
The term 'melting pot of personalities' is an understatement, and many were new to open source and still taking it all in, but all were enthused and inspired by the idea of great design infused with strong community.
The first project to come out of the team was called Notify OSD and provided a new approach to notification bubbles, which we were all too familiar with in Ubuntu. For years we had seen these boring yellow square bubbles appear in the top-right of the Gnome desktop when an application needed to tell you something.
Notify OSD was the same basic concept, but re-imagined. With it, an attractive black transparent bubble would appear, and instead of clicking it to dismiss it, hovering your mouse over it would cause the bubble to fade so you could interact with the application underneath it.
The justification for the design was that notification bubbles should present information to the user in a way that isn't intrusive. With the first version of Notify OSD released and shipped in Ubuntu, the Kubuntu team wanted the technology in KDE too.
Fortunately, the Ayatana team had created the Notify OSD specification in a cross-desktop way and the Kubuntu team simply worked on a different GUI that fitted well into the KDE desktop. Like the Notify OSD in Gnome, it was well received; a subtle and gentle improvement to the desktop.
The Ayatana team weren't limiting themselves to just notification bubbles, though. The next goal was to fix the system and application notification area; an area that had become something of a wasteland in the Linux desktop. There were multiple problems with the notification area.
To start, the notification area typically had a number of notification icons for applications that used it, and you couldn't click once and scrub through the icons ? you had to click each individually to use it. In addition, the user interface on these icons was often inconsistent. Some have certain types of menu in left-click menus, some in right-click menus, some had strange and inconsistent widgets, and some had other odd bits.
The icons in the notification area were the same as in the application launcher ? typically full-colour icons ? and this often looks sub-optimal in different themes.
As an example, in a dark theme you usually want single-colour icons in the notification area for clarity and definition, but also normal bright-coloured icons in the application launcher. All of these issues caused accessibility problems for blind and disabled users, and made it difficult to navigate the notification area with a keyboard.
The Ayatana team wanted to fix these problems in a cross desktop way. To do this they based their work on the System Notifier Specification that was created and used by the KDE project, and created a new application programming interface (API) that developers could use to put an icon in the notification area for Gnome applications.
The technology had a number of benefits, including the fact that you can now click one icon in the panel and scrub through the icons and each notification area menu would drop down (similar to how you can move your mouse through the menus in an application). Additionally, applications can set a specific icon in the notification area, which made single colour notification area icons a reality while keeping the application icon a normal full colour icon.
Notification area menus were made more consistent. No more confusion about left- or right-clicking to see a menu; you can only left-click, and only standard menu items, checkboxes and radio buttons are supported. This results in a much simpler and more consistent user experience. Everything was made far more accessible, and functions in the notification area can be controlled by the keyboard, which makes it much easier for blind and disabled users.
When the technology was ready, it was shipped in Ubuntu and was well received by users. With these indicators being fully open and with APIs for C, Python and Mono, application developers had a field day and more and more applications were adjusted to support the technology.
What is particularly interesting from a cross-desktop perspective is that due to the technology being built on a standard cross-desktop specification, KDE applications running in Gnome have their notification menus rendered in the native GTK toolkit and using native Gnome icons. The same works for Gnome applications running in KDE: those notification menus are rendered in Qt. This makes applications that aren't designed for your desktop feel much more native and integrated.
System indicators
Another feature of the technology is the concept of system indicators: notification icons that group together similar types of content (such as messages) or present system related content (such as battery, power and sound).
A key technology here was the messaging menu: a small envelope-shaped icon that presents all of your incoming messages in one place. With it, applications can put content there; you can see how many new emails you have, new social network messages, chat messages and more.
Again, due to the cross-desktop specification, any application can put content in the messaging menu and many projects surfaced to bring support in Zimbra, Gmail and more. Other system indicators have also been produced in Ayatana too.
A good example is the sound menu, which not only enables you to adjust the volume of your soundcard, but also shows which song you're listening to and gives you the ability to skip through songs when listening. This is handy because typically when you want to listen to music on shuffle, you never need to interact with the music player other than for skipping tracks. With this feature you can hide your music player and just use the sound indicator to skip tracks.
Application menus
The final indicator-related feature that the Ayatana team have focused on is making an application's main menu also use this specification. The driving influence here was the netbook world.
On netbooks and other small form-factor devices, vertical space is a premium, and putting the application menu in the top panel saves space. This was developed as part of the work on Unity, a new netbook interface.
The application menu indicator technology was developed and applies to almost all applications; all KDE and Gnome, GTK and Qt applications get the benefits of the technology without any changes to the application. Consequently, if you run an application with these new application menu indicators switched on, the application's menus appear in the panel and work in exactly the same way.
Like the notification indicator icons, this is an entirely cross-desktop technology, so running KDE applications in Gnome means that the application menus are all rendered in native GTK widgets and icons, and vice-versa. It's pretty stunning to run KWord in Gnome and see all the application menus rendered as native widgets; again, it makes applications designed for other desktops feel more native and more accessible.
Over the last three years, the Ayatana team have gone from strength to strength and some important lessons have been learned along the way. When Notify OSD was first launched, there was a pretty severe lack of interaction between the Canonical designers and the community, and this rightly caused some irritation among those in that community.
However, we took those lessons onboard and now new technologies are not only discussed first in the community, but running code is released as soon as it's available. As an example, when the application indicator work was started, running code was available within a few weeks, and the community could play with it, explore the code and contribute bugfixes and improvements. This improved transparency has its most notable benefit in application support.
A number of applications have built support into their projects for the application indicators and Notify OSD, and more and more applications are harnessing these features because Ubuntu ships all this technology, too.
Looking forward
We've come a long way on the Linux desktop. It only feels like yesterday when having a graphical desktop in the first place was a huge novelty on Linux, and luxuries such as consistent user interfaces, great usability and quick and easy access to devices and applications seemed like a world away.
The community has come together, fuelled by inspiration for making a better experience for everyone, and we're seeing the benefits of many these changes. While we have made great progress, the future holds so much more potential.
Linux is now an unstoppable force and, unlike back in 1998, we now have a great portfolio of technology that has the ability to touch the lives of computer users around the world.
We also have a rich range of hardware to target ? laptops, desktops, netbooks, tablets, phones, appliances and more ? the world is our oyster, and driven by our continually growing community, who knows what Linux will look like in 2018?
 |  |
No comments:
Post a Comment