Design features of tachy interfaces
This is a translation of the original article Designing for touch.
The principles of managing familiar desktop interfaces are turned upside down when it comes to touch interfaces. This article provides guidance from Josh Clark, an interaction design engineer, on the development of interfaces for mobile touch devices and compares the touch interfaces of Android, iPhone, and iPad devices.
')
To succeed in developing a mobile interface, it is not enough just to squeeze it into the frame of a tiny screen of a mobile device. Effective mobile touch interfaces allow you to adapt the gestures of our clumsy fingers to control. The interface features of portable devices encourage developers to go beyond the principles of graphic and information design and step onto industrial design territory. Here, in the world of sensory devices, at stake is nothing but ergonomics itself. Now you can not only look at the pixels: you can touch them, and they should be pleasant to the touch.
When designing a touch device interface, you need to be clear about how the device lies in your hand and how the user's fingers cover it. Using, for example, a mobile phone, we mostly wield a thumb (although, probably, there are originals who hold the phone in some other sophisticated way). Thus, when developing an interface for a phone, it is necessary to adjust to the user's thumb.
Oh, thumbs up! It is they (and, probably, the love of gossip about the lives of celebrities) that distinguish us from the dumb beasts. Unfortunately, you can't reach everything with your thumb. Of course, with proper effort, the thumb can reach almost any point on the screen of a mobile phone (if you do not take into account the very giant models), but without unnecessary stress you can work only with the third part of the screen - its lower part from the side opposite the thumb.
It is in this zone that the main elements of the touch interface should be located. If you take the phone, for example, in the right hand, then your thumb will be above the lower left corner of the screen.
For this reason, in mobile device interfaces, toolbars and navigation elements are usually located at the bottom of the screen, whereas in traditional desktop applications interfaces they are usually located at the top of the screen: you will most likely find the menu of desktop applications at the top of the screen or window, and the navigation elements of websites - at the top of the pages. However, the use of the thumb imposes its limitations, turning the usual desktop interfaces upside down - and the navigation tools along with the main interface elements move to the bottom of the screen.
The thumb to the bottom of the screen of a mobile device is a much more important factor when designing mobile interfaces than choosing between the left and right side of the screen. As it turns out, most mobile phone users easily change hands when working with the device. Right-handers often and with pleasure “go to the left” (sometimes it comes to the fact that the left hand is used more often than the right), and left-handers, respectively, often change the left with the right. Although it is believed that the average user is more likely to use his right hand than his left, there is still not a sufficiently clear trend, so developers can relax and not puzzle over the question “right or left ?!”.
Our rule of thumb works regardless of the hand in which the user holds the device, and allows you to build an effective visual hierarchy of interface elements. The most frequently used buttons should be placed at the bottom of the screen, where the user will be comfortable to press them. All other controls should be moved away - away from sin. In iOS applications, for example, the Edit button is usually placed in the upper right corner — that is, in sight, but out of direct reach, which avoids accidental clicks.
Placing the main interface elements at the bottom of the device screen is necessary not only to make it more comfortable to be controlled with your thumb, but simply because otherwise the user's fingers obscure the screen. With the interface elements at the bottom, your hands do not overlap the displayed content. To ensure that the content of the developed application is visible, place it above the controls. This logical and familiar approach is used in most physical devices, such as iPods, calculators, cell phones, bathroom scales, and so on: content is on top, controls are on bottom.
However, this rule is not so simple as we would like: in particular, Android developers took and placed the corresponding buttons on the bottom of the close screens of the corresponding devices (up to the release of Android 3 "Honeycomb", the physical buttons, including Android 4 "Ice Cream Sandwich" - only virtual). Of course, according to the reasons described above, these buttons should be placed at the bottom of the screen, but this leads to the OS control buttons and application control buttons being heaped, which makes it difficult to work with the touch interface. Placing additional controls at the bottom of the screen leads to a jumble of toolbars - and you have to admit that in such interfaces, alas, the user is constantly at risk of clicking somewhere not there. And on the screen overlapped by the thumb, to avoid such errors is almost impossible. Look at this main screen of the Android device - it actually leaves the user no chance of error-free control.
When developing touch interfaces, such clutter of controls (especially at the bottom of the screen) should be avoided by all means. Unfortunately, this means that the controls for Android applications must be placed at the top of the screen in order to avoid crowds at the bottom, which is occupied by system controls. Such an alignment is far from ideal: the navigation elements are outside the zone of direct reach of the thumb, and when the user tries to reach them, his hand covers the entire screen. But even such inconveniences are insignificant compared to the situation when the finger constantly touches the adjacent buttons when pressed.
On Android devices, navigation and control elements should be placed at the top. This is the opposite principle used in iPhone devices, where the Home button does not interfere with applications, as is the case with the Android system buttons. Compare Foursquare apps for Android (left) and for iPhone (right).
Trying to avoid cluttering up the interface elements on the screens of mobile devices, we also encounter problems with the use of websites. As you know, any websites and web applications function within another application - a web browser. In browsers on many mobile platforms, there are also buttons and controls that can make it difficult to work with the user interface during web navigation. Consequently, in the context of working with websites, you should avoid pinning navigation elements at the bottom of the screen, because otherwise the website’s toolbar will be in rather close proximity to the browser’s toolbar (this recommendation is also supported by the fact that position (fixed) is not supported in the CSS of all mobile browsers equally, which makes fixing the toolbar at the bottom is quite a difficult task).
The solution is not to place the web navigation elements at the top of the screen (as is the case with Android devices), but rather to move them to the bottom of the page. Since a large part of the resources of mobile browsers "eat up" a variety of bells and whistles, in no case should you score the top part of a web page with navigation parameters, finally displacing the content from the screen.
Luke Wroblewski, in a truly magnificent book Mobile First, says: “Too often, user relationships with mobile web applications ... begin not with the actual content, but with the list of navigation options. When working with mobile devices, time can be literally worth its weight in gold, and downloading files can cost real money, so try to give people what they need as quickly as possible. ”
When working with mobile applications, the content should be in the foreground, and the main navigation elements should be placed below and not let them crawl all over the screen. Wroblewski calls for the use of a design pattern, as an example of which is the Ad Age mobile website: all navigation elements are hidden and appear when you click the Menu button on the toolbar at the top of the screen. It is necessary to press the button - and the navigation parameters will immediately appear on the device screen. The menu is displayed instantly, as if the overlay occurred, but in fact it works as a link link to the navigation elements at the bottom of the page.
Luke Wroblewski emphasizes the following advantages of this approach:
“It uses a minimal set of navigation elements (the only link is at the top), while users can first easily get acquainted with the content, and only then deal with the navigation. This menu does not duplicate any other menu, and for its operation (the most pleasant part) only a simple reference link is required. Yes, no clever javascript, overlays or separate navigation pages - just a link to the bottom of the page. It doesn't get any simpler — it's like HTML 0. ”
Content from above, controls from below - it would seem that everything is so simple, but we have already seen that the results of the design can vary significantly, since application developers have to reckon with the requests that the operating system or browser makes to resources. The following conclusions can be drawn:
But these recommendations primarily concern phones. What about more touch devices? When it comes to devices like the iPad, the design rules change again.
The rule of thumb applies to iPad devices, but the zone of direct reach is somewhat different here, because we hold tablets not like phones. The way the user holds the iPad, directly depends on his posture. In the standing position you will need to use both hands. Sitting at the table, the user is likely to support him with one hand and control the other. Sitting in a chair, he will put the tablet on his knees and be controlled with the device with one hand. And if the user is lying down or leaning against something and is in an inclined position, he will most likely place the device on his stomach, supporting him with one hand and controlling the other.
In all these positions, the user's fingers are in different parts of the device screen. In addition, in each pose, the user holds the device at a certain distance. The closest it will be to keep the iPad in a standing position and farthest of all - in the prone position.
From all this diversity one can deduce two general principles. First, the iPad is best kept at the top, with the user's thumbs over the top corners of the device screen. Secondly, it is rather difficult at first glance to cover all the content displayed on the iPad screen, since it is simply larger than the screen of the phone. Since the gaze primarily focuses on the top of the tablet (and the printed page — this principle is taken from the typographic design area), the hierarchy of the displayed information should be organized accordingly. In other words, when working with an iPad, both the user's gaze and fingers are on the upper part of the device (the lower part is sometimes out of sight: at the most common and certainly the most relaxed position - lying or reclining - the lower part of the front panel of the device is buried in the folds of blankets , sweaters and users tummy).
In applications for tablets iPad, unlike phones, the main controls and buttons should be placed at the top , namely in the upper corners, since it is there that the thumbs of the user who has taken the iPad are located. As positive examples, we present Instapaper and Twitter for iPad applications.
At the same time, you should not place controls in the top center, as when using these buttons, the user's hand will close the displayed content. Since the controls in principle should not be located directly above the content associated with them, this template (placing these elements at the corners) is quite useful. For example, in The Daily for iPad application, a tool is located at the top center that allows you to view the issue page by page, but when you try to use it, the hand covers the page thumbnails, which complicates the user's task.
The above blunder, admitted by the developers of The Daily, demonstrates that any rule has its exceptions and in some cases controls should be placed at the bottom of the screen, and not at the top at the corners. Controls that are responsible for displaying or modifying content should always be placed under or on this side of the content, but not at the top. Here, for example, the developers of The Sydney Morning Herald for iPad have implemented an original navigation tool in it: the user can quickly browse all the articles of the current issue by simply swiping the pointer consisting of page numbers at the bottom of the screen. This management tool displays a long list of titles, so it’s best to place it at the bottom of the screen, because otherwise using the tool the user's hand will overlap the displayed content.
So what to choose - top or bottom? Let's see.
That is why the miniatures of the pages of books or magazines are best placed at the bottom. Another example: suppose that you are developing an application for creating maps, which, among other functions, contains a palette of objects to add to the map you are creating. As you may have guessed, this palette should also be placed at the bottom of the screen so that when working with a card the user's hand does not overlap the screen.
In the same way as the user's way of holding the device determines the location of controls, the size of users' fingers, in turn, determines the size of these elements. Elements of sensory interfaces should be large enough so that the user does not overshoot and could get on them without straining his eyes intensely on the screen.
What is the sufficient size of the elements of the touch interface? Counter question: what is the size of your fingertip? For each platform has its own recommendations. Apple, as usual, shows the greatest perseverance and offers the best (in the opinion of the author of the article) and universal recommendation for all platforms: the size of the elements of the touch interface should be at least 44 points (which equals a quarter of an inch or 7 mm). For web applications, this limit of 44 pixels also applies well.
Developers accustomed to desktop interfaces, such controls may seem gigantic and some kind of toy, but you just need to get used to it. Using huge buttons and giant elements of the touch interface is not only easy to get into - they are also very noticeable: even a scattered user can easily find the right button on the screen of a mobile device.
Ideally, the size of all elements of the touch interface should be at least 44 x 44. But here, as elsewhere, it is often necessary to look for compromise solutions. Even the size of the standard iPhone controls sometimes deviates from the proclaimed 44 pixels. For example, the size of keyboard buttons is 44 points in height and only 30 points in width. When the landscape screen orientation of the buttons is 44 points, and height - 38 points, respectively. Here, Apple developers do not have much space for maneuver: it is extremely important that the entire QWERTY keyboard be visible, and if you set the key size to 44 x 44 for all keys, they won't fit on one screen. Something has to be sacrificed.
Here is a good rule that helps in the development of the elements of the touch interface in a limited space. If, for example, the width of an interface element is at least 44 points, then if necessary you can shrink the height to 30 points, and vice versa. Therefore, the actual minimum size of any element of the touch interface should be 44 x 30.
The author of this article spent many years of his wasted youth in the company of elegant wristwatch-calculator Casio, with whom he finally broke up only in 1985. The buttons they had were just tiny, besides they prevented the author from becoming the prom ball king ... but even this cannot be called their main drawback. The fact is that the above buttons were too crowded. You try to press "5", but in the end you press "2" or "8" - the result is impossible to predict, a pure lottery, not a calculator. In other words, the size of the buttons is not the only determining factor: you need to think about the distance between the buttons.
Photo by: John Rawlinson
When developing interfaces for devices with small screens, it is inevitable that we must resist the temptation to solve the problem of limited space by compacting the interface elements. "Let's move this a little closer ... Add another button to this toolbar ..." To quote the popular motto of the heyday of calculator watches: "Just say no".
The closer the buttons are, the more they should be. Consider a couple of applications for VoIP telephony for the iPhone: Skype and Call Global App. In both applications, the keyboard buttons are located rather closely, but this is compensated for by their size, which significantly exceeds the above minimum 44 x 44. So, despite the rather close proximity of the buttons, it is relatively easy to hit them.
However, these applications are not completely identical: let's look at the bottom of the screen. In both applications, the buttons are located on top of the navigation tab panel: such an arrangement, as already discussed above, always creates some difficulties for the user. But in Skype (left) due to the impressive size of the buttons, design flaws are smoothed out. But in the Call Global App, the buttons above the bookmarks bar are too narrow, and their close location will lead to user errors. Despite the fact that in fact the size of these buttons exceeds the stated minimum of 44 x 30, the lack of space between them and their very location at the bottom of the screen play a fatal role. Here we need large buttons and a freer layout of interface elements.
Let's make a conclusion. Although this may seem counterintuitive, the efficiency of interfaces for devices with small screens is provided by large interface elements and a sufficient amount of space between them. Yes, device screens can be really small, but our fingers (as well as the volume of our attention) are not so small. So do not forget about fat fingers when developing.
Posted by: Josh Clark
The principles of managing familiar desktop interfaces are turned upside down when it comes to touch interfaces. This article provides guidance from Josh Clark, an interaction design engineer, on the development of interfaces for mobile touch devices and compares the touch interfaces of Android, iPhone, and iPad devices.
')
To succeed in developing a mobile interface, it is not enough just to squeeze it into the frame of a tiny screen of a mobile device. Effective mobile touch interfaces allow you to adapt the gestures of our clumsy fingers to control. The interface features of portable devices encourage developers to go beyond the principles of graphic and information design and step onto industrial design territory. Here, in the world of sensory devices, at stake is nothing but ergonomics itself. Now you can not only look at the pixels: you can touch them, and they should be pleasant to the touch.
Rule of thumb
When designing a touch device interface, you need to be clear about how the device lies in your hand and how the user's fingers cover it. Using, for example, a mobile phone, we mostly wield a thumb (although, probably, there are originals who hold the phone in some other sophisticated way). Thus, when developing an interface for a phone, it is necessary to adjust to the user's thumb.
Oh, thumbs up! It is they (and, probably, the love of gossip about the lives of celebrities) that distinguish us from the dumb beasts. Unfortunately, you can't reach everything with your thumb. Of course, with proper effort, the thumb can reach almost any point on the screen of a mobile phone (if you do not take into account the very giant models), but without unnecessary stress you can work only with the third part of the screen - its lower part from the side opposite the thumb.
It is in this zone that the main elements of the touch interface should be located. If you take the phone, for example, in the right hand, then your thumb will be above the lower left corner of the screen.
For this reason, in mobile device interfaces, toolbars and navigation elements are usually located at the bottom of the screen, whereas in traditional desktop applications interfaces they are usually located at the top of the screen: you will most likely find the menu of desktop applications at the top of the screen or window, and the navigation elements of websites - at the top of the pages. However, the use of the thumb imposes its limitations, turning the usual desktop interfaces upside down - and the navigation tools along with the main interface elements move to the bottom of the screen.
The thumb to the bottom of the screen of a mobile device is a much more important factor when designing mobile interfaces than choosing between the left and right side of the screen. As it turns out, most mobile phone users easily change hands when working with the device. Right-handers often and with pleasure “go to the left” (sometimes it comes to the fact that the left hand is used more often than the right), and left-handers, respectively, often change the left with the right. Although it is believed that the average user is more likely to use his right hand than his left, there is still not a sufficiently clear trend, so developers can relax and not puzzle over the question “right or left ?!”.
Our rule of thumb works regardless of the hand in which the user holds the device, and allows you to build an effective visual hierarchy of interface elements. The most frequently used buttons should be placed at the bottom of the screen, where the user will be comfortable to press them. All other controls should be moved away - away from sin. In iOS applications, for example, the Edit button is usually placed in the upper right corner — that is, in sight, but out of direct reach, which avoids accidental clicks.
Placing the main interface elements at the bottom of the device screen is necessary not only to make it more comfortable to be controlled with your thumb, but simply because otherwise the user's fingers obscure the screen. With the interface elements at the bottom, your hands do not overlap the displayed content. To ensure that the content of the developed application is visible, place it above the controls. This logical and familiar approach is used in most physical devices, such as iPods, calculators, cell phones, bathroom scales, and so on: content is on top, controls are on bottom.
I am a robot
However, this rule is not so simple as we would like: in particular, Android developers took and placed the corresponding buttons on the bottom of the close screens of the corresponding devices (up to the release of Android 3 "Honeycomb", the physical buttons, including Android 4 "Ice Cream Sandwich" - only virtual). Of course, according to the reasons described above, these buttons should be placed at the bottom of the screen, but this leads to the OS control buttons and application control buttons being heaped, which makes it difficult to work with the touch interface. Placing additional controls at the bottom of the screen leads to a jumble of toolbars - and you have to admit that in such interfaces, alas, the user is constantly at risk of clicking somewhere not there. And on the screen overlapped by the thumb, to avoid such errors is almost impossible. Look at this main screen of the Android device - it actually leaves the user no chance of error-free control.
When developing touch interfaces, such clutter of controls (especially at the bottom of the screen) should be avoided by all means. Unfortunately, this means that the controls for Android applications must be placed at the top of the screen in order to avoid crowds at the bottom, which is occupied by system controls. Such an alignment is far from ideal: the navigation elements are outside the zone of direct reach of the thumb, and when the user tries to reach them, his hand covers the entire screen. But even such inconveniences are insignificant compared to the situation when the finger constantly touches the adjacent buttons when pressed.
On Android devices, navigation and control elements should be placed at the top. This is the opposite principle used in iPhone devices, where the Home button does not interfere with applications, as is the case with the Android system buttons. Compare Foursquare apps for Android (left) and for iPhone (right).
Internet: application inside the application
Trying to avoid cluttering up the interface elements on the screens of mobile devices, we also encounter problems with the use of websites. As you know, any websites and web applications function within another application - a web browser. In browsers on many mobile platforms, there are also buttons and controls that can make it difficult to work with the user interface during web navigation. Consequently, in the context of working with websites, you should avoid pinning navigation elements at the bottom of the screen, because otherwise the website’s toolbar will be in rather close proximity to the browser’s toolbar (this recommendation is also supported by the fact that position (fixed) is not supported in the CSS of all mobile browsers equally, which makes fixing the toolbar at the bottom is quite a difficult task).
The solution is not to place the web navigation elements at the top of the screen (as is the case with Android devices), but rather to move them to the bottom of the page. Since a large part of the resources of mobile browsers "eat up" a variety of bells and whistles, in no case should you score the top part of a web page with navigation parameters, finally displacing the content from the screen.
Luke Wroblewski, in a truly magnificent book Mobile First, says: “Too often, user relationships with mobile web applications ... begin not with the actual content, but with the list of navigation options. When working with mobile devices, time can be literally worth its weight in gold, and downloading files can cost real money, so try to give people what they need as quickly as possible. ”
When working with mobile applications, the content should be in the foreground, and the main navigation elements should be placed below and not let them crawl all over the screen. Wroblewski calls for the use of a design pattern, as an example of which is the Ad Age mobile website: all navigation elements are hidden and appear when you click the Menu button on the toolbar at the top of the screen. It is necessary to press the button - and the navigation parameters will immediately appear on the device screen. The menu is displayed instantly, as if the overlay occurred, but in fact it works as a link link to the navigation elements at the bottom of the page.
Luke Wroblewski emphasizes the following advantages of this approach:
“It uses a minimal set of navigation elements (the only link is at the top), while users can first easily get acquainted with the content, and only then deal with the navigation. This menu does not duplicate any other menu, and for its operation (the most pleasant part) only a simple reference link is required. Yes, no clever javascript, overlays or separate navigation pages - just a link to the bottom of the page. It doesn't get any simpler — it's like HTML 0. ”
Content from above, controls from below - it would seem that everything is so simple, but we have already seen that the results of the design can vary significantly, since application developers have to reckon with the requests that the operating system or browser makes to resources. The following conclusions can be drawn:
- iPhone application controls should be placed at the bottom of the screen;
- Android application controls should be placed at the top of the screen;
- Web application navigation elements should be placed at the bottom of the page (and not at the bottom of the screen).
But these recommendations primarily concern phones. What about more touch devices? When it comes to devices like the iPad, the design rules change again.
Tablets - in the corners
The rule of thumb applies to iPad devices, but the zone of direct reach is somewhat different here, because we hold tablets not like phones. The way the user holds the iPad, directly depends on his posture. In the standing position you will need to use both hands. Sitting at the table, the user is likely to support him with one hand and control the other. Sitting in a chair, he will put the tablet on his knees and be controlled with the device with one hand. And if the user is lying down or leaning against something and is in an inclined position, he will most likely place the device on his stomach, supporting him with one hand and controlling the other.
In all these positions, the user's fingers are in different parts of the device screen. In addition, in each pose, the user holds the device at a certain distance. The closest it will be to keep the iPad in a standing position and farthest of all - in the prone position.
From all this diversity one can deduce two general principles. First, the iPad is best kept at the top, with the user's thumbs over the top corners of the device screen. Secondly, it is rather difficult at first glance to cover all the content displayed on the iPad screen, since it is simply larger than the screen of the phone. Since the gaze primarily focuses on the top of the tablet (and the printed page — this principle is taken from the typographic design area), the hierarchy of the displayed information should be organized accordingly. In other words, when working with an iPad, both the user's gaze and fingers are on the upper part of the device (the lower part is sometimes out of sight: at the most common and certainly the most relaxed position - lying or reclining - the lower part of the front panel of the device is buried in the folds of blankets , sweaters and users tummy).
In applications for tablets iPad, unlike phones, the main controls and buttons should be placed at the top , namely in the upper corners, since it is there that the thumbs of the user who has taken the iPad are located. As positive examples, we present Instapaper and Twitter for iPad applications.
At the same time, you should not place controls in the top center, as when using these buttons, the user's hand will close the displayed content. Since the controls in principle should not be located directly above the content associated with them, this template (placing these elements at the corners) is quite useful. For example, in The Daily for iPad application, a tool is located at the top center that allows you to view the issue page by page, but when you try to use it, the hand covers the page thumbnails, which complicates the user's task.
Drawing the line
The above blunder, admitted by the developers of The Daily, demonstrates that any rule has its exceptions and in some cases controls should be placed at the bottom of the screen, and not at the top at the corners. Controls that are responsible for displaying or modifying content should always be placed under or on this side of the content, but not at the top. Here, for example, the developers of The Sydney Morning Herald for iPad have implemented an original navigation tool in it: the user can quickly browse all the articles of the current issue by simply swiping the pointer consisting of page numbers at the bottom of the screen. This management tool displays a long list of titles, so it’s best to place it at the bottom of the screen, because otherwise using the tool the user's hand will overlap the displayed content.
So what to choose - top or bottom? Let's see.
- In the upper corners of the iPad screen, it is best to position the navigation elements and tools with which the user can share content with friends, add it to your favorites or delete.
- The lower part is great for controls that are responsible for displaying content in the active window.
That is why the miniatures of the pages of books or magazines are best placed at the bottom. Another example: suppose that you are developing an application for creating maps, which, among other functions, contains a palette of objects to add to the map you are creating. As you may have guessed, this palette should also be placed at the bottom of the screen so that when working with a card the user's hand does not overlap the screen.
Akella will not miss
In the same way as the user's way of holding the device determines the location of controls, the size of users' fingers, in turn, determines the size of these elements. Elements of sensory interfaces should be large enough so that the user does not overshoot and could get on them without straining his eyes intensely on the screen.
What is the sufficient size of the elements of the touch interface? Counter question: what is the size of your fingertip? For each platform has its own recommendations. Apple, as usual, shows the greatest perseverance and offers the best (in the opinion of the author of the article) and universal recommendation for all platforms: the size of the elements of the touch interface should be at least 44 points (which equals a quarter of an inch or 7 mm). For web applications, this limit of 44 pixels also applies well.
Developers accustomed to desktop interfaces, such controls may seem gigantic and some kind of toy, but you just need to get used to it. Using huge buttons and giant elements of the touch interface is not only easy to get into - they are also very noticeable: even a scattered user can easily find the right button on the screen of a mobile device.
Ideally, the size of all elements of the touch interface should be at least 44 x 44. But here, as elsewhere, it is often necessary to look for compromise solutions. Even the size of the standard iPhone controls sometimes deviates from the proclaimed 44 pixels. For example, the size of keyboard buttons is 44 points in height and only 30 points in width. When the landscape screen orientation of the buttons is 44 points, and height - 38 points, respectively. Here, Apple developers do not have much space for maneuver: it is extremely important that the entire QWERTY keyboard be visible, and if you set the key size to 44 x 44 for all keys, they won't fit on one screen. Something has to be sacrificed.
Here is a good rule that helps in the development of the elements of the touch interface in a limited space. If, for example, the width of an interface element is at least 44 points, then if necessary you can shrink the height to 30 points, and vice versa. Therefore, the actual minimum size of any element of the touch interface should be 44 x 30.
Do not push me
The author of this article spent many years of his wasted youth in the company of elegant wristwatch-calculator Casio, with whom he finally broke up only in 1985. The buttons they had were just tiny, besides they prevented the author from becoming the prom ball king ... but even this cannot be called their main drawback. The fact is that the above buttons were too crowded. You try to press "5", but in the end you press "2" or "8" - the result is impossible to predict, a pure lottery, not a calculator. In other words, the size of the buttons is not the only determining factor: you need to think about the distance between the buttons.
Photo by: John Rawlinson
When developing interfaces for devices with small screens, it is inevitable that we must resist the temptation to solve the problem of limited space by compacting the interface elements. "Let's move this a little closer ... Add another button to this toolbar ..." To quote the popular motto of the heyday of calculator watches: "Just say no".
The closer the buttons are, the more they should be. Consider a couple of applications for VoIP telephony for the iPhone: Skype and Call Global App. In both applications, the keyboard buttons are located rather closely, but this is compensated for by their size, which significantly exceeds the above minimum 44 x 44. So, despite the rather close proximity of the buttons, it is relatively easy to hit them.
However, these applications are not completely identical: let's look at the bottom of the screen. In both applications, the buttons are located on top of the navigation tab panel: such an arrangement, as already discussed above, always creates some difficulties for the user. But in Skype (left) due to the impressive size of the buttons, design flaws are smoothed out. But in the Call Global App, the buttons above the bookmarks bar are too narrow, and their close location will lead to user errors. Despite the fact that in fact the size of these buttons exceeds the stated minimum of 44 x 30, the lack of space between them and their very location at the bottom of the screen play a fatal role. Here we need large buttons and a freer layout of interface elements.
Let's make a conclusion. Although this may seem counterintuitive, the efficiency of interfaces for devices with small screens is provided by large interface elements and a sufficient amount of space between them. Yes, device screens can be really small, but our fingers (as well as the volume of our attention) are not so small. So do not forget about fat fingers when developing.
Posted by: Josh Clark
Source: https://habr.com/ru/post/150905/
All Articles