Роль UI

[Igors]

UI - работа тонкая, ...
Это не просто сборка конструкции из кубиков ..
..работа творческая, ...

Ах как мы любим хвалить самих себя - что впрочем совершенно нормально 

проложенный ими путь не так уж и плох

Может наоборот - он "слишком хорош". Чему учится человек работая с Qt UI? Найти нужный инструментарий, и здесь это целиком оправдано, большинство UI задач типовые, и хорошие готовые решения есть. Это стремление поюзать/попастись развивается стремительно, что я ощутил на себе. Чем меньше самопального кода - тем лучше, в идеале должны быть только манипуляции с классами Qt. В изучение "документации" (так сладострастно называется букварь) начинает вкладываться все больше и больше времени - ведь это эффективно, и результат налицо.

Я не уверен (или сомневаюсь) что этот путь "так уж хорош". Удивить кого-то мастерством UI достаточно сложно, ведь этим занимаются многие. "Зато" человек оказывается беспомощным в др областях - где нет такой "документации" и готовых классов. А есть напр какая-то теория, возможно проблематичные open-sources, а то и их нет. В общем "все хорошо в меру".

[Авварон]

"Зато" человек оказывается беспомощным в др областях - где нет такой "документации" и готовых классов.

Зато вы регулярно оказываетесь беспомощны там, где можно заюзать готовое, т.к. не читали "букварь".

[Igors]

Зато вы регулярно оказываетесь беспомощны там, где можно заюзать готовое, т.к. не читали "букварь".

Это легко проверить. Напр недавно приглашал попинать мой велосипед здесь - но как-то не ощутил силу "читающих документацию" 

[Racheengel]

Если совсем коротко: UI - это лицо программы. Первое впечатление у пользователей создается именно по интерфейсу, и от него сильно зависит, как будут восприняты остальные функции (даже если UI это не главное). Поэтому, это как минимум 40-50% труда, который себя оправдает. Потому что кривой UI заставляет думать, что и внутри софт устроен так же криво, даже если это на самом деле и не так.

[Igors]

Если совсем коротко: UI - это лицо программы. Первое впечатление у пользователей создается именно по интерфейсу, и от него сильно зависит, как будут восприняты остальные функции (даже если UI это не главное).

С этим никто не спорит

Поэтому, это как минимум 40-50% труда, который себя оправдает.

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

[Old]

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

По моему все очевидно. Чем больше возможностей предоставляет библиотека UI, тем более навороченный интерфейс хочется сделать. Например, пользователю можно азимут показать как обычное число от 0 до 359, но хочется показать ему виджет типа компаса, показывающий направление, дать возможность мышкой это направление менять и т.д. В таблицах показывать не просто числа, а разноцветные бары с градиентами, иконки, кнопки и т.д. Всплывающие окошки, мигающие кнопки, ...

Плюс, очень много зависит от назначения программы, ее целевой аудитории и количества входных данных. Есть программы, у которых GUI состоит из одной кнопки Вкл/Выкл.

[Racheengel]

средства то мощнейшие... только их тоже нельзя в одну кучу мышом накидать и радоваццо - оо, типа у меня кнопочек дофига, я крууттт ололо
У нас много времени на идеологию дизайна уходит, чтобы удобно пользоваться было, на разных разрешениях работало, слабо видящие различали ОК и Отмену, например...
Тем более когда софт коммерческий - тут уже не отвертишься хреновым дизайном за счет функционала, клиенты будут плакаться и жаловаться, типа неудобно, криво и т.д.
Послать их йожиков пасти не получится, увы... Сейчас 21-й век, всем красссоту подавай)

[Nidxogg]

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

Так же это хорошо. Мне вот нравится в "свободное" время что-то доработать для удобства заказчика по его просьбе. Зачастую клиенту хорошие мысли по поводу интерфейса приходят, которые в ходе проектирования gui, да и просто потому что своей программой особо не пользуешься, как-то мимо проходят.

[m_ax]

По мне, так если речь идёт о более-менее серьёзном приложении, то за ГУЙ должна отвечать определённая команда, компетентная именно в этом вопросе (за взаимодействии интэрфейса с конечным пользователем).. За саму же ночинку (бизнес-логику) должна нести ответсвенность (имхо) другая команда.. Но, очевидно, между обоими должна существовать некая кооперация и "синхронизация", но в своих пределах компетенции.. Т.е. должен существовать определённый диалог)

ЗЫ Мне сейчас близка та парадигма, когда ГУЙ рисуют специалисты, возможно и не втыкающие в програмирование как таковое..        

[m_ax]

По мне, так если речь идёт о более-менее серьёзном приложении, то за ГУЙ должна отвечать определённая команда, компетентная именно в этом вопросе (за взаимодействии интэрфейса с конечным пользователем).. За саму же ночинку (бизнес-логику) должна нести ответсвенность (имхо) другая команда.. Но, очевидно, между обоими должна существовать некая кооперация и "синхронизация", но в своих пределах компетенции.. Т.е. должен существовать определённый диалог)

ЗЫ Мне сейчас близка та парадигма, когда, ГУЙ рисуют специалисты, возможно и не втыкающие в програмирование как таковое..        

Может, отчасти из-за того, что я уже сам давно отошёл от насущных вопросов ГУЯ 

[Igors]

По мне, так если речь идёт о более-менее серьёзном приложении, то за ГУЙ должна отвечать определённая команда, компетентная именно в этом вопросе (за взаимодействии интэрфейса с конечным пользователем).. За саму же ночинку (бизнес-логику) должна нести ответсвенность (имхо) другая команда.. Но, очевидно, между обоими должна существовать некая кооперация и "синхронизация", но в своих пределах компетенции.. Т.е. должен существовать определённый диалог)

ЗЫ Мне сейчас близка та парадигма, когда ГУЙ рисуют специалисты, возможно и не втыкающие в програмирование как таковое..        

Ну да, "не царское это дело...". Но UI сильно зависит от структур данных, поэтому выделить/назначить "чисто рисовальщиков кнопок" обычно не выходит   

[Racheengel]

По мне, так если речь идёт о более-менее серьёзном приложении, то за ГУЙ должна отвечать определённая команда, компетентная именно в этом вопросе (за взаимодействии интэрфейса с конечным пользователем).. За саму же ночинку (бизнес-логику) должна нести ответсвенность (имхо) другая команда.. Но, очевидно, между обоими должна существовать некая кооперация и "синхронизация", но в своих пределах компетенции.. Т.е. должен существовать определённый диалог)

ЗЫ Мне сейчас близка та парадигма, когда ГУЙ рисуют специалисты, возможно и не втыкающие в програмирование как таковое..       

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

[gil9red]

По мне, так если речь идёт о более-менее серьёзном приложении, то за ГУЙ должна отвечать определённая команда, компетентная именно в этом вопросе (за взаимодействии интэрфейса с конечным пользователем).. За саму же ночинку (бизнес-логику) должна нести ответсвенность (имхо) другая команда.. Но, очевидно, между обоими должна существовать некая кооперация и "синхронизация", но в своих пределах компетенции.. Т.е. должен существовать определённый диалог)

ЗЫ Мне сейчас близка та парадигма, когда ГУЙ рисуют специалисты, возможно и не втыкающие в програмирование как таковое..       

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

У нас целые отделы тестировщиков, переводчиков и документаторов, и еще несколько других отделов, не считая разработчиков фирма не такая уж очень большая -- на все подразделения человек 500 будет

[m_ax]

У нас целые отделы тестировщиков, переводчиков и документаторов, и еще несколько других отделов, не считая разработчиков  фирма не такая уж очень большая -- на все подразделения человек 500 будет

Ну и как у вас там с гуём дела обстоят? 

 

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

Согласен) Я говорил больше о неком идеалистическом варианте, возможно даже очень наивном, поскольку сам не являюсь специалистом в этом плане) 

[gil9red]

У нас целые отделы тестировщиков, переводчиков и документаторов, и еще несколько других отделов, не считая разработчиков  фирма не такая уж очень большая -- на все подразделения человек 500 будет

Ну и как у вас там с гуём дела обстоят? 

Разработчики им и занимаются
Но проблем особых нет -- qt-jambi используем (родная и любимая Qt ), а большая часть гуи генерируется автоматически, не часто приходится пользовательские формы создавать