ProgressBar и индикаторы выполнения процесса

Любое приложение, содержащее длинные операции (в которых время выполнения может превышать 1 минуту), должно иметь ProgressBar. Причем не просто "бегунок" который показывает что процесс идет, но по которому не понятно сколько выполнилось и сколько еще осталось и вообще работает приложение или "подвисло", а хороший ProgressBar с индикатором % выполнения операции и, желательно, показом сколько времени осталось до окончания выполнения. Такие длинные операции содержатся в большинстве систем работающих с данными и в вычислительных задачах. И, я думаю, большинство разработчиков постоянно сталкивается с ProgressBar-ами.

Что должен содержать ProgressBar и индикаторы процесса выполнения (в логическом порядке, а не в порядке важности):

• 1. Количественный показатель (в штуках, в байтах и т.д.) общего объема данных, которые требуется обработать.
• 2. Количественный показатель обработанных данных.
• 3. Количественный показатель данных, которые осталось обработать.
• 4. Время, потраченное на обработку данных (из п.2).
• 5. Ориентировочное время обработки оставшихся данных.
• 6. Визуальное отображение % обработанных данных (собственно сам ProgressBar).
• 7. Скорость обработки данных.

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

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

• 1. Заранее не известно, сколько данных должно быть обработано. Эта проблема очень часто возникает при запросах к базе данных, когда заранее не известно, сколько данных должно быть возвращено базой. Так же не редка ситуация, когда в вычислительных задачах перебор элементов делается по большому набору критериев, в результате чего заранее точно не известно, сколько данных надо перебрать. В обоих случаях оценить общее количество данных все-таки можно выполнив предварительные вычисления или предварительный запрос к базе. Это, конечно, займет лишнее время, но в большинстве случаев это окупается, т.к. информированный пользователь - удовлетворенный пользователь, а неинформированный будет злиться на "глупую программу" которая повисла и не понятно чего там делает. Минус такого решения - оно не подходит для задач, критичных к общему времени выполнения. Второй минус - появляется дополнительный процесс предварительного подсчета, которому так же может потребоваться свой ProgressBar.
• 2. В процессе выполнения операции невозможно (или можно, но с серьезной дополнительной нагрузкой на систему) узнать процент выполнения операции. Тут все зависит от архитектуры системы и вопрос возвращения данных для показа прогресса надо закладывать еще в момент проектирования. Встраивание этого функционала в уже готовую систему может быть очень сложным и может потребовать "перекраивания" взаимодействия классов и модулей системы. Более-менее стандартные решения: при запросах к базе данных отдавать информацию постранично; в задачах, работающих в основном потоке поднимать события обрабатывающим классом; в задачах, работающих в отдельном потоке периодически опрашивать поток или посылать сообщения из потока.
• 3. Процесс состоит из набора подпроцессов. Здесь есть, где разгуляться фантазии.
1. Можно сделать единый ProgressBar и показывать пользователю только сколько времени осталось до конца обработки всех процессов.
2. Можно к единому ProgressBar-у добавить индикатор наименования выполняющегося процесса.
3. Можно сделать отдельный ProgressBar для каждого процесса. Это хорошо когда процессов всего 2, иначе в окне будет слишком много информации, что будет путать пользователя.
4. Можно показывать один ProgressBar, но перезапускать его для каждого процесса. Дополнительно к нему будет полезен лог с законченными и незаконченными процессами.
5. Можно объединить первый и предыдущий варианты и показывать один общий ProgressBar, и второй перезапускаемый для каждого процесса.
• 4. Выполняется параллельно несколько процессов. Раньше эта проблема появлялась не часто и, в основном, при закачке данных. Для вычислительных задач распараллеливание процесса вычисления при одноядерном процессоре большого смысла не имела, т.к. одна задача занимала весь ресурс процессора (ну или столько, сколько ей отводилось системой) и запуск второй, параллельной, задачи пропорционально тормозил выполнение первой. Сейчас при появлении CoreDuo и Core2Duo (а в дальнейшем ядер, похоже, будет все больше и больше) можно и нужно пускать параллельные процессы в разных потоках, соответственно вопрос отображения в одном ProgressBar-е нескольких операций выполняющихся в разных потоках становится очень актуальным. Если единицы измерения количественных данных всех параллельных операций одинаковые и операции имеют единую логическую базу – можно показывать единый ProgressBar с суммарными данными. Что делать с операциями, логически не совместимыми, покажет будущий опыт, а пока у меня красивого решения для такой ситуации нет.

Развлекаемся...

Развлекательные посты - замечательный способ продвижения даже для серьезных сообществ.

Richard Quick, freelance web designer, в своем блоге про дизайн написал забавный пост "How to fake a Web 2.0 logo", который читается именно как развлечение. Пост попал на головную страницу Digg.com, в результате рост посетителей за день с 555 до 47501 захода. Трафик, конечно, обеспечил Digg.com, а вот попадание поста на Digg.com обеспечили, скорее всего, название (тут сразу и Web2.0, и How to, и fake) и хороший развлекательный тон.

Сейчас на головной странице Digg.com 2 первых поста: "Porn-Infected PC Crazy Woman Faces 40 Years - True Story" (с pcworld.com между прочим) и "10 Amazing Things You Didn't Know about Animals".

Еще за одним примером далеко ходить не надо. На ITBlogs по посещениям с большим отрывом лидирует пост "Слухи...", несущий в своем названии явно развлекательную направленность. На втором месте пост "Чего громим? Кого мочим? (Читаем версии в обсуждении)" тоже с не особо серьезным названием.

Т.е. пост на серьезную тему прочтут не все, а те, кому тема интересна и в данный момент есть время на осмысление. Пост с развлекательным заголовком прочтут все (или, как минимум, откроют).

PS: Кстати в тему пост "Buzz titles" о том как составить привлекательное название для статьи или книги по IT, ну и для постов тоже.

Блого-зависимость

10 дней практически без интернета явно продемонстрировали отрицательные стороны постоянной "включенности".

1. Желание что-нибудь почитать (блоги или новости) близко к наркотической зависимости. Рука тянется к иконке броузера, хотя мозг знает, что интернета нет.
2. В связи с тем, что броузер ничего не показывает, резко возросла производительность труда. Через дней 5 трудотерапия начала оказывать благотворное влияние и рука почти перестала тянуться к иконке броузера.
3. Появилось много идей по поводу решения тактических вопросов. Похоже, излишнее увлечение блогосферой стимулирует мысли стратегического направления (наверное из-за того, что обсуждается много тем не затрагивающих текущих задач, но рождающих новые идеи "на будущее"), и за этими думами "о высоком" решение текущих проблем становится "текучкой", что отражается на качестве принимаемых решений.
4. Одинаковые мысли приходят в голову разным людям практически одновременно. Может количество идей (а не ума) величина постоянная при постоянно растущем количестве людей? Окончательно убедилась в том, что если появилась мысль, о которой хочется написать – писать надо сразу же, иначе об этом напишет кто-то другой. При ежедневном прочтении лент это не так заметно, т.к. можно поучаствовать в обсуждении. Но если прошло уже несколько дней, то обсуждение уже закончилось, а поднимать заново тему смысла не имеет т.к. все желающие уже высказались.
5. Новые блоги, которые хочется почитать, появляются слишком часто. Старые при этом так же читаются. В результате за 10 дней более 200 непрочитанных постов! А ведь если бы интернет был, я бы их прочла. Причем действительно полезной информации в этом потоке очень мало.

Когда то "телевизор нам природу заменил", теперь, похоже, "интернет нам телевизор заменил".

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

С интернетом все сложнее. Во первых он нужен для работы, во вторых, в отличии от телевизора, дает доступ к массе полезной и просто интересной информации. Т.ч. побороть блого-зависимость отключением интернета не удастся. Надо как-то искать золотую середину между "постоянной включенностью" и "абсолютной выключенностью".

Чем бы заняться стартапу

Чем бы заняться стартапу, чтобы перестать быть стартапом и превратиться в крупную фирму (возможно по пути еще получить инвесторские деньги с вариантом продажи в конце). Даже до инвесторских денег надо дожить, т.к. инвесторы очень редко вкладываются в идею. Инвесторы хотят растущую компанию, которой можно помочь вырасти, заработав на этом. Но сначала стартап, по любому, должен обеспечивать себя сам, и или он будет проедать учредительские деньги в надежде на деньги инвесторов или будет жить на то, что принесет его продукт. Так чем же заняться стартапу?

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

Пройдемся по пунктам.

1. Нужное

С первым постулатом про нужное все более-менее ясно. Хорошо бы только определиться кому нужное, но это уже детали, а сам по себе постулат вопросов не вызывает.

2. Новое

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

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

• Пользователям не надо объяснять, что ваш продукт делает и зачем он им вообще нужен.
• Пользователи сами ищут продукт данной категории и нужно только найти места, где они его ищут.
• Хорошо работает контекстная реклама т.к. пользователи ищут и чем более "горячая" тема тем больше ищут.
• Продукт можно позиционировать внутри категории и относительно других известных продуктов данной категории.
• Пресс-релизы можно делать короткие, но содержательные, концентрируясь на особенностях продукта, а не на объяснении, зачем он в принципе нужен.
• И если продукт все-таки стал известен, журналистам проще о нем писать.

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

2.1. Повторение - не уникальное и не новое

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

2.2. Новое, но не уникальное

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

3. Уникальное

А теперь самый экстремальный вариант – новый уникальный продукт. Создатели должны очень сильно верить в то, что то, что они делают хоть кому-то нужно. Но даже если это действительно очень нужный продукт, надо о нем сначала как-то известить потенциальных пользователей. Тут ситуации очень сильно отличаются в зависимости от рынка.

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

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