> Для начинающих приложений очень важно получить второй и третий шанс у пользователя. Спящая аудитория приложения после 2-3 месяцев от запуска может быть очень большой. Посчитайте базу установок за вычетом активных месячных пользователей.
Отлично. Здесь работает правило кошек: кошки, на которых Вы тренировались, но не возымели успеха, по второму кругу тестировать Ваше приложение скорее всего не будут, ввиду уже сложившегося мнения.
> Второй получить легко, но думайте о том, чем вы можете быть полезны или интересны вашему пользователю. В этом случае будет и следующий раз.
Об этом думать надо изначально, а не когда обнаруживаешь, что забыл сделать приложение полезным о_О мне так еще бабушка говорила.
> Вы рискуете за назойливость вы сразу можете быть удалены. Не злоупотребляйте нотификациями. Будить пользователь не нужно часто. Дайте возможность отключить эти сообщения.
Ну, лучше не отключить, а настроить. Причем нужно учесть, что:
— пользователь априори вообще не знает, нужны ему уведомления или нет, если он запускает приложение впервые. Нужно его об этом спросить или предупредить, но уже ПОСЛЕ того, как он начнет использовать приложение, иначе это нон-сенс.
— везде нужно подходить адекватно. Если есть оповещения, у которых обычная частота может зашкаливать, а есть те, которые появляются намного реже, имеет смысл сделать для них раздельную настройку.
М-м-м, а сделать приложение качественное с минимально возможным уровнем вхождения для целевой аудитории, чтобы пользователь действительно был заинтересован в его использовании?
Придумал приложение? Сделал прототип? Отлично, а теперь возьми свой дев-смартфон и дай поюзать приложение пяти-десяти френдам, которым оно может быть интересно, выслушай мнения, отфильтруй крайности, смой, повтори.
Отладить его, чтобы не было ошибок?
Одна ошибка, и я уже не уверен в стабильности приложения. А если это критический для меня почтовый клиент, например, то неуверенность в том, что он сейчас висит в фоне и сообщит мне о новом письме сразу, как оно появится, заставит меня его удалить, не размышляя и не ждя «напоминания дать ему второй шанс».
Прогнать интерфейс по 10 правилам хорошего тона юзабилити?
Приложение всем понравилось? Ошибок не обнаружено? Вот и пользуйся. Сам. С друзьями. С семьей. Но не публикуй. Если за неделю плотного использования ни у кого не появилось желания переставить кнопку, чтобы до нее, наконец-то, стал дотягиваться большой палец и не приходилось прибегать к помощи второй руки, вот только тогда можешь публиковать.
Думаю, что для команды, запускающей новый продукт, будет намного более полезным подумать именно над этими темами, чем спамить пользователя.
В случае, если Вы не делаете 100% ноу-хау, целью разработки должен быть не «первонах», а приложение, которое само по себе мотивирует пользователя его запускать снова и снова.
Любая разработка, по сути, это итерационный процесс обнаружения и уменьшения рисков, как мелких, так и конечных (как результат накопления мелких). Один из главных рисков — это выпуск не реюзабельного приложения (того, которое не хочется запустить еще раз): направьте на его уменьшения все силы, тогда и напоминать никому ничего не придется.
Да, и к слову, при напоминании о выходе новой версии, неплохо указывать, что же нового там появилось. Я, например, обновляю приложения в дежурном плане: примерно каждую неделю, когда их там накопилось хотя бы 4-5 в очереди, но только потому что приложение не сообщает мне о том, насколько стоящий вышел апдейт.
Что-то мне подсказывает, что разработчики iOS просто ставят эту фичу, а разрабы Android как засирали маркет мусорными приложениями, так и продолжают не обращать внимания на библиотеку «real-time crash reporting».
Как пользователь iOS добавлю: краши есть даже у Gmail-приложения, но они не проявляются ровно до тех пор, пока сам не почувствуешь, что перегрузил девайс параллельно выполняющимися приложениями, а ведь он так и мотивирует запустить в фоне кучу проверялок почты и IM, а самому врубить трехмерный шутер и резаться )
Ну, не все так плохо, как Вы считаете. Есть ПО и технологии, которые совершенно внезапно становятся лучше или раскрывают те или иные фишки, из-за которых некоторое время назад читатель забросил все подписки и отказался от использования продукта. В этом смысле информация о новинках — это достаточно здорово.
Учитывая то, что хабр позволяет управлять подписками и ранжировать информацию по топикам, считаю сабж неактуальным.
А ведь всего-то ничего: достаточно продолжить звездочки в рейтинге в отрицательную сторону и выбрасывать из статистики приложения, набравшие критический уровень отрицательных голосов (естественно по отношению к количеству загрузок, времени использования приложения и проч), а также проводить автоматические рассылки с рекомендациями по увеличению качества приложений их авторам, ссылками на последние версии фреймворков, примерами…
Считаю, что приложения, у которых существуют лучшие бесплатные аналоги, и которые не развиваются, вообще не имеют права на существование. Но, как я понимаю, гугл здесь бежит за красивыми графиками статистики что по количеству приложений, что по количеству активаций устройств, меряясь писькой с эплами.
А кто Вам это даст?) Я про то и говорю, что уровень контроля должен быть не только технический, но и административный, когда доступ в режиме реального времени осуществляется ко всем данным, включая синхронизацию с камерами наблюдения, в противном случае можно будет забросить еще пару-тройку сотен бюллетеней в таблицу, скорректировав результаты, один хрен — они все тайно-голосованные, обезличенные.
Я предлагаю закончить эту ветвь дискуссии, т.к. в соседних комментариях дали ссылки на конкретные разработки, которым действительно стоит уделить внимание.
Кто-то кого-то не понял)
Представим невероятное: две таблицы БД. Одна — с отдельными голосами. Вторая — результаты суммирования.
Проверяете Вы по первой — все сходится, естественно. А вот во вторую можно записать все, что угодно. На Ваши проверки отдельных голосов это не повлияет.
Может, я очень ошибаюсь, но проблемой прошлого голосования была НЕ ПОДМЕНА голосов. Другими словами система Вам сообщит, что Вас посчитали правильно, но вот всех вместе — так, как «приказали сверху».
Должен быть контроль количества бюллетеней, подтверждение, что их количество совпадает с количеством реально голосовавших УНИКАЛЬНЫХ людей (видео-наблюдение), и вот только после выполнения этих условий можно будет говорить о проверке частных голосов для сопоставления результатов.
И да. Все должно делаться, не взирая на остальные инстанции: проблемы с судьями и прочим подкупным ворьем — их исправим технологически или насильственно следующим шагом — нужно с чего-то начинать, и начинать не кусочно, а фундаментально.
К слову, нужна популяризация источников информации, касающихся физических и юридических лиц: права, обязанности, быстрая консультация, потоки, списки ответственных лиц администрации городов, текущий список районных работ и т.д. Время, когда каждый ресурс корыстно тянет аудиторию на себя, копируя функционал конкурента — прошло. Теперь нужно консолидироваться в единую информационную сеть. Идеально, если это будет развитием сайта гос-услуги, как единственного портала, наиболее полно (на данный момент) подключенного к реестру данных о гражданах.
Ключи? PIN-коды? Бабушки не запутаются?
На хабре было очень много грамотных предложений и по контролю, и по верификации, но крутых только с нашей, айтишной, точки зрения. Считаю, что какое бы ни было решение, оно обязано быть максимально автоматизированным (эквивалентно или проще чем существующий механизм проведения выборов), а контроль должен осуществляться только на стороне техники, с возможностью пост-верификации.
Например, можно отправлять данные с опущенной бюллетени, синхронизируя их во времени с записью камеры с каждого участка, обычными средствами определения движения подтверждая, что бюллетень была действительно опущена, одна и в рамках периода работы участка.
Тут же ведь какие проблемы нужно решить:
1. подтасовка результатов
2. вброс бюллетеней до и после голосования
3. повторное голосование по открепительному
4. голосований по чужому удостоверению
Первые два вопроса тривиальны по своему решению: контрольные суммы, ассиметричные ключи, защита от прямого внесения данных в устройство подсчета голосов (например, защита ключом шифрования, который генерируется случайно при старте устройства).
А вот следующие два — уже интереснее. И если делать онлайн-голосование, то количество фальсификаций такого уровня может возрасти. Компьютер же не видит лицо голосующего, а вбить паспортные данные в форму можно по базе ОВД, наняв пару десятков специально обученных студентов.
Имеет смысл подходить к задаче комплексно, а то получается, что для полной настройки защиты сервера Вы предлагаете проверять входные данные на уровне Apache/php, но ни слова о том, что надо бы еще открытые порты проверить, актуальные версии библиотек и проч.
Помимо контроля бюллетеней на техническом уровне необходим административный контроль выполнения всех прав и обязанностей ответственных лиц на территории участка, а именно:
— права и обязанности комиссии
— права и обязанности наблюдателей
— порядок подсчета голосов
— единый конечный перечень (для всех участков) документов, которые предоставляются наблюдателям, включая ключевые отличительные черты (номера, штампы, количество подписей), подтверждающие подлинность документа (это я к случаю, когда наблюдателям выдавали якобы тестовые безномерные заключения о подсчете голосов)
За тем, чтобы это все выполнялось, необходим контроль: лучший контроль — тот, который можно второй раз проконтролировать, и лучшим образом здесь справится интернет-толпа (крауд):
— постоянное видео-наблюдение с разных точек, на автономном питании с параллельной передачей: в сеть на открытый ресурс для трансляции и сохранения, способный справиться с нагрузкой, и в локальное хранилище на случай выхода (чудесным образом) из строя соединения с сетью.
— синхронизация информации о том, что бюллетень опущен, с видео-потоком.
— запись лиц, присутствующих и голосующих людей (без раскрытия персональных данных) для возможности выявления повторных голосований. Соответственно, отсюда и требование к высокому качеству видео-сигнала. В наличии уже имеются подходящие аппаратные и программные средства, позволяющие обеспечить это с минимальными расходами на аппаратуру и трафик.
— все записи должны быть доступны с серверов, способных выдержать хабра-эффект, с применением технологии p2p и защитой (автоматическим баном) от подброса битых пакетов, для того, чтобы далее можно было накинуться всей мыслящей частью хабра и провести автоматическое распознавание и сравнение лиц в рамках участков в городах. Организовать единую ферму для этого не составит никакого труда — все технологии давно доступны. Отсюда, соответственно, требование к отсутствию на лице очков, масок, паранжей и прочего мешающего заснять лицо шмота.
Все вышесказанное не будет иметь должного эффекта, если не будет предварительного крауд-контроля.
Таким образом, заблаговременно (1-2 месяца) до начала голосования все административные и технические средства по каждому участку должны быть опубликованы и предоставлены для конструктивной критики, неудобных вопросов и комментариев: со всеми описаниями моделей камер, электронных урн, документаций, административных документов и проч.
Все комментарии (за исключение троллинга и прочей гадости, естественно) должны получить либо ответное действие, либо официальный ответ. У меня нет юридического образования, но как любой айтишник могу массово в уме моделировать ситуации на заданную тему, с определенной вероятностью находя подвох в тех или иных административных документах. А когда нас много, верификация пройдет достаточно быстро и точно.
Интересно, а когда считают количество активаций андроид-устройств для статистики, они и подобные гаджеты тоже учитывают? Если да, тогда понятно, откуда такие большие цифры :D
Ну, учитывая, что в топике про синхронизацию состояний они аж на 3 этапа растянули решение о том, что все-таки нужно использовать локальные хранилища flash (старо как мир, в браузерных играх) и средства HTML5 с библиотекой EasyXDM, то я совершенно не удивлен такому топорному методу, если это действительно попытка борьбы со спамом.
Есть какие-нибудь официальные релизы/ответы по этому поводу?
Отлично. Здесь работает правило кошек: кошки, на которых Вы тренировались, но не возымели успеха, по второму кругу тестировать Ваше приложение скорее всего не будут, ввиду уже сложившегося мнения.
> Второй получить легко, но думайте о том, чем вы можете быть полезны или интересны вашему пользователю. В этом случае будет и следующий раз.
Об этом думать надо изначально, а не когда обнаруживаешь, что забыл сделать приложение полезным о_О мне так еще бабушка говорила.
> Вы рискуете за назойливость вы сразу можете быть удалены. Не злоупотребляйте нотификациями. Будить пользователь не нужно часто. Дайте возможность отключить эти сообщения.
Ну, лучше не отключить, а настроить. Причем нужно учесть, что:
— пользователь априори вообще не знает, нужны ему уведомления или нет, если он запускает приложение впервые. Нужно его об этом спросить или предупредить, но уже ПОСЛЕ того, как он начнет использовать приложение, иначе это нон-сенс.
— везде нужно подходить адекватно. Если есть оповещения, у которых обычная частота может зашкаливать, а есть те, которые появляются намного реже, имеет смысл сделать для них раздельную настройку.
М-м-м, а сделать приложение качественное с минимально возможным уровнем вхождения для целевой аудитории, чтобы пользователь действительно был заинтересован в его использовании?
Придумал приложение? Сделал прототип? Отлично, а теперь возьми свой дев-смартфон и дай поюзать приложение пяти-десяти френдам, которым оно может быть интересно, выслушай мнения, отфильтруй крайности, смой, повтори.
Отладить его, чтобы не было ошибок?
Одна ошибка, и я уже не уверен в стабильности приложения. А если это критический для меня почтовый клиент, например, то неуверенность в том, что он сейчас висит в фоне и сообщит мне о новом письме сразу, как оно появится, заставит меня его удалить, не размышляя и не ждя «напоминания дать ему второй шанс».
Прогнать интерфейс по 10 правилам хорошего тона юзабилити?
Приложение всем понравилось? Ошибок не обнаружено? Вот и пользуйся. Сам. С друзьями. С семьей. Но не публикуй. Если за неделю плотного использования ни у кого не появилось желания переставить кнопку, чтобы до нее, наконец-то, стал дотягиваться большой палец и не приходилось прибегать к помощи второй руки, вот только тогда можешь публиковать.
Думаю, что для команды, запускающей новый продукт, будет намного более полезным подумать именно над этими темами, чем спамить пользователя.
В случае, если Вы не делаете 100% ноу-хау, целью разработки должен быть не «первонах», а приложение, которое само по себе мотивирует пользователя его запускать снова и снова.
Любая разработка, по сути, это итерационный процесс обнаружения и уменьшения рисков, как мелких, так и конечных (как результат накопления мелких). Один из главных рисков — это выпуск не реюзабельного приложения (того, которое не хочется запустить еще раз): направьте на его уменьшения все силы, тогда и напоминать никому ничего не придется.
Да, и к слову, при напоминании о выходе новой версии, неплохо указывать, что же нового там появилось. Я, например, обновляю приложения в дежурном плане: примерно каждую неделю, когда их там накопилось хотя бы 4-5 в очереди, но только потому что приложение не сообщает мне о том, насколько стоящий вышел апдейт.
Как пользователь iOS добавлю: краши есть даже у Gmail-приложения, но они не проявляются ровно до тех пор, пока сам не почувствуешь, что перегрузил девайс параллельно выполняющимися приложениями, а ведь он так и мотивирует запустить в фоне кучу проверялок почты и IM, а самому врубить трехмерный шутер и резаться )
Учитывая то, что хабр позволяет управлять подписками и ранжировать информацию по топикам, считаю сабж неактуальным.
Считаю, что приложения, у которых существуют лучшие бесплатные аналоги, и которые не развиваются, вообще не имеют права на существование. Но, как я понимаю, гугл здесь бежит за красивыми графиками статистики что по количеству приложений, что по количеству активаций устройств, меряясь писькой с эплами.
Я предлагаю закончить эту ветвь дискуссии, т.к. в соседних комментариях дали ссылки на конкретные разработки, которым действительно стоит уделить внимание.
Представим невероятное: две таблицы БД. Одна — с отдельными голосами. Вторая — результаты суммирования.
Проверяете Вы по первой — все сходится, естественно. А вот во вторую можно записать все, что угодно. На Ваши проверки отдельных голосов это не повлияет.
Должен быть контроль количества бюллетеней, подтверждение, что их количество совпадает с количеством реально голосовавших УНИКАЛЬНЫХ людей (видео-наблюдение), и вот только после выполнения этих условий можно будет говорить о проверке частных голосов для сопоставления результатов.
И да. Все должно делаться, не взирая на остальные инстанции: проблемы с судьями и прочим подкупным ворьем — их исправим технологически или насильственно следующим шагом — нужно с чего-то начинать, и начинать не кусочно, а фундаментально.
К слову, нужна популяризация источников информации, касающихся физических и юридических лиц: права, обязанности, быстрая консультация, потоки, списки ответственных лиц администрации городов, текущий список районных работ и т.д. Время, когда каждый ресурс корыстно тянет аудиторию на себя, копируя функционал конкурента — прошло. Теперь нужно консолидироваться в единую информационную сеть. Идеально, если это будет развитием сайта гос-услуги, как единственного портала, наиболее полно (на данный момент) подключенного к реестру данных о гражданах.
На хабре было очень много грамотных предложений и по контролю, и по верификации, но крутых только с нашей, айтишной, точки зрения. Считаю, что какое бы ни было решение, оно обязано быть максимально автоматизированным (эквивалентно или проще чем существующий механизм проведения выборов), а контроль должен осуществляться только на стороне техники, с возможностью пост-верификации.
Например, можно отправлять данные с опущенной бюллетени, синхронизируя их во времени с записью камеры с каждого участка, обычными средствами определения движения подтверждая, что бюллетень была действительно опущена, одна и в рамках периода работы участка.
Тут же ведь какие проблемы нужно решить:
1. подтасовка результатов
2. вброс бюллетеней до и после голосования
3. повторное голосование по открепительному
4. голосований по чужому удостоверению
Первые два вопроса тривиальны по своему решению: контрольные суммы, ассиметричные ключи, защита от прямого внесения данных в устройство подсчета голосов (например, защита ключом шифрования, который генерируется случайно при старте устройства).
А вот следующие два — уже интереснее. И если делать онлайн-голосование, то количество фальсификаций такого уровня может возрасти. Компьютер же не видит лицо голосующего, а вбить паспортные данные в форму можно по базе ОВД, наняв пару десятков специально обученных студентов.
Имеет смысл подходить к задаче комплексно, а то получается, что для полной настройки защиты сервера Вы предлагаете проверять входные данные на уровне Apache/php, но ни слова о том, что надо бы еще открытые порты проверить, актуальные версии библиотек и проч.
Помимо контроля бюллетеней на техническом уровне необходим административный контроль выполнения всех прав и обязанностей ответственных лиц на территории участка, а именно:
— права и обязанности комиссии
— права и обязанности наблюдателей
— порядок подсчета голосов
— единый конечный перечень (для всех участков) документов, которые предоставляются наблюдателям, включая ключевые отличительные черты (номера, штампы, количество подписей), подтверждающие подлинность документа (это я к случаю, когда наблюдателям выдавали якобы тестовые безномерные заключения о подсчете голосов)
За тем, чтобы это все выполнялось, необходим контроль: лучший контроль — тот, который можно второй раз проконтролировать, и лучшим образом здесь справится интернет-толпа (крауд):
— постоянное видео-наблюдение с разных точек, на автономном питании с параллельной передачей: в сеть на открытый ресурс для трансляции и сохранения, способный справиться с нагрузкой, и в локальное хранилище на случай выхода (чудесным образом) из строя соединения с сетью.
— синхронизация информации о том, что бюллетень опущен, с видео-потоком.
— запись лиц, присутствующих и голосующих людей (без раскрытия персональных данных) для возможности выявления повторных голосований. Соответственно, отсюда и требование к высокому качеству видео-сигнала. В наличии уже имеются подходящие аппаратные и программные средства, позволяющие обеспечить это с минимальными расходами на аппаратуру и трафик.
— все записи должны быть доступны с серверов, способных выдержать хабра-эффект, с применением технологии p2p и защитой (автоматическим баном) от подброса битых пакетов, для того, чтобы далее можно было накинуться всей мыслящей частью хабра и провести автоматическое распознавание и сравнение лиц в рамках участков в городах. Организовать единую ферму для этого не составит никакого труда — все технологии давно доступны. Отсюда, соответственно, требование к отсутствию на лице очков, масок, паранжей и прочего мешающего заснять лицо шмота.
Все вышесказанное не будет иметь должного эффекта, если не будет предварительного крауд-контроля.
Таким образом, заблаговременно (1-2 месяца) до начала голосования все административные и технические средства по каждому участку должны быть опубликованы и предоставлены для конструктивной критики, неудобных вопросов и комментариев: со всеми описаниями моделей камер, электронных урн, документаций, административных документов и проч.
Все комментарии (за исключение троллинга и прочей гадости, естественно) должны получить либо ответное действие, либо официальный ответ. У меня нет юридического образования, но как любой айтишник могу массово в уме моделировать ситуации на заданную тему, с определенной вероятностью находя подвох в тех или иных административных документах. А когда нас много, верификация пройдет достаточно быстро и точно.
Получил 4-х значное число, а оно ни так, ни сяк не подходит :D
Есть какие-нибудь официальные релизы/ответы по этому поводу?