N
Nathan Mellor
These are the requirements related to SIP that I am attempting to
understand.
==
Required: Applications Must Handle the Input Panel Appearing/Disappearing
From the UI perspective, the application must be designed to account for the
fact that an 80-pixel tall Soft Input Panel (SIP) may be docked in the area
immediately above the command bar at any time, requiring the application to
be resized out of the way. The specific requirements are:
1). All text entry fields must be accessible with the SIP up. This can be
accomplished either by placing all edit fields high enough on the screen so
that they will not be obscured by an 80 pixel tall SIP, or by having a
scroll bar when the SIP is displayed (or both).
2) Applications must resize in response to docked input methods. This
includes resizing and/or shifting things like dialog tabs, status bars, and
other elements as needed, and/or resizing or drawing scroll bars to ensure
all UI is accessible while an 80-pixel tall SIP is up. Note that a docked
input method may be as tall as 140 pixels, but applications are not expected
to be optimized for a SIP height greater than 80 pixels.
===
1). Number one sounds reasonable and understandable. Keep *text* inputs up
higher than 80 pixels or be prepared to scroll or resize.
2) You must resize things in response to the SIP. This no longer applies to
just text input UI, and having scroll bars is no longer considered
acceptable.
Why is requirement 1 even mentioned? It seems superceded by requirement 2.
My main window, for example, is four tab pages in a tab control. The SIP is
not needed for input in any of them. However, I can not make the SIP button
disappear. Is it reasonable to resize all these subforms and a tabcontrol
for an input method that is not valid on any of these screens?
In another example, a dialog is tabbed and does require textual input in
some of its screens. The textboxes are above the 80 pixel no man's land.
However, if you move the tab control tabs up, they will obscure some of the
text boxes and other UI elements.
Nathan
understand.
==
Required: Applications Must Handle the Input Panel Appearing/Disappearing
From the UI perspective, the application must be designed to account for the
fact that an 80-pixel tall Soft Input Panel (SIP) may be docked in the area
immediately above the command bar at any time, requiring the application to
be resized out of the way. The specific requirements are:
1). All text entry fields must be accessible with the SIP up. This can be
accomplished either by placing all edit fields high enough on the screen so
that they will not be obscured by an 80 pixel tall SIP, or by having a
scroll bar when the SIP is displayed (or both).
2) Applications must resize in response to docked input methods. This
includes resizing and/or shifting things like dialog tabs, status bars, and
other elements as needed, and/or resizing or drawing scroll bars to ensure
all UI is accessible while an 80-pixel tall SIP is up. Note that a docked
input method may be as tall as 140 pixels, but applications are not expected
to be optimized for a SIP height greater than 80 pixels.
===
1). Number one sounds reasonable and understandable. Keep *text* inputs up
higher than 80 pixels or be prepared to scroll or resize.
2) You must resize things in response to the SIP. This no longer applies to
just text input UI, and having scroll bars is no longer considered
acceptable.
Why is requirement 1 even mentioned? It seems superceded by requirement 2.
My main window, for example, is four tab pages in a tab control. The SIP is
not needed for input in any of them. However, I can not make the SIP button
disappear. Is it reasonable to resize all these subforms and a tabcontrol
for an input method that is not valid on any of these screens?
In another example, a dialog is tabbed and does require textual input in
some of its screens. The textboxes are above the 80 pixel no man's land.
However, if you move the tab control tabs up, they will obscure some of the
text boxes and other UI elements.
Nathan