diff --git a/source/img/Desktop_UX.png b/source/img/Desktop_UX.png new file mode 100644 index 0000000..b1c73fb Binary files /dev/null and b/source/img/Desktop_UX.png differ diff --git a/source/introduction/convergence.rst b/source/introduction/convergence.rst index a3a2f64..2382a7c 100644 --- a/source/introduction/convergence.rst +++ b/source/introduction/convergence.rst @@ -1,33 +1,105 @@ -Optimized convergence +Optimized Convergence ===================== -Kirigami is made with convergent applications in mind. "Convergent" for -KDE means that one instance of an application can adapt its user -interface (UI) depending on the context, most importantly depending on: - -- Primary input method (for now "pointing device + keyboard" vs. touch, - in the future possibly also simple directional inputs like TV - remotes, game controllers, in-vehicle controls, ...) -- Physical screen size (for now phone vs. tablet vs. laptop/desktop - screen, in the future possibly also TV screens, smart watches, ...) -- Screen orientation / aspect ratio (mostly portrait vs. landscape) - -Kirigami is not about simple "responsive" user interfaces, though (i.e. -those which just adapt their layout a bit), but really optimized ones. -For example, "pointing device + keyboard" UIs should use -mouse-over/hover effects to reveal inline controls, whereas touch UIs -should use touch gestures. - -When navigating through hierarchies, portrait mode mode shows only one -column/page at a time, whereas landscape shows multiple ones. - -UIs for screens with different input methods show more controls permanently, whereas UIs for -small screens show only the most important controls always, while -showing secondary controls only on demand. The convergence for these -screens will prefer to show only the most important controls when the -screen has become smaller. Developers and designers must determine which -elements on the screen are the most relevant for use. - -Kirigami Components will do some of that adaptation/optimization work -for you, but be prepared to also manually adapt your user interface for -different devices. +The design of KDE software, and by extension the KDE HIG, is made with +convergence in mind. *Convergence* means that a user interface (UI) can +immediately adapt its user experience (UX) depending on the UX Context. + +There terms are explained in the :doc:`resources/glossary`. + +Device Types +------------ + +The KDE HIG defines an optimal UX for each UX Context which are identified as +Device Type. The optimal UX of a Device Type describes how the user interface +(UI) should behave to provide users with the best user experience (UX). This +is defined in :doc:`devicetypeUX` + +Some devices may change their UX Context to correspond with a different Device +Type, e.g. adding a keyboard and mouse to a tablet. This means a different UX +may need to be provided to the user. If minimal changes are needed, this can be +achieved with a "responsive" design, as described in :doc:`responsive`. For more +extensive changes, an entirely different UI may need to be presented. + +Common Components +----------------- + +Convergence requires an understanding of the commonalities in the UI. To that +end, we define a set of Common Components which are independent of any device +type. Convergence can then be implemented by providing variations of these +common UI components which correspond with the optimal UX of each Device Type. + +For each Common Component we describe what it does and define its user story. +This user story describes the functionality of the component from a user's +perspective. This provides more detail and context than the short description +of what the component does. + +- **Workspace**: The top-level container of the workspace. Often called desktop, + home screen or shell, it shows your wallpaper and allows users to add widgets, + app launchers, files or folders. + + - **Application Launcher**: Provides an overview of installed applications and + allows the user to launch one of them. + + - *User Story: Susan wants to launch any of her applications so she can use + its functionality.* + + - **Application Shortcuts**: Provides quick access to often-used applications. + + - *User Story: Susan wants to launch her favorite applications more + quickly than other applications so she can use her device more efficiently.* + + - **Active Application Overview**: Provides an overview of the active + applications that are directly used by the user. + + - *User Story: Susan wants to switch between the applications she is using + so she can efficiently use the functionality from multiple applications.* + + - **Workspace Actions**: Provides quick access to functionality + integrated into the workspace that needs to highly visible to the user. These + are things like enabling/disable wifi and bluetooth or showing notifications. + + - *User Story: Susan wants to access functionality integrated into the + workspace so she can configure it to suit her needs.* + + - **Application-Workspace Interaction**: Displays information about active + applications and provides ways to change how the application runs within the + workspace (e.g. minimize, maximize, close). + + - *User Story: Susan wants to customize how an application runs within the + workspace so she can configure it to suit her needs.* + +- **Application**: The top-level container of a single application which is + directly used by the user. + + - **Application Tools**: Provides access to common functionality of + applications. An application may also choose to provide this functionality in + the Application Content. + + - *User Story: Susan wants to access common functionality of applications in a + similar way for all applications so she can always easily find this + functionality.* + + - **Application Content**: The actual content of an application. This depends + on the application itself but conformance to the KDE HIG should make it + easier to allow convergence for this component + + - *User Story: Susan wants to access the content of the application so she + can use its functionality.* + +These common components may become a bit more clear with a visual example: + +.. figure:: /img/Desktop_UX.png + :scale: 25% + :alt: Example showing the common components on a Desktop device type + +Making convergent applications +------------------------------ + +The KDE HIG describes patterns and components that an application developer can +use to manually define how their application fits the UX of each device type. +The UI toolkit Kirigami provides many of these patterns and components already +so they can be easily integrated in the application. If application developers +keep to the recommendations and best practices from the KDE HIG, their +application would support convergence. These recommendations may include manual +work for convergence, like creating additional UIs for different Device Types. diff --git a/source/introduction/devicetypeUX.rst b/source/introduction/devicetypeUX.rst new file mode 100644 index 0000000..0f239ac --- /dev/null +++ b/source/introduction/devicetypeUX.rst @@ -0,0 +1,150 @@ +Device Type UX +============== + +A Device Type corresponds to the UX Context of a specific user experience (UX). +So for each Device Type the UX Context and the optimal UX are defined here. An +example is included to indicate how this might influence the Common Components +(which are described in :doc:`convergence`), but it is not part of the +definition for the Device Type. + +A single device may represent multiple Device Types so the UI would need to +adapt to the Device Type most closely matching the device's current behaviour in +order to provide an optimal UX. For example, a tablet will normally have an +optimal UX, as defined for a Tablet. When the tablet is docked into its +docking station its UX Context more closely matches that of the Desktop/Laptop +UX. So the UI needs to be changed to correspond with the optimal UX for a +Desktop/Laptop. This example essentially shows how convergence works. + +.. contents:: :depth: 2 + +Desktop/Laptop +-------------- + +UX Context +^^^^^^^^^^ +- Primary Input method: *Keyboard/Pointing device from close range.* +- Screen size: *Moderate to Large.* +- Screen orientation: *Landscape, fixed.* + +Optimal UX +^^^^^^^^^^ +Since there is sufficient space, all components are directly accessible and +multiple applications can be shown at once. The use of a keyboard allows quick +and efficient text input without any on-screen elements. Pointing devices are +highly accurate and can use mouse-over (or "hover") effects. This allows for +additional elements, like hidden controls, to be shown on-screen when the cursor +"hovers" over a specific area. It is also possible to configure the workspace to +always maximize applications, which is more suitable for smaller screen sizes. + +Example +^^^^^^^ +This example shows how the Desktop UX can be applied in the Plasma Desktop +workspace: + +- **Workspace**: has Virtual Desktops. + + - **Application Launcher**: Kickoff Menu in the taskbar. + - **Application Shortcuts**: Applications can be dragged to the Panel or + pinned in the Active Application Overview. + - **Active Application Overview**: Task Manager in the taskbar. + - **Workspace Actions**: System Tray in the taskbar. + - **Application-Workspace Interaction**: Window Decorations for each + application. + +- **Application**: is windowed. + + - **Application Tools**: shows all top-level menu items at once at the top of + the application window. + - **Application Content**: most applications are already optimized for this + device type. + +.. figure:: /img/Desktop_UX.png + :scale: 25% + :alt: Example of the Desktop UX in the Plasma Desktop + +Tablet +------ + +UX Context +^^^^^^^^^^ +- Primary Input method: *Touchscreen from close range, usually with both hands.* +- Screen size: *Moderate.* +- Screen orientation: *Landscape/Portrait, dynamic.* + +Optimal UX +^^^^^^^^^^ +The workspace hides as much as possible, given the lack of screen space. The +main focus is the Application Content. Components are designed to be controlled +by fingers, which are less accurate than a pointing device. Given that the user +interacts directly with the screen, swiping inwards from screen edges can be +used to access otherwise hidden components. + +Example +^^^^^^^ +This example shows how the Tablet UX can be applied in a Plasma Tablet workspace +(though this does not exist yet, it is based on common tablet interfaces such as +on Android tablets): + +- **Workspace**: has multiple home screens (similar to Virtual Desktops). + + - **Application Launcher**: a launcher accessible from the home screen (not + necessarily fullscreen). + - **Application Shortcuts**: the bottom bar on the home screen. + - **Active Application Overview**: a fullscreen application switcher accessible + from the bottom bar or auto-hidden controls (like a button bar containing the + Home, Back and application switcher buttons). + - **Workspace Actions**: a minimal top bar that auto-hides. + - **Application-Workspace Interaction**: only from the Active Application + Overview (close only). + +- **Application**: running fullscreen or tiled. + + - **Application Tools**: available from a single button within the Application + Content, a component shown by swiping from the edge of the workspace or + through a shortcut (e.g. long-press a button in the button bar). + - **Application Content**: needs to conform to the KDE HIG in order to display + content in a way that's suitable for this device type. + +Smartphone +---------- + +UX Context +^^^^^^^^^^ +- Primary Input method: *Touchscreen from close range, mostly with one hand.* +- Screen size: *Small.* +- Screen orientation: *Landscape/Portrait, dynamic.* + +Optimal UX +^^^^^^^^^^ +The workspace hides as much as possible, given the lack of screen space. The +main focus is the Application Content. Components are designed to be controlled +by fingers, which are less accurate than a pointing device. This UX differs from +the Tablet UX in that the Application Content is adapted more heavily to the +smaller screen size, for which guidelines are provided in this KDE HIG. Also, +while it is optimized for one-handed use it may sometimes be necessary to use +both hands. + +Example +^^^^^^^ +This example shows how the Smartphone UX can be applied in the Plasma Mobile +workspace: + +- **Workspace**: has multiple home screens (similar to Virtual Desktops). + + - **Application Launcher**: a fullscreen launcher accessible from the home + screen. + - **Application Shortcuts**: the bottom bar on the home screen. + - **Active Application Overview**: a fullscreen application switcher + accessible from the bottom bar or auto-hidden controls (like a button bar + containing the Home, Back and application switcher buttons). + - **Workspace Actions**: a minimal top bar that auto-hides. + - **Application-Workspace Interaction**: only from the Active Application + Overview (close only). + +- **Application**: always running fullscreen. + + - **Application Menu**: available from a single button within the Application + Content, a component shown by swiping from the edge of the workspace or + through a shortcut (e.g. long-press a button in the button bar). + - **Application Content**: needs to conform to the KDE HIG in order to display + content in a way that's suitable for this device type. diff --git a/source/introduction/index.rst b/source/introduction/index.rst index d00f3cd..824a386 100644 --- a/source/introduction/index.rst +++ b/source/introduction/index.rst @@ -1,23 +1,25 @@ Introduction ============ .. toctree:: :titlesonly: :hidden: vision architecture convergence + devicetypeUX responsive concept personas research * :doc:`vision` * :doc:`architecture` * :doc:`convergence` +* :doc:`devicetypeUX` * :doc:`responsive` * :doc:`concept` * :doc:`personas` * :doc:`research`