Здравствуйте, Sheridan, Вы писали:
S>Ну, как бы в вики слов побольше написано...
А это не так важно. По сути нейросетями решают две задачи: классификацию и аппроксимацию. Лучше для начала прочитать пару книг,
например, "Методы и технологии искусственного интеллекта", и оценить место нейросетей в такой области знаний, как методы ИИ.
К сожалению, статьи в википедии, формирует мнение об этих методах, как о волшебных таблетках, но в реальности все гораздо печальнее.
Расположение элементов на форме — задача оптимизации скорее, и решается совсем по-другому.
Здравствуйте, m.aksenov, Вы писали:
MA>Расположение элементов на форме — задача оптимизации скорее, и решается совсем по-другому.
Проблема — в том, что проектирование гуя не сводится к "расположению элементов на форме". В таких задачах равных компьютеру нет — достаточно скормить ему формальные правила вёрстки с параметрами "оптимизации", и он ловко раскидает контролы по форме в соответствии с этими критериями.
Увы, реального улучшения UI по сравнению с PropertyGrid вы так не получите. Для него надо копать глубже, и не только разбрасывать контролы, а и выбирать подходящие.
Ну там — если есть два параметра по три варианта каждый, то это 9 сочетаний. Не все сочетания могут быть валидны. И одну и ту же задачу "выбрать значения двух связанных параметров" можно решать огромным количеством способов:
— две радиогруппы, при выборе в одной невалидные значения в другой дизаблятся
— квадрат 3*3 из радиобаттонов, в котором нелегальные сочетания задизаблены сразу
— дроп-даун со всеми валидными комбинациями
— радиогруппа со всеми валидными комбинациями
Какой из них будет более удобен? А хрен его знает — без закапывания в семантику мы это не узнаем. Может быть, эти параметры вообще не надо вводить — они выводятся из контекста взаимодействия.
Может быть, из 5 легальных сочетаний этих двух параметров в 99% случаев используется ровно одно, а остальные надо показывать только по дополнительному запросу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
S>Камрады, не всплывала ли идея? Реально ли реализовать? S>Что думаете?
У нас есть автоматическое создание форм из кучи таблиц и контролов. На начальном этапе использовали симплекс-метод для формирования хотя бы относительно красивых форм. Потом по мере развития естественно выкинули это и перешли на какие-то лэйауты по умолчанию с возможностью редактировать дизайн.
В общем, насчет нейросетей думаю, что если и заморачиваться с такой вот автоматической генерацией форм, то вполне можно нормальные математические методы и применить вроде симплекс-метода и аналогов, а нейросети оставить для тех областей, где они нужны и применимы.
Здравствуйте, m.aksenov, Вы писали: MA>Это будет аналог PropertyGrid или чего-то подобного, но с более-менее адекватными отступами и прочим. Зачастую люди сами ничего лучше не дизайнят, такой уж он, корпоративный софт.
А, вот, собственно. http://rsdn.ru/forum/usability/4896253.1
Здравствуйте, Sheridan, Вы писали:
S>Ну как то же учат AI в марио играть или AI к нейросетям отношения не имеет? (я ни то ни другое не курил подробно) S>http://www.youtube.com/watch?v=bBZ7kEphv3s
Обучить такому можно используя динамические модели, которые вообще не machine learning, а теория автоматического управления. Здесь задача
повторить движения игрока, за которым адаптивная система наблюдает, а потом на те же события (то же состояние среды) повторить реакцию.
Еще раз AI != Machine Learning, Machine Learning != Neural Networks.
Ну, тут примерно получается решение задачи оптимизации, хотя на мой взгляд, это решение задачи классификации
(оптимальное — неоптимальное локальное решение), но это уже философия скорее.
Если посмотреть на исходник библиотеки convnetjs,
которая там используется, то можно увидеть, что система берет случайные шаги в доступном пространстве решений и
пытается выбрать из 4 имеющихся наиболее выгодное. Сказать что это — прорыв весьма сложно, и, вероятно,
использование других подходов к решению этой задачи дало бы более эффективные результаты. Автор, кстати,
сам указывает, что до 2048 он еще пока не дошел, что намекает на то, что достижение локальных оптимумов
вообще говоря может не привести к решению целевой задачи.
Об этом (о вопросах сходимости и теоретической обоснованности модели), кстати, и написано в английской вики.
Здравствуйте, m.aksenov, Вы писали:
S>>http://www.youtube.com/watch?v=OKTD_VedHdA
MA>А тут надо смотреть методологию. Скорее всего решалась задача классификации, MA>но интересно взглянуть на топологию сети и конкретные методы обучения. Из акадамического интереса.
Если я не ошибся, есть исходники и я временно это запустил тут
Здравствуйте, Sheridan, Вы писали: S>А дальше гуй-компилер на основе подсказок и своего "опыта" выстраивает контролы на форме(формах) и генерирует код этих форм плюс код прослойки взаимодействия между формой и нашим кодом. S>Как то так.
Такого — как грязи. Все программисты проходят в своём взрослении через этап "давайте генерировать гуй по метаданным".
В дотнете, к примеру, встроен контрол PropertyGrid, который воплощает один из вариантов этой идеи.
Проблема — только одна: юзабилити такого гуя стремится к нулю.
При небольшом количестве управляемых параметров он не слишком ужасен, но и экономия усилий разработчика невелика. (Главное — он спасает от ситуации типа "добавили поле в базу — забыли добавить в UI").
А как только начинается что-то более-менее сложное — всё, копец, приехали.
Сгенерированный UI становится ужасен, и приходится звать дизайнера с юзабилистом, выбрасывать автогенерённый гуй и заменять его на спроектированный человеком.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
BT>>А вот как обучить нейросеть продумывать ресайз и якоря — S>Это да... Тут придется хорошенько думать...
ИМХО, как раз ресайз и якоря — это та часть гуя, которую проще всего скормить нейросети (с тем, чтобы получить на выходе осмысленный результат).
Примерно так:
1. Взять набор форм из разных приложений, которые мы считаем "хорошими" в плане гуя. Их ресайз и якоря — либо должны быть описаны декларативно, либо их можно вытащить эмуляцией (программно порастягивать форму, посмотреть, как изменились контролы, и все это записать в статистику).
2. На этой обучающей выборке обучить нейросеть. Получившаяся обученная нейросеть должна представлять собой "правила хорошего тона" для ресайза контролов.
3. К контролам новой формы применить эти правила ресайза, записанные в структуре нейросети (т.е. на выходе получить программный код, делающий ресайз в соответствии с этими правилами).
Здравствуйте, Sheridan, Вы писали:
S>Камрады, не всплывала ли идея? Реально ли реализовать? S>Что думаете?
Думаю сначала надо сделать функцию оценки gui по разным критериям.
Читаемость, функциональнось, последовательность операций, группировку, кол-во операций для выполнения типовых сценарив и т.п., утомляемость, концентрацию, кол-во параметров удерживаемых в памяти ...
По целевым группам: ввод данных для дебилов, ввод данных дисциплинированным персоналом, мониторинг, отладка, ....
Только потом можно натравливать нейронные сети, генетические алгоритмы и другие методы перебора вариантов с
различными эвристиками и адабустами.
Здравствуйте, Brice Tribbiani, Вы писали:
S>>Ну не скажи, в корпоративном софте частенько встречаются монстроформы с 30+ контролами и, соответственно, крайне мало кто заморачивается продумать их расположение, не говоря о том, чтобы упаковать в лайоуты, продумав ресайз и якоря. Ну итд.
BT>Расположение определяется мокапом же, не?
Ну я не совсем про мокап... Мокап это уже почти готовый гуй.
На пальцах:
В коде есть переменные, флаги, значения которых надо показать пользователю\спросить у пользователя. Отмечаем их флагами-комментариями, например как для того-же doxygen, указываем их отношения, привязываем к неким группам. Ну, то есть пишем подсказки гуй-компилеру.
А дальше гуй-компилер на основе подсказок и своего "опыта" выстраивает контролы на форме(формах) и генерирует код этих форм плюс код прослойки взаимодействия между формой и нашим кодом.
Как то так.
BT>А вот как обучить нейросеть продумывать ресайз и якоря —
Это да... Тут придется хорошенько думать...
Здравствуйте, Sheridan, Вы писали:
S>А дальше гуй-компилер на основе подсказок и своего "опыта" выстраивает контролы на форме(формах) и генерирует код этих форм плюс код прослойки взаимодействия между формой и нашим кодом.
в 80-х генераторы программ для субд это делали. помню, на кларионе можно было за 10 минут создать простенькую программу, в частности благодаря этой фиче
Здравствуйте, Brice Tribbiani, Вы писали:
BT>В смысле, на входе мокап, на выходе форма с контроллами?
Да, чтото такое.
BT>Наверно реально, но смысла немного, имхо.
Ну не скажи, в корпоративном софте частенько встречаются монстроформы с 30+ контролами и, соответственно, крайне мало кто заморачивается продумать их расположение, не говоря о том, чтобы упаковать в лайоуты, продумав ресайз и якоря. Ну итд.
S>Ну не скажи, в корпоративном софте частенько встречаются монстроформы с 30+ контролами и, соответственно, крайне мало кто заморачивается продумать их расположение, не говоря о том, чтобы упаковать в лайоуты, продумав ресайз и якоря. Ну итд.
Расположение определяется мокапом же, не?
А вот как обучить нейросеть продумывать ресайз и якоря —
хотел уже на боковую
папаху снял и сапоги
но в комментариях проснулись
враги
Здравствуйте, Don Reba, Вы писали:
DR>Нейросети — метод интерполяции. Что мы собираемся интерполировать в случае GUI приложений?
Ну, как бы в вики слов побольше написано...
Здравствуйте, Sheridan, Вы писали:
S>На пальцах: S>В коде есть переменные, флаги, значения которых надо показать пользователю\спросить у пользователя. Отмечаем их флагами-комментариями, например как для того-же doxygen, указываем их отношения, привязываем к неким группам. Ну, то есть пишем подсказки гуй-компилеру.
Это лучше делать через модель данных в MVC архитектуре, тогда да, указываем интересующие поля модели и набор необходимых контролов можно сгенерить автоматически. Тогда код взаимодействия тоже легко делается, наподобии QDataWidgetMapper в Qt, в дотнете вроде тоже такое есть.
S>А дальше гуй-компилер на основе подсказок и своего "опыта" выстраивает контролы на форме(формах) и генерирует код этих форм плюс код прослойки взаимодействия между формой и нашим кодом. S>Как то так.
А вот тут интересно, насколько удобный гуй можно автоматически сделать, потому что тупо загнать все в лейаут и компактно расположить — да, а вот разбить на подгруппы сообразно функционалу — никак, ибо данных не хватает.
Короче, имхо если мы пытаемся заменить софтом работу квалифицированного UI дизайнера и разработчика — это врядли, а если облегчить рутинную часть работы — так её не так много, чтобы ради этого стоило такой инструмент разрабатывать/покупать, имхо.
хотел уже на боковую
папаху снял и сапоги
но в комментариях проснулись
враги
Здравствуйте, Sheridan, Вы писали:
S> Ну не скажи, в корпоративном софте частенько встречаются монстроформы с 30+ контролами
Это встречается в узких нишах от отсутствия конкуренции. В конкурентной среде такие долго не выживают.
S> и, соответственно, крайне мало кто заморачивается продумать их расположение, не говоря о том, чтобы упаковать в лайоуты, продумав ресайз и якоря. Ну итд.
Думаешь, те же люди заморочатся с нейросетью?
Hardware eventually fails. Software eventually works. ::: avalon/1.0.442
BT>А вот тут интересно, насколько удобный гуй можно автоматически сделать, потому что тупо загнать все в лейаут и компактно расположить — да, а вот разбить на подгруппы сообразно функционалу — никак, ибо данных не хватает.
Поэтому и нейросеть. Только как обучить?...
BT>Короче, имхо если мы пытаемся заменить софтом работу квалифицированного UI дизайнера и разработчика — это врядли, а если облегчить рутинную часть работы — так её не так много, чтобы ради этого стоило такой инструмент разрабатывать/покупать, имхо.
Ну как бы там правил не так уж и много... Ну например ввод даты после ввода времени или "применить ко всем" рядом с выбором действия
Вопрос был — есть ли такое или реально ли создать, а не "как?" и "зачем?"
Ну и в этюды, соответственно, потому как имхо интересная задача
Здравствуйте, wildwind, Вы писали:
S>> Ну не скажи, в корпоративном софте частенько встречаются монстроформы с 30+ контролами W>Это встречается в узких нишах от отсутствия конкуренции. В конкурентной среде такие долго не выживают.
А в неконкурентной, к сожалению, процветают
S>> и, соответственно, крайне мало кто заморачивается продумать их расположение, не говоря о том, чтобы упаковать в лайоуты, продумав ресайз и якоря. Ну итд. W>Думаешь, те же люди заморочатся с нейросетью?
Почему же те-же?
Здравствуйте, wildwind, Вы писали:
BT>> В смысле, на входе мокап, на выходе форма с контроллами? W>Не, та входе текст в стиле "Хачу, чтоб была крутааа!!11"
Нее, неверная постановка задачи. На вход надо подавать "Хочу завтра купить яхту и прилететь к ней на багамы в личном самолете, чтобы уплыть к себе в особняк на небольшом острове"
Здравствуйте, Sheridan, Вы писали:
BT>>Наверно реально, но смысла немного, имхо. S>Ну не скажи, в корпоративном софте частенько встречаются монстроформы с 30+ контролами и, соответственно, крайне мало кто заморачивается продумать их расположение, не говоря о том, чтобы упаковать в лайоуты, продумав ресайз и якоря. Ну итд.
Здравствуйте, night beast, Вы писали:
S>>Вопрос был — есть ли такое или реально ли создать, а не "как?" и "зачем?" NB>основной вопрос: что подается на вход и что ожидается на выходе.
На выходе готовая форма. Ну смотря для чего... Для qt например класс формы с кодом генерации...
На входе... Было бы неплохо на входе исходники проекта с отметкой переменных, которые следует отображать на форме.
Дьявол, конечно, в мелочах, я прекрасно понимаю.
S>>Ну и в этюды, соответственно, потому как имхо интересная задача NB>интересная потому-что встречается слово нейросети?
Именно так.
Здравствуйте, Sheridan, Вы писали:
S>>>Вопрос был — есть ли такое или реально ли создать, а не "как?" и "зачем?" NB>>основной вопрос: что подается на вход и что ожидается на выходе. S>На выходе готовая форма. Ну смотря для чего... Для qt например класс формы с кодом генерации... S>На входе... Было бы неплохо на входе исходники проекта с отметкой переменных, которые следует отображать на форме. S>Дьявол, конечно, в мелочах, я прекрасно понимаю.
нейросети не работает с "формами".
нейросеть, это грубо говоря "черный ящик".
фиксированное количество входов, и фиксированное количество выходов. все естественно числовые значения.
как твою форму туда запихивать будем?
S>>>Ну и в этюды, соответственно, потому как имхо интересная задача NB>>интересная потому-что встречается слово нейросети? S>Именно так.
тогда и задача забивания гвоздей нейроесетью тоже наверно интересна
Здравствуйте, night beast, Вы писали:
NB>нейросеть, это грубо говоря "черный ящик". NB>фиксированное количество входов, и фиксированное количество выходов. все естественно числовые значения. NB>как твою форму туда запихивать будем?
Ну как то же учат AI в марио играть или AI к нейросетям отношения не имеет? (я ни то ни другое не курил подробно) http://www.youtube.com/watch?v=bBZ7kEphv3s
Здравствуйте, Sheridan, Вы писали:
NB>>нейросеть, это грубо говоря "черный ящик". NB>>фиксированное количество входов, и фиксированное количество выходов. все естественно числовые значения. NB>>как твою форму туда запихивать будем? S>Ну как то же учат AI в марио играть или AI к нейросетям отношения не имеет? (я ни то ни другое не курил подробно) S>http://www.youtube.com/watch?v=bBZ7kEphv3s
Здравствуйте, m.aksenov, Вы писали:
MA>Обучить такому можно используя динамические модели, которые вообще не machine learning, а теория автоматического управления. Здесь задача MA>повторить движения игрока, за которым адаптивная система наблюдает, а потом на те же события (то же состояние среды) повторить реакцию. MA>Еще раз AI != Machine Learning, Machine Learning != Neural Networks.
О как. А что насчет этого?
Using a deep learning artificial neural network, I built a 2048 playing bot that teaches itself how to play over time. It reinforces itself after each move based on the score, and whether or not the move lead to a win or loss.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, m.aksenov, Вы писали:
S>О как. А что насчет этого? S>
S>Using a deep learning artificial neural network, I built a 2048 playing bot that teaches itself how to play over time. It reinforces itself after each move based on the score, and whether or not the move lead to a win or loss.
А тут надо смотреть методологию. Скорее всего решалась задача классификации,
но интересно взглянуть на топологию сети и конкретные методы обучения. Из акадамического интереса.
Все, что ты показываешь, имеет четкие критерии входа и четкие критерии выхода. В случае с 2048 даже наверняка формально описываемые. В случае с формами у тебя будет проблема даже описать вход, не говоря уже о выходе.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, m.aksenov, Вы писали:
S>Проблема — в том, что проектирование гуя не сводится к "расположению элементов на форме".
Этого я и не утверждал. Но именно расположение исходя из набора ограничений, на мой взгляд, является задачей оптимизации
S>Какой из них будет более удобен? А хрен его знает — без закапывания в семантику мы это не узнаем. Может быть, эти параметры вообще не надо вводить — они выводятся из контекста взаимодействия. S>Может быть, из 5 легальных сочетаний этих двух параметров в 99% случаев используется ровно одно, а остальные надо показывать только по дополнительному запросу.
А тут может быть уже нужно привлекать статистику использования, как набор входных параметров. Есть, правда, опасения, что составить подходящую систему уравнений будет построить слишком сложно,
и проще нанять специально обученных людей.
Я просто предполагаю, что чисто механическую работу типа дизайна форм для оперденей можно решать в виде чего-то подобного, используя гайдлайны, например, Metro или Cocoa, и на основании них что-то строить.
Это будет аналог PropertyGrid или чего-то подобного, но с более-менее адекватными отступами и прочим. Зачастую люди сами ничего лучше не дизайнят, такой уж он, корпоративный софт.
Здравствуйте, m.aksenov, Вы писали:
MA>Этого я и не утверждал. Но именно расположение исходя из набора ограничений, на мой взгляд, является задачей оптимизации
Вы какую задачу хотите решить? Ту, которую удобнее, или ту, которая людям нужна?
MA>А тут может быть уже нужно привлекать статистику использования, как набор входных параметров. Есть, правда, опасения, что составить подходящую систему уравнений будет построить слишком сложно, MA>и проще нанять специально обученных людей.
Ну вот до ввода формы в эксплуатацию нет никакой статистики. А после ввода уже поздно заниматься редизайном.
Кстати, адаптивные UI умерли — помните меню офиса, которые автоматически сворачивали редкие пункты? Оказалось, что Ribbon на порядок удобнее.
MA>Я просто предполагаю, что чисто механическую работу типа дизайна форм для оперденей можно решать в виде чего-то подобного, используя гайдлайны, например, Metro или Cocoa, и на основании них что-то строить. MA>Это будет аналог PropertyGrid или чего-то подобного, но с более-менее адекватными отступами и прочим. Зачастую люди сами ничего лучше не дизайнят, такой уж он, корпоративный софт.
Если честно, я не понимаю этого разговора в 2015 году. В те времена, когда я занимался оперднями (а это было примерно 20 лет назад), всё, что вы описываете, существовало в полный рост.
Вы мне что, хотите сказать, что все эти формочки в 1c 8.х теперь снова педалятся вручную?
Верится, если честно, с трудом. У нас вот, к примеру, в APS 1.2(образца ~2010 года) весь UI взаимодействия с пользователем генерировался автоматически на основе метаданных. И это далеко не первый проект такого рода. Лично мой первый проект такого рода был написан в 1991 году на Клиппере.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
S>Камрады, не всплывала ли идея? Реально ли реализовать? S>Что думаете?
Нужно не просто построить, а выдать тот, который понравится большинсту пользователей. Пока что нет способа более-менее формально описать "нравится-не нравится" особенно с учетом различия у разных аудиторий.
И описывать придется не просто важность свойств, а учитывать все нюансы взаимодействия с пользователем, всю семантику каждой операции.
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Sheridan, Вы писали:
S>> Ну не скажи, в корпоративном софте частенько встречаются монстроформы с 30+ контролами
W>Это встречается в узких нишах от отсутствия конкуренции. В конкурентной среде такие долго не выживают.
Как раз таки в конкурентной среде такие и выживают. Потому что в корпоративном софте приоритет это — скорость разработки фич, и на всё остальное плевать: Пока к коробочной софтине нарисуют три формы, семь раз измерив пиксели, в корпоративной среде нарисуют одну (заменяющую все три) и состряпают отчёт по вводимым в эту форму данным.
Пока в коробочной софтине разрабы мучают асинхронщину с индикаторами и прогресс барами, разрабы корпоративного софта, повесив часики на указатель мыши, и давно забыв о каких-то там тормозах, пилят новый функционал.
Пока разрабы коробочной сонфтины мучают правильное отображение ошибок, разрабы корпоративного софта, положив болт на кастомные мессаги и иконки, и возложив всю отвественность на глобальный обработчик исключений, пилят новый функционал.
Дизайнеры для коробочного софта определяют концепты, рисуют иконки, продумывают UI, но они не создают фич, поэтому в корпоративной разработке их нет.
Итого: корпоративная софтина за то же время получит в десять раз больше полезных фич, чем к коробочной софтине будет прикручено свистоперделок. Фичи в единицу времени определяют конкурентное преимущество,
ибо в отчёте о разработке ты не можешь описать красоту форм, а список фич описать обязан.
Всё сказанное выше — личное мнение, если не указано обратное.
