Comments 19
Привет, интересно было бы поучаствовать в тестировании этой штуки.
p.s. И это не вы осенью приходили в комментарии к нашему посту об автоматизации веб-дизайна на vc?
Спасибо за интерес! Как я упоминал в статье, планы были выпустить бета-версию после новогодних праздников, но, к сожалению, не получилось. Думаю, в течение месяца постараюсь всё-таки зафиксировать какое-то состояние системы и опубликовать сервис. Сейчас куплен домен png2html.com — там сейчас заглушка на WordPress, но вообще идея такая, что Щелкунчик будет работать по этому адресу. Так что, если интересно, проверяйте сайт через месяц.
По поводу Вашей статьи, нет, я её как-то пропустил тогда. Сейчас нашёл — очень интересная и полезная для меня статья, спасибо!
По поводу Вашей статьи, нет, я её как-то пропустил тогда. Сейчас нашёл — очень интересная и полезная для меня статья, спасибо!
Сейчас куплен домен png2html.com… Так что, если интересно, проверяйте сайт через месяц.
Посоветовал бы там поставить простой сборщик имейлов — да тот же плагин mailchimp для wp, особенно если будете писать о проекте до запуска где-то еще.
Письмо-напоминалка в час X будет гораздо эффективнее проверок сайта в рандомный момент времени)
Да, конечно, это более разумное решение)) Спасибо!
Привет, хотел узнать, как прогресс проекта? И поделиться прогрессом коллег, которые автоматом переверстывают сайты, беря за основу их старые версии:
www.youtube.com/watch?v=s4DoihjJgro
www.youtube.com/watch?v=s4DoihjJgro
Из принципиальных проблем: не все видно из статического изображения. Например:
— при скролировании: что остаётся на месте, что двигается. Бонусом изменение размера, появление/скрытие элементов при скролинге.
— разная верстка под разный размер окна браузера: резиновая/фиксированная, появление/скрытие элементов (адаптивная вёрстка)
— z-index — в простейшем случае для модальных окон
— наведение мышью
— щелчки — анимация кнопок
— эффекты от таймера — анимации, карусели
Но сама по себе идеи интересна и в будущем дизайнеры, возможно, будут помечать слои в psd понятным для щелкунчика образом.
— при скролировании: что остаётся на месте, что двигается. Бонусом изменение размера, появление/скрытие элементов при скролинге.
— разная верстка под разный размер окна браузера: резиновая/фиксированная, появление/скрытие элементов (адаптивная вёрстка)
— z-index — в простейшем случае для модальных окон
— наведение мышью
— щелчки — анимация кнопок
— эффекты от таймера — анимации, карусели
Но сама по себе идеи интересна и в будущем дизайнеры, возможно, будут помечать слои в psd понятным для щелкунчика образом.
Да, Вы совершенно правы! Это именно то, что я имел ввиду, когда говорил о том, что не всё заложено в изображении макета и об экспертных эвристиках. Одна из идей, как покрыть часть этих проблем — подавать на вход несколько изображений одной и той же страницы в разном состоянии. Впрочем, это всё мысли об относительно отдалённом будущем. Думаю, что если эти вещи останутся единственным, что останется на откуп человеку — это будет уже неплохим шагом вперёд.
… А ещё компании могут занести в него свои корпоративные стандарты, и он не только будет сам верстать как сотрудник компании, но и можно будет оценивать, насколько та или иная вёрстка следует стандартам, сравнивая со сгенерированным кодом....
Будущее еще одним маленьким шагом становится ближе… ) Вот она, первая «ласточка» автоматизации и замены людей, машинным кодом так сказать…
Вообще реально может получиться очень интересный продукт, будет реально востребован фрилансерами и малыми веб-студиями. взял бы на пробу, где посмотреть бы на «Щелкунчика»? )))
Насчёт замены людей, лично я всё ещё настроен весьма скептически на этот счёт, но делегирование рутины машине — это самое ближайшее будущее. Выше в комментариях написал о деталях релиза, не хочу дублировать комментарий.
А ещё компании могут занести в него свои корпоративные стандарты, и он не только будет сам верстать как сотрудник компании, но и можно будет оценивать, насколько та или иная вёрстка следует стандартам, сравнивая со сгенерированным кодом....
Это тоже уже здесь, по сути) Сейчас активно развиваются как дизайн-системы в корпоративном секторе — а как писал jvetrau, «если компания зрелая и имеет дизайн- систему, то подключение к ней алгоритмов позволит делать больше меньшими средствами», — так и появляются рассчитанные под массовость обучаемые системы, проводящие оценку качества дизайна сайтов — как раз сегодня RusBase о таком написали.
Есть способ постановки задачи из трех последовательных элементов:
I. проблема – состояние мира, которое требуется «разрешить»,
II. решение – собственно метод устранения проблемы,
III. результат – состояние мира после разрешения проблемы.
Но есть метод решения задачи с помощью постановки проблемы как кажущегося исключительным факта как прецедента, но на самом деле имеющего решение в прошлом. И есть метод решения задачи с такой постановкой проблемы с помошщью сравнительного анализа из имеющихся в прошлом базы решений на основе аналогии и адаптации, который заключается в цикле из повторяющихся шагов:
1. извлечение (retrieve) из базы решений
2. адаптация (reuse) извлечённого решения под новую проблему,
3. оценка (revise) адаптированного решения до его применения с подшагом дополнительной адаптации, либо переход на два шага назад к извлечению дополнительногое решения,
4. сохранение (retain) решения после успешной проверки с добавлением в базу.
Проект «Щ»:
I. Проблема: шаблон и код применительно к конкретному случаю.
II. Решение:
1. извлечение: префиксный ПОИСК шаблона из базы, который реализовал бы код похожим образом со СВОЙСТВАМИ описываемой проблемы с набором ПАРАМЕТРОВ
2. адаптация: набор ПАРАМЕТРОВ узла, а также СВОЙСТВ его ближайших потомков.
3. оценка:
4. сохранение:
III. Результат: шаблон и код который сгенерирован из шаблона применительно к конкретному случаю.
Как итог получаем новую проблему: решение задачи «N»- классовой классификации по X;Y-ПАРАМЕТРАМ проектируемых объектов с «n» прецедентами в базе, которая решается параметричеки без ввода опредделеныых СВОЙСТВ (например, макета дизайнера).
Поэтому возникает новая проблема: оценка результатов поиска, которая решается простым перебором.
Но в итоге: проще ручная адаптации от простого к сложному, с алгоритмом полу-ручного подбора свойств по структуре шаблона. И все из-за отсутствия самой базы шаблонов и коммерческой цели в получении НОВОГО продукта, а не в адаптации шаблона из баз методом перебора.
I. проблема – состояние мира, которое требуется «разрешить»,
II. решение – собственно метод устранения проблемы,
III. результат – состояние мира после разрешения проблемы.
Но есть метод решения задачи с помощью постановки проблемы как кажущегося исключительным факта как прецедента, но на самом деле имеющего решение в прошлом. И есть метод решения задачи с такой постановкой проблемы с помошщью сравнительного анализа из имеющихся в прошлом базы решений на основе аналогии и адаптации, который заключается в цикле из повторяющихся шагов:
1. извлечение (retrieve) из базы решений
2. адаптация (reuse) извлечённого решения под новую проблему,
3. оценка (revise) адаптированного решения до его применения с подшагом дополнительной адаптации, либо переход на два шага назад к извлечению дополнительногое решения,
4. сохранение (retain) решения после успешной проверки с добавлением в базу.
Проект «Щ»:
I. Проблема: шаблон и код применительно к конкретному случаю.
II. Решение:
1. извлечение: префиксный ПОИСК шаблона из базы, который реализовал бы код похожим образом со СВОЙСТВАМИ описываемой проблемы с набором ПАРАМЕТРОВ
2. адаптация: набор ПАРАМЕТРОВ узла, а также СВОЙСТВ его ближайших потомков.
3. оценка:
4. сохранение:
III. Результат: шаблон и код который сгенерирован из шаблона применительно к конкретному случаю.
Как итог получаем новую проблему: решение задачи «N»- классовой классификации по X;Y-ПАРАМЕТРАМ проектируемых объектов с «n» прецедентами в базе, которая решается параметричеки без ввода опредделеныых СВОЙСТВ (например, макета дизайнера).
Поэтому возникает новая проблема: оценка результатов поиска, которая решается простым перебором.
Но в итоге: проще ручная адаптации от простого к сложному, с алгоритмом полу-ручного подбора свойств по структуре шаблона. И все из-за отсутствия самой базы шаблонов и коммерческой цели в получении НОВОГО продукта, а не в адаптации шаблона из баз методом перебора.
Присоединяюсь к желающим увидеть демо. Если можно, чуть подробностей как решили задачу распознавания таблиц? Если плясать от рисунка, то довольно сложно определить место где таблица начинается и заканчивается ( когда нет явных границ или разделения цветом, или, еще сложнее когда таблицы перемежаются с текстом). Потом есть куча видов таблиц: с заголовками, с итоговыми строками, с обьединенными ячейками, со списками в ячейках и т.д. Тут использование нейронной сети для сегментации и классификации выглядит более перспективно. Похожая проблема с выпадающими списками и менюшками. Понятно, никто не ожидает что из рисунка можно вытащить список или дерево меню, но, хотя-бы определить верно элемент верстки (кнопка, выпадающий список или меню) будет большим прогрессом.
Распознавание таблиц пока ещё не реализовано. Это, действительно, одна из самых сложных подзадач. С меню проще — прецеденты, описывающие такие элементы, имеют чёткие характеристики (несколько текстовых элементов, расположенных в линию, находятся либо в верхней части страницы, либо в нижней). В принципе плоское меню распознаёт пока не плохо. С выпадающими сложнее. Часто путает с плавающим блоком. Я писал в одном из комментариев выше, что есть идея подавать на вход несколько изображений с разным состоянием страницы, но это пока гипотеза.
Спасибо за ответ. Получается, для классификации элементов, таких как меню, вам приходится самостоятельно находить ключевые характеристики и писать алгоритм их проверки. Такой подход череват тем что процесс «допиливания» становится бесконечным из-за постоянного появления новых характеристик при работе с большим обьемом входных данных в продакшене. Система разрабатывается и тестируется на определенном небольшом наборе вариантов верстки и понятно что в реальности будут случаи которые таким характеристикам не будут удовлетворять. Даже такое описание как «верхняя часть страницы» довольно расплывчато. Чтож, наберемся терпения и дождемся этапа тестирования.
Да, безусловно, будут случаи, которые не покроются прецедентами, особенно, если их собирать вручную.
С другой стороны, я сейчас работаю над механизмом полуавтоматического заполнения базы прецедентов.
Алгоритм сам выберет, какие свойства будут лучше идентифицировать объект. Здесь подходов множество: метод главных компонент, анализ формальных концептов, что-нибудь ещё. Надо экспериментировать… Но на первое время зафиксирую самые типовые блоки вручную. Повторюсь, по собственному опыту, мне кажется, что большая часть элементов не так уж и «уникальна».
К тому же, не требуется описать прецедент максимально точно. Нужно лишь сделать так, чтобы расстояние до более «близких» прецедентов" было меньше.
Например, «верхняя часть страницы» в данном случае определяется через свойство relative_position — это относительные координаты внутри родителя. Аналогичное свойство есть и для определения относительных координат внутри страницы в целом. Понятно, что чем данные координаты будут ближе соответствовать эталону, заданному в прецеденте, тем меньший штраф будет получать прецедент при нахождении расстояния. Нужно лишь найти эти «эталонные» значения. На лицо классическая задача регрессии, в которых нужно минимизировать ошибку.
Спасибо за интерес и конструктивные комментарии!
С другой стороны, я сейчас работаю над механизмом полуавтоматического заполнения базы прецедентов.
Алгоритм сам выберет, какие свойства будут лучше идентифицировать объект. Здесь подходов множество: метод главных компонент, анализ формальных концептов, что-нибудь ещё. Надо экспериментировать… Но на первое время зафиксирую самые типовые блоки вручную. Повторюсь, по собственному опыту, мне кажется, что большая часть элементов не так уж и «уникальна».
К тому же, не требуется описать прецедент максимально точно. Нужно лишь сделать так, чтобы расстояние до более «близких» прецедентов" было меньше.
Например, «верхняя часть страницы» в данном случае определяется через свойство relative_position — это относительные координаты внутри родителя. Аналогичное свойство есть и для определения относительных координат внутри страницы в целом. Понятно, что чем данные координаты будут ближе соответствовать эталону, заданному в прецеденте, тем меньший штраф будет получать прецедент при нахождении расстояния. Нужно лишь найти эти «эталонные» значения. На лицо классическая задача регрессии, в которых нужно минимизировать ошибку.
Спасибо за интерес и конструктивные комментарии!
довольно сложно определить место где таблица начинается и заканчивается ( когда нет явных границ или разделения цветом, или, еще сложнее когда таблицы перемежаются с текстом)
Можно определить некий служебный цвет, линии с этим цветом будут означать границу, но в конечную верстку не включаются.
Ваше решение позволяет обойти проблему в реализации алгоритмов классификации элементов, но, врятли приемлимо из-за необходимости учить дизайнеров верстать под специальную систему или же, если дизайн был сделан давно, придется нанимать человека который будет делать такую разметку. Тогда уж проще и надежнее заплатить верстальщику.
Sign up to leave a comment.
Свой pix2code с блэкджеком, но без нейронок