A study of what-if scenarios which posit what KDE would look like if it took a different approach to certain aspects of design. Note that these posts are in no way “the direction KDE is going” and are simply a study done to reference designs and ideas we may never have investigated.

Forward

First, a brief overview of Windows 8;

Windows 8 was Microsofts’ first step towards creating a unified ‘experience’ between the range of products running Microsoft Windows. Before Windows 8, early tablets which ran Windows typically ran a traditional Windows desktop; because desktop Windows was designed for mice, it typically required a stylus, trackball, or other similar input; keyboard solutions were universally sub-par. Microsoft ideally wanted its mobile audience to use laptops and phones instead of tablets. Apple and Google later devoured the tablet/phone market with iOS and Android respectively, and touch-screen devices became the norm. With their advantage in touch input, these two systems grew into tablets. This left Microsoft in a bind; Windows mobile was not capable of delivering a capable experience, so instead of taking the route Android and iOS did (growing their OSs’ up) Microsoft decided to begin shrinking its more capable desktop OS down. Windows 8 was the first step in this process, and essentially laid a touch-centric layer on top of a traditional desktop OS. The end result was an OS with split personalities and it required desktop users to work around touch components, while mobile users more/less had a decent – but more limited – experience.

Windows 10 is Microsofts’ attempt to correct the design flaws of Windows 8; Mainly by allowing the interface to vary between form-factors, such as including a start menu and introducing a multi-desktop mode.

Consumption vs Work-Oriented Design

In terms of design, Windows 8+ has a much more consumption-oriented design, as opposed to a work-oriented design; and it has a large amount of data throughput even in the main menu. This is appealing to mass-market users who desire quick access to information, and the ability to quickly act on it. For example, the twitter live-tile not only shows the latest updates, but is a one-click access point to that data. We don’t have that efficiency; we can launch applications, or display plasmoids, but we don’t have an efficient solution that does both. On the other hand, users have complained that the live-tile interface can become chaotic, with literally dozens of tiles calling for attention.

Desktop Linux and KDE have traditionally kept towards work-oriented designs, and consumption efficiency is left in the hands of the applications. This is trouble for KDE, because we don’t bundle simple applications which other environments do; i.e weather, maps/directions, or a clock/timer/alarms app. We do keep these as desktop components, but instead of simply launching applications, KDE requires a user to use complex editing tools to add and configure those widgets. In addition, if we did bundle those applications plasma widgets still do not launch relevant applications; our weather plasmoid does not launch a weather app, our photo widget does not launch a gallery. This poses another problem because a user must also know how to create a dash with independent widgets and know how to invoke that dash if they do not wish to crowd their desktop with plasmoids.

One way this could be solved would be creating a class of “launcher widgets” which are read-only QML widgets the system would treat as icons. Additionally, we might create a new file-level protocol for a QML “icon widget” format which could enable dynamic icons for application launchers. For example, a weather app might have a QML-based icon which displays todays’ weather. Though this could cause serious performance ramifications if implemented poorly, and adds dramatic complexity to simple file-browsers.

It should be noted that you can launch plasmoids in KDE through KRunner, but this method is pretty much inaccessible for regular users. This feature is much more slanted towards development than actual real-world usage.

KDE should consider allowing widgets to flag themselves as being “launchable” – allowing them to be launched similarly to applications from a proper applications menu. Sometimes you need to make quick notes about something without the need to save files or open the “KDE Advanced Text Editor”. Maybe you just only need the dictionary once in a blue moon. Allowing these to launch as KDEs’ version of “modern apps” might be highly beneficial, and give access to KDEs well-designed plasmoids without the need to modify the desktop. Also, our container application which actually contains the widgets could offer buttons to do things like quickly add the app to the current desktop, panel, or dash. This could later be integrated into Martin Gräßlins’ server-side-decorations.

While a great deal of applications are being written in QML, launchable plasmoid applications for KDE might be a good option when use-cases are simple-enough to be desktop-ready, but still useful enough to work as ‘standalone apps’. This might also make plasmoid development more attractive to developers who work more in traditional applications. Things like maps, directions, notes, cloud-based services, contacts, and other simple utilities – especially those which piggyback off the system – would be especially viable if developed under this model. Not only would we have our own ‘metro apps’, but these ‘Plasma Apps’ would be incredibly flexible in their ability to integrate to the desktop.

Start Menus

The Windows 10 Start menu has embedded live tiles. For plasmoids which aren’t big enough to be launched as applications, or not used consistently enough to be placed on the desktop or in the panel, Plasma could offer a launcher that has an embedded widget tray, or offer pop-up containments which could house collections of plasmoids.

Technical Challenges

For the most part, Plasma is already flexible enough to allow us to extend plasmoids into ‘Plasma Apps’. As a matter of fact, the plasmoid preview utility used by developers already gets us most of the way there. For the most part, there’s no real (obvious) technical hurdles.

One design aspect would be making a ‘native’ plasma theme for plasma running in an application mode.

Pros

• Launching plasmoids as applications offers extreme occasional-use convenience.
• Ensuring widgets can easily launch related full applications fits the “simple by default, powerful when needed” mantra.
• Application developers might be more interested in plasmoid development when KDE users could launch it as a ‘real app’
• It would help fill KDEs’ need for simple applications.

Cons

• Users might not appreciate their program lists getting filled with plasmoids, especially if they can’t be hidden.
• Plasmoids looking to be used as applications would need to account for more static contexts or alternate storage locations.
• Everything listed here would add redundant applications to the system.
• If plasmoids launched generic types of applications, we would need tonnes of default application types; default weather, default stock ticker, default dictionary, etc.
• Applications lists would need to be overhauled to display plasma-apps.
• Adding widgets to widgets (for the ‘start menu’) would need a clever editing UI, adding complexity.

Notes

Overall, the main issue KDE has is the disconnect between simple applications and simple plasmoids. KDE does have the functionality of other desktops in plasma, but it can feel more cumbersome to access it, especially if it’s in a situation where you may only need it on occasion. Plasmoids like the dictionary are the perfect example of this; I know no-one who refers to a dictionary often enough to constantly need one, but I can also say everybody likely needs one on occasion. For me, launching a browser and doing a Google search is faster than digging out the plasmoid. I don’t use the dash either, but even still do we want the KDE dash to be the junk-drawer of occasionally used widgets forever?

I found that adding live tiles was beneficial to the start menu, as it does become a simple notification area; I think it would be beneficial if we were capable of embedding widgets into launchers or secondary ‘container plasmoids’. I think KDE did do this at one point – can anyone let me know? I also think launching applications by directly clicking on plasmoids should be added; opening a full weather application would be great if we could package them together, and the same goes for stocks, maps, etc etc.

Chime in!

What are your thoughts on creating a more consumption-oriented design? What did I miss, any addendums? Let us know!

A study of what-if scenarios which posit what KDE would look like if it took a different approach to certain aspects of design. Note that these posts are in no way “the direction KDE is going” and are simply a study done to reference designs and ideas we may never have investigated.

Forward

KDE and Plasma has several methods of launching programs; simple list menus, quick short-cuts, powerful multi-component menus, and task ‘pinning’… Command line. Plasmas’ default setup is to use two of these in tandem; ‘task pinning’ and multi-component menus.

Other environments tend to use the same methodology, but usually with far less configuration options. Windows, for example, often allows pinning applications as quick launchers, and a multi-component menu. Apples’ OSX takes a different approach, using a multi-component quick-launcher (the dock) and opening components via the file manager. Elementary OS takes a middle-road having a multi-component dock, and a simple launcher. Gnome uses a multi-component dashboard which serves as the ‘nerve centre’ for application launching and management.

For the sake of brevity (hahah! Like that’ll happen!), part one of this what-if will focus on Elementary OS; in addition to looking at launchers, the overall feel of the systems will also be briefly explored and discussed separately.

What if… Plasma Used Launchers from Other Systems & Environments Elementary OS?

Elementary OS is a distribution of Linux which makes used of a highly customised desktop shell called “Pantheon”, which originally started as a set of modifications to the Gnome desktop. It consists of a panel at the top, and a dock at the bottom. While visually similar to Apples’ OSX, Elementary aims for a mono-tasking approach on all actions, and has a simpler approach to task/application launching and management.

I’m going to mention “Mono-Widgets“, “Compound Widgets” and “Multitasking Widgets” several times; this is because my analysis of KDE/Plasma and Elementary presented the need for some vocabulary.

• When I refer to Mono-Widgets, I’m referring to a widget which performs only one operation. For example, the Elementary Launcher very strictly finds and launches applications. It does nothing else, and dismisses itself when the single task is complete.
• Compound Widgets perform several functions, but when a user enters a compound widget they only do one thing, then the widget exits. They only ever use one part of the widget per invocation. KDE Launchers fall into this category, bundling power, application, search, recent documents, places, favourites, and other functions into one area; however you only ever do one at a time, and then the widget dismisses itself.
• Multitasking Widgets are widgets where you’ll enter them, work on a task or two, and eventually dismiss them when you are finished. For example, the network widget will have you create, modify, update, select, and delete networks and basic network settings. Where this differs from Elementary is that Elementary will only list existing networks, opening a separate program to edit them.

Comparison to KDE/Plasma

EOS desktop components such as the Plank (the dock), and Slingshot (applications launcher) are extreme mono-tasking widgets, simplifying the work-flow substantially but also necessitating more individual widgets. A good example of this is the exclusion of power options in Slingshot, but the addition of a power widget on the far side of the panel. Ironically, KDE contains a much more comprehensive legion of widgets, many of which mono-task similarly to Elementary widgets – but instead Plasma defaults to compound widgets and multitask widgets.

Elementary supports minimal customization options out-of-box. Because they have chosen to avoid customization Elementary must approach their static configuration with much more discipline. Combined with their minimal approach, there’s a distinct feeling that every UI element added was harshly scrutinised before inclusion. Elementary almost never hides UI elements in their desktop environment; if a widget would not have space to include all the options necessary, it will instead attempt to include the options for most use-cases and provide access to a more comprehensive application. On the other side, Plasma widgets don’t tend to launch applications.

“An undiscovered feature really doesn’t exist to people who haven’t found it.”

“Simple by default, Powerful when needed”

The Plasma default layout tends to focus on displaying fewer compound widgets which rely on more robust configuration. Compound widgets come with all functionality enabled by default and tend to be “configured down” in a way that users must pick what they [i]don’t[/i] want; this is directly counter to “Simple by default”. Elementary on the other hand has exceptionally focused mono-tasking widgets, but no configuration options. In other words, Elementary meets the first half of the mantra (Simple by default), but the plasma desktop achieves neither (Powerful when needed)

Widgets in plasma which do focus on mono-tasking (such as the calendar) tend to have a higher focus on design, and are exceptionally intuitive. KDE developers could and should investigate the creation of more mono-tasking widgets for areas currently dominated by heavy-duty compound widgets. Developers could also re-investigate the default layout after mono-task widgets are complete to relegate much heavier widgets to configuration options. By packaging simple widgets into the default configuration and keeping heavier widgets as options KDE would further achieve the “Simple by default, powerful when needed” mantra.

The best example may be the Kickoff launcher which features favourites, applications, places, recently used files, account info, search, and other options. Some of these exist in other widgets, and the launcher could be forked into its remaining constituent parts; a launcher, a recent files widget, a computer widget, an account widget, etc. Plasma fails in intuitiveness when it packs this functionality into a widget and hides some components to keep the design clean such as hiding search in its launcher – where Elementary refuses to hide any feature. While this makes individual plasmoids powerful, it actually reduces the functionality because an undiscovered feature really doesn’t exist to people who haven’t found it.

Technical Challenges

If KDE were to attempt to lean towards an Elementary setup the largest hurdle would not be the addition of features or new monotasking widgets, but instead the streamlining of the desktop and its options into a functional, streamlined, and focused desktop without upsetting its user-base. This is less of a technical problem and more of an emotional one: KDE users tend to worry when applications become ‘dumbed down’ despite the fact that functionality remains. Granted, Marco Martin has done some fantastic work which eases operations like the swapping of widgets, so the road to quickly allow users to reconfigure to more complex setups has been paved.

Pros

• Elementarys’ static structure requires far less cognative throughput on its users
• Mono-widgets are lightweight, and visually more appealing. They have high discoverability.
• Mono-widgets are simple to understand and intuitive. Search will want you to type something. Launching opens applications.
• Configuration options which do exist are easier to understand, and will likely be better understood.
• Elementarys’ highly disciplined approach packs similar functionality into a much smaller package

Cons

• Mono-widgets are functionally a step back.
• Each mono-widget requires a way to get to it, pushing complexity up the UI to areas like the panel.
• Sometimes operations are complimentary or highly similar, and that is lost in mono-tasking. For example, a launcher search and a file search are highly complimentary.
• Mono-tasking can result in a “good enough” experience where widgets get the job done, but sacrifice power and convienience.
• Mono-tasking can make an otherwise capable tool feel oversimplified or underpowered.

Notes

In Plasma, default widgets should enforce a minimal configuration by default to present core functionality first, then allow users to “configure up”. For widgets added to the system via configuration tools, we should remain with the “configure down” approach to expose functionality when a user adds a (presumably) unknown widget. This is much more in-line with the “Simple by default, Powerful when needed”.

While Elementary is considered Linuxs’ most “elegant” desktop, KDE has more technology to quickly and easily iterate. KDE5/Plasma5  makes far better use of text and design elements, and actually feels more “designed” compared to Elementary in some areas; when you inspect an individual widget in Elementary they can be surprisingly utilitarian and uninsipred. The calendar is a prime example of where KDE has more visually appealing design. When Elementary Freya is released, I have no doubt that if KDE/Plasma developers hunkered-down and focused on design, we could “out-Elementary” Elementary by their next release.

On the inverse, KDE developers tend to lean towards “proper” system-level design, making them less willing to make technical exceptions for strictly design reasons, or at least slow KDE design down while better methods are engineered. This is not a bad thing. For example (as far as I know) KDE will not kludge in code to make docks adjust their colours based on wallpapers; but when similar functionality eventually does hit, it will be done in a way that is technologically superior, where plasma theme designers could easily tap well-designed APIs. Often, this comes down to the “glue” libraries used by KDE when adding APIs to QML.

Overall, technology-wise, KDE is capable of easily out-designing Elementary OS in a sustainable way; but where KDE has Technology Elementary has tenacious focus and dicipline we should learn from. They don’t try to please everybody, and perhaps KDE/Plasma shouldn’t try either. Focusing on a simpler default desktop enviornment and having power-users configure-in more powerful widgets where they want it may ultimately be a better model; power-users can be expected to “configure up”, but casual users won’t “configure down”.

Chime in!

What are your thoughts on Elementary OSs’ design merits? What did I miss, any addendums? Let us know!

A study of what-if scenarios which posit what KDE would look like if it took a different approach to certain aspects of design. Note that these posts are in no way “the direction KDE is going” and are simply a study done to reference designs and ideas we may never have investigated.

This is also an older what-if, and since it has been written, work on different approaches to design highly dynamic decorations has advanced. This post is here more/less for posterity. More info will come later on other methods.

Forward

“Client-Side Decorations” (or “CSDs” for short) are a method of decorating windows where the application is responsible for the window frame. Commonly, Linux and Linux desktop environments have favoured “Server Side” decorations (SSDs for short), where it was up to the window manager to draw the window frames. In this “What if” scenario we’ll explore two hypothetical applications; a media player and a PDF viewer, programs which might benefit from CSD technology. Before the CSD-enabled mockup, here’s what the media player application might look li ke using KDEs’ current SSD method:

And here’s what it might look like using CSD:

In the CSD design, the various window buttons are moved down into the control bar of the media player. This saves vertical space, meaning an un-maximised video will always be slightly larger. In addition, the buttons can follow a separate theme from the main window; in this case a less distracting button is used. Additionally, the application could partially fade buttons in the bottom bar, or, if the bar was laid over the video the entire bar could be faded out (when the mouse leaves) for maximum display – though this is not in the mockup.

In this PDF reader, the CSD is on the left, and uses the thumbnail column as the decoration. As PDFs generally tend to be a series of portrait sheets, vertical space is at a premium.

Technical Challenges

The main technical challenges faced by KDE developers is ensuring application consistency will continue to work under various form-factors. When Kwin (the KDE window manager) controls window borders, it can quickly and gracefully adapt to multiple form-factors. For example, in Plasma active space is at such a premium KDE can hide window decorations and embed them into the workspace itself.

The other technical challenge is protocol and cross-enviornment consistency. It’s known that CSD-enabled applications can look extremly awkward when window borders are wrapped around an application not designed to use them. In addition, protocols for drawing CSDs on Linux are a mish-mash at best, and CSD code tends to be far less portable to other desktop environments. Compounding that, KDE has additional features (such as window tabbing) which are inherently incompatible with the feature.

If KDE were to use CSDs, it would likely be preferable for all applications to support CSDs as a secondary ‘upgrade’ and default to using SSDs until the window manager explicitly enables the CSD; meaning KDE apps with CSDs would need alternate layout code. KDE might also need to reserve the ability to revoke CSDs from an application or flag them to keep CSDs disabled; for example, it might only allow Wayland-composited environments to use CSDs, as Wayland has protocols for CSD-specific problems (such as application hangups). It might revoke the CSD layout if a user disabled it, or if an application is moved into a window-tab.

Application crashes are another significant issue; If applications are made responsible for their own close buttons you enter a situation where the close button on a crashing program will fail to function. There are several technical aspects to this which can defer the impact, but in a worst-case scenario the GUI of an application will become an non-responsive picture. Wayland has solutions to detect this, while Xorg is a hot mess; if Wayland/KDE used CSDs, a window manager overlay might need to be created in the event of a crash to retake the minimal window-level control of applications.

Pros

• Applications would waste less space on screen; for small laptops this is a significant advantage.
• The decoration can be placed on any side. Applications like a movie player could hide decorations completely.
• Applications with a full-screen mode may just use the same chrome in full-screen, maintaining placement of close/minimise/maximise buttons.
• A strong CSD protocol/library could ensure reliability[/list]

Cons

• Outside of the extra code overhead, applications could more easily break in the future as technology changes.
• Depending on the implementation, applications could be larger.
• Kwin would need more code to recover, mark, or kill crashed CSD applications.
• Consistency is lost; Windows might place buttons on the top, bottom, left, or right. Users would need to adjust to applications individually.
• Poorly chosen widgets can interfere with window dragging, space meant for dragging windows might be lost.
• Depending on implementation, polling mechanisms might falsely label applications as non-responsive.

Other Points

• Applications can crash many ways, causing whole-system breaks. SSDs can’t police the whole system; Bad applications shouldn’t be the example.
• Using an “SSD until otherwise permitted” model can still allow users who dislike CSDs to enforce SSDs.
• KDE applications are beginning to ship with multiple layouts for convergence purposes; CSD layouts might piggyback on this.

Notes

On a personal level, I love applications which properly use CSDs. They’re more screen-efficent and applications can look much more professional. I also believe that CSDs will be inevitable, and that a strong KDE CSD library which enforces smart use of CSDs would be better now than applications inventing their own solutions later; especially when other environments are starting to make good use of it.  After looking at Gnomes solution, I do think CSDs as-an-upgrade would be ideal, as applications can behave “normally” until they get the go-ahead to be shiny. This will help KDE apps fit into environments like Windows, OSX, or Gnome without issues. Also, users might want to forcefully disable CSDs desktop-wide for consistency purposes, and having CSDs as-an-upgrade would assist in this.

I also think that CSDs should also be required to adhere to Kwin specifications will first and foremost; while it’s nice applications might ‘brand’ themselves using colours or unique styling, I believe allowing Kwin to dictate the style would be a usability win. In addition, KDE 5 is incredibly friendly to dark themes (or is increasingly getting better at it), and allowing CSDs to colour themselves would take away from user options. On the other hand, since windows would not necessarily display titles, colouring becomes an important identifier.

I also like the idea that a full-screen application could just continue recycling the same piece of chrome; often applications use entirely different UIs in full-screen mode, which reduces usability – especially when hot-keys are required to exit fullscreen.

Technology-wise, I’ve read impressive articles on Wayland in regards to how they’ve thought through many CSD specific problems – such as application crashes rendering windows unmovable. No matter how its sliced though, CSDs should be approached carefully and thoughtfully if they were to be implemented as a part of KDE in the future.

In terms of the “simple by default, powerful when needed” mantra, CSD decorations follow the pros and cons listed above; mainly by making more efficient use of screen-space and giving applications a more simple, less intimidating demeanour. On the other hand, it decreases the intuitivity of applications by potentially moving window controls, or causing issues in event of a hangup. I think CSD driven designs tend to be more simple and reserved (at least as Gnome has done it). Disabling the CSD desktop-wide for features like window tabbing is where “powerful when needed” kicks in; especially since its an uncommon and difficult to discover feature.

One Last Note;

This is actually a fairly old what-if, and since it has been published work on different approaches to design has advanced. This post is here more/less for posterity.

Chime in!

What are your thoughts on CSD; what did I miss, any addendums? Let us know!