Разработка iPhone/iPod touch приложений: Mobile Human Interface Guidelines aka HIG (Избранное)

Появилось немного свободного времени, и, наконец-то до меня добралась книга с названием iPhone Human Interface Guidelines.

Как известно, Apple довольно часто имеет склонность к отказам принятия приложений в AppStore. Мотивации бывают разные – дублирование функционала (Apple не любит программы, которые дублируют функционал программ, установленных по умолчанию), “запрещенный содержимое”, не соответсвие iPhone Human Interface Guidelines, сокращенно HIG. О последнем и пойдет речь. Чтобы уменьшить количество отказов от Apple (хотя бы в пределах нашей компании), я буду отмечать особенности из HIG, которые посчитаю “не вполне очевидными”, но на которых Apple заостряет внимание. То есть, в конце концов пост должен превратиться в краткую выдержку из HIG. Он будет дополняться по мере чтения книги, и по мере осознания дзен Apple. Все, кому лень читать книгу из 300 с лишним страниц – можете отслеживать прогресс ;)
Но, как бы там ни было, прийдется начинать с вещей более-менее очевидных, но о которых все же, иногда забывают. Иногда я буду отмечать вещи, требующие особого внимания и не совсем очевидные.

iPhone

Как это не удивительно, но iPhone – это все-таки мобильное устройство, с относительно небольшим (480х320) экраном, и не каждое десктопное приложение может быть успешно портировано на него в том виде, в каком оно выглядит на PC или Mac.

Кроме небольшого экрана, необходимо учитывать, что “точность позиционирования” на экране iPhone тоже меньше, чем на десктопах и КПК со стилусами. Кнопка 5х5, в которую при должной сноровке можно “попасть”  мышкой или стилусом за доли секунды, предоставит массу проблем человеку, пытающимся сделать это на iPhone. В общем это можно сделать, но тогда приложение должно выпускаться в рубрике для “очень и точных и терпеливых “.

HIG

HIG нужен для того, чтобы разработчики не забывали о том, что iPhone  все-таки для пользователей. И им должно быть удобно. Apple заинтересован в том, чтобы приложения под iPhone были понятными и доступными. Эта “сюжетная линия” плавно проходит через весь HIG.

Приложение

После того, как появилась идея, и Вам уже начали приходить мысли о ее реализации, подумайте. Подумайте, для кого будет написано приложение. Кто им будет пользоваться, в случае успешной реализации. Как много должно быть этих людей. Какие это будут люди? Чего вы хотите (что вы получите) от приложения.

Alert

Если влючить здравый смысл, то можно понять, что чем больше Alert’ов используется, тем чаще пользователь просто их не читает. Не стоит использовать AlertView для уведомления пользователя о чем-то ( с одной кнопоко ОК).

• Правая кнопка в AlertView должна быть “по-умолчанию”, и представлять собой наименее разрушительное действие.
• Прежде чем использовать AlertView с тремя и более кнопками – подумайте семь раз – может, стоит все-таки использовать ActionSheet ( настойчиво предлагается использовать ActionSheet, в случае более двух кнопок)
• Ни в коем случае не используйте слово Error в AlertView. Это не критично и не смертельно, но иногда за такое возвращают приложение на доработку.
• Не стоит использовать AlertView для сообщения пользователю о чем-то, на что пользователь не может повлиять.

(Будет обновляться)