[gnome-devel-docs/wip/aday/gnome-devel-docs-add-adaptive: 2/2] hig: fold adaptive guidelines into the other pages

[Allan Day <allanday src gnome org>]

commit 87ff730b085a014f96e04723e4b879dcbe49a06f
Author: Allan Day <allanpday gmail com>
Date:   Wed Feb 20 15:43:21 2019 +0000

    hig: fold adaptive guidelines into the other pages
    
    Make adaptive design part of the standard pages, rather than have
    it separated off on its own page.

 hig/C/adaptive-design.page         | 48 --------------------------------------
 hig/C/design-principles.page       |  8 +++----
 hig/C/display-compatibility.page   |  4 +++-
 hig/C/index.page                   |  2 +-
 hig/C/pointer-and-touch-input.page | 18 +++++++++++++-
 5 files changed, 25 insertions(+), 55 deletions(-)
---
diff --git a/hig/C/design-principles.page b/hig/C/design-principles.page
index 21cad5ff..0f71e1f9 100644
--- a/hig/C/design-principles.page
+++ b/hig/C/design-principles.page
@@ -110,12 +110,12 @@
 
 </section>
 
-<section id="emotion">
-<title>Use emotion and humor (sparingly)</title>
+<section id="hardware-support">
+<title>Design for a range of hardware</title>
 
-<p>Used effectively, emotion and humor can lift the experience provided by your application, and help to 
develop a positive relationship with your users. Be careful not to over-use these techniques, though — it is 
far more effective to pick a small number of moments to use emotion, rather than spraying them throughout 
your user interface.</p>
+<p>Modern hardware includes a range of device types, including different screen sizes and input devices. 
These can vary dynamically during a session as displays and input devices are added and removed.</p>
 
-<p>Be welcoming when your application is used for the first time. Using humor when things go wrong is 
another effective technique.</p>
+<p>GNOME's design patterns allow applications that provide a great experience across this range of devices. 
Applications can also be made to adapt between desktop and phone form factors.</p>
 
 </section>
 
diff --git a/hig/C/display-compatibility.page b/hig/C/display-compatibility.page
index 97517b6f..76482e92 100644
--- a/hig/C/display-compatibility.page
+++ b/hig/C/display-compatibility.page
@@ -22,7 +22,9 @@
 
 <list>
 <item><p>It should be possible for all application windows to fit on the smallest recommended displays for 
GNOME 3. Currently, this is 1024×600 pixels.</p></item>
-<item><p>Ensure that your application works well in portrait orientation. The minimum recommended width for 
portrait mode is 768 pixels.</p></item>
+<item><p>For desktop screens in portait mode, the minimum recommended width for portrait mode is 768 
pixels.</p></item>
+<item><p>Applications intended to support phone form factors should fit onto 360×600 pixels for portrait, 
and 720×290 pixels for landscape.</p></item>
+<item><p>If an application requires keyboard input, it should be prepared to be vertically resized when the 
on-screen keyboard is opened.</p></item>
 <item><p>All primary windows should be resizable. This ensures that transitions between landscape and 
portrait mode can be automatically handled by the window manager.</p></item>
 <item><p>Test to make sure that your interface works well on large displays. Where possible, scale content 
to make the best use of available space, or use fixed width layouts to ensure that interface elements 
maintain effective grouping and alignment.</p></item>
 </list>
diff --git a/hig/C/index.page b/hig/C/index.page
index 5c051357..6f83252f 100644
--- a/hig/C/index.page
+++ b/hig/C/index.page
@@ -79,7 +79,7 @@
 <td><p>Keyboard navigation, access and shortcut keys.</p></td>
 </tr>
 <tr>
-<td><p><link xref="adaptive-design"><em style="strong">Adaptive design</em></link></p></td>
+<td><p><link xref="display-compatibility"><em style="strong">Display compatibility</em></link></p></td>
 <td><p>How to support different device and display types.</p></td>
 </tr>
 </table>
diff --git a/hig/C/pointer-and-touch-input.page b/hig/C/pointer-and-touch-input.page
index 7394af97..0f5f4079 100644
--- a/hig/C/pointer-and-touch-input.page
+++ b/hig/C/pointer-and-touch-input.page
@@ -16,7 +16,7 @@
 
 <title>Pointer and touch input</title>
 
-<p>Pointer and touch input are two of the primary means through which users will interact with your 
application.</p>
+<p>This page includes basic information about how to design for pointer and touch input. It covers standard 
conventions for input of this type, as well as considerations for handling different types of input 
devices.</p>
 
 <section id="pointer-input">
 <title>Pointer input</title>
@@ -219,5 +219,21 @@
 </table>
 
 </section>
+
+</section>
+
+<section id="adaptive">
+<title>Adaptive Considerations</title>
+
+<p>Modern hardware means that people can use a variety of input devices. Input devices can change as they 
are added and removed, and multiple pointing devices can sometimes be used in combination. It is therefore 
important that, as far as possible, applications accommodate the full range of pointing and touch devices, 
and adapt to hardware changes.</p>
+
+<list>
+<item><p>Most applications should assume that they will be used on devices with and without keyboard or 
pointing device.</p></item>
+<item><p>Pay particular attention to actions or information that are shown on pointer hover, as these will 
not be available with touch screens. Any action that is only shown on hover should also be available on touch 
through some other means.</p></item>
+<item><p>It is often possible to create interfaces which work well with both pointer and touch input. 
However, it can be appropriate to change the UI depending on the input devices that are present.</p></item>
+<item><p>One useful technique can be to expose actions that are typically acheived with touch gestures only 
on pointer hover. For example, zoom controls can be shown on pointer hover or movement, while being acheived 
with pinch gestures on touch. This means that unnecessary controls aren't shown when using touch, but are 
still available with pointer devices.</p></item>
+<item><p>Since displays of any size can be touch-enabled, click targets sizes should always be large enough 
to be usable on touch.</p></item>
+</list>
+
 </section>
 </page>