barcode

ePythia - пока полный epic fail

давно думал о полезности такой штуки, и как только узнал, что есть ребята, которые такое делают - сразу подписался на тестирование.

Пока впечатление очень грустные.

Приложение для телефона на таком уровне, что я бы просто стыдился даже любимой женщине показать. А это уже вторая бета (или третья?), которая доступна соверешнно посторонним людям тестерам. Наверное я перфекционист?

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

Вот только что, добавил задание в телефоне, полез на сайт - его нет в списке. Ну ок, автоматическая синхронизация (сложно ли, например, проверить что есть WiFi, и сразу закинуть добавленное задание на сервер?) у ребят только в планах.
Тыкаю в меню "Synchronization...". Приложение о чем-то думает без каких-либо видимых проявлений, потом выдает мне окошко "Unknow error" с кнопкой "Ок".

Это полный провал (мягко говоря, хотя хочется выразиться по-крепче).

Конечно, в aLogCat есть стандартный трейсбек от java-прогарммы с десятком классов из stdlib и строками в которых поймали исключение записи о том, где валится.

И тут сразу становится виден второй "провал" - средства для обратной связи прикольные (цуи2ю0 и всякое такое), но не очень удобные, для того, чтоб по каждому чиху эту обратную связь можно было осуществить. Из самой программы сообщить о проблеме совсем никак. Судя по всему, сама программа адекватных протоколов своей работы и возникших ошибок не ведет.

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

Есть, конечно, некоторое количество людей которые продираются через все этапы, но мне, например, уже лень выдирать из aLogCat кусочки, и высылать разработчикам.

Пока еще не лень просто написать багрепорт, но видимо с каждым разом будет всё ленивее и ленивее.
Tags: , ,
Привет Bor!

Я руковожу стартапом ePythia и мне было интересно прочитать такой подробный пост о текущем состоянии проекта.

Все так, прямо сейчас у нас масса недостатков.

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

Приложение, которое сейчас лежит в Маркете - это просто макет, проволочная конструкция, для которой мы сейчас готовим интерфейс, проектируемый исходя из сценариев использования приложения.

Прямо сейчас мы тестируем наш основной функционал. Определение положения пользователя в фоне и оповещение его о том, что он достиг заданной точки. Нам важно знать ограничения и недостатки текущей реализации, чтобы планировать дальнейшие шаги.

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

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

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

1. что значит не закончили работу над интерфейсом? В моём понимании, интерфейс - штука живая. Как и программный продукт. На начальных этапах - особенно, интерфейс развивается одновременно с добавлением функциональности.
Но есть вещи, из серии "сказал А, нужно непременно сказать Б". Если я выбираю точку на карте, и говорю "Ok", программа мне должна собщить, что именно я выбрал. Для функциональности "выбор точки" должен быть интерфейс, который отображает выбор. Он сейчас есть - но он не работает. Например, если текущее определяется автоматически, то после "Ok", в предыдущей Activity не пишут адрес. А если сдвинуть точку пальцем (кстати, спасибо что сделали это в этом релизе), то видимо карты вернут улицу/дом, и вот это уже таки возвращается и подписывается.
Т.е. определенная функциональность есть, UI в минимальном виде к этой функциональности есть, но работает криво. По-моему, это должен был проверить еще разработчик, и такое состояние вообще не должно выходить за рамки команды разработчиков/тестеров.

2. Макет, в моём понимании, это когда функциональность очерчена, но вместо реального кода местами заглушки, а "мясо" только нарастает. Но опять-же, если макет отдается отдается наружу, людям, которые не знают что задумано, что уже сделано, а что еще нет - заглушки тоже должны иметь некий UI.

3. Определение места, кстати, сработало, телефон подал сигнал :)
Но через несколько секунд после этого мне система сказала, что ePhythia упала. Был в дороге, смотреть что же там произошло и записывать кусочек лога не стал. Вот тут мне снова не очень понятно - вот я протестировал на одном примере эту функцию - вы об этом что-то узнали? Узнаете? Как?

4. Жду следующих обновлений с автоотправкой репортов :)

5. "Обновляться каждую неделю" - это реально круто.
Посмотрим, как оно на самом деле будет :)

я, наверное, из другой вселенной, но первое что я бы хотел видеть в публичной бете (хоть и по приглашениям) - это автоматический репорт о проблемах. Второе - "целостный" подход к построению приложения. То, что включено в сборку, должно быть проверено и работать полностью. Что не сделано, или живет в соседней ветке, или в релизной ветке должны быть заглушки тех мест, которые не сделаны.
Иначе получается, что человек что-то делал, оно не работает, время потрачено, но законченного результата нет.
1. Сейчас интерфейс собирает разработчик, так как ему это нравится, описаны только основные элементы, дальше он решает сам. Параллельно, дизайнер проектирует интерфейс. Не рисует кнопочки для текущей версии, а проектирует ее с нуля. Как только он закончит первую версию UI - дальше приложение будет развиваться в ее русле. То, что есть сейчас - черновик, который мы не будем исправлять - переделаем.
Баги в текущей версии есть, кто же спорит, сейчас правим их. Да, есть и досадные, которые должны были отловить еще до релиза. Будем строже подходить к выходному тестированию. У нас тут была проблемка с количеством аппаратов для внутреннего тестирования, но сегодня мы ее решили :)

2. Мясо нарастает, но нам "изнутри" не всегда очевидно то, что хорошо видно стороннему тестеру. Именно в этом смысл закрытой беты. Мы со своей стороны обеспечим быстрое исправление и возможность легкой отправки фидбека прямо из приложения. В следующей версии - уже будет.

3. Сбор статистики по использованию приложения мы делаем прямо сейчас. В смысле пишем эту часть. Тут проблема не в том, чтобы получать эти данные, а в том, чтобы обрабатывать их. Нам нужны инструменты для анализа этих данных. Работаем над ними.

4 и 5 Следующая версия будет не позже чем через неделю :)

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

Приложение меняется буквально каждый день. С первыми огрехами справимся быстро, дальше будет веселее. Дальше будем решать новые задачки, там самое интересное, так что надеюсь энтузиазм мы еще не задушили :)
опять-же, imho
1. Не важно кто именно делает что-то криво.
Эта сборка уровня "посмотреть, собирается ли оно вообще, перед коммитом"

2. Т.е. например, тот факт, что синхронизация может занимать много времени, не очевиден? И тот факт, что нужно пользователю показать, что
а) процесс синхронизации идет
б) завершился успешно или не очень
в) если завершился с ошибкой, нужно выделить хотя-бы три (навскидку для вашего случая) класса ошибок - "проблема тут", "проблема на сервере", "что-то совсем странное"
не очевидно?
По моему мнению такие вещи должны быть реализованы невзирая на то, как синхронизация внутри сделана. Эта та функциональность и представление, которое должно быть обязательно в приложении с котором работает пользователь. Хоть синхронизацию будет исполнять демон, а UI - суть отдельный процесс и просто показывает состояние демона, хоть эта функция будет висеть в коде рядом с UI.

3. imho, чтоб эффективно ошибки обрабатывать, их сначала нужно таки собирать. В зависимости от того, насколько они хорошо собираются, будут меняться требования к автоматической обработке. Чем больше будет сделано при сборе репортов, тем проще будет обрабатывать :)

для меня разделение публичная или нет проходит по границе "тестеровщик член команды или нет". Но если он в процессе разработки не участвует, о планах разработки ничего не знает, никаких NDA не подписывал и тд - это публика. Приглашения/подписка - это ограничение количества публики и возможность более детально подходить к конкретным проблем конкретного тестера (например можно набрать людей с разными устройствами, разными версиями платформы, и при обработке багрепортов от них сразу учитывать это).
Это пользователи, которые заранее понимают, что не всё работает, итд, но они не часть команды. Как-то так я это воспринимаю.

энтузиазм не задушили :)

На самом деле, спасибо, что отвечаете. Надеюсь, что будет веселее :)