Могу предположить что задержки распознавания действительно малы (не 2мс, конечно, но и не 150-200мс).
Скорее проблема кроется во взаимодействии Kinect с другой системой
Все же мне кажется, что работа дизайнера должна заключаться в отрисовке дизайна, но никак не нативных компонентов для какой либо платформы. И тем более он не должен, как мне кажется, заниматься созданием прототипа.
Впрочем, в небольших фирмах дизайнер может выполнять много ролей сразу, это не редкость.
Все же, до сих пор, cистема реагирует с некоторой задержкой на действия, впрочем это уже гораздо лучше того, что было всего пару-тройку лет назад :)
Ждем и надеемся…
Проблема еще в том, что эти темплейты — просто некий абстрактный набор стандартных компонентов, причем достаточно скудный. При любой необходимости использовать более сложный объект придется поработать дизайнеру. Да бесплатно, но платят за инструменты прототипирования как раз таки, чтобы разгрузить дизайнера/разработчика от лишних задач.
А насчет интерактивности — вопрос спорный. Полная интерактивность действительно редко нужна, но небольшое количество действий обычно присутствует в каждом создаваемом конкретно нами прототипе.
Тем более, как только Вам захочется или понадобится показать прототип заказчику (как минимум в более-менее приближенном к финальному варианту виде) возникнут проблемы.
Мне кажется, что с тем же успехом, имея нужные изображения объектов можно и в Word/Excel (кстати мы сами видели, как некоторые фирмы так делают) клипать прототипы. Увы, это совсем не говорит о том, что это удобно/быстро/просто.
Хотя учитывая как Google Docs набирает обороты, возможно там вскоре появится что-то для создания прототипов ;)
Fireworks, на самом деле, слабо подходит для прототипирования (особенно приложений), так как нет готовых компонентов и слабоват набор действий. Плюс сам прототип получается практически статичен.
Выезжает Fireworks засчет хорошей работы с другими продуктами Adobe — не было бы этого, думаю мало кто бы его впринципе использовал. Ну, это лично мое мнение…
А, да, еще он только Win/Mac. А у нас люди, занимающиеся содание прототипов отчасти сидят на Linux'ах, поэтому этот вариант отпадает. И нет, менять ОС ради одного инструмента мы были не готовы.
А на цену, на самом деле, мы смотрели в последнюю очередь.
Если уж об этом говорить — добрая половина постов делается ради рекламы, но все же хочется поделиться своим опытом, а не просто банально прорекламировать какой-либо очередной продукт, не согласны?)
Просто для тех, кому интересно узнать продолжение истории мы сделаем следующий пост, в котором детально опишем этапы создания инструмента, какие проблемы и сложности мы встретили и как их решали. Думаю это может быть полезно вне зависимости от того нужен ли Вам сам продукт или нет :)
Насчет цены — это отдельный большой разговор, ибо каждая компания выбирает цену на свой продукт по весьма неясным и известным только им меркам. Правда иногда, следуя запросам от пользователей могут отделяться лицензии для частного использования/обучения/других случаев, впрочем это происходит достаточно редко и занимает длительные периоды.
P.S. Ответ строкой ниже на самом деле предназначался Вам, извиняюсь за промах.
Кстати тоже замечал, что у мобильных устройств отсутствует банальная заливка — это весьма странно, учитывая что платформы разработки и скорости устройств более чем позволяют реализовывать куда более сложные вещи.
Тем более сами алгоритмы уже давно придуманы и реализованы на всех возможных языках…
Axure был одним из первых на проверку, когда мы пытались найти подходящий инструмент, но у нас остро стояла необходимость в кроссплатформенном решении, как я уже писал.
Если говорить конкретно — у нас часть фирмы работает на Linux'ах, пара Mac'ов и остатки — Windows (даже некоторое время была пара Sun'овский станций). Axure — win/mac решение only, увы.
К тому же на тот момент (не хочу соврать, был примерно 2005-2006 год) разрабатывать в Axure десктопные приложения было весьма накладно.
По этим и некоторым другим причинам этот вариант отпал достаточно быстро.
Хотя сложно поспорить, что Axure на данный момент один из самых лучших инструментов для прототипирования вэб-сайтов.
Да даже данную реализацию можно ускорить, вполне вероятно.
К тому же автор уже приводил выше ссылку на более оптимальные варианты заливки.
Думаю есть и другие алгоритмы и немало…
Я так понимаю про чай — это был для наглядности сделан первый неоптимальный вариант (или же нет?)
На Java, к примеру, подобный алгоритм мгновенно заполняет такие небольшие изображения и секунду-две тратит на огромные (2000х2000+). А «пошаговая» отрисовка заливки как на видео сделана скорее для наглядности, чтобы показать как работает алгоритм, так что не думаю что там самый оптимальный вариант
Довольно давно реализовывал данный алгоритм на Java для заполнения BufferedImage — столкнулся с указанной в статье проблемой и еще парой других. Впрочем результат после пары-тройки оптимизаций работает очень даже.
Возможно чуть позже, когда к самому заполнению допишу часть алгоритма для сглаживания границ заполнения (а-ля то, что делает Photoshop), стоит разместить в отдельную статью?
В любом случае данная статья будет весьма полезна для тех, кто не в курсе что и как :)
Естественно!
Помимо того что уже было сказано в топике — в случае удачно проведенного мероприятия (в чем лично я не сомневаюсь ;) мы выложим все результаты встречи в виде отдельной офромленной статьи в блог.
Также, основная (сырая) часть материалов будет доступна вскоре после события (раньше статьи) на нашем сайте — для тех кто не любит долго ждать.
Скорее проблема кроется во взаимодействии Kinect с другой системой
Впрочем, в небольших фирмах дизайнер может выполнять много ролей сразу, это не редкость.
Ждем и надеемся…
А насчет интерактивности — вопрос спорный. Полная интерактивность действительно редко нужна, но небольшое количество действий обычно присутствует в каждом создаваемом конкретно нами прототипе.
Тем более, как только Вам захочется или понадобится показать прототип заказчику (как минимум в более-менее приближенном к финальному варианту виде) возникнут проблемы.
Хотя учитывая как Google Docs набирает обороты, возможно там вскоре появится что-то для создания прототипов ;)
Добавили, что это была «Часть I» — продолжение следует ;)
Выезжает Fireworks засчет хорошей работы с другими продуктами Adobe — не было бы этого, думаю мало кто бы его впринципе использовал. Ну, это лично мое мнение…
А, да, еще он только Win/Mac. А у нас люди, занимающиеся содание прототипов отчасти сидят на Linux'ах, поэтому этот вариант отпадает. И нет, менять ОС ради одного инструмента мы были не готовы.
А на цену, на самом деле, мы смотрели в последнюю очередь.
Просто для тех, кому интересно узнать продолжение истории мы сделаем следующий пост, в котором детально опишем этапы создания инструмента, какие проблемы и сложности мы встретили и как их решали. Думаю это может быть полезно вне зависимости от того нужен ли Вам сам продукт или нет :)
P.S. Ответ строкой ниже на самом деле предназначался Вам, извиняюсь за промах.
Тем более сами алгоритмы уже давно придуманы и реализованы на всех возможных языках…
Если говорить конкретно — у нас часть фирмы работает на Linux'ах, пара Mac'ов и остатки — Windows (даже некоторое время была пара Sun'овский станций). Axure — win/mac решение only, увы.
К тому же на тот момент (не хочу соврать, был примерно 2005-2006 год) разрабатывать в Axure десктопные приложения было весьма накладно.
По этим и некоторым другим причинам этот вариант отпал достаточно быстро.
Хотя сложно поспорить, что Axure на данный момент один из самых лучших инструментов для прототипирования вэб-сайтов.
К тому же автор уже приводил выше ссылку на более оптимальные варианты заливки.
Думаю есть и другие алгоритмы и немало…
А ресурс достаточно интересный, спасибо за ссылку :)
Тем более, что самому интересно заняться доработкой алгоритма :)
На Java, к примеру, подобный алгоритм мгновенно заполняет такие небольшие изображения и секунду-две тратит на огромные (2000х2000+). А «пошаговая» отрисовка заливки как на видео сделана скорее для наглядности, чтобы показать как работает алгоритм, так что не думаю что там самый оптимальный вариант
Возможно чуть позже, когда к самому заполнению допишу часть алгоритма для сглаживания границ заполнения (а-ля то, что делает Photoshop), стоит разместить в отдельную статью?
В любом случае данная статья будет весьма полезна для тех, кто не в курсе что и как :)
Помимо того что уже было сказано в топике — в случае удачно проведенного мероприятия (в чем лично я не сомневаюсь ;) мы выложим все результаты встречи в виде отдельной офромленной статьи в блог.
Также, основная (сырая) часть материалов будет доступна вскоре после события (раньше статьи) на нашем сайте — для тех кто не любит долго ждать.