Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Может быть действительно в будущем задача создания ГУИ будет решаться автоматически... Или есть принципиальные сложности?
Для форм ввода — почему бы и нет... Но представьте себе генерирование GUI для VS2005 Или создание соответствующей схемы
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Slicer [Mirkwood],
LCR>>Может быть действительно в будущем задача создания ГУИ будет решаться автоматически... Или есть принципиальные сложности? SM>Для форм ввода — почему бы и нет... Но представьте себе генерирование GUI для VS2005 Или создание соответствующей схемы
Ну что касается схемы — конечно она слишком тоща для описания общего случая. Можно взять что-нибудь более мощное. И генератор сделать не просто переливатель из одного формата файлов в другой, а что нибудь более интеллектуальное.
Создать скажем экспертную систему, научить её тому, что пишут в книжках про юзабилити и на apple.com. Пусть она по неформальному описанию генерирует определение GUI в терминах этого языка. Неужели такие фантазии больше никому в голову не приходили, кроме меня?
для VS нужно что? Редактор с подстветкой синтаксиса (довольно повторяющаяся сущность), тулбар (правда какие кнопки должны быть на тулбаре? нужна статистика по часто используемым операциям), липкие окна (какие сделать липкими? можно все подряд) и т.д. Описать всё тяжело, но ведь намного тяжелее сделать это всё руками.
Только что дошло...
LCR>Создать скажем экспертную систему, научить её тому, что пишут в книжках про юзабилити и на apple.com. Пусть она по неформальному описанию генерирует определение GUI в терминах этого языка. Неужели такие фантазии больше никому в голову не приходили, кроме меня?
Если задача творческая — то тут любая железяка отдыхает. А создание UI в общем случае — самая что ни на есть творческая задача. Создание форм — рутинная операция, поэтому её и удалось автоматизировать...
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Может быть действительно в будущем задача создания ГУИ будет решаться автоматически... Или есть принципиальные сложности?
Есть принципиальные сложности.
Чтобы действительно генерировать UI автоматически — слишком многое нужно формализовывать. Например, формально и подробно описывать типовые сценарии использования (use cases), то что есть сейчас — очень неформально. Но и этого мало — нужно весь опыт человека — проектировщика GUI — формализовать. А в этой области не так много вещей, хорошо поддающихся формализации. Есть, например, GOMS (по-сути — оптимизация по количеству кликов), но я видел интерфейсы, в которых во главу угла поставлена GOMS... Или скажем понятие "интуитивно понятно" — по сути отражающее опыт пользователя в использовании существующих интерфейсов — тоже слабо представляю его формализацию.
Что же касается интерфейсов на основе XML или автоматической генерации форм по описаниям данных — это уже давно используется, и бывает удобно, но только как в качестве отправной точки.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
N>>Есть, например, GOMS (по-сути — оптимизация по количеству кликов), но я видел интерфейсы, в которых во главу угла поставлена GOMS...
LCR>И насколько они плохи?
Ну не сказать что они прямо сразу таки плохи. Вероятно, грамотное использование GOMS даже намного улучшает интерфейс программы.
НО, если при проектировании UI сосредоточиться ТОЛЬКО на количестве кликов — получится некоторые перегибы. В каждом режиме пользователь будет видеть огромное количество возможностей, 90% которых ему, как правило, не нужны. Например, в графическом редакторе пользователь выбирает команду Создать — и ему на весь экран вываливается набор кнопок со всеми примитивами и шаблонами, которые есть в наличии. По числу кликов мы оптимизировали, но качество программы, с точки зрения пользователя, пострадало.
Т.е. я хотел сказать, что не стоит сосредотачиваться на формальных правилах. Опыт проектировщика интерфейсов часто дает лучшие результаты.
nzeemin,
LCR>>И насколько они плохи?
N>НО, если при проектировании UI сосредоточиться ТОЛЬКО на количестве кликов — получится некоторые перегибы. В каждом режиме пользователь будет видеть огромное количество возможностей, 90% которых ему, как правило, не нужны. Например, в графическом редакторе пользователь выбирает команду Создать — и ему на весь экран вываливается набор кнопок со всеми примитивами и шаблонами, которые есть в наличии. По числу кликов мы оптимизировали, но качество программы, с точки зрения пользователя, пострадало.
Хм, спасибо. Сделать такую же вещь как "скрыть кнопки" только в общем виде (чтобы легко скрывать неиспользуемые возможности)?
N>Т.е. я хотел сказать, что не стоит сосредотачиваться на формальных правилах. Опыт проектировщика интерфейсов часто дает лучшие результаты.
Да оно конечно понятно, что человек совершенно новую задачу решит намного лучше, чем машина. Просто с ростом повторяемости мы получаем уже определённую статистику, которая уже может позволять решить задачу автоматически. Ведь выделили же общие повторяющиеся элементы управления (кнопки, тривью)? Принципиально новые элементы управления имеет смысл создавать для штучных задач, и не факт, что игра будет стоить свеч. А для существующих элементов управления у нас уже есть определённая статистика: "кнопка — тогда-то лучше, список лучше заменить комбо-боксом в таких-то случаях" и т.д.
Что если отталкиваться от статистических данных, чтобы статистически выяснить, что же пользователю чаще всего нужно?
Здравствуйте, Lazy Cjow Rhrr, Вы писали: LCR>Что если отталкиваться от статистических данных, чтобы статистически выяснить, что же пользователю чаще всего нужно?
Есть проблема курицы и яйца. Она же известна в узких кругах как "проблема оптимизации закупок". Прикол оптимизации закупок в том, что она принципиально может оперировать только со своей же статистикой. Так что алгоритм может только предложить перестать заказывать какой-то из товаров. Добавить новый товар он не предложит — для него нет никакой статистики.
То же самое с интерфейсом — можно статистически оттрекать то, чем в UI пользуются чаще, а чем — реже. И что? Частая возможность может означать вынужденное повторение избыточных действий, а редкая — о неудобстве использования. Статистика может дать некоторую информацию о том, насколько плох интерфейс. Вряд ли она предложит какие-то улучшения.
Ну вот как профилирования может показать, что в программе 90% времени занимает сравнение даух значений. Но перейти с пузырька на heapsort ни один профайлер не предложит
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair,
LCR>>Что если отталкиваться от статистических данных, чтобы статистически выяснить, что же пользователю чаще всего нужно?
S>Есть проблема курицы и яйца. Она же известна в узких кругах как "проблема оптимизации закупок". Прикол оптимизации закупок в том, что она принципиально может оперировать только со своей же статистикой. Так что алгоритм может только предложить перестать заказывать какой-то из товаров. Добавить новый товар он не предложит — для него нет никакой статистики.
Да, творческая задача (от слова "творить"="создавать") это прерогатива человека. Я уже сам догадался
S>То же самое с интерфейсом — можно статистически оттрекать то, чем в UI пользуются чаще, а чем — реже. И что? Частая возможность может означать вынужденное повторение избыточных действий, а редкая — о неудобстве использования. Статистика может дать некоторую информацию о том, насколько плох интерфейс. Вряд ли она предложит какие-то улучшения.
+1
S>Ну вот как профилирования может показать, что в программе 90% времени занимает сравнение даух значений. Но перейти с пузырька на heapsort ни один профайлер не предложит
Хех, твоя мысль когерентна с моей:
Да оно конечно понятно, что человек совершенно новую задачу решит намного лучше, чем машина.
Здравствуйте, Lazy Cjow Rhrr, Вы писали: LCR>Неужели такие фантазии больше никому в голову не приходили, кроме меня?
Почему не приходило. Приходило и даже делается, правда в несколько упрощенном варианте...
Сейчас по этому принзипу ваяю для своей задачки модуль связи erlang-tcl/tk (в замен штатного gs).
N>Ну не сказать что они прямо сразу таки плохи. Вероятно, грамотное использование GOMS даже намного улучшает интерфейс программы.
N>НО, если при проектировании UI сосредоточиться ТОЛЬКО на количестве кликов — получится некоторые перегибы. В каждом режиме пользователь будет видеть огромное количество возможностей, 90% которых ему, как правило, не нужны. Например, в графическом редакторе пользователь выбирает команду Создать — и ему на весь экран вываливается набор кнопок со всеми примитивами и шаблонами, которые есть в наличии. По числу кликов мы оптимизировали, но качество программы, с точки зрения пользователя, пострадало.
Надо всего лишь скомбинировать GOMS c законом Фитса, и окажется что три большие кнопки + большое меню с остальным функционалом, окажется удобенее чем куча легко доступных, но маленьких кнопок на экране.
-- Главное про деструктор копирования не забыть --
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Slicer [Mirkwood],
LCR>>>Может быть действительно в будущем задача создания ГУИ будет решаться автоматически... Или есть принципиальные сложности? SM>>Для форм ввода — почему бы и нет... Но представьте себе генерирование GUI для VS2005 Или создание соответствующей схемы
LCR>Ну что касается схемы — конечно она слишком тоща для описания общего случая. Можно взять что-нибудь более мощное. И генератор сделать не просто переливатель из одного формата файлов в другой, а что нибудь более интеллектуальное.
LCR>Создать скажем экспертную систему, научить её тому, что пишут в книжках про юзабилити и на apple.com. Пусть она по неформальному описанию генерирует определение GUI в терминах этого языка. Неужели такие фантазии больше никому в голову не приходили, кроме меня?
LCR>для VS нужно что? Редактор с подстветкой синтаксиса (довольно повторяющаяся сущность), тулбар (правда какие кнопки должны быть на тулбаре? нужна статистика по часто используемым операциям), липкие окна (какие сделать липкими? можно все подряд) и т.д. Описать всё тяжело, но ведь намного тяжелее сделать это всё руками.
Den' dobrij!
Ja sdelel odnagdi necto podobnoe --- legkij sintax w XML i v PHP-GTK parser i GUI konstruktor.
Samaja bolshaja problemm eto zavisimmosti megdy elementami, tak-kak kolichestvo "stranic" dialogov
moget bit neogranicheno i kolichestvo elementov na stranice toge. v obshem ne wsjo tak prosto.
Progy moju mogno bilo v ljuboj proekt integrirovat'.... No "dependences" ostalis ne resheni do konca, t.e.
bilo reshenie no element awtomatizacii s etogo momenta prekrashalsja .
Demosfen,
D>Den' dobrij!
Добрый!
D>Я сдeлeл однагди нeцто подобноe --- лeгкий синтаx в XМЛ и в ПХП-ГТК парсeр и ГУИ конструктор. D>Самая болшая проблeмм это зависиммости мeгды eлeмeнтами, так-как количeство "страниц" диалогов D>могeт бит нeограничeно и количeство eлeмeнтов на страницe тогe. в обшeм нe всё так просто. D>Прогы мою могно било в любой проeкт интeгрировать.... Но "дeпeндeнцeс" осталис нe рeшeни до конца, т.e. D>било рeшeниe но eлeмeнт автоматизации с этого момeнта прeкрашался .
Ага, спасибо, интересно.
А что за зависимости? Вернее, какие зависимости в данном случае вы имеете ввиду? Состояние одного элемента управления на диалоге А1 зависит от состояния другого элемента управления на диалоге А2?
Последнее время подумываю о написании библиотечки под .Net, которая по метаданным строила бы несложные формы с красивой валидацией и т.д. Может быть, такая штука уже существует?
Andy77,
A>Последнее время подумываю о написании библиотечки под .Net, которая по метаданным строила бы несложные формы с красивой валидацией и т.д. Может быть, такая штука уже существует?
Последнее время подумываю о написании библиотечки под .Net, которая по метаданным строила бы несложные формы с красивой валидацией и т.д. Может быть, такая штука уже существует?
1. http://sss1024.narod.ru/ver.htm
интерфейс к базам данных строится по ER-связям. Например если есть таблички Поставщики <- Товары то на форме поставщика будет предложено вставить подчинённый грид с его товарами. Прога старая
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Demosfen,
D>>Den' dobrij! LCR>Добрый!
D>>Я сдeлeл однагди нeцто подобноe --- лeгкий синтаx в XМЛ и в ПХП-ГТК парсeр и ГУИ конструктор. D>>Самая болшая проблeмм это зависиммости мeгды eлeмeнтами, так-как количeство "страниц" диалогов D>>могeт бит нeограничeно и количeство eлeмeнтов на страницe тогe. в обшeм нe всё так просто. D>>Прогы мою могно било в любой проeкт интeгрировать.... Но "дeпeндeнцeс" осталис нe рeшeни до конца, т.e. D>>било рeшeниe но eлeмeнт автоматизации с этого момeнта прeкрашался .
LCR>Ага, спасибо, интересно.
LCR>А что за зависимости? Вернее, какие зависимости в данном случае вы имеете ввиду? Состояние одного элемента управления на диалоге А1 зависит от состояния другого элемента управления на диалоге А2?
LCR>PS: Транслит тяжело читать (не только мне), пожалуйста рассмотрите возможность применения http://physics.nad.ru/translit.html
Здравствуйте!
Да именно, в моём случаe "унивeрсальный диалог" должeн был вдeлан в большой проeкт.
Короче нужно было выбирать компонeнты для конeчной систeмы (Linux based) и послeдующиe скрипты дeлали image(CD, DVD) готовый к автоматичeской установке.
Сами понимаетe в зависимости от вобранного порта COM1,2,3..,10 или LPT нe всякий Printer/Scaner можeт быть выбран и т.д.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Или создание соответствующей схемы 
1.1.4 stable rev. 510
