Comments 65
Правильная, хорошая статья, но ведь это прописные истины.
Многие, к сожалению, начинают не с истин, а лезут на рожон. Как минимум, им эта статья будет крайне полезна.
Ага… я только недавно узнал много подробностей по поводу своего сайта в коментах: habrahabr.ru/blogs/design/81564/?reply_to=2415452#comment_2415452, а думал, что все предусмотрел, т.ч. повторение мать учения!
Всем спасибо, переделываю!
Всем спасибо, переделываю!
Действительно, но будь статья в виде короткой памятки, я бы повесил ее на стену у нас, но в таком формате она не тянет ни на полноценный мануал(т.к. не хватает очень многих еще вещей, начиная с определения аудитории, для которой разрабатывается, заканчивая выбором цветов и рассчитанным местоположением элементов интерфейса), ни на памятку.
Возможно, так и есть, но многие с этим явно не согласны (см. комментарии ниже и соотношение оценок этой статьи :))
Может стоило бы добавить еще что-нибудь новое? Об eye-tracking'e при работе с программой, например, т.к. очень многие сейчас с плохим зрением и пытаются беречь глаза.
Мнения людей расходятся даже в вопросах использовать или нет фокус-группы для тестирования ПО, что уж там говорить про eye-tracking..? Я лишь хотел рассказать про самые основы (по моему мнению) при разработке софта, причём только с точки зрения программиста. Ибо, судя по моим наблюдениям, даже эти «прописные истины» понятны далеко не каждому.
Прописные то они прописные. Но за каждодневной программистской рутиной и они могут забыться.
Думаю, любому программисту пойдет на пользу сделать на основе этих истин «чеклист», и проверять по нему результаты своей работы.
Думаю, любому программисту пойдет на пользу сделать на основе этих истин «чеклист», и проверять по нему результаты своей работы.
Ну, для начала, хочу Вас поздравить: "–1-й в рейтинге хабралюдей" — это должно быть круто! ;-)
Что касается Ваших возражений — они написаны с точки зрения программиста, а статья — с точки зрения пользователя. Если Вы хотите написать программу, удобную пользователю — действуйте примерно так, как написано в статье. Если Вы хотите написать программу, получив меньше проблем и больше удовольствия в процессе разработки как программист — тогда Ваш комментарий вполне разумен, но полученная программа может оказаться не удобной для пользователю.
Что касается Ваших возражений — они написаны с точки зрения программиста, а статья — с точки зрения пользователя. Если Вы хотите написать программу, удобную пользователю — действуйте примерно так, как написано в статье. Если Вы хотите написать программу, получив меньше проблем и больше удовольствия в процессе разработки как программист — тогда Ваш комментарий вполне разумен, но полученная программа может оказаться не удобной для пользователю.
О боже! Вы действительно думаете, что текст написан с точки зрения пользователя? 95% пользователей (по пунктам):
— не стремятся к наибольшей эффективности! они стремятся, чтобы всё можно было таскать мышкой
— не устанавливают самостоятельно ничего, кроме троянов
— отзывчивость от интерфейса им не нужна! они готовытерпеть материть любые тормоза, но не переползут на новый софт. вы что? никогда не слышали жалоб и стонов пользователей? эти стоны никогда не вызывают никаких действий.
— это же касается пункта 4 и 5.
Статья написана не с точки зрения пользователя, а с точки зрения продвинутого школьника, в свободное время администрирующего школьный компьютерный класс вместе с учительницей информатики, которая боится электричества.
— не стремятся к наибольшей эффективности! они стремятся, чтобы всё можно было таскать мышкой
— не устанавливают самостоятельно ничего, кроме троянов
— отзывчивость от интерфейса им не нужна! они готовы
— это же касается пункта 4 и 5.
Статья написана не с точки зрения пользователя, а с точки зрения продвинутого школьника, в свободное время администрирующего школьный компьютерный класс вместе с учительницей информатики, которая боится электричества.
Ок, пронумеровал, хотя немного по-другому, чем Вы, ибо это было 2 совершенно различных раздела, и я бы не стал объединять их нумерацию.
> Это прям утопия, чтоб программа не сопротивлялась своему закрытию:)
Программа не должна сопротивляться своему закрытию, если на то нет очень веских причин. Если они есть, то обязательно должна быть возможность отключить подтверждение. Экономьте каждый клик мышью и каждое нажатие клавиши пользователем. И если стоит выбор — предпочитайте клавиатуру мыши.
Программа не должна сопротивляться своему закрытию, если на то нет очень веских причин. Если они есть, то обязательно должна быть возможность отключить подтверждение. Экономьте каждый клик мышью и каждое нажатие клавиши пользователем. И если стоит выбор — предпочитайте клавиатуру мыши.
В том-то и дело, что прецендентов, когда программы всё же не дают себя закрыть, больше чем достаточно, особенно среди мобильного софта. К примеру, в моей Nokia N91 было сделано всё, чтобы пользователь не мог выключить телефон, пока все программы не завершились корректно. Тем не менее, основной причиной, по которой я его выключал и включал заново было именно то, что он «зависал», причём приходилось делать ему «жесткую» версию выключения, вынув батарейку, потому что софтверно он выключаться отказывался.
Примеров «хороших» программ можно привести массу.К сожалению, «масса» на самом деле очень невелика. Более того, многие программы окажутся «хорошими» для одних людей и «ужасными» для других. Я, к примеру, считаю «хорошими» программами текстовый редактор Vim и почтовый клиент mutt — и я лично знаю несколько людей, как разделяющий мою точку зрения, так и категорически с ней несогласных. Вот в чём сходится большинство — так это в том, что «хороших» программ мало.
Ещё один интересный факт — если проанализировать наиболее популярные программы и веб-сервисы, то выяснится, что большинство из них не соответствуют описанным в статье характеристикам (они глючат, тормозят, etc.). Так что в статье, на мой взгляд, описана теория — что-то типа шарообразной лошади в вакууме. Идеальные программы для идеальных людей. В теории должно быть так, как в статье — а на практике всё совсем иначе. Интересно, почему так? :)
Опять же я описал «хорошие» программы с точки зрения того, насколько они нравятся пользователям, а не по их популярности и коммерческому успеху. К тому же, людям с различным складом ума и различным характером нравятся различные программы, что тоже не удивительно :).
P.S. Я с vim'а сначала долго плевался, до тех пор, пока нам не показали в институте, как им пользоваться, после чего мне тоже полюбился этот текстовый редактор :).
P.S. Я с vim'а сначала долго плевался, до тех пор, пока нам не показали в институте, как им пользоваться, после чего мне тоже полюбился этот текстовый редактор :).
Есть очень важный фактор — время! Чтобы приложение понравилось пользователю оно должно, как минимум, быть написано! Это обязательно.
Почему Excel популярней Lotus 1-2-3? Просто потому, что Excel для Windows успели выпустить раньше! А почему так произошло? Потому, что MS «портировал» Excel по пути Mac->DOS->Windows, плодя глюки, дыры в безопасности… А в Lotus решили полностью переписать 1-2-3, чтобы обойти Excel. Скорее всего, продукт бы получился действительно отменный (проект закрыли), но он не взлетел бы — у людей уже есть Excel — он стал эталоном удобства. Ты не можешь сделать удобней, ты можешь сделать либо так же, либо «да там ничего понять не возможно».
Почему Excel популярней Lotus 1-2-3? Просто потому, что Excel для Windows успели выпустить раньше! А почему так произошло? Потому, что MS «портировал» Excel по пути Mac->DOS->Windows, плодя глюки, дыры в безопасности… А в Lotus решили полностью переписать 1-2-3, чтобы обойти Excel. Скорее всего, продукт бы получился действительно отменный (проект закрыли), но он не взлетел бы — у людей уже есть Excel — он стал эталоном удобства. Ты не можешь сделать удобней, ты можешь сделать либо так же, либо «да там ничего понять не возможно».
Верно подмечено, хорошо сделать в плане GUI можно только маленькую программу, а если хорошо сделать большую программу, то ей практически никто пользоваться не будет, как раз, потому что непривычно — «да там ничего понять не возможно».
Даже MS столкнулась с этим феноменом при изменении GUI в Office и Windows.
Их многомиллиардные исследования в области юзабилити уже который год разбиваются о стену непонимания обычных пользователей.
Даже MS столкнулась с этим феноменом при изменении GUI в Office и Windows.
Их многомиллиардные исследования в области юзабилити уже который год разбиваются о стену непонимания обычных пользователей.
Мне кажется, ошибкой MS было радикальное изменение интерфейса вместо более плавного, как делает, к примеру, Adobe со своими продуктами. Они постепенно меняют пользовательский интерфейс в лучшую сторону, внося в привычные вещи изменения по-немному, и также постепенно добавляя новые возможности.
Вообще, разработка и поддержка действительно больших приложений — это отдельная песня, и этому учатся в другом месте, не на хабре :). Я, безусловно, говорю лишь о небольших приложениях, которые посильно написать либо одному, либо небольшой команде человек.
Вообще, разработка и поддержка действительно больших приложений — это отдельная песня, и этому учатся в другом месте, не на хабре :). Я, безусловно, говорю лишь о небольших приложениях, которые посильно написать либо одному, либо небольшой команде человек.
А что Adobe поставила себе задачу сделать нормальный GUI своим приложениям к 2020 году? :-)
По мне так лучше уж резко улучшать. Честно говоря, я не в курсе что у них сейчас с GUI, но PhotoShop 7 был ярким примером того, как не надо делать GUI ни при каких обстоятельствах. Но при этом его продвинутые пользователи будут стеной стоять на защите интерфейса PhotoShop, потому что именно его невменяемая сложность их кормит. Был бы удобный GUI и руководство пользователя с 1500 страниц сократилось бы до 250. Прикинь как это усилило бы конкуренцию среди фотошоперов. А сколько бы учебных курсов пришлось бы закрыть. Ведь известный факт, что если программа имеет удобный интерфейс, то она не требует никакого специального обучения по работе с ней, а работает по принципу «включил -> сделал что нужно -> выключил».
По мне так лучше уж резко улучшать. Честно говоря, я не в курсе что у них сейчас с GUI, но PhotoShop 7 был ярким примером того, как не надо делать GUI ни при каких обстоятельствах. Но при этом его продвинутые пользователи будут стеной стоять на защите интерфейса PhotoShop, потому что именно его невменяемая сложность их кормит. Был бы удобный GUI и руководство пользователя с 1500 страниц сократилось бы до 250. Прикинь как это усилило бы конкуренцию среди фотошоперов. А сколько бы учебных курсов пришлось бы закрыть. Ведь известный факт, что если программа имеет удобный интерфейс, то она не требует никакого специального обучения по работе с ней, а работает по принципу «включил -> сделал что нужно -> выключил».
Многие пользователи не любят приложения, они вообще не любят работать — только вола пинать
На заре своей тестировщицкой карьеры, как и многие, считала, что качественное приложение — это приложение, соответствующее спецификации. Грубо говоря: если сделали то, что задумывали без отклонений, и в приложении не выявлено критических ошибок, то оно качественное.
Ну и нафиг кому нужно то, что задумали разработчики, если оно неудобно или невовремя? Даже, если ошибок «не содержит» и работает предсказуемо.
А вот другая программа не содержит и половины функционала, зато у ней кнопочки мимимишечные, или она вышла как раз в сезон сдачи отчетов, или для установки ничего делать не нужно — запустил, и она сама поставилась.
То есть, качество — это соответствие ожиданиям пользователя. Нужно смотреть, КТО пользователь вашей программы, ЧТО он ждет, ЧТО ему нужно. Если есть конкуренты — нужно сделать лучше с точки зрения пользователя, а не вас как разработчика.
Конечно, если ваша программа — единственная в сегменте, то можно и схалтурить, только тем самым открываете дорогу конкурентам, пользователя не просто уйдут чуть позже к ним, а уйдет с удовольствием =)
Ну и нафиг кому нужно то, что задумали разработчики, если оно неудобно или невовремя? Даже, если ошибок «не содержит» и работает предсказуемо.
А вот другая программа не содержит и половины функционала, зато у ней кнопочки мимимишечные, или она вышла как раз в сезон сдачи отчетов, или для установки ничего делать не нужно — запустил, и она сама поставилась.
То есть, качество — это соответствие ожиданиям пользователя. Нужно смотреть, КТО пользователь вашей программы, ЧТО он ждет, ЧТО ему нужно. Если есть конкуренты — нужно сделать лучше с точки зрения пользователя, а не вас как разработчика.
Конечно, если ваша программа — единственная в сегменте, то можно и схалтурить, только тем самым открываете дорогу конкурентам, пользователя не просто уйдут чуть позже к ним, а уйдет с удовольствием =)
eclipse и netbeans — текстовые редакторы?
> Простота установки — у пользователя должно быть минимум препятствий в установке вашего приложения, программа не должна зависеть ни от каких сторонних библиотек / утилит, которые не идут в комплекте
Трактовка этого пункта очень различается для разных ОС.
Windows: не забудьте положить в дистрибутив программы все dll'ки.
Что-нибудь с менеджером пакетов, например FreeBSD или Gentoo Linux: не забудьте в пакете указать все зависимости.
Трактовка этого пункта очень различается для разных ОС.
Windows: не забудьте положить в дистрибутив программы все dll'ки.
Что-нибудь с менеджером пакетов, например FreeBSD или Gentoo Linux: не забудьте в пакете указать все зависимости.
Я прежде всего говорил либо о веб-приложениях (в данном случае стоит воспринимать это как минимальную зависимость от расширений того языка, на котором вы пишете), либо о приложениях с графическим интерфейсом под «десктопные» дистрибутивы или ОС, вроде Windows, Mac OS X, Ubuntu, PC-BSD…
Если посмотреть с точки зрения *nix и консольных утилит, то с этим я полностью согласен.
Если посмотреть с точки зрения *nix и консольных утилит, то с этим я полностью согласен.
Я считаю что приложение должно быть ориентировано на группу пользователей, и чем она больше тем больше внимания надо уделить его юзабилети.
Прошу заметить, что я пишу не «как должно быть», а «как я делаю». Это не теоретические изыски, поскольку я именно так и пишу программы уже много лет, и >90% людей, для которых я делал какой-то софт, остались очень довольны тем, что я написал.
были ли программы, а программные комплексы, на которые затрачено хотя бы несколько сотен челоеко-часов? программы, количество выполняемых уникальных действий пользователя исчислялось бы хотя бы сотней, а самих пользователей несколько сотен? и при этом сотням пользователям понравился интерфейс больше, чем у аналогичных программ.
если да, то вас поздравляю — вы один из неногих программистов, которые пишут хороший интерфейс сами, без помощи дизайнеров.
PS. Сложный интерфейс — я подразумеваю интерфейс сложности крупной ERP/CRM-системы (для веб-приложения) или сложности сравнимой хотя бы с Office (Open или MS)
если да, то вас поздравляю — вы один из неногих программистов, которые пишут хороший интерфейс сами, без помощи дизайнеров.
PS. Сложный интерфейс — я подразумеваю интерфейс сложности крупной ERP/CRM-системы (для веб-приложения) или сложности сравнимой хотя бы с Office (Open или MS)
Программы, на которые затрачены сотни человеко-часов, я писал. Количество «выполняемых уникальных действий», я думаю, несколько десятков. Количество пользователей несколько сотен — тоже не вопрос, у сайта моего файлового менеджера (его сайт временно в дауне) только ежедневно по 20 человек, и пока что все отзывались о нём очень хорошо.
А Вы..? Я подозреваю, что нет…
А Вы..? Я подозреваю, что нет…
Участвовал в их поддержке и сейчас пишу.
примеры :ERP -система для одной сибирской корпорации в несколько тысяч человек
специализированная соцсеть, рассчитанная на тысячи человек с онлайном хотя бы в сотню =)
Сайт файлового менеджера, прошу прощения, это не сложная система.
Сложные сайты со сложной иерархией достаточно: сайт Toshiba, Intel и др.
примеры :ERP -система для одной сибирской корпорации в несколько тысяч человек
специализированная соцсеть, рассчитанная на тысячи человек с онлайном хотя бы в сотню =)
Сайт файлового менеджера, прошу прощения, это не сложная система.
Сложные сайты со сложной иерархией достаточно: сайт Toshiba, Intel и др.
Коли речь зашла о TextMate, обьясните пожалуйста мне дураку почему эта идеальная программа так себя ведет:
drp.ly/grA1g (скрин)
А именно почему у нее такие проблемы с шрифтами? Перепробовал все шрифты которые есть, везде такой косяк.
drp.ly/grA1g (скрин)
А именно почему у нее такие проблемы с шрифтами? Перепробовал все шрифты которые есть, везде такой косяк.
сейчас поставил Consolas который выдернул из 7рки, все нормально кажет… Это что получается, в маке все шрифты кривые? :)
По умолчанию, кажись, в TextMate используется шрифт Monaco, в котором всё нормально. К тому же, в моей версии TextMate честно предупреждает, что он не поддерживает шрифты, которые не являются моноширинными (а Вы что, пишете код с использованием шрифта Arial??)
про юзабилити-тестирование ничего не сказано :(
Сожалею, никогда этим не занимался, поэтому и не написал. Как правило, моё «юзабилити-тестирование» начинается с меня самого и заканчивается максимум моими друзьями :), если я вообще его провожу. Я лично слабо в это верю, если честно.
это помогает, просто не все вообще о нем знают.
Можно огрничиваться и друзьями-знакомыми (все равно достаточно порядка 10 прогонов), но как пункт в разработке приложения обязательно нужно включить.
Можно огрничиваться и друзьями-знакомыми (все равно достаточно порядка 10 прогонов), но как пункт в разработке приложения обязательно нужно включить.
Зря вы в это не верите и, судя по всему, считаете это бесполезной ерундой. Программист вовсе не эталон в плане тестировния функционала и юзабилити. Тем более программист, который тестирует программу, разрабатываемую им же.
Моё мнение — и для коммерческого софта многое тоже можно применять.
О UI — из моей практики я заметил, что часто программистам не критично как выглядит интерфейс и насколько он удобен — они то всё в нём понимают, а потом пользователям нужно изучать сотни страниц интструкция для того, чтобы всё работало как надо.
Потому и есть такие люди, которые занимаются дизайном интерфейсов в специально предназначеном для этого софте и строят прототипы приожений.
Подход, когда цикл разработки приложения в общем виде выглядит как:
«Дизайн интерфейса» -> «Разработка» -> «Тестирование» -> «Релиз»
лично для меня наиболее приемлем хоть в OpenSource, хоть в коммерческом ПО (кстати, часто и оба вида приложений страдают именно сложностью и неудобностью интерфейсов)
О UI — из моей практики я заметил, что часто программистам не критично как выглядит интерфейс и насколько он удобен — они то всё в нём понимают, а потом пользователям нужно изучать сотни страниц интструкция для того, чтобы всё работало как надо.
Потому и есть такие люди, которые занимаются дизайном интерфейсов в специально предназначеном для этого софте и строят прототипы приожений.
Подход, когда цикл разработки приложения в общем виде выглядит как:
«Дизайн интерфейса» -> «Разработка» -> «Тестирование» -> «Релиз»
лично для меня наиболее приемлем хоть в OpenSource, хоть в коммерческом ПО (кстати, часто и оба вида приложений страдают именно сложностью и неудобностью интерфейсов)
Внесу свои пять копеек. По пунктам:
1) Вы совершенно необосновано выбросили за борт .NET Framework. Эта платформа, а конкретно ее базовая версия, .NET Framework 2.0 устанавливается на любой компьютер начиная с Windows XP SP2. Те же самые зависимости пакетов в Linux, поклонником которого, вы судя по всему являетесь, заставят вас при установке какого-нибудь сложного приложения вытянуть из интернета кучу библиотек. И их суммарный весь может превысить 100 МБ. Почему вас это не смущает?
6) Широкополосный интернет прочно входит в быт людей. Слово модем уже скоро станет чем-то далеким и забытым. Тем более, не всегда можно уменьшить объем генерируемого траффика в Web-приложении. Иногда это просто невозможно сделать. Поверьте мне, как разработчику ASP.NET :)
Теперь о самой статье. Конечно ничего плохого в том, что вы предпочитаете программы с аскетичным ПИ. Но, как вам уже выше говорили, большинство пользователей их не оценит. Потому что они встречают программы прежде всего «по одежке»: по красивой «шкурке», по красивому экрану-заставке. Пользователи любят красоту и им наплевать что ваша программа, которая выглядит серо и непривлекательно умеет в разы больше чем, к примеру MS Office 2010. Он просто красивее, больше рекламируется и продается в красивой коробке.
Список книг вы рекомендуете, мягко говоря, странный. Нет ни одной книги по пользовательскому интерфейсу, ни одной книги по паттернам проектирования, тестирования ПО, рефакторингу.
PS Вы в комментариях писали что уже много лет, а в профиле у вас указано, что вы студент 5-го курса :) Хотелось бы ознакомиться со списком ваших работ.
1) Вы совершенно необосновано выбросили за борт .NET Framework. Эта платформа, а конкретно ее базовая версия, .NET Framework 2.0 устанавливается на любой компьютер начиная с Windows XP SP2. Те же самые зависимости пакетов в Linux, поклонником которого, вы судя по всему являетесь, заставят вас при установке какого-нибудь сложного приложения вытянуть из интернета кучу библиотек. И их суммарный весь может превысить 100 МБ. Почему вас это не смущает?
6) Широкополосный интернет прочно входит в быт людей. Слово модем уже скоро станет чем-то далеким и забытым. Тем более, не всегда можно уменьшить объем генерируемого траффика в Web-приложении. Иногда это просто невозможно сделать. Поверьте мне, как разработчику ASP.NET :)
Теперь о самой статье. Конечно ничего плохого в том, что вы предпочитаете программы с аскетичным ПИ. Но, как вам уже выше говорили, большинство пользователей их не оценит. Потому что они встречают программы прежде всего «по одежке»: по красивой «шкурке», по красивому экрану-заставке. Пользователи любят красоту и им наплевать что ваша программа, которая выглядит серо и непривлекательно умеет в разы больше чем, к примеру MS Office 2010. Он просто красивее, больше рекламируется и продается в красивой коробке.
Список книг вы рекомендуете, мягко говоря, странный. Нет ни одной книги по пользовательскому интерфейсу, ни одной книги по паттернам проектирования, тестирования ПО, рефакторингу.
PS Вы в комментариях писали что уже много лет, а в профиле у вас указано, что вы студент 5-го курса :) Хотелось бы ознакомиться со списком ваших работ.
Вы совершенно необосновано выбросили за борт .NET Framework. Эта платформа, а конкретно ее базовая версия, .NET Framework 2.0 устанавливается на любой компьютер начиная с Windows XP SP2.
То есть, в WinXP SP2 уже «в комплекте» идёт .NET Framework 2.0? Хм…
В любом случае, для небольших приложений использование .NET тех версий, которые отсутствуют в SP2 мне кажется неоправданным. К тому же, приложения на .NET загружаются намного дольше, что для небольших программ опять же мне кажется не очень-то оправданным (по крайней мере, так было раньше).
Те же самые зависимости пакетов в Linux, поклонником которого, вы судя по всему являетесь, заставят вас при установке какого-нибудь сложного приложения вытянуть из интернета кучу библиотек. И их суммарный весь может превысить 100 МБ. Почему вас это не смущает?
Я никогда не был поклонником ни Linux ни пакетной системы большинства дистрибутивов Linux. Впрочем, и от портов FreeBSD/Gentoo я тоже не очень в восторге, хотя идеологически мне они нравятся больше. Более того, и для Linux мне не нравится, когда мелкие утилиты используют что-либо отличное от GTK/Qt или используют какие-то очень хитрые библиотеки, которые нужно перед этим скачивать. Но конкретно пользователям Linux от этого всё равно никуда не деться, поскольку весь софт так работает, и им нужно много скачивать из интернета. Пакетная система PC-BSD, между прочим, сделана немного по-другому, в ней отсутствуют зависимости, как класс — с каждым пакетом идут все библиотеки и программы, необходимые для её работы. Что-то очень близкое можно встретить и под Windows и под Mac OS X, и это, ИМХО, хорошо.
Широкополосный интернет прочно входит в быт людей. Слово модем уже скоро станет чем-то далеким и забытым. Тем более, не всегда можно уменьшить объем генерируемого траффика в Web-приложении. Иногда это просто невозможно сделать. Поверьте мне, как разработчику ASP.NET :)
Насчёт широкополосного интернета я с Вами точно не соглашусь, ибо даже в 100 км от Москвы он не везде есть (в частности, его нет у моих родителей)…
Что касается большого объема трафика в веб-приложениях на ASP.NET — не знаю, не пробовал. На PHP+JsHttpRequest я с такими проблемами не сталкивался, всё работает очень шустро даже на узеньком и нестабильном канале (после того, как все скрипты загрузятся, конечно же).
Теперь о самой статье. Конечно ничего плохого в том, что вы предпочитаете программы с аскетичным ПИ. Но, как вам уже выше говорили, большинство пользователей их не оценит. Потому что они встречают программы прежде всего «по одежке»: по красивой «шкурке», по красивому экрану-заставке. Пользователи любят красоту и им наплевать что ваша программа, которая выглядит серо и непривлекательно умеет в разы больше чем, к примеру MS Office 2010.
Сделать программу «красивой», как правило, задача не программиста, а дизайнера. Об этом в статье ни слова, ибо статья не об этом. Я ни в коем случае не призываю делать программы серыми и скучными, но вот от ничего не делающих «красивостей» программа тоже лучше не станет (вернее, станет хуже).
PS Вы в комментариях писали что уже много лет, а в профиле у вас указано, что вы студент 5-го курса :) Хотелось бы ознакомиться со списком ваших работ.
См. мой профиль в Моем Круге, там всё хорошо описано.
Чтобы программа понравилась пользователю, она должна быть как минимум симпатичной. Иначе на нее никто и не посмотрит. Другими словами, красивый интерфейс — это необходимое условие успеха. А достаточным условием является все что вы написали + красивый интерфейс.
По поводу .NET, время WinXP уже уходит, да и там при включенном Windows Update (что само по себе полезно) он давно уже установлен. В Win7 которая постепенно вытесняет все предыдущие версии, .NET 3.5 SP1 уже есть сразу и без вопросов. Сегодня .NET это часть WinAPI, а не какая-то библиотека.
По поводу .NET, время WinXP уже уходит, да и там при включенном Windows Update (что само по себе полезно) он давно уже установлен. В Win7 которая постепенно вытесняет все предыдущие версии, .NET 3.5 SP1 уже есть сразу и без вопросов. Сегодня .NET это часть WinAPI, а не какая-то библиотека.
> Более того, и для Linux мне не нравится, когда мелкие утилиты используют что-либо отличное от GTK/Qt
Мне не нравится когда мелкие утилиты используют что-либо отличное от Tk или FLTK. С GTK/Qt утилиту уже мелкой не назовёшь. А вообще, нехорошо привязывать функциональность к наличию графического интерфейса, если он не является заведомо присутствующим. Например, не понятно, почему к mumble официальный (и единственный) клиент имеет GUI. Может я хочу пускать его на домашнем сервере с мощной звуковухой, но без видео?
Мне не нравится когда мелкие утилиты используют что-либо отличное от Tk или FLTK. С GTK/Qt утилиту уже мелкой не назовёшь. А вообще, нехорошо привязывать функциональность к наличию графического интерфейса, если он не является заведомо присутствующим. Например, не понятно, почему к mumble официальный (и единственный) клиент имеет GUI. Может я хочу пускать его на домашнем сервере с мощной звуковухой, но без видео?
Сейчас перечитал статью и очень не понравились слова:
помогающими лучше научиться писать программы
Программист, который пишет программы лично для меня плохой программист, на кодирование уходит максимум процентов 35% времени, остальные время — проектирование, тестирование, поиск решений и т.п.
Программист — это не кодер, а разработчик, человек который не только напишет программу, но и объяснит как и почему
Лично я бы порекомендовал следующие книги (если речь идет об объектно-ориентированной разработке):
Фаулер М. — Рефакторинг. Улучшение существующего кода
Дж. Кериевски — Рефакторинг с использованием шаблонов
Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы объектно-ориентированного проектирования. Паттерны проектирования
Крэг Ларман Применение UML 2.0 и шаблонов проектирования
Книги по TDD тоже стоит посмотреть, да и просто почитать про эту методологию
помогающими лучше научиться писать программы
Программист, который пишет программы лично для меня плохой программист, на кодирование уходит максимум процентов 35% времени, остальные время — проектирование, тестирование, поиск решений и т.п.
Программист — это не кодер, а разработчик, человек который не только напишет программу, но и объяснит как и почему
Лично я бы порекомендовал следующие книги (если речь идет об объектно-ориентированной разработке):
Фаулер М. — Рефакторинг. Улучшение существующего кода
Дж. Кериевски — Рефакторинг с использованием шаблонов
Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы объектно-ориентированного проектирования. Паттерны проектирования
Крэг Ларман Применение UML 2.0 и шаблонов проектирования
Книги по TDD тоже стоит посмотреть, да и просто почитать про эту методологию
Меня кстати тоже очень удивил список рекомендуемой литературы — я комментарием выше написал об этом. Только не стал приводить свой список — лень было :) С вашим списком согласен полностью — единственное, дополнил бы его еще несколькими пунктами:
1) Роберт Дж. Торрес — Практическое руководство по проектированию и разработке пользовательского интерфейса
2) Jenifer Tidwell — Designing Interfaces: Patterns for Effective Interaction Design
3) Alan Cooper — About Face: The Essentials of User Interface Design
Последние две можно найти также и в переводе.
1) Роберт Дж. Торрес — Практическое руководство по проектированию и разработке пользовательского интерфейса
2) Jenifer Tidwell — Designing Interfaces: Patterns for Effective Interaction Design
3) Alan Cooper — About Face: The Essentials of User Interface Design
Последние две можно найти также и в переводе.
А ещё, как мне кажется, важны правильные настройки по умолчанию. И, конечно же, качество документации к ПО тоже играет далеко не последнюю роль. Я считаю, что это самый сложный момент — написание понятной документации.
Эти советы можно применять только если вам уже рассказали кто, как и зачем будет использовать написанный продукт.
Иначе они весьма слабо помогут «сделать приложение, которое будет нравиться пользователям»
Иначе они весьма слабо помогут «сделать приложение, которое будет нравиться пользователям»
Да и рассказывать программистам, какие им книжки почитать по программированию смысла не имеет. Подавляющее большинство их и так уже почитало.
Лучше порекомендуйте почитать книжки по UIX.
«Интерфейс» Раскина и «Психбольницу в руках пациента» Купера. В рамках поставленной задачи от них будет больше пользы.
Лучше порекомендуйте почитать книжки по UIX.
«Интерфейс» Раскина и «Психбольницу в руках пациента» Купера. В рамках поставленной задачи от них будет больше пользы.
Sign up to leave a comment.
Как сделать приложение, которое будет нравиться пользователям