У меня мало опыта в разработке GUI для windows desktop приложений, но сейчас на проекте встала такая задача.

Задача:
Есть какая-то сущность (допустим, Клиент, Поставщик и т.д.) и нужно создать интерфейс для создания/редактирования и удаления этих сущностей.

Мне видится 3 основных варианта решения:

1) В простых случаях задачу можно решить обычным гридом:



Т.е. воркфлоу такой: при нажатии Add добавляется пустая строка в грид. При нажатии Delete у пользователя спрашивается точно ли он хочет удалить выделенный в гриде экземпляр сущности. При нажатии Save сохраняются все что там пользователь наредактировал/наудалял. При нажатии Close форма закрывается предварительно спросив нужно ли сохранить изменения.

Минус — имхо такое подходит только для простейших сущностей. Редактировать в гриде что-то сложное имхо неудобно ни пользователю ни программисту (в плане реализации).


2) Если у нас что-то более сложное, то возможен такой вариант:



Жмем Add — появляется модальная форма для ввода информации о новом экземпляре сущности. При нажатии OK — валидация и если все ок, то добавление в грид. При двойном клике по строке в гриде (ну можно еще кнопку Edit добавить в принципе) появляется та же модальная форма, но уже в режиме редактирования.

Минус — на каждую сущность приходится делать минимум 2 формы.


3) Еще такой вот вариант вижу:



Грид тут работает только в режиме отображения. При фокусе на какой-либо строке грида, заполняются поля над гридом и в них можно изменить данные. При нажатии Add создается новый объект, добавляется в datasource грида, фокусируется в гриде, срабатывает байндинг, вверху поля очищаются, курсор перемещается на первое поле.

Минусов вроде не вижу, вроде неплохой вариант, хотя я такое почему-то мало где видел.


Теперь вопросы к людям с опытом в проектировании пользовательского интерфейса и юзабилити:

— Какой вариант обычно используете вы? Может другой (не представленный выше)?
— Если можно, то вкратце о релизации (dataset/custom business objects/binding и т.д.). У меня в проекте .NET Windows Forms.
— Какие недостатки вы заметили в приведенных выше вариантах?
— Посоветуете что-то почитать по теме?

Спасибо за помощь.

Здравствуйте, Junior1993, Вы писали:

J>У меня мало опыта в разработке GUI для windows desktop приложений, но сейчас на проекте встала такая задача.

J>Задача:
J>Есть какая-то сущность (допустим, Клиент, Поставщик и т.д.) и нужно создать интерфейс для создания/редактирования и удаления этих сущностей.
Начинать надо с анализа пользователей и задач, которые им требуется решать.
А не с изображения окошек.
Окошки сами родятся после анализа задач-пользователей.

Здравствуйте, Junior1993, Вы писали:

J>У меня мало опыта в разработке GUI для windows desktop приложений, но сейчас на проекте встала такая задача.

J>Задача:
J>Есть какая-то сущность (допустим, Клиент, Поставщик и т.д.) и нужно создать интерфейс для создания/редактирования и удаления этих сущностей.

1-й, 3-й варианты для маленьких приложений, которые быстро сделал и забыл. Эти варианты только кажутся простыми, на деле, логика редактирования данных в них имеет свои нюансы.
2-й вариант универсальный. Функционал отображения и редактирования данных разбивается на два модуля. Количество кода от этого сильно не увеличивается, логика программы становиться прозрачной.

Сам имею опыт создания приложения с 500 сущностями в БД -> 1000 форм GUI.

Предлагаю свое решение http://daremanager.sourceforge.net/ru/

Здравствуйте, LaptevVV, Вы писали:

LVV>Начинать надо с анализа пользователей и задач, которые им требуется решать.
LVV>А не с изображения окошек.

Изображенные окошечки родились не на пустом месте. Это реальные варианты, которые у меня получились и уже используются. Но
1) Мне хочется более-менее унифицировать GUI для типовых задач, чтобы пользователям было привычнее.
2) Хочется получить замечания по моим вариантам либо узнать другие общепринятые варианты.

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

Здравствуйте, sereginseregin, Вы писали:

S>1-й, 3-й варианты для маленьких приложений, которые быстро сделал и забыл. Эти варианты только кажутся простыми, на деле, логика редактирования данных в них имеет свои нюансы.
А почему 3-й вариант для маленьких приложений? Имеете в виду, что места на форме может не хватить?

S>2-й вариант универсальный. Функционал отображения и редактирования данных разбивается на два модуля. Количество кода от этого сильно не увеличивается, логика программы становиться прозрачной.
Кстати, по второму варианту вопрос — когда лучше сохранять изменения в БД? При нажатии ОК в модальном окне создания/редактирования или только после нажатия кнопки Save в главном окне?

S>Предлагаю свое решение http://daremanager.sourceforge.net/ru/
Я мельком глянул: тяжело читается, нет сразу чувства понимания понимания как это все работает, насколько это удобно. Мне кажется вам лучше добавить какую-то единую статейку, в которой вы бы применили своё решение и объяснили преимущества вашего решения; как вариант можно записать видео минут на 30 где вы с нуля создаете простенький проект используя ваш DaReManager.

Здравствуйте, Junior1993, Вы писали:

LVV>>Начинать надо с анализа пользователей и задач, которые им требуется решать.
LVV>>А не с изображения окошек.
J>Изображенные окошечки родились не на пустом месте. Это реальные варианты, которые у меня получились и уже используются. Но
J>1) Мне хочется более-менее унифицировать GUI для типовых задач, чтобы пользователям было привычнее.
J>2) Хочется получить замечания по моим вариантам либо узнать другие общепринятые варианты.

J>Т.е. я не думаю? что я первый решаю задачу проектирования типового GUI для редактирования всяких клиентов, поставщиков и т.п. Ну и хочу чтобы в моем приложении GUI был более-менее привычный для пользователей, поэтому и спрашиваю у более опытных людей как принято делать, или к какому варианту в итоге пришли они.
Почему не думаете? Если б не думали — не задали бы вопросов...
Но вот вы же сами написали, что хотите, чтобы интерфейс был привычный для пользователей...
Получается, что вы проблем пользователей не знаете ?
А идете от некоей типовой задачи.
Мой опыт мне говорит, что типовые интерфейсы в каждом конкретном случае приходится переделывать под конкретного пользователя.

Я б еще подумал о возможности динамической генерации интерфейса...
Страницы ж генерятся — почему здесь об этом не подумать?

Здравствуйте, LaptevVV, Вы писали:

LVV>Но вот вы же сами написали, что хотите, чтобы интерфейс был привычный для пользователей...
LVV>Получается, что вы проблем пользователей не знаете ?

Я пробовал спрашивать пользователей. Типичные ответы "оба варианта нормальные" или "ну я не знаю, ты сам реши как лучше".

LVV>А идете от некоей типовой задачи.

Как я уже писал, я не думаю что у меня задача прям какая-то новая. Думаю что редактирование клиентов, поставщиков, и т.д. — это типовые задачи, которые встречаются у многих при разработке корпоративных приложений. Поэтому для начала хочется узнать как обычно делают, как принято, получить какие-то советы.

LVV>Мой опыт мне говорит, что типовые интерфейсы в каждом конкретном случае приходится переделывать под конкретного пользователя.
Пользователей пока немного, но возможно будут десятки людей. Под каждого конкретного пользователя переделать по-любому не получится

LVV>Я б еще подумал о возможности динамической генерации интерфейса...
LVV>Страницы ж генерятся — почему здесь об этом не подумать?

У меня и веб-страницы не генерируются. Обычно делаю html шаблон, и его уже использую из какого-либо template framework'а. Я не очень верю в идею успешной генерации интерфейсов. Во-первых надо будет приложить большие усилия чтобы написать генератор. Во-вторых не думаю что сгенерированный интерфейс получится таким же удобным и красивым как это можно сделать вручную. Но если у кого-то есть опыт с генерацией интерфейса с удовольствоием послушаю.

Здравствуйте, Junior1993, Вы писали:

J>А почему 3-й вариант для маленьких приложений? Имеете в виду, что места на форме может не хватить?
...
J>Кстати, по второму варианту вопрос — когда лучше сохранять изменения в БД? При нажатии ОК в модальном окне создания/редактирования или только после нажатия кнопки Save в главном окне?
Сценарии добавления, обновления, удаления данных должны быть интуитивно понятны пользователю.
Я считаю так:
— 1 и 3 варианты интуитивно понятны, если изменения фиксируются в базе данных сразу (без дополнительных кнопок и переходов на другую строку). Недостаток в том, что пользователь может случайно ткнуть не в ту ячейку и затереть важные данные. [/list]
— Можно повесить дополнительную кнопку для фиксации изменений, или фиксировать изменения по переходу на новую строку. В этом случае сценарии добавления и удаления данных несколько запутанные, а при тормозах системы становятся КОШМАРОМ пользователя. Но, такой подход удобен для операторов, которые вносят однородные данные большими объемами.
— В случае добавления, обновления и удаления данных через дополнительное окно пользователю интуитивно понятно, что нажав на "ОК" — изменения отправились в БД, нажав "Отмена" — с БД ничего не произошло. Любые дополнительные кнопки сохранения только запутают пользователя.

Что касается размещения всех реквизитов в одном окне. Скорость навигации по основной таблице резко падает, если для каждой строки необходимо делать дополнительный запрос к БД. Можно собирать данные для всех строк заранее, но это может быть большая нагрузка на БД.
Для себя я выбираю навигацию отдельно, а запрос дополнительных данных по открытию отдельного окна.

S>>Предлагаю свое решение http://daremanager.sourceforge.net/ru/
J>Я мельком глянул: тяжело читается, нет сразу чувства понимания понимания как это все работает, насколько это удобно. Мне кажется вам лучше добавить какую-то единую статейку, в которой вы бы применили своё решение и объяснили преимущества вашего решения; как вариант можно записать видео минут на 30 где вы с нуля создаете простенький проект используя ваш DaReManager.

Эксперементирую я давно, но описывать стал недавно. До "Введения" и видео пока не дошел. Пиши на почту, расскажу подробнее.

Здравствуйте, Junior1993, Вы писали:

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

IMHO все, что необходимо в бизнес приложениях, уже давно опробовано, негодное отброшено, лучшее вылизано и устаканилось в интерфейсе 1С. Посмотри.
Там можно встретить два варианта интерфейсов: "старый", который был до версии 8.2 и немного в ней, "новый", т.н. "управляемые формы", с несколькими новыми идеями. У тебя как раз нарисован "старый" вариант.

Сам я использовал в основном твой вариант 2), иногда 1). Вариант 3) считаю злом, в нем пользователи путаются.

Давний опыт показывает, что лучше всего — явные кнопки добавить\изменить\удалить (с дублированием даблкликами и хоткеями).
И отдельная, в ручную нарисованная, форма для работы с каждой записью. При массовом вводе работает настройка "открывать новую форму сразу после ввода старой". Все остальные подходы (и редактирование в строке грида и автогенерация форм) — исключительно от лени и желания сэкономить денег разработчиком. Хорошо и удобно так не сделать.

Вариант с одновременным показом полей редактирования и списка применяю редко — в основном, когда приложение больше как справочник используется. Для просмотра данных. И с другим расположением. Например — список сотрудников. Слева узкий грид на 2-3 колонки с навигацией, а справа — отображение данных с возможностью перейти в режим правки.

Здравствуйте, Junior1993, Вы писали:

J>Задача:
J>Есть какая-то сущность (допустим, Клиент, Поставщик и т.д.) и нужно создать интерфейс для создания/редактирования и удаления этих сущностей.

Это не задача, а так... размышления о функционале. В принципе, ВСЕ ТРИ варианта допустимы. Причём с вариациями времени записи в каждом из них. И вот для правильного выбора вам и нужно чуть точнее распросить — как конкретно будет всё это использоваться. Скажем, если это регистрация пациентов, её можно вообще делать целый день и в конце сохранить! А если это бронь билетов, выполнение должно быть незамедлительным.
Что я точно скажу, так редактирование "по месту" в гриде — плохая идея, ибо даже за собой замечаю — тупо кликаю на записи (или одну запись, чтобы легче читалось), а она мне — на, редактируй! ОПАСНО.

А в чём вы делали картинки? Искал похожий софт, но он оказался "слишком точным" хотелось добавить неряшливости.

> Случай 2: Минус — на каждую сущность приходится делать минимум 2 формы.

Какие ещё ДВЕ формы??

Здравствуйте, matumba, Вы писали:

M>Что я точно скажу, так редактирование "по месту" в гриде — плохая идея, ибо даже за собой замечаю — тупо кликаю на записи (или одну запись, чтобы легче читалось), а она мне — на, редактируй! ОПАСНО.

Спасибо за ответ. Тут я согласен, мне тоже кажется это несколько опасным..

M>А в чём вы делали картинки? Искал похожий софт, но он оказался "слишком точным" хотелось добавить неряшливости.

http://pencil.evolus.vn/

>> Случай 2: Минус — на каждую сущность приходится делать минимум 2 формы.
M>Какие ещё ДВЕ формы??

На картинке показано — форма просмотра и поверх неё модальная форма редактирования.

J>У меня мало опыта в разработке GUI для windows desktop приложений, но сейчас на проекте встала такая задача.
Тут нужен не опыт в разработке GUI, а опыт в использовании таких приложений. С точки зрения пользователя удобно "как в Excel'e".