Мы любим смартфоны и приложения для них, поэтому любовь эта иногда выливается в текст. Этот текст написан креативный директором REDMADROBOT Максом Десятых и призван помочь начинающим и продолжающим дизайнерам интерфейсов мобильных приложений задуматься над важными вещами. Далее — прямая речь.

Readability for iPhone

Дизайн приложений — это куда больше, чем красиво расставленные пиксели. Дизайн — про то, что делает приложение, как делает и какое ощущение от него остается у пользователя.

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

Предыдущие статьи:

• Путь независимых разработчиков на примере игры, которую они не пиарят в статье со сложным и отвлечённым названием про путь независимых…
• Техническая препарация одной игры, созданной независимыми разработчиками.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

История Pinterest очень похожа на Instagram. Феноменальный рост, огромное количество пользователей и хранимых данных, при этом поразительно мало сотрудников. А еще все в облаке.

Действительно, ни Pinterest ни Instagram не сделали больших научных или технологических открытий, но это скорее является следствием простоты использования облачных технологий, нежели признаком заката эры инноваций в Кремниевой Долине (Золотой век Кремниевой долины окончен, и мы танцуем на её могиле – прим. переводчика). Цифры в заголовке и оценки стоимости этих компании настолько велики, что нам кажется, будто бы за ними стоит некий вид технологической революции, обеспечивающей их бурный рост. Однако, эта революция гораздо более искусна – она показывает, насколько легко добиться столь быстрого роста, если вы способны реализовать хорошую идею. Привыкайте. Теперь это норма.

Хорошо это или плохо, но для Android-приложений существует большое количество различных рынков продаж. С одной стороны приходится публиковать в нескольких, с другой — охват обеспечивается более широкий. Когда я задумался о том, что пора бы задействовать альтернативные маркеты для своего приложения, то толковой информации не нашёл. Сразу хочу предупредить, что программа предназначена для узкой русскоязычной аудитории, абсолютно ничем не примечательна, является по сути обычным rss-ридером для моего сайта халявы. Т.е. для многих этот опыт не будет показателен. Также я не использовал никаких средств для раскрутки своего приложения(реклама, обзоры, накрутка).

Я и пару моих друзей недавно самостоятельно решили заняться разработкой приложений под IOS. Ну и понятно что сразу начали «набивать шишки», но когда я случайно наткнулся на серию статей — понял что найди я их раннее, возможно многие вопросы в нашей работе и не возникли бы.
Итак я решил поделиться переводом первой статьи из четырех (перевод сделал самостоятельно, жестко к тексту не привязывался, ссылка на источник в конце статьи).

Фаза «предразработки» приложения

Прежде чем приступить к реализации вашей идеи вы должны задать себе пять вопросов:
1. Кто будет использовать ваше приложение?
2. Какие у вас конкуренты?
3. Почему ваше приложение уникально?
4. Когда вы его выпустите?
5. Как люди будут взаимодействовать с вашим приложением?

Рассмотрим каждый вопрос по отдельности.

На хабре в прошлом месяце была опубликована статья Конкурс ВК: Мессенджер для Android. Как это было!, в которой автор поделился своими мыслями о конкурсе и опубликовал список ресурсов и статей, которые помогли ему в создании приложения. Так как в последнее время я начал изучать разработку под iOS, то у меня скопилось некоторое количество ссылок, которые могут быть полезны для начинающих. Поэтому я последую его примеру и сделаю то же самое, только для своей платформы. Надеюсь, кому-нибудь они окажутся полезны и сэкономят немного времени.

Введение

На своем сайте на php для авторизации пользователей я в последнее время пользовался сервисом Loginza. Все было очень круто и удобно, но в голове начала зарождаться идея отказа от этого замечательного сервиса и вот почему:

1. Авторизация пользователей в случае закрытия Loginza или отказа от нее — в этом случае мы потеряем пользователей, в привязанных профилях которых не указан email;
2. Дополнительная информация, например, ВКонтакте умеет отдавать фото пользователя в нескольких видах, в том числе квадратный аватар. С Логинзой получить эти данные не представляется возможным, сервис сам решает какие данные запрашивать и какие отдавать;
3. С момента продажи Яндексу Логинза начала умирать: на запросы пользователей никто не отвечает, сервис не развивается, а находится в том виде, в котором был 1-2 года назад.

Встал вопрос замены и использовать альтернативные сервисы желания уже не возникало — никто не представлял возможности «общаться» с соц. сетью напрямую, а расширенные поля профиля обычно включались в платные услуги. Хотелось автономного решения с возможностью гибкой настройки запрашиваемых полей и в итоге я остановился на php библиотеке HybridAuth.

Если по-честному, то эта статья не должна являться продолжением первой моей статьи о мгновенном изменении языка iOS-приложений. Если первая статья была написана программистом для программистов, то в этой заметке пойдет речь непосредственно о процессе локализации, применимом к любой мобильной (и не очень) платформе.

Но мы меня простим и сделаем вид, что это цикл статей ;).

Итак. В процессе разработки большинства мобильных приложений возникает необходимость локализации. И в этот неловкий момент может возникнуть ряд правомерных вопросов: на какие языки переводить, что именно переводить, куда обращаться, на какие мелочи стоит обратить внимание.

Попробуем ответить на каждый из этих вопросов по отдельности.

Разработчик, кто он?

Для начала, надо понимать зону ответственности разработчика приложений и те роли, которые могут присутствовать в ходе всего процесса разработки. Лучше всего это понимание приходит после работы в команде, но все-таки немного теории. Роли примерно следующие:

• Заказчик
• Менеджер
• Архитектор, старший разработчик
• Разработчики
• Дизайнер

Роли можно расписать более подробно – все зависит от сложности проекта и от наличия или отсутствия человеческих ресурсов.
Как это все работает. У заказчика появляется идея, он хочет ее воплотить жизнь. Возможно, он еще сам толком не представляет, чего хочет и может выговорить менеджеру только несколько слов. К примеру «iphone» и«карта моих ресторанов». После чего, задача менеджера составить с заказчиком максимально подробную спецификацию приложения. В спецификацию должна входить вся информация от поддерживаемых версиях операционной системы до зарисовок экранов. Вот пример зарисовок(wireframes, mockups) вместе с оценкой.


Архитектор или старший разработчик — это опытный человек, который знает как выстроить архитектуру приложения в соответствии с принципами ООП, MVC(паттерн модель-вью-контроллер), как сделать код приложения гибким, красивым и удобно поддерживаемым. Он смотрит на спецификацию, рисует архитектуру и раздает задания разработчикам. С дизайнером, чаще всего, общается менеджер, предоставляя ему зарисовки и концепт. Это очень общее представление о том как происходит разработка ПО, поэтому я советую вам так же познакомиться с наиболее распространённым итеративным подходом к разработке.

Tips and tricks

За время своей работы мне удалось взглянуть на процесс разработки технических заданий на программные продукты с нескольких точек зрения. С точки зрения аналитика – непосредственного исполнителя работ, с точки зрения руководителя проекта со стороны исполнителя, организующего процесс создания ТЗ, с точки зрения руководителя группы разработчиков, реализующих эти самые ТЗ, а также с точки зрения заказчика системы, впоследствии принимающего решение по разработанному ранее ТЗ.

Надо сказать, что у каждой из этих заинтересованных сторон свои требования и свое видение того, каким должно быть «хорошо написанное ТЗ». Например, у заказчика и исполнителя могут быть совершенно противоположные мнения на этот счет. Исполнитель может быть заинтересован в максимально подробном ТЗ для того, чтобы максимально формализовать свои обязательства по функционалу создаваемого решения. При этом заказчик, который точно не определился с параметрами будущей системы или у которого «ветер в голове», может требовать более общих формулировок, описания системы крупными мазками для того, чтобы потом попытаться включить в рамки оговоренного бюджета новые требования. Конечно же, при другом «менталитете» заказчика и исполнителя все может быть с точностью до наоборот. Сейчас мне хотелось бы остановиться именно на разработке ТЗ с точки зрения его заказчика, рассмотрев возможные ситуации, цели и тактики поведения.

Привет Хабр,

На сайте немало статей рассказывающих о том, как успешно пройти модерацию у Apple Review Team. Эта статья не об этом. Она скорее о том, как мы случайно получили аппрув, не особо этого желая.
К чему это привело и во что вылилось — читайте дальше.

Это перевод оригинальной статьи «Wireframing, Prototyping, Mockuping – What’s the Difference?».

Итак

Пару лет назад я понял, что многие из моих коллег(не дизайнеров) по разному называют результаты моей работы. Они предположили, что блочная разметка (wireframe), прототип (prototype) и макет (mockup) – это одно и тоже – своего рода сероватый, квадратный, эскиз поясняющий гениальные идеи.

Всем привет! В этом топике мне хотелось бы обсудить одну из самых интересных и в тоже время загадочных тем для большинства, как мне кажется, инди-разработчиков – это продвижение своих собственных приложений. Скажу пару слов о себе: я примерно 2 года занимаюсь Android-разработкой (исключительно в качестве хобби, правда). У меня есть десяток приложений в Play Store, с совокупным количеством загрузок более 5 млн. Ни то что бы очень много, да и большая часть загрузок приходится на одно приложение, но какие-то выводы касательно маркетинга я для себя сделал. Здесь я хочу поделиться своим опытом, наблюдениями, а так же призываю Вас рассказывать о своих результатах в комментариях. Обмен опытом в этом вопросе был бы полезен всем, я думаю.

Вчера задался себе таким вопросом: как можно обезопасить мой профиль в Google Chrome и вообще все данные, которые в нем хранятся? Немножко погуглив, я нашел ссылки на кучу расширений (типа этого), которые позволяют устанавливать пароль как на браузер так и на отдельные его профиле (это логично, если знать как работает Chrome в режиме мультипрофильности). Я начал их устанавливать и сразу тесты на баги. И как оказалось ни один из них не хочет адекватно работать в режиме мультипрофильности. Не очень-то долго думая я решил написать собственное расширение и заодно разобраться в Google Chrome API.

Доброго дня. Меня зовут Илья и я — перфекционист.

Одна из главных проблем большинства стартаперов состоит в том, что они так и не становятся стартаперами: они просто не в состоянии закончить свой первый проект. Схожие трудности испытывают некоторые фрилансеры — у них не всегда выходит закончить проект в срок.

У этих проблем есть общее достаточно тривиальное решение. Но никто не решается отказаться от идеальности своего кода и вместо того, чтобы получить завершённый проект, обычно делают проект мечты.

Месяц назад наша команда, состоящая из полутора дизайнеров и полутора кодеров взяла первое место на региональном чемпионате по скоростной разработке игр. На разработку давалось всего 48 часов. Двое суток, целиком состоящих из кофе и нервов дали итогом самый завершённый из проектов конкурса. Я расскажу вам, что мне пришлось сделать с собой и своим желанием написать идеальный код, который не страшно будет показать людям.

Большая часть материалов на хабре посвящена людям, работающим в ИТ-компаниях. Однако люди, близкие к ИТ, бывают не только в профильных конторах — на стороне заказчика тоже трудятся увлеченные люди, любящие и понимающие современные технологии.

Хочу поделиться с вами тем, как я делал свой первый, по-настоящему большой проект; рассказать о граблях, трудностях и некоторых хаках, которые я успел осознать. Сегодня я не буду говорить о технологиях как таковых — всё больше я буду говорить о процессах.

Прошу прощения у сообщества за ошибки в тексте. Как я не пытался поднять уровень своей грамотности, у меня так ничего и не получилось. Основную массу ошибок я поправил благодаря Ворду. Если вы интеллигентно сообщите мне об оставшихся – буду вам крайне признателен.

Хочу поделиться опытом размещения приложений в социальных сетях.

Никого не удивлю, если скажу, что самые известные соцсети на территории нашей родины — это ВКонтакте, Одноклассники, Мой Мир и Facebook. Твиттер и YouTube в счет не берем, потому что там нет каталога приложений. Другие социальные сети не дотягивают по популярности и поэтому не представляют интереса.

Поедем вперед по списку. В качестве подопытного будет выступать наш Fresh Shop — магазин-приложение в социальных сетях.

Для удобства восприятия каждый кейс будет разбит на три шага, а в конце будут приведены итоги.

На днях появился новый веб-сервис, позволяющий в несколько кликов создавать новый проект для андроид со всеми современными вкусностями сторонних библиотек.
Название AndroidKickstartr.com отлично описывает его задачу — максимально быстро и просто сконфигурировать новый проект, добавив туда все самое необходимое.

Я обожаю twitter bootstrap. Прост, местами логичен, достаточно красив, подходит для быстрого прототипирования веб-интерфейсов. Но этого оказалось недостаточно. Взяв twitter bootstrap в большой проект, мне пришлось целиком его разобрать и переосмыслить css-фреймворки как боевые единицы в веб-проектах. В результате переосмысления родились требования к любому css-фреймворку, удобному как верстальщику, так и frontent-разработчику.