hydroidev, Jul 5 2024

Description

Goal Summary

The goal is to provide users with better control and digital autonomy by adjusting discoverability, cohesion, and interoperability of interfaces for managing user data and application workflow across the ecosystem.

At a high level the changes include:

• Modifications to Activities, Virtual Desktops, Tiling, and more in KDE Plasma;
• Additions and changes to components and interfaces in KDE libraries and frameworks such as KConfig and Kiosk to coordinate adherence to user settings and improve cohesion and interoperability in application and user data management across the KDE ecosystem; and
• Adjustments in user interfaces to improve discovery and exploration of all of these options and tools to users;
• All of this with a focus on easing integration of these components in KDE applications--both within the Plasma desktop itself and separately--with both users and developers in mind

Background and Motivation

Over time, KDE has explored a number of innovative ideas concerning user organization in desktop and application workspaces, workflows, configuration, and data. Current iterations of Plasma feature Activities and Virtual Desktops for placing and organizing windows according to purpose and workflow. Desktop sessions are designed to save and restore application state between logins. Applications such as Kate and Krita offer local sessions for switching between sets of related open files. Frameworks for application configuration management are provided for via KConfig and Kiosk and pre-built components for general application needs are available in offerings such as KDialog. However, while most these features and frameworks are well maintained, innovation and exploration into new ways of providing useful behaviours and interfaces has significantly slowed, leaving many features feeling redundant and unloved.

Although initially promising, Activities are currently limited in capability and configuration, development has stagnated, and support is meager across KDE applications. This is partly because both users and developers alike are confused about the distinction between activities and virtual desktops. Meanwhile, individual applications spend precious development resources reimplementing limited, local session management or provide none at all. Users are required to search for popular and useful functionality for tiling, desktop management, and even proper KDE backup and restore in the KDE Store and external repositories, or even start bounties for these to be added, then hope these will ultimately stay maintained. Scripts modifying the behaviour of virtual desktops have to hack around the interface to provide alternative structure and behaviour. Most end users find themselves unaware of useful features like activity scripting with existing utilities to explore them designed bare bones for an experienced developer workflow.

These issues and shortcomings--among many others--concern the freedom and control users have to organize their desktop, workflows, applications, configurations, and data files; a significant portion of most user's digital lives. To meet KDE's vision to provide a diverse body of end users with freedom and control over their desktop, applications, and more, this goal proposes to revitalize, rework, experiment, and innovate on features, both extant and as-of-yet unrealized, to manage digital workspace, application workflow, and overall data organization across the KDE ecosystem of desktop applications, frameworks, and interfaces.

What it will take

What is your plan for making it happen? What do we need to do to make this reality? What kind of support do you need?

The Basics

Organizational Pillars

The overall focus of this goal is on improving organization with an emphasis on flexibility, discoverability, and interoperability across the various system and application interfaces exposed to users, power users, and developers. This not only covers tools for window management and visual organization of *graphical* user interfaces but equally organization in configuration and data files stored on behalf of users by the system and applications. Improvements may come in the form of restructuring features or components; adding new components or modules; polishing or extending APIs for better user control through scripting; and more across KDE's desktop, applications, and libraries.

The goal of providing organization breaks down into three pillars:

• User-guided Tailoring and Control: Put users in *control over their digital life* by improving and innovating on open-ended apps, components, plasmoids, and other interfaces for introspecting and modifying overall configuration and data structure in apps, workspace, and the system itself.
• Feature Cohesion and Discoverability: Knowing is half the battle: tools and features for organizing the system need to be obvious and relevant to one another and provide critical information upfront, letting users naturally find and explore more complex options at their own pace with a gentle learning curve.
• Components and Interoperability: Workflows don't flow when applications don't communicate fluidly with one another. We need to double down on exploring and developing innovative ideas, especially with regards to pushing for components over monolithic applications.

Leveraging Community Infrastructure

The KDE community provides a wide variety of services to facilitate a comfortable and flexible workflow for various developers and projects. This section simply notes any important, specific actions on how to apply the existing tools to this goal rather than the community at-large.

• Focus on facilitating community efforts by maintaining the Goal page to the standard of the current Sustainability Software Goal and doing the same for individual pages related to the goal such as reviving the Plasma/Activities wiki page.
  • This would naturally be the first place to look for a 'live' overview of current developments to help bring out-of-the-loop developers and interested users into the fold.
• Discussions and developments tend to span across multiple KDE Invent repositories, KDE Discuss threads, Phabricator threads, Bugzilla issues, Matrix rooms, etc. with relatively few links in between each. Discoverability and good housekeeping is important here for maintaining interest and a good connection between developers and users.
  • Provision a central location to track actual user's use cases for the various features, in addition to the usual use cases and personas--likely a collaborate board / doc and/or a wiki page. A similar page would be made to track and group requests, ideas, issues, and merge requests and specific user input referenced from outreach such as polls and surveys
• Keep interested parties informed with a blog or similar timeline for tracking important milestones, experimental releases, and progress updates.

Current ideas in this space are great but progress is stagnating. As a significant community-wide goal this could help provide further exposure, efforts, or resources to have developers, UI designers, and interested users weigh in and test work-in-progress solutions and provide feedback on how these new solutions facilitate or interfere their individual use-cases.

Plasma

Desktop & Workspaces

• Initial focus is to complete efforts to define a clear distinction between Activities, Virtual Desktops, and Sessions by building on tables like this one.
  • A number of KDE's developers are adamant that the two represent orthogonal concepts but the UI for Activities makes them inextricably linked to Virtual Desktops. "To the user, the interface is the product" (Video): Users tend to understand Activities as simply another 'dimension' of Virtual Desktops because visually that's how they are presented and behave: e.g. opening a text file in Kate will force switch activities to use an existing Kate process (often in the wrong Kate session); stopping an activity appears to remove virtual desktop space; etc.
  • We need a clear resolution on whether intentional limitations in the design of Activities and Virtual Desktops are actually inherent to the concepts and whether these goals match with how users utilize these features ("Plasma never defines what the user is allowed to do"). Many interesting uses and parallels of the existing concepts have been offered. However the underlying tech needs to be general enough to allow users or scripts to define these kinds of specific uses, rather than facilitate one in particular.
  • Subsequently, we should continue to work on breaking this behavior apart as suggested here, potentially redefining the concepts and focusing on making the orthogonal features of each more distinct to users in their presentation. Along these lines, it would make sense to rename Activities to represent their more slimmed down functionality rather than how to use them.
• Improve cohesion in session management across the bulk of applications by making activities more transparent to applications. Support even from KDE apps is very weak due to the current opt-in model and that makes the feature hard to utilize in the intended way while requiring more maintenance on the part of all application developers instead of one team. Efforts should focus on broad solutions that *actually work* regardless of the application since this kind of tool will actually benefit users.
  • One of the more promising ideas to focus on in testing and development include associating activities with seperate user accounts and/or leveraging lightweight sandboxing or jail solutions; non-technical users would benefit from making it easier to employ these concepts through Plasma's interfaces to properly divide application behaviour and configuration between Activities.
• Virtual Desktops should shift to accomodate the 'additional dimension' functionality that users seem to appreciate in Activities, while Activities focus on separating application configuration and data at a lower level. The plan here is to change the 'row' concept to 'axis', likely moving row visualization and wraparound to plasmoid settings (e.g. the pager), desktop effects, etc. instead. Similar redesign should be explored to separate Virtual Desktops from Screens.
• Improve standard tiling capabilities and reinvent window grouping to better facilitate component based workflows while improving the KDE experience to users for whom the general windowing behaviour isn't useful. What features to add should follow KDE's visual design philosophy, studying which tiling based features of other desktops provide actual use to users and which popular community plugins could be polished and offered by default in KDE.

Naturally, this goal concerns more than just organization of Activities and Virtual Desktops. A strive for better ways to enable users to tailor their experience in management of applications and configurations, invites application, plasmoid, library, and component developers to participate as well. Each of these areas affect how users are able to interact with their computer as a whole and affects the interface between the user and various services on their device, with some specifically designed to provide configuration or application management capabilities.

System Settings & Configuration Interfaces

Improve the cohesion and semantic proximity of related configurations in settings:

• The settings for Activities, Virtual Desktops, and Sessions should have an apparent relationship to one another in the way the settings are laid out, such as by being grouped together or linking to one another
• Improve discovery of various configurations and data related to each setting: e.g. configuration for Activities, such as favourite or pinned applications, has no presence in the Activity related settings but only a very meager set of options to set on each Activity
• Other modules have similar organizational design problems, e.g. makes no considerations in its design or wording to suggest that the system might have non-KDE related services, making it difficult for non-technical users to understand and discover the full functionality of their desktop
• When settings and configuration and the Get New Stuff dialog / KDE Store can't account for specific use cases, there should be links and docs nearby to help smooth onboarding for the average user to discover, explore, and take advantage of scripting interfaces and existing development tools such as the , to empower users with more fine-grained local control over their desktop.

KDE Applications

• Application developers are encouraged to provide their perspective in discussions on how to make Activities and their associated configurations transparent to applications with fewer interfaces requiring opt-in for instance to share only parts of configurations between individual activities more seemlessly.
  • This especially regards what capabilities the remaining opt-in interfaces should provide, e.g. synchronizing specific parts of the application's configuration across activities; also whether functionality from specs like XDG Portals is enough or if there are features more in-scope for KDE than Portals; etc.
• Encourage applications to provide additional interfaces for some of their customized but generally useful components in for more scripting potential
  • This is a focus on the third pillar of moving more towards components and interoperability rather than large applications; allowing applications to 'borrow' more functionality from one another improves user control and choice
• Explore other areas where KDE's libraries and compile-time components are are missing , ignored, or re-implemented, and what kind of runtime components and services could be encouraged, focusing on the pillars including user control over interoperability.

KDE Libraries and Frameworks

• Work on adapting functionality and configuration through interfaces like Kiosk or Activity scripts to more discoverable, user-friendly interfaces and components; e.g. maybe a version of designed to give non-technical end users a chance to learn and explore what kinds of scripting or interfaces their desktop provides for customization beyond the normal system settings interface.
• Improvements to configuration management in libraries such as KConfig to make the actual configuration and data files for Plasma, individual Activities, Sessions, and some KDE apps easier to compose, swap, save, restore, etc.
  • Make KDE's frameworks more flexible to the user's needs regarding overall organization of configuration files, focusing on how to address issues such as this one. At minimum this should include an environment variable honored by KDE and its apps, a la
  • Most application configuration could likely be handled by the suggested changes to Activities/Sessions anyways, but we should still work with KDE application and library developers to understand what kind of API would provide flexibility for both users and developers beyond hardcoding some arbitrary group of configurations into a likely less-than-ideal library/location

In General

This goal is intended to be extensible to allow users and developers alike to add their own ideas into the mix, allowing for the goal to develop further to encompass other plans within the breadth of the goal's overall pillars. Just to throw a smattering of additional (but incomplete) ideas and examples to get the community thinking about other ways KDE could improve on user control in application configuration and management:

• Looking for other ways to lessen the hold of individual monolithic applications as encouraged in the recommended reading for design
  • This complements the changes in VDs and Activities by making individual applications less reliant on other applications and providing better mechanisms for not only visually organizing workflows through tiling and grouping of apps but by helping the applications communicate better through the desktop.

• Explore ways to make it easier for users to explore and test changes to their overall desktop configuration while having an easy way to revert to a specific known-good configuration, potentially extending this to applications by tracking non-KDE configuration files
  • e.g. what can be learned and applied from immutable configuration setups like Nix to give users more freedom to test while drawing from KDE's history in providing an end-user friendly interface and experience

• Innovation to add new or modify existing tools allowing users to better introspect their system, learn about, or ultimately modify it in ways that work for the average user
  • The plasma-interactiveconsole is designed to let developers poke around activity scripting, but its design is limited in useful, modern IDE features and has a very tradition developer-oriented interface. Maybe KDE could benefit from providing a plugin for the more friendly Kate application and/or we could look into other ideas for how to empower less tech-savvy KDE users through visual programming languages (e.g. Blockly/Scratch) or other methods of 'End-User Development' (e.g. IFTTT automation)
  • Components similar to that provide more varied types of functionality (e.g. a color picker) and/or provide APIs and/or GUIs building on like so that users could swap between different components offering the same kind of programmatic interface with a different human interface.

• Expand user options in deciding how links clicked in applications open in other applications; the current model allows setting exactly one default option for this with no built-in option to drop or ignore attempts from a program to open

• Along the vein of window grouping, the desktop could provide a means for panels and or plasmoids to be attached to windows as well, extending the windowing metaphor to make plasmoids and application components associated with particular workflows work more like dockers in applications like Krita

How we know we succeeded

Will we have fluffy kittens? Anything we can measure? How will the world be better once we're done with this?

Towards the end of the goal, KDE users will notice significant updates to application management in the Plasma desktop and better cohesion in session and configuration management options across a majority of KDE applications.

System settings pages for Virtual Desktops, Activities, and Sessions will have more relevant and clearly distinct options from one another while the pages themselves feel more semantically connected by their organization in the interface. Users and developers will be able to clearly distinguish between each of these concepts and why each is useful both individually and together when discussing them and suggesting improvements. Configuration of applications will be easily discoverable and searchable within the module to ensure a one-stop shop so users don't have to hunt for an errant setting; many configurations will also discoverable and/or available from the KDE apps, plasmoids, and panels they relate to. Users will feel comfortable experimenting with the different configurations after getting familiar with presets including one similar to the current workspace setup. Similarly, the average user will find it easier to replicate KDE-wide configuration to new installations without need for an external application.

Developers will be more confident in the existance and maintainability of each of these features. Fewer feature requests will be filed regarding capability, flexibility, and organization in application management interfaces, overall KDE configuration files in the underlying system. Many existing requests will be resolved or closed as wontfix, with the remainder representing futher additions in line with the direction and pillars pushed by this goal. Community members will be able to see the progress, timeline, and milestones of completed work over the goal's lifetime on its wiki page, blog, etc. and be able to use its links to scout for unresolved threads, discussions, and ideas to explore beyond the goal's initial two year span. There will be a noticeable improvement towards flexibility via components over full applications in the desktop interface as well as KDE frameworks and APIs, representing a more solid foundation for future work (or another goal) to build upon.

More generally, when the goal has succeeded users will feel:

• less annoyance, dismay, and distress related to poor availability or accessibility of methods or options to guide and assist overall organization, introspection, and customization of their desktop, applications, and data;
• that available configuration of their desktop and KDE applications don't step on the toes of the organization scheme and workflow that works best for them--that it doesn't get in their way, ignore their settings, or hardcode problematic behavior; and
• that the tools and options they need to organize their workspace and data are readily available, accessible, and apparent to them

For this goal, the KDE community will mostly leverage its existing infrastructure and the varied skillset of our talented developers new and old to track progress of the goal and measure and apply user feedback and satisfaction. This includes community outreach through surveys and opt-in metrics like that used in Dolphin.

Champions

The team (so far) is:

• @hydroidev - Visioneer (Vision + Technical Steering)
  • I'm aiming to provide a cohesive vision and technical direction by leveraging my academic and career experience in computer science. I pay attention to a lot of emerging standards and projects but I don't have much of a contribution history for open-source projects. I think this is a good opportunity to change that in more ways than just submitting pull requests.
• XXX
• XXX

Looking for Champions offering additional guidance and experience for promotional activities in particular, but also to round out technical direction and vision with complementary perspectives.

I am willing to put work into this

• add your name

I am interested

• add your name