Полезные советы новичкам в дизайне под Android

[Goodkat]

Никогда не уделял гайдлайнам достаточно внимания, считая их скучными и неинтересными

Увы, автор не одинок.

[slaveoffear]

Тут все просто, если по таблице, то почти для всех dpi смотреть экраны normal (кроме ldpi). Таким образом получаем:

• ldpi — 240х320
• mdpi — 320х480
• hdpi — 480х800
• xhdpi — 640х960 (но тут лучше все же 720x1280)

только xhdpi выбивается из «пропорционального» масштабирования, так как разрешение 640 я не припомню, а 720 является самым распрастраненым.

[ZaiSL]

Под ldpi рисовать не обязательно, поскольку:
1. таких устройств уже очень мало, и с каждым днём становится всё меньше и меньше
2. графика для ldpi получается из hdpi-ресурсов путём выкидывания каждого второго пикселя по горизонтали и вертикали

[ZaiSL]

Я тоже озадачивалась таким вопросом. В итоге написала заметку

[Palehin]

А когда вторая часть заметок?)

[DevAndrew]

С тем что в статье, вроде всё понятно. А вот такой вопрос: а если игра(в которой много графики), допустим TD, нарисовал я башню для xhdpi, далее её нужно пересохранить 2 раза дня hdpi и mdpi, и получится для 1 башни — 3 изображения, или всё такие просто рисуется для xhdpi и больше ничего делать не надо?

[slaveoffear]

Все верно, для каждого dpi необходима графика в соответствующих размерах. В итоге получится куча графики для одного элемента.

[DevAndrew]

Получается сделал башню в 720x1280 и пересохранил её в 540×960, 360×640?

И ещё с анимацией тоже самое? это же… вообще куча графики будет.

[deM1d]

При декодировании ресурсов изображения можно сжимать. Плюс — не большой размер apk, минус — графика при сжимании теряет качество. Во втором случаи рисуем графику для каждого разрешения. Плюс — графика будет везде красивая, минус — толстая apk. Анимация — это такие же текстуры. Просто рисуются тайлы для каждого кадра.

[Suvitruf]

Хм.

Сделать в относительных координатах и центрировать, а потом уже в зависимости от экрана края заполнять фоновыми элементами. Вместо 3 пикч будет одна. Не вариант?

[JaLoveAst1k]

Естественно все можно делать руками. Добавлять только максимальный размер, во время запуска обрабатывать все ресурсы, подгоняя под нужный размер. И рисовать их :)
Суть отдельной графики для отдельных dpi в UI.

[Evgenij_Popovich]

Если отсутствует какой-либо ресурс в необходимом dpi, то android сам пережмет доступный в необходимое разрешение
developer.android.com/guide/practices/screens_support.html

The Android system helps your application achieve density independence in two ways:

The system scales dp units as appropriate for the current screen density
The system scales drawable resources to the appropriate size, based on the current screen density, if necessary
…

However, bitmap scaling can result in blurry or pixelated bitmaps, which you might notice in the above screenshots. To avoid these artifacts, you should provide alternative bitmap resources for different densities. For example, you should provide higher-resolution bitmaps for high-density screens and the system will use those instead of resizing the bitmap designed for medium-density screens. The following section describes more about how to supply alternative resources for different screen configurations.

[Evgenij_Popovich]

еще есть удобные утилиты, которые сами сгенерируют hdpi, ldpi, mdpi ресурсы из xhdpi источника
code.google.com/p/9patch-resizer/

[JaLoveAst1k]

Там во время этих «пережатий» размер меняется интересным образом, помню как-то недоумевал по этому поводу, когда поместил все ресурсы в drawable)

[Evgenij_Popovich]

Не совсем понял, что Вы имеете в виду. Размер меняется в строгом соотношении
developer.android.com/training/basics/supporting-devices/screens.html#create-bitmaps

To generate these images, you should start with your raw resource in vector format and generate the images for each density using the following size scale:

xhdpi: 2.0
hdpi: 1.5
mdpi: 1.0 (baseline)
ldpi: 0.75

[artishok]

Вот интересное приложение — play.google.com/store/apps/details?id=com.groidify.uipatterns — это сборник ui шаблонов, которые можно скачать с гитхаба

[itspers]

Как должно быть:

— Дизайнер рисует макеты
— Макеты утверждаются и отдаются разработчикам
— Дизайнер изучает полностью гайдлайны developer.android.com/design/index.html
— Берет Fireworks, качает набор стенсилов и на основе макетов делает дизайн для телефонов и планшетов, с страницами и состояниями
— Готовый fw.png файл отдается разработчикам и они берут оттуда нужные графические элементы, меняя по мере надобности размеры, сохраняя для mdip-xhdpi, делая 9-патчи где нужно.
— Готово

Как есть на самом деле:

— Заказчик отдает ТЗ (если повезет) разработчикам и дизайнеру. Они начинают параллельно работать.
— Дизайнер открывает редактор фотографий от Adobe, находит в интернете рамочку и ложит в файл размером «как там делали для айфона»
— Вдохновляясь TouchWiz дизайнер вставляет кучу разноцветных кнопочек, и так чтобы влезало четко по размеру экрана. И ставит красивую картинку на фон.
— Готовый набор psd-файлов с кучей слоев и групп отдается разработчикам.
— Разработчки забивают на попытки сделать правильно и просто нарезают слайсами то что есть в папу drawable-hdpi, ибо на маленьких экранах все равно все не помещается, а для планшетов дизайна и не присылали…
— Заказчик доволен, дизайнер доволен, аналитики жалуются на плохое качество приложений.

[vovkab]

Если уж писать как должно быть, то вот тут вот не правильно:
… отдается разработчикам и они… сохраняя для mdip-xhdpi,…

Это тоже должен делать дизайнер, для того то бы картинка для каждого разрешения выглядела правильно. Не была размытой при масштабировании вверх, когда нарисована например для mdpi, или же вниз, когда картинка нарисована для xhdpi.

[itspers]

Да, но большинство графики при нормальном дизайне сверстается в xml-e, то, что не поддастся — в найн-патчах, дизайнеру останутся только иконки и растровые картинки, если такие будут. Их быстрее сделать самому, чем объяснять какие картинки нужны, в каких состояниях, и надеяться что он сложит все по подпапочкам, без пробелов и больших буков. А если еще работа через менеджера…

[vovkab]

> Да, но большинство графики при нормальном дизайне сверстается в xml-e
это хорошо если ваш дизайнер любит метро стиль :), а если нет?

> что не поддастся — в найн-патчах
оставлять блюренный или не правильно от масшабированный найн патч это тоже самое.

> Их быстрее сделать самому
с такими то дизайнерами, только это и остается делать. Порой сам перерисовываю для 3х разрешений в inkscape, если что то не сильно сложное, что бы хотя бы линии все были четкие.

[p777]

28px для текста, 96px для меню и заголовка

М-да… Размер шрифта в пикселях. Сразу видно — статью писал профессионал в дизайне приложений для Андроида.

[Rebelart]

24 для ios не менее странно, минимальный размер для ios это 12 в не-ретина размере. И указывать его разработчикам надо именно в не-ретина размере.

[justnomi]

Статья больше похожа на вредные советы. Многие вещи расписаны неправильно или не расписаны полностью.

1. Не нужно как-то ориентироваться на размер экрана, и полностью привязываться к нему. Андроид устройств очень много, все они разные. В первую очередь нужно отталкиваться от плотности экрана, и дизайн делать с расчетом на резину. Например, mdpi устройства могут быть как и 320 пикселей в ширину, как и 360, да и вообще какими угодно. В конце концов, устройство можно поворачивать.

2. Action Bar — крайне важная вещь, и если вы действительно хотите сделать качественное приложение, то нужно на берегу разобраться как он работает. Там гораздо больше сложностей, чем просто «то, что не влезло, прячем за тремя точечками». Опять же action bar выглядит по разному на телефонах и планшетах, он может объединяться с navigation bar при повороте. На устройствах с аппаратной кнопкой «Меню» эти три точки вообще не должны показываться.

3. Дизайн инстаграма, фейсбука и твиттера для андроида можно с уверенностью не упоминать в подобных текстах. Они сделаны с крайне оттдаленными представлениями об экосистеме современного андроида.

4. PSD файлы со всеми элементами выкладывает (в отличие от эппл) сам гугл, прямо на своем сайте. Качай не хочу: developer.android.com/downloads/design/Android_Design_Holo_Widgets_20120814.zip

5. Минимальный рекомендуемый размер тапабельного элемента в андроиде — 48dp (то есть, 48 пикселей при плотности mdpi)

6. «Никогда не уделял гайдлайнам достаточно внимания». Чувак, до версии 4.0 гайдлайнов для андроида просто не существовало ;). И это объясняет, почему в гугл плее так много крайне некачественных приложений.

Чтобы начать рисовать под андроид, достаточно немного терпения, устройства с андроидом >4.0 на руках (лучше что-то типа нексуса) и вот этой ссылки: developer.android.com/design/index.html

[Kapitan_Vanya]

Я просто забил на < 4.0

[gildor]

Роман Нурик из Google рекомендует делать для устройств с <4.0 аналогичный дизайн как и для >=4.0, используя соответсвующие библиотеки для обратной совместимости

[Evgenij_Popovich]

Да, ActionBarSherlock и HoloEverywhere (спасибо Prototik) творят волшебство

[justnomi]

Рисовать все по гайдам четверки. Существуют неплохие средства реализовать почти все нарисованное и в версиях ниже 4.0.

[noma4i]

Вы видно до 4.0 просто гайдлайнами не интересовались. Гайдлайны появились еще для 1.5 r1
web.archive.org/web/20090301000000*/http://developer.android.com/guide/practices/ui_guidelines/index.html

[justnomi]

Есть видео-интервью Матиаса Дюарта изданию The Verge. Он там прямым текстом говорит, что до 4.0 ничего и не было толком

[ichik]

потянуть, чтоб обновить как на iPhone, очень редко используются в Android

Во-первых, крайне сомнительное утверждение. Во-вторых, еще и вредное.

[bstnd]

Есть стандартный компонент?

[n0ne]

Для вводной статьи вполне сойдёт, спасибо.
Но лично мне бы больше хотелось видеть статьи именно по дизайну… как напрограммировать — пруд пруди, а как сделать ListView отличный от дефолтного — уже перелопатить пол-инета надо. А не дай Бог добавить тень, изменить границу и т.п. — это уже вообще.

[godAlex]

Кроме 9-slice Scaling недавно прочитал про другой способ создания сложных фоновых изображений. С помощью Drawable ресурсов — http://developer.android.com/guide/topics/resources/drawable-resource.html. В некоторых случаях этот способ может оказаться полезным не только для создания фонов кнопок, но и сложных фоновых изображений.

[mapper]

Впервые вижу, чтоб этот формат называли 9-slice Scaling. В гугловской документации его повсеместно называют 9patch.

[godAlex]

Я название из этой статьи скопировал. А в документации верно — называется «Nine-Patch».

[mapper]

Что-то невезёт кнопке Up — если даже среди людей делающий приложения не все понимают как она должна работать, то с пользователями совсем беда.

. Нажатие на логотип обычно вызывает боковое меню или возвращает вас “назад”, к предыдущему экрану.

На самом же деле кнопка Up делает переход по иерархии экранов (то есть, если вы на экране описания приложения в маркете, то по нажатию на кнопку Up вы попадаете в список приложений маркета, даже если на экран описания приложения пришли совсем из другого места).

Вот тут про это замечательно написано, только нужно не поленится прочитать всё от начала до конца, а не ограничится просмотром картинок.

Боковое меню это вообще UI шаблон, которого в гайдлайнах нет вовсе, это заимствавание из iOS. Потому, чтоб не путать пользователся, лучше не вешать его открытие на логотип, или, по крайней мере, скрывать стрелочку (которая и показывает, что логотип работает как Up).

[junk]

Бокового меню и в iOS гайдах нет, его «популяризировали» полулярные iOS приложения. Ну и часто очень удобная штука.

[bracadabra]

Есть боковое меню в гайдлайнах и зовется Navigation drawer, для него даже специальную иконку придумали.

[mapper]

А 23 марта 2013 года его еще не было ;) а теперь да, ситуация немного изменилась. В прочем вот эта часть "… или возвращает вас «назад», к предыдущему экрану" так и осталась не совсем верной.

[bracadabra]

Ну да, скорее даже больше не верной, чем верной.

[bracadabra]

(удалено)

[bracadabra]

Не заметил, что статья годовой давности, виноват)