Ув. прогеры! Пожалуйста, выскажите своё мнение по поводу этого интерфейса:



Это моя попытка создать удобный инструмент для управления таблицами (в MS SQL, многобазовость вряд ли предвидится). На картинке — форма редактирования колонки таблицы. Чтобы сразу не хотелось кинуться калом, объясню принципы, которыми я руководствовался:
1. 99% действий за 1% кликов.
2. Самое нужное и часто используемое — в начале.
3. Экзотика — в наименьшем приоритете (а-ля "а вот мы часто пользуемся гео-данными!"). Некоторых функций вообще может не быть, будут добавляться только при большом спросе.

Это часть будущего проекта а-ля "EMS MS SQL Manager", но сильно упрощённого (интерфейсно) для быстрого решения наиболее частых задач, так что ваша помощь будет неоценима.
Спасибо!

PS
Чекбокс на Size — сделать поле maximum size. Линк Default — очистить поле.

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

Я бы сделал DropDown (именно DropDown, а не DropDownList) вверху и динамически появляющийся (UserControl?) набор своств под ним. Сейчас у вас большинство ЭУ использованы не по назвачению.

Name первым (слева сверху). Type радиогруппой (и не обязательно в 1 столбец) — типов же не бывает одновременно несколько.
M>Чекбокс на Size — сделать поле maximum size. Линк Default — очистить поле.
Слишком загадочно. Чекбокс — это вкл/выкл, линк — куда-то перейти. Специфические действия лучше делать кнопками с иконкой справа от едита.

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

A>Я бы сделал DropDown (именно DropDown, а не DropDownList) вверху...

Это вы про тип колонки? А зачем ему позволяться редактироваться?

A> ... и динамически появляющийся (UserControl?) набор своств под ним.

эээ... из "динамического" там только Size/precision. Ради них городить динамику?

A> Сейчас у вас большинство ЭУ использованы не по назвачению.

А можно конкретнее? Эта форма сильно вводит в заблуждение? Неадекватные UI?

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

O>Name первым (слева сверху).

Тут было соображение экономии места: типов может быть немало, поэтому под них желательно отвести максимальный вертикальный размер. Форма — часто используемая, поэтому вряд ли мы услышим "оопс! где же тут поле 'name'?!" , т.е. вопрос привычки.

O> Type радиогруппой (и не обязательно в 1 столбец) — типов же не бывает одновременно несколько.

Радиогруппа имеет смысл на 3-5 элементах. Двадцать элементов в 3-5 столбцах запутают любого. Плюс, как вы заметили, типы не идут тупо по алфавиту — вычленены наиболее общеупотребительные (есессно, я дам возможность менять порядок). Может даже имеет смысл их давать разным цветом (строковые — синие, цифровые — зелёные и т.п.). И здесь ЛистБокс одновыбирабельный.

M>>Чекбокс на Size — сделать поле maximum size. Линк Default — очистить поле.
O>Слишком загадочно.

Matumba> "Форма — часто используемая".
Прицел идёт на ежедневное ковыряние, а не исследования "ну чо, как тут у вас это делается?". Чекбокс максимального размера именно "включает максимальный размер" и запрещает его указывать числом. Вопрос привычки.

O> линк — куда-то перейти. Специфические действия лучше делать кнопками с иконкой справа от едита.

Экономия места. Лишние элементы замусоривают тырфейс, а линк — некий аналог "текстовой кнопки", только без бордюра. Опять же, вопрос привычки.


Мне нравится, что вы подходите к тырфейсу "классически", т.е. как бы подошёл неподготовленный человек. Но видимо мне надо было сделать замечание, что это не тулза для чайников "ща я тут нафотошоплю!" — это ежедневный инструмент профессионала, т.е. который знает что он делает. Плюс, опять обращу внимание на принцип построения: минимум кликов, максимум пользы, самое частоделаемое должно быть самым быстроделаемым:
1. Набрали имя
2. клик на типе
3. (уточнили размер для строковых)
4. УЖЕ МОЖНО ЖАТЬ [OK]!

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

M>Ув. прогеры! Пожалуйста, выскажите своё мнение по поводу этого интерфейса:

M>

M>Это моя попытка создать удобный инструмент для управления таблицами (в MS SQL, многобазовость вряд ли

Картинка не отображается перезалей

Здравствуйте, matumba, Вы писали:
M>
Вопрос не по теме: на скрине контрол NumericUpDown — откуда взят? У штатного с верхней кнопки срезана полоса высотой один пиксель:

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

M>PS
M>Чекбокс на Size — сделать поле maximum size. Линк Default — очистить поле.
Интерфейс — так себе.
1. Полагается на то, что пользователь хорошо знает систему типов MS SQL Server — разницу между money и decimal.
2. Использует контролы не по назначению. List провоцирует на выбор нескольких вариантов; линки никуда не ведут; checkbox вообще непонятно что делает.
3. Задаёт ненужные вопросы. Scale нужен только для некоторых типов полей, равно как и Size.

Единственный сомнительный плюс — сортировка типов колонок по частоте использования. Сомнительный — потому, что выбор между char/varchar/nvarchar (кстати, а что случилось с nchar?) сильно зависит от специфики задачи и предпочтений архитектора. У вас предусмотрена пересортировка списка в соответствии с фактически наблюдаемыми частотами?

В общем, пока что есть такое впечатление, что профессионалу быстрее будет набить alter table add column MiddleName varchar(500) not null default '', чем натыкать то же самое в вашем UI. А непрофессионал непременно запутается и ошибётся, потому что ничего не понятно.

Если бы я делал UI для редактирования колонки, то я бы начал с имени. Покопал в сторону проверки соответствия заданных для проекта style and naming conventions — чтобы не было разнобоя в кейзинге, подчёркиваниях, и использовании рунглиша.
Потом бы пытался помочь с типом — предлагая дефолты, которые учитывают уже введённое имя колонки. Например, если ввели ID, то типом будет скорее всего int, или guid. Если ввели FirstName, то типом будет скорее всего varchar или nvarchar. Если ввели ProductID, где Product — имя таблицы, то тип скорее всего будет совпадать с типом колонки Product.ID. Понятное дело, что нужно учитывать статистику — например, если в данной базе во всех таблицах ID — это bigint, то и в новой таблице оно скорее всего будет таким.
Потом попытался бы помочь с констреинтами — догадываясь по имени колонки, куда будет сделан foreign key.

Идея такая, чтобы достаточно было набить имя, а всё остальное в 99% случаев UI угадает правильно.

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

M>Ув. прогеры! Пожалуйста, выскажите своё мнение по поводу этого интерфейса:

Выкиньте это всё и оставьте человеческий многострочный edit control. Можно с подобием IntelliSense, если уж хочется что-то упрощать пользователю. Потом выкиньте и edit control тоже и верните пользователю его любимый редактор, будь то FAR, vim или Emacs.

Обоснование: Действия пользователей с колонками не ограничиваются точечным редактированием одной характеристики одного поля. Пользователи хотят (1) копипейстить поля, (2) делать контекстную замену всех timestamp without time zone на integer и обратно, (3) …. И они хотят делать это быстро — подвёл курсор в нужное место, стёр одно, написал другое — а не кликая 200 раз в спинбаттон.

O>>Name первым (слева сверху).

M>Тут было соображение экономии места: типов может быть немало, поэтому под них желательно отвести максимальный вертикальный размер. Форма — часто используемая, поэтому вряд ли мы услышим "оопс! где же тут поле 'name'?!" , т.е. вопрос привычки.

Это не вопрос привычки. Это вопрос удобства. Большинство других инструментов (стандартный sql) приучают сначала думать о названии колонки, а затем уже о типе. Да и когда колонка добавляется, она придумывается от "названия" (а не назначения).


M>>>Чекбокс на Size — сделать поле maximum size. Линк Default — очистить поле.
O>>Слишком загадочно.

M>Matumba> "Форма — часто используемая".
M>Прицел идёт на ежедневное ковыряние, а не исследования "ну чо, как тут у вас это делается?". Чекбокс максимального размера именно "включает максимальный размер" и запрещает его указывать числом. Вопрос привычки.

Почему не работают другие варианты? Почему мы можем только включить максимальный размер или выключить его? Почему я не могу посмотреть максимальный размер и поправить его, например? И почему там нули по умолчанию? Гораздо более правильное поведение для нее следующее:
1. Если в поля был пользовательский ввод, сохраняется он.
2. Значение для MAX выделяется (например, MAX(12345), MAX=12345, M 12345, 12345 M)
3. Ввод допускает текстовое значение MAX (или просто M). Устанавливается соответствующий MAX с выделением.
4. При выборе нового типа значение для MAX в скобочках может меняться. Но только если установлено максимальное значение (которое выражается как MAX, 12345 и M — это разные вводы пользователя).
5. По умолчанию в поля вводится сразу MAX.

O>> линк — куда-то перейти. Специфические действия лучше делать кнопками с иконкой справа от едита.
M>Экономия места. Лишние элементы замусоривают тырфейс, а линк — некий аналог "текстовой кнопки", только без бордюра. Опять же, вопрос привычки.
А зачем линк? И почему он только один? Я сценарий не могу подобрать, в котором пользователю нужен такой ввод. Если пользователь в текстовом поле, быстрее будет Ctrl-A, Del. Если пользователь редактирует что-то другое и хочет исправить Default, поможет выделение всего текста при получении фокуса (можно сразу начинать ввод). Остается последний вариант — пользователь находится в другом поле и хочет удалить значение Default. Причем это у него частая операция (иначе работает автовыделение + Del). Странный сценарий, не находите?


M> это ежедневный инструмент профессионала, т.е. который знает что он делает. Плюс, опять обращу внимание на принцип построения: минимум кликов, максимум пользы, самое частоделаемое должно быть самым быстроделаемым:
Что интересно — правильный интерфейс здесь будет с нулем кликов вообще! Так как пользователь вынужден работать с текстом (вводить имя!), нужно как можно больше действий делать с клавиатуры. Кстати, покажите ваш Tab order, интересно очень . Да и ни одного акселератора нет, что плохо.
M>1. Набрали имя
Здесь есть еще два действия — перенести руку на мышку и спозиционировать указатель. За это время вполне нажимается Tab, <abc>, abc — три буквы, при грамотном autocomplete вполне достаточно для типа.
M>2. клик на типе
M>3. (уточнили размер для строковых)
Угу. Вы не учитываете, что это опять таскание мышки, перенос руки на клавиатуру, набор чисел (или тыканье по мелким кнопкам).
M>4. УЖЕ МОЖНО ЖАТЬ [OK]!
А в клавиатурном варианте можно жать Enter.

Автор, откуда контролы взял? Я тоже хочу.

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

M>это ежедневный инструмент профессионала, т.е. который знает что он делает.

Показываю, как правильно делается такой инструмент для профессионала. Будет обгонять ваш всегда. Для типичных простых задач (добавить колонку) будет быстрее, чем Alter table. Для добавления колонок при создании таблицы — сравним с написанием текста в DML. Для сложных операций (редактирование и т.п.) не подходит, так же, как и ваш. Да, требует больше обучения, но дает существенную выгоду.

1. Поле теста — первое. Сразу после открытия окна имеет фокус. По табу переходит в редактор типа.
2. Мне нравится идея Sinclair, пусть при первом переходе в поле ввода типа подставляется тип, выведенный из имени. В любом случае весь "тип" выделяется, т.е. начало ввода стирает старое значение. Поиск "нечеткий", не требует строгой последовательности букв. Возможно, учитывает позицию первой буквы при порядке вывода. Т.е. "vcr", "varc", "vchar" — это все "varchar". "nvc" — "nvarchar". Для диапазонов — либо буква m (максимум), либо число или два через пробел. Если диапазон не указан — тоже m. Т.е. "vcr", "vcr m", vcr max" — это одно и то же — varchar максимальной длины. "vcr 3", "vchar 3", "varchar 3" — varchar длины 3. По табу переходит к флагам.
3. Флаги. Секция получает фокус "целиком", так же и работает. Имеет индикаторы для ваших nullable, unique, primary key. Каждый флаг переключается одной буквой клавиатуры. Может быть, мнемонические клавиши, но мне кажется, что удобнее будет 3 клавиши рядом на правой части клавиатуры (левая рядом с табом с предыдущего шага и для перехода на следующий). Таб — переход на значение по умолчанию.
4. Значение по умолчанию. Обычное поле, возможно — с автокомплитом. Таб — переход в комментарий.
5. Комментарий. Просто текстовое поле. Таб — переход к имени.
6. "enter" — закрыть окно с применением результатов, esc — закрыть с отменой.

Альтернативные варианты. Возможно, пользователи будут выбирать из автокоплита "enter'ом". Тогда для закрытия можно добавить отдельную комбинацию. Также в этом случае после комментария идет там на ОК, затем — на текст. На Cancel не попадаем вообще через таб, для отмены служит esc (или комбинация клавиш).

Может быть, типы стоит повесить на комбинации клавиш (типов не так много, можно или F* задействовать, или комбинации основного блока с Alt-Ctrl). В этом случае нажатие клавиши (комбинации) сразу устанавливает тип (вручную тип не выбирается и не редактируется). Если есть указание диапазона — фокус перемещается туда (по умолчанию там — максимум), если нет — на флаги.

Итого — ввод выглядит так:
1. Набрали имя
2. Нажали таб
3. Ввели три буквы типа
4. Ввели размер для строковых (пробел и размер)
5. Можно жать Enter.

Заметьте — ни одного клика, все с клавиатуры. Учитывая, что перенос руки на мышку — это примерно 2,5-3 клика, такой вариант уже быстрее. И это не считая позиционирования мышки и поиск типа в списке. А ведь вам еще руку и обратно на клавиатуру придется переносить после закрытия окна (или выбора типа).

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

Выскажусь как представитель якобы целевой аудитории. То есть разработчик БД, постоянно занимающийся "управлением таблицами" и "редактированием колонок". :) Полностью согласен с Centaur. Никакой GUI не заменит мощи и гибкости текстового редактирования SQL. И причины он назвал верные, но не главные. Главная заключается в том, что работать с базой через подобный GUI — это все равно что общаться с корейцем на английском через Google Translate. Я как разработчик, прекрасно осознаю, что база понимает только один язык — SQL, и все прослойка в виде GUI и псевдоязыки типа HQL в итоге все равно транслируются в него же. Я специально выучил этот язык (и продолжаю пополнять словарный запас) для того, чтобы меня всегда понимали быстро, четко и однозначно. Любой переводчик там тут будет только мешать. В любом GUI я буду чувствовать себя некомфортно. Все равно я в итоге должен посмотреть на сгенерированный SQL и убедиться, что будет сделано именно то, что я хотел и ничего лишнего. А уж если дело касается чего-то mission-critical, то любой самый банальный ALTER TABLE перепроверяется по три раза разными людьми.

Так что ваш будущий продукт не для меня. Он как раз для тех "казуальных" пользователей, кто вынужден заниматься "редактированием колонок" иногда, время от времени. И учить ради этого все нюансы данного диалекта SQL не собирается. Это админы (не DBA), разработчики middle tier, веб-разработчики и т.д.

---

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

60% формы занимают два поля, использующихся наименее часто — список типов и комментарий. Тип выбирается самым первым (после имени!), да; но видеть все время набор вариантов, которые уже отверг, смысла по-моему нет никакого, они только отвлекают внимание. Поэтому комбобокс будет лучше. Комментарии обычно если и вводятся, то на самом последнем этапе, когда все остальные атрибуты у всех колонок уже устаканились.

Как уже заметили, нужна адаптивность, после выбора типа показать его и только его атрибуты и параметры. А их у MSSQL довольно много и разных.

Nullable, Unique и Primary key связаны, не знаю, так ли у вас. IMHO Primary логично поставить первым (из Primary следует Unique и Non-Nullable).

Нет возможности задать Check ограничение.

Нет возможности задать имена ограничений, в серьезном проекте это обязательно.

Нет возможности задать Foreign key, хотя это спорно. По крайней мере, если колонка уже участвует в FK, это нужно показать. Если я собрался ее менять, это важно.

W>база понимает только один язык — SQL, и все прослойка в виде GUI и псевдоязыки типа HQL в итоге все равно транслируются в него же.
База (точнее сервер) понимает не SQL, а AST, в которое транслирует человекочитаемый текст перед выполнением.
SQL — лишь прочий среди равных "псевдоязыков", транслируемых в/из AST. (И вообще SQL замышлялся как язык для бухгалтеров.)
Работа с базами через SQL — такой же пережиток, как двойное преобразование туда-сюда при подключении цифрового монитора по аналоговому кабелю. Будущее за серверами баз, понимающими деревья выражений.
W>В любом GUI я буду чувствовать себя некомфортно. Все равно я в итоге должен посмотреть на сгенерированный SQL
Правильный подход — давать возможность использовать оба представления (и диалоговое окно, где элементы AST разложены по подписанным ячейкам, и сплошная строка для тех кто "погружен в контекст" именно SQL, а не каких-то других знаковых систем). Так сделано в новой визуал студии — при редактировании таблицы на экране одновременно диалог (правда, примитивный, грид с полями) и SQL create table. Редактируешь одно — синхронно меняется другое.

2. Выше писали "Пользователи хотят (1) копипейстить поля, (2) делать контекстную замену". Сейчас такое делается через хранение текстовых sql-исходников всех объектов базы. Но иногда возникает необходимость хранить и дополнительные атрибуты, которых нет в SQL (например, дополнительное русское название поля). В MSSQL такие вещи хранятся в спец. таблице (extended properties), и в скрипт таблицы заталкиваются ну совершенно не по-людски (не атрибутом тут же у нужной колонки, а дополнительным запросом где-то сзади за 3 экрана). Считаю, для редактирования в виде текста лучше подходит XML с AST (содержащим больше атрибутов, чем необходимо для создания SQL), а диалоговое окно чтобы было по структуре 1:1 с XML.

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

F>Вопрос не по теме: на скрине контрол NumericUpDown — откуда взят?

Если не нативный, то скорее всего из DotNetBar.

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

S>1. Полагается на то, что пользователь хорошо знает систему типов MS SQL Server — разницу между money и decimal.

удобный инструмент для управления таблицами (в MS SQL, многобазовость вряд ли предвидится

S>2. Использует контролы не по назначению. List провоцирует на выбор нескольких вариантов; линки никуда не ведут; checkbox вообще непонятно что делает.

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

Линкам и не надо никуда вести, это не браузер. Линк — это урезанная форма кнопки, некоего "активного текста".

S>3. Задаёт ненужные вопросы. Scale нужен только для некоторых типов полей, равно как и Size.

Согласен, но только с одной стороны — с т.з. загруженности тырфейса. С другой, просто бесят тырфейсы, где по клику меняется пол-формы (да ещё съезжают координаты статических элементов).
Видимо, я их буду просто дизэйблить или менять прозрачность.

S> У вас предусмотрена пересортировка списка в соответствии с фактически наблюдаемыми частотами?

Список задаётся в сеттингах по усмотрению юзера.

S>В общем, пока что есть такое впечатление, что профессионалу быстрее будет набить....

Спасибо, поржал. Дайте угадаю: мышку он уже отгрыз и навигируется чисто клавишами. Обладает красными глазами, живёт под ArchLinux.

S>Если бы я делал UI для редактирования колонки, то я бы начал с имени.

Объяснил выше — список типов должен быть максимально большим. Форма — для ежедневного использования, в самом верху — имя. Очень сомнительно, что юзер будет пропускать поле ввода.

S>Потом бы пытался помочь с типом — предлагая дефолты, которые учитывают уже введённое имя колонки.

Больше, чем тупые интерфейсы, раздражают слишком умные интерфейсы. Я согласен с некоторой долей AI в форме, но строго опционально через конфиг программы.
Кстати, описанную вами идею я уже сделал для FK по подбору ссылаемой таблицы. Одинаково мыслим!

S>Потом попытался бы помочь с констреинтами — догадываясь по имени колонки, куда будет сделан foreign key.

Тут может быть сложность. Ну ввёл ты "PersonID", потом прыгнул к типам, а написать хотел "PersonIdiot" — а система уже создала FK! Не, здесь пусть лишний раз кликнет и подтвердит намерения. Да и разницы нет — что запрашивать создание FK, что щёлкнуть на чекбоксе.

S>Идея такая, чтобы достаточно было набить имя, а всё остальное в 99% случаев UI угадает правильно.

+100, к этому и стремлюсь. Но все эти "скрепки-помощники" не должны мешать. Интерфейс и так сделан максимально сжатым, отказ от помощи — это лишние клики.

Спасибо за ответ!

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

M>Почему я не могу посмотреть максимальный размер и поправить его, например?

гыгы Да потому что пишут либо varchar(число), либо varchar(max)! Вы SQL вообще видели?

M> И почему там нули по умолчанию?

Потому что ни одно дефолтовое значение не удовлетворит Хотя это мыль — брать его из настроек.

M> 1. Если в поля был пользовательский ввод, сохраняется он.

Зачем? Если вдруг ты забудешь сменить старое значение, оно так и полетит в базу. Типичная ошибка копипасты.

M> 3. Ввод допускает текстовое значение MAX (или просто M). Устанавливается соответствующий MAX с выделением.

Чекбокс и всё сделано.

M> 4. При выборе нового типа значение для MAX в скобочках может меняться.

Тут трудно угадывать, придётся для каждого типа хранить некий "удобный дефолт". Который, как ни странно, нафик никому не нужен.

M> 5. По умолчанию в поля вводится сразу MAX.

MAXимумов в таблице намного меньше лимитированных значений. Ставить МАХ заранее — это обрекать на лишний клик.

M>Если пользователь в текстовом поле...

Без разницы в каком. Я очень много действий делаю именно мышой, поэтому ваши "Ctrl-A, Del" — это слишком долго и неудобно.
В принципе, единственное назначение линка — убрать дефолт если он уже был в существующей колонке. Можно и без линка, но почему бы не упростить работу?

M> Так как пользователь вынужден работать с текстом (вводить имя!), нужно как можно больше действий делать с клавиатуры.

Не вижу связи. Ввёл имя — всё остальное накликал, зачем там клава? Поле имени будет активироваться первым, далее всё мышой.

M> Кстати, покажите ваш Tab order, интересно очень

Знал бы как — показал. В Дельфи — могу, в студии — нет.

M> Да и ни одного акселератора нет, что плохо.

+1! Это прототип, но хоткеи будут, 146%!

M>Здесь есть еще два действия — перенести руку на мышку и спозиционировать указатель. За это время вполне нажимается Tab, <abc>, abc — три буквы

...а за ваши "три буквы" вообще можно всю форму заполнить! Смысл? Да и контролов относительно много, вы что, будете по ним табом прыгать??

M>Угу. Вы не учитываете, что это опять таскание мышки, перенос руки на клавиатуру, набор чисел (или тыканье по мелким кнопкам).

Не-не, numeric UpDn — это чисто для визуального понимания, сам по себе это самый дебильный контрол мелкософта. Скорее, туда имеет смысл поставить комбобокс с какими-то частыми значениями.

Спасибо за оценку!
Так как я больше мышевоз, чем клавоблуд, UI ориентируется на быстрокликанье. Но конечно я постараюсь и для джедаев клавы.

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

M>Показываю, как правильно делается такой инструмент для профессионала.

Я уже понял, что клавоманьяки категорически не приемлют мышеинтерфейсы.
Я попробую сделать так, чтобы можно было обходиться одной клавой (мысль про выбор типа по F* тоже приходила и я точно это сделаю), но вам надо осознать, что кроме вас существуют ещё 99% людей, которым проще кликнуть, чем искать на клаве "any key"! Кроме того, "визуально" (т.е. мышой) это делается очевиднее.

M>На Cancel не попадаем вообще через таб, для отмены служит esc (или комбинация клавиш).

Разумно.

M>Итого — ввод выглядит так:
M>1. Набрали имя
M>2. Нажали таб
M>3. Ввели три буквы типа
M>4. Ввели размер для строковых (пробел и размер)
M>5. Можно жать Enter.

Всё то же самое, только с клавы.
Понимаете, я не делаю СТРАШНЫЙ УСКОРИТЕЛЬ создания колонок! Я делаю УДОБНЫЙ тырфейс, где парой кликов делается вся работа. Т.е. подпираем одной рукой голову, второй — необременительно кликаем в батоны.
Спасибо за интересные мысли!

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

C>Выкиньте это всё и оставьте человеческий многострочный edit control.

Не, на маразм времени нет. На батоны-чекбоксы — есть.

C>верните пользователю его любимый редактор, будь то FAR, vim или Emacs.

И что мне в этом ФАРе делать?? Говорю же — на маразм времени нет, нужно взять таблицу, добавить/изменить колонку. Всё.

C>Обоснование: Действия пользователей с колонками не ограничиваются точечным редактированием одной характеристики одного поля.

Контролов на форме — море, что хочешь, то и редактируй!

C> Пользователи хотят (1) копипейстить поля

Будет. Сделаю отдельный батон на тулбаре, по которому дублируется текущая колонка. +1 в карму!

C> (2) делать контекстную замену всех timestamp without time zone на integer и обратно

Больные штоле?? Ну пусть делают, это далеко не основное назначение инструмента.
Вообще, стоит пояснить: основная роль моего "манагера" — заниматься структурой таблиц. Репликации, замены, I/O записей, бэкапы — всё это второстепенные плюшки, которые будут добавляться потом.

C> (3) …. И они хотят делать это быстро — подвёл курсор в нужное место, стёр одно, написал другое — а не кликая 200 раз в спинбаттон.

У вас претензия к numeric UpDown? Согласен, не самый лучший контрол, я обязательно посмотрю альтернативу (см. выше мой ответ).

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

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

M>>Показываю, как правильно делается такой инструмент для профессионала.

M>Я уже понял, что клавоманьяки категорически не приемлют мышеинтерфейсы.
M>Я попробую сделать так, чтобы можно было обходиться одной клавой (мысль про выбор типа по F* тоже приходила и я точно это сделаю), но вам надо осознать, что кроме вас существуют ещё 99% людей, которым проще кликнуть, чем искать на клаве "any key"! Кроме того, "визуально" (т.е. мышой) это делается очевиднее.
Я вас разочарую — реальные профессионалы очень клавиатурно развиты. Это суровая необходимость — если вам нужно набить 15 мегабайт исходников, вы таки освоите клаву, хотите вы этого или нет. Знаете, как на собеседованиях отличают тех, кто реально DB-девелопер, от тех, кто SQL по книжке выучил? Вопросом "как выглядит select в русской раскладке". Потому, что реальный DB-девелопер select набирает двумя руками и за 0.6 секунды, т.к. это примерно пятисоттысячный select, который он набрал.

M>Всё то же самое, только с клавы.
M>Понимаете, я не делаю СТРАШНЫЙ УСКОРИТЕЛЬ создания колонок! Я делаю УДОБНЫЙ тырфейс, где парой кликов делается вся работа. Т.е. подпираем одной рукой голову, второй — необременительно кликаем в батоны.
У тех, кто ищет на клавиатуре any key, проблема не в том, чтобы ускорить набивку, а в том, чтобы разобраться, куда нажимать.
Им ваша форма никак не помогает.
Так что вы делаете инструмент, который пытается попасть строго между двух возможных аудиторий.

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

W>В любом GUI я буду чувствовать себя некомфортно.

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

W> А уж если дело касается чего-то mission-critical...

"Эх, а говорил, что романтик профессионал!...". Неужто такому профи не очевидно, что данная форма не предназначена для удалённых синхронизаций и хитровывернутых апдейтов?
Мне нужна таблица — я её создал, заполнил колонками. Что за мутные проверки я должен делать? Для параноиков есть ассемблер, а я доверяю SQL, который сгенерит программа.

W>Он как раз для тех "казуальных" пользователей...

Спасибо, смешно. Если вам так хочется, считайте это "казуальный редактор таблиц", но если он поможет хотя бы половине тех, кто дрючится в EMS или, прости господи, "MS Management STUDIO", то я свою миссию выполнил.

W>60% формы занимают два поля, использующихся наименее часто — список типов и комментарий.

"типы" — это у вас НАИМЕНЕЕ ЧАСТО? Типы — это НАИБОЛЕЕ ЧАСТО, поправьте спеллчекер.

W> Тип выбирается самым первым (после имени!), да; но видеть все время набор вариантов, которые уже отверг, смысла по-моему нет никакого, они только отвлекают внимание. Поэтому комбобокс будет лучше.

Рассуждение — логичное, но неправильное — сказывается недостаток опыта в ГУЯх. Вот именно потому, что я прыгаю в комбобоксе по типам, да ещё скроллируя, я и ненавижу EMS Manager. НЕУДОБНО сначала кликать-раскрывать список, потом искать свой тип (скроллируя), потом снова кликать... ОДИН клик — и тип выбран. Видны практически все частые типы. Визуально — это "белая полоса слева", она автоматически вырезается из зоны внимания (как выкидывается полоса меню у сайтов). Другой вопрос, что список — вроде бы не самый очевидный контрол, тут согласен, но другого нет.

W> Комментарии обычно если и вводятся, то на самом последнем этапе, когда все остальные атрибуты у всех колонок уже устаканились.

Согласен. Однако, и стоит он на последнем месте, не особо отсвечивая. Вообще, я уже несколько исковеркал эту форму, так что надо будет опять спрашивать.

W>Как уже заметили, нужна адаптивность, после выбора типа показать его и только его атрибуты и параметры. А их у MSSQL довольно много и разных.

Ну да, много и разных — size и scale
Я думал о том, чтобы их прятать/динамически показывать, но "мутирующие" тырфейсы меня бесят. Конечно, я сделаю визуальную подсказку, если тип требует тюнинг.

W>Nullable, Unique и Primary key связаны, не знаю, так ли у вас.

эээ... чем связаны? Nullable может быть любой тип. Unique — тоже и оба независимо от PK. А выставленный PK в Nullable вообще не нуждается. Зато рядом с PK я положил autoincrement, который, кстати, тоже от PK не зависит.

W>Нет возможности задать Check ограничение.

Да его вообще там нет! Но будет, не всё сразу. Я ж грю — прототип, т.е. набросок общего вида.

W>Нет возможности задать имена ограничений, в серьезном проекте это обязательно.

Это 100% будет. Я, правда, не уверен, что юзеру надо докучать именованием PK....

W>Нет возможности задать Foreign key

нене, уже есть! В доработанной форме там всё задаётся и даже можно автоматом генерить имя.

Ещё раз спасибо за отзыв!

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

M>Ну да, много и разных — size и scale :)))

M>эээ... чем связаны? Nullable может быть любой тип. Unique — тоже и оба независимо от PK.

Вы с MSSQL сколько месяцев знакомы? До сих пор не возникало желания хотя бы ознакомиться со спецификацией? Боюсь, вас ждет столько открытий, что может пропасть весь запал "сделать удобнее, чем в EMS".


W>>Нет возможности задать имена ограничений, в серьезном проекте это обязательно.
M>Это 100% будет. Я, правда, не уверен, что юзеру надо докучать именованием PK.... :shuffle:

Юзеру пожалуй не надо. А у разработчиков есть coding style и naming conventions, знаете ли.

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

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

M>>Ну да, много и разных — size и scale

M>>эээ... чем связаны? Nullable может быть любой тип. Unique — тоже и оба независимо от PK.

W>Вы с MSSQL сколько месяцев знакомы?

Достаточно, чтобы ткнуть вас носом. Набираем:

CREATE TABLE bzbz (
   ID int PRIMARY KEY IDENTITY(1,1)
)

Прекрасно создаётся таблица безо всяких NON NULL и UNIQUE. Для юзера выглядит всё аналогично прозрачно: захотел PK — просто кликнул чекбокс без заморочек с NULL, менеджер это просекает и выдаёт код выше.


W>Боюсь, вас ждет столько открытий, что может пропасть весь запал "сделать удобнее, чем в EMS".

Не надо бояться — плохо пахнуть будет! Прототип уже дошёл до стадии "показываются колонки таблиц". Не боги горшки обжигают, да и я не лезу туда, где тёмный лес (для меня это DirectX, например).


W>>>Нет возможности задать имена ограничений, в серьезном проекте это обязательно.
M>>Это 100% будет. Я, правда, не уверен, что юзеру надо докучать именованием PK....

W>Юзеру пожалуй не надо. А у разработчиков есть coding style и naming conventions, знаете ли.

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

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

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

M>Увы, я — проктолог, вам нужен врач этажом выше.
M>Не, серьёзно, вы же не думаете, что тысячи остальных прогеров думают как вы?? GUI на то и придуман, что для работы, которая занимает минуту в день, не нужно досконально помнить низкоуровневый язык.
При этом вы почему-то думаете, что ваша аудитория досконально помнит разницу между money и decimal.
Может, вы подробнее напишете о том, для кого именно вы делаете инструмент?

M>Мне нужна таблица — я её создал, заполнил колонками. Что за мутные проверки я должен делать? Для параноиков есть ассемблер, а я доверяю SQL, который сгенерит программа.
Тогда нужно потратиться на то, чтобы сделать UI человекопонятным. Пока что вы от этого крайне далеки. Вам уже указали на большинство ваших ошибок, но вы последовательно игнорируете полезные советы.

M>Рассуждение — логичное, но неправильное — сказывается недостаток опыта в ГУЯх. Вот именно потому, что я прыгаю в комбобоксе по типам, да ещё скроллируя, я и ненавижу EMS Manager. НЕУДОБНО сначала кликать-раскрывать список, потом искать свой тип (скроллируя), потом снова кликать... ОДИН клик — и тип выбран.
Вы по-прежнему не понимаете. Наверное, сказывается недостаток опыта в гуях. Не нужно прыгать в комбобоксе по типам, да ещё скроллируя. Достаточно нажать первые две-три буквы типа (да, да, о ужас, на клавиатуре).
Поймите, что проблема выбора типа — не в том, что трудно попасть в него мышкой. Проблема — в том, чтобы знать, какой тип выбрать. Вот я, со своим опытом работы в MS SQL, знаю, что для PK имеет смысл делать int. А для человека с опытом "по книжками" numeric(10, 2) выглядит ничуть не хуже.

W>>Как уже заметили, нужна адаптивность, после выбора типа показать его и только его атрибуты и параметры. А их у MSSQL довольно много и разных.

M>Ну да, много и разных — size и scale
А COLLATE? А ROWGUIDCOL?

W>>Nullable, Unique и Primary key связаны, не знаю, так ли у вас.
M>эээ... чем связаны? Nullable может быть любой тип. Unique — тоже и оба независимо от PK. А выставленный PK в Nullable вообще не нуждается. Зато рядом с PK я положил autoincrement, который, кстати, тоже от PK не зависит.
Я вас разочарую. Сделать PK Nullable у вас не получится, так же как и неуникальным. То, что "NOT NULL" можно опускать для primary key колонок — это всего лишь синтаксический сахар.

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

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

Колесо — оно тоже простое, А ТЫ ИЗОБРЕТИ! Я видел сотни му**ов, для которых "формоклепание в Дельфи" сродни подметанию улицы. И только дурачок Раскин додумался написать для этого целую книгу. Абалдеть, да?
Я это к тому, что если кто-то не видит проблемы, это ещё не значит, что её нет. Юзабилити — ГРОМАДНАЯ проблема, споры в этом форуме только подтверждают это.

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

M>>для работы, которая занимает минуту в день, не нужно досконально помнить низкоуровневый язык.
S>При этом вы почему-то думаете, что ваша аудитория досконально помнит разницу между money и decimal.

Мне пофиг, что они помнят. Моя задача — дать выбрать тип. Решать за них автоматом я не могу (но попытаюсь применить некоторый AI).

S>Может, вы подробнее напишете о том, для кого именно вы делаете инструмент?

Для прогеров. Нужно только вдумчиво прочитать изначальный пост:

но сильно упрощённого (интерфейсно) для быстрого решения наиболее частых задач

.
Т.е. создание/удаление таблиц/колонок/PK/FK — этим я занимаюсь 99% всей возни с базами. Это главная цель. Остальное можно добавлять по мере надобности.

S>Тогда нужно потратиться на то, чтобы сделать UI человекопонятным. Пока что вы от этого крайне далеки.

Из "непонятного" там только Max length и линк Default. Да и те — вопрос привычки. Если вы не понимаете остальной интерфейс, с трудом верится, что вы вообще видели базы данных. (это я утрирую, потому что не менее смешно слышать "далёк от человекопонятности" — захотелось красного словца? Понимаю, но такое не лечу.)

S> Вам уже указали на большинство ваших ошибок, но вы последовательно игнорируете полезные советы.

Всё полезное отмечено моими же комментами. А считать за "ошибки" личные капризы и привычки — не профессионально, поэтому проигнорировано.

S>Не нужно прыгать в комбобоксе по типам, да ещё скроллируя. Достаточно нажать....

И этот человек мне говорит об ошибках... Мистер, вы вообще что ли слово "мышь" не умеете читать? Подымитесь выше и прочтите каждое упоминание хвостатого — там же я даю исчерпывающие объяснения, почему сделано именно так.
НЕ НАДО ничего нажимать. Или по кр. мере не надо портить жизнь тем, кому ваши клавы — как Гейтсу перфокарты. Мышь — удобна, интуитивна, на неё делается весь упор. Заодно посмотрите комментарий со словами "СТРАШНЫЙ УСКОРИТЕЛЬ".

S>Поймите, что проблема выбора типа — не в том, что трудно попасть в него мышкой. Проблема — в том, чтобы знать, какой тип выбрать.

Я не лечу хроническую лень изучать программинг. Инструмент не содержит видеоуроков "Как выбрать правильный тип". Он просто даёт выбор. Моя проблема — как этот выбор сделать наиболее простым.
Так, для себя: каким образом вы потенциально могли бы решить проблему незнания типов SQL при помощи GUI??

M>>Ну да, много и разных — size и scale
S>А COLLATE? А ROWGUIDCOL?

COLLATE — анахронизм, его выбор я дам, но в самой Ж формы.
ROWGUIDCOL — как часто вы им пользуетесь?
Как я уже говорил, вначале — САМОЕ ЧАСТОЕ. Все остальные экзотики будут добавляться после и в самый зад формы. Конкретно ROWGUIDCOL — рядом с PK.

W>>>Nullable, Unique и Primary key связаны, не знаю, так ли у вас.
M>>эээ... чем связаны? Nullable может быть любой тип. Unique — тоже и оба независимо от PK. А выставленный PK в Nullable вообще не нуждается. Зато рядом с PK я положил autoincrement, который, кстати, тоже от PK не зависит.
S>Я вас разочарую. Сделать PK Nullable у вас не получится

Не в ту сторону мыслите. Ключевая фраза: "А выставленный PK в Nullable вообще не нуждается". Поставил галку PK и забыл про всё остальное — вот цель.

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

M>Мне пофиг, что они помнят. Моя задача — дать выбрать тип. Решать за них автоматом я не могу (но попытаюсь применить некоторый AI).
Вы, наверное, надо мной прикалываетесь. Кто именно ваш пользователь?
Он не умеет пользоваться клавиатурой — то есть он не девелопер.
Он не знает синтаксис alter table add column — то есть он совсем не девелопер.
Но он прекрасно знает, какой тип он хочет для колонки, чем отличается nchar от nvarchar и decimal от numeric.
Лично я с такими не знаком.

M>Для прогеров. Нужно только вдумчиво прочитать изначальный пост:
M>

но сильно упрощённого (интерфейсно) для быстрого решения наиболее частых задач

.
Что вы называете "упрощением"? Что, по-вашему, "сложно" в процессе создания колонки?

M>Из "непонятного" там только Max length и линк Default.
Из непонятного там всё, на что вам указали. Вместо того, чтобы острить, постарайтесь понять, что вам пишут, и почему.

M>Всё полезное отмечено моими же комментами. А считать за "ошибки" личные капризы и привычки — не профессионально, поэтому проигнорировано.
Поймите, если вы хотите иметь аудиторию больше одного человека, то вам нужно следовать стандартам. "Удобно" и "привычно" в usability синонимы. Вы хотите сделать "упрощение", которое требует от пользователей отказаться от привычек. Увы, для них это будет сложностью, а вовсе не упрощением.

M>И этот человек мне говорит об ошибках... Мистер, вы вообще что ли слово "мышь" не умеете читать? Подымитесь выше и прочтите каждое упоминание хвостатого — там же я даю исчерпывающие объяснения, почему сделано именно так.
Ваши объяснения ничего не исчерпывают. Поймите, что бесклавиатурных программистов — ещё меньше, чем глухих дирижёров.
Объясните мне, зачем пользователь, который только что слепым десятипальцевым методом набрал имя поля, станет бросать клавиатуру и тыкать мышкой в какой-то список? Какая причина может быть у этого?

M>НЕ НАДО ничего нажимать. Или по кр. мере не надо портить жизнь тем, кому ваши клавы — как Гейтсу перфокарты. Мышь — удобна, интуитивна, на неё делается весь упор. Заодно посмотрите комментарий со словами "СТРАШНЫЙ УСКОРИТЕЛЬ".
Не вижу никакого "всего" упора. Имя поля — по-прежнему фейл: надо набирать на клавиатуре. Может, вам вместо него вставить виртуальную клавиатуру, в которую тыкать мышкой, раз уж вам клава — как Гейтсу перфокарты?

А если серъёзно, то я вам подскажу потенциальную целевую аудиторию. Если пользователь работает на планшете или телефоне, т.е. устройстве с touch input — там да, классические дроп-дауны — ужасны, а клавиатурный ввод — зло.
Вот если вы сделаете тул, который позволяет легко добавить колонку с винфона — вам скажут спасибо.

M>Я не лечу хроническую лень изучать программинг. Инструмент не содержит видеоуроков "Как выбрать правильный тип". Он просто даёт выбор. Моя проблема — как этот выбор сделать наиболее простым.
Ваша проблема — в полном непонимании того, что просто, а что сложно.

M>Так, для себя: каким образом вы потенциально могли бы решить проблему незнания типов SQL при помощи GUI??
Ну как каким? Выяснил бы, с какими представлениями приходят люди создавать колонку, и построил бы GUI от этого.
Скорее всего плясал бы от того, какие данные пользователи хотят хранить там. Идентификатор/строка/число. В зависимости от выбора, задавал бы доп.вопросы до прояснения.


M>COLLATE — анахронизм, его выбор я дам, но в самой Ж формы.
M>ROWGUIDCOL — как часто вы им пользуетесь?
Я — не часто. Но ведь тул для прогеров, не?

M>Не в ту сторону мыслите. Ключевая фраза: "А выставленный PK в Nullable вообще не нуждается". Поставил галку PK и забыл про всё остальное — вот цель.
А ещё лучше — отсутствие необходимости ставить галку PK. В 100% проектов первое же поле таблицы — это и есть PK. Его название и тип в 99% определяются project-wide политикой. То есть можно сэкономить сразу десяток кликов, если создавать его по умолчанию.

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

M>>Мне пофиг, что они помнят. Моя задача — дать выбрать тип. Решать за них автоматом я не могу (но попытаюсь применить некоторый AI).
S>Вы, наверное, надо мной прикалываетесь. Кто именно ваш пользователь?

Отвечаю в третий раз: не обременённый "интыпрайзом" прогер, тот же "автоматизатор бухгалтерии". Т.е. когда забота о бизнес-логике важнее той свалки, где нужно хранить данные. Запустил, тыкнул — вот тебе таблица с колонкой. Да, этот инструмент ВОЗМОЖНО вызовет баттхёрт глубокобазыданных профи, но для остальных 99% прогеров может оказаться намного более удобным.

M>>

но сильно упрощённого (интерфейсно) для быстрого решения наиболее частых задач

.
S>Что вы называете "упрощением"? Что, по-вашему, "сложно" в процессе создания колонки?

Usability. Когда я выбираю тип из комбобокса — это сакс. Когда я лажу по тэбам за частоиспользуемым чекбоксом — сакс. Когда я вынужден пролистывать таблицы в поисках ссылкаемой из FK — сакс и так до бесконечности. *в воздухе слышен свист тухлого яйца, летящего в EMS* Это не то слово "сложно", это скорее "неудобно". Меня раздражают вещи, которые потенциально должны решаться за два клика, а вместо этого я трачу порядка пяти минут на разгребание тырфейса ленивых, программирующих укурков.

M>>Из "непонятного" там только Max length и линк Default.
S>Из непонятного там всё, на что вам указали. Вместо того, чтобы острить, постарайтесь понять, что вам пишут, и почему.

Ну на... В данном случае пойдём путём Джобса: я сделаю, покажу, а там свои фанаты найдутся. Я просто уверен, что делаю лучше существующего.

S>"Удобно" и "привычно" в usability синонимы.

ОТЧАСТИ согласен. Но как и в любом мнении/парадигме, бездумное следование ведёт в ад. Иногда имеет смысл сделать "поперёк", чтобы кто-то почесал голову: "а чего мы раньше-то так не делали?!". Пример из истории: RibbonBar. Толстый, эпатирующий, но таки стал любимцем секретарш. А у меня таких "поперёк" можно сказать и нет — почти все элементы присутствуют и у других "колонкоредакторов".

S>Поймите, что бесклавиатурных программистов — ещё меньше, чем глухих дирижёров.

Вы не совсем о том. ВСЯ ВИНДА существует на мышином тырфейсе, мышь — обязательное требование. Когда можно обойтись мышью — я использую именно её. Поэтому что и как будет набирать "клавофил" мне пофиг — я сделаю для него шоткаты. Главное — работу можно сделать за минимум кликов. Кроме того, не надо петь про слепые 10-пальцевые методы — едва ли трёх прогеров я видел в жизни, кто мог не глядя что-то там набирать. ТРЁХ(!!!) из минимум сотни. Хотят — пусть тратят время в текстбоксе MS SQL Studio, мой инструмент для тех, кто не напрягает понапрасну фаланги.


M>>Так, для себя: каким образом вы потенциально могли бы решить проблему незнания типов SQL при помощи GUI??
S>Ну как каким? Выяснил бы, с какими представлениями приходят люди создавать колонку, и построил бы GUI от этого.
S>Скорее всего плясал бы от того, какие данные пользователи хотят хранить там. Идентификатор/строка/число. В зависимости от выбора, задавал бы доп.вопросы до прояснения.

Визард штоле? Чтобы на третьем его появлении меня прибили стулом? У вас даже сейчас "мутное" представление о том, что вы хотите иметь. Я же имею чёткую картину, хочется изгнать дьявола из деталей.

M>>ROWGUIDCOL — как часто вы им пользуетесь?
S>Я — не часто. Но ведь тул для прогеров, не?

Для прогеров. А в чём логика-то? И я вот тоже ВООБЩЕ НЕ использую этот флаг. Ну так зачем его совать вперёд? "Усё будет", но в разных табах и разной степени доступности. Если на это вообще будет спрос.

S>А ещё лучше — отсутствие необходимости ставить галку PK. В 100% проектов первое же поле таблицы — это и есть PK.

Ну вот видите, вот и вы доросли до моего понимания! УЖЕ СДЕЛАНО, не обращая внимание на занудство "профи" "А вдруг я захочу имя не ID, а SUPERID!". Опять же, это чётко следует моей политике: минимум кликов и максимум помощи для самых распространённых задач. Т.е. при создании таблицы я сразу же создаю "ID int PRIMARY KEY IDENTITY(1,1)". Кому не нравится — EMS в руки.

Я ведь не спорю, что делаю всё идеально — но я точно знаю, как НЕ идеально сделано существующее и это исправляю. Тем более, в инструменте, который использую уже бог знает сколько лет.

Здравствуйте, matumba, Вы писали:
M>Отвечаю в третий раз: не обременённый "интыпрайзом" прогер, тот же "автоматизатор бухгалтерии". Т.е. когда забота о бизнес-логике важнее той свалки, где нужно хранить данные. Запустил, тыкнул — вот тебе таблица с колонкой. Да, этот инструмент ВОЗМОЖНО вызовет баттхёрт глубокобазыданных профи, но для остальных 99% прогеров может оказаться намного более удобным.
В третий раз спрашиваю: почему вы думаете, что этот прогер хорошо разбирается в различиях типов данных MS SQL?

M>Usability. Когда я выбираю тип из комбобокса — это сакс. Когда я лажу по тэбам за частоиспользуемым чекбоксом — сакс. Когда я вынужден пролистывать таблицы в поисках ссылкаемой из FK — сакс и так до бесконечности. *в воздухе слышен свист тухлого яйца, летящего в EMS* Это не то слово "сложно", это скорее "неудобно". Меня раздражают вещи, которые потенциально должны решаться за два клика, а вместо этого я трачу порядка пяти минут на разгребание тырфейса ленивых, программирующих укурков.
Ок, я, кажется, вас понял. Вы действительно не владеете клавиатурой, поэтому баттхёрт.

M>Ну на... В данном случае пойдём путём Джобса: я сделаю, покажу, а там свои фанаты найдутся. Я просто уверен, что делаю лучше существующего.
Ну чтож, посмотрим. Я буду очень рад ошибаться
Кстати, путь Джобса, помимо всего прочего, включает фокус-группы и юзабилити-тестирование.

M>ОТЧАСТИ согласен. Но как и в любом мнении/парадигме, бездумное следование ведёт в ад. Иногда имеет смысл сделать "поперёк", чтобы кто-то почесал голову: "а чего мы раньше-то так не делали?!". Пример из истории: RibbonBar. Толстый, эпатирующий, но таки стал любимцем секретарш.
Хороший пример. Кстати, вы обратили внимание, что риббон дружлюбнее к клавиатуре, чем тулбары+меню?

S>>Поймите, что бесклавиатурных программистов — ещё меньше, чем глухих дирижёров.
M>Вы не совсем о том. ВСЯ ВИНДА существует на мышином тырфейсе, мышь — обязательное требование.
Это вы не совсем о том. "Вся винда" разработана для домохозяйки. Потому что Гейтс хотел, чтобы компьютер был "в каждом доме, на каждом столе". Среди пользователей винды процент владеющих клавиатурой на приемлемом уровне не очень велик.
Среди программистов он значительно выше. В силу очевидной специфики их работы.

M>Кроме того, не надо петь про слепые 10-пальцевые методы — едва ли трёх прогеров я видел в жизни, кто мог не глядя что-то там набирать.
Что я могу сказать — вам не повезло. Я лично в такое не верю. Просто потому, что человек не может не учиться.
Если программист реально пишет код, он рано или поздно освоит клавиатуру.
В качестве примера: я сейчас пишу этот текст на клавиатуре, где нет (и не было) кириллических символов. Ноутбук импортирован из штатов. Как видите, никаких проблем писать кириллицей при этом нет.

Я никогда не ходил ни на какие курсы, не учился слепой печати специально. Просто с 12 лет программировал столько, сколько мог. Руки сами запомнили раскладку йцукен. Ясное дело, что с кверти то же самое.
И я ешё плохо владею клавиатурой. Видел выступление Дона Бокса — его ассистент в чистом нотепаде играл текстом, как зинчук на гитаре. Я так не могу.

M>Визард штоле?
Не обязательно. Progressive disclosure бывает в нескольких способах.
M>У вас даже сейчас "мутное" представление о том, что вы хотите иметь. Я же имею чёткую картину, хочется изгнать дьявола из деталей.
У меня — очень внятное представление о том, чего я хочу иметь. Я не верю в создание таблиц людьми, не разбирающимися в вопросе. То есть верю, но не считаю эту тему заслуживающей отдельного продукта. Только в качестве мысленного упражнения — вроде "спроектируйте панель управления лифтом в стоэтажном здании для слепоглухонемых".
А иметь я хочу текстовый редактор с продвинутым автодополнением и коррекцией ошибок, который не слишком путается у меня под ногами, и учитывает контекстную информацию — как статистику использования конструкций в текущем проекте, так и требования стилистики кода.

M>Ну вот видите, вот и вы доросли до моего понимания!

M>Я ведь не спорю, что делаю всё идеально — но я точно знаю, как НЕ идеально сделано существующее и это исправляю. Тем более, в инструменте, который использую уже бог знает сколько лет.
Ничего, не переживайте. С опытом придёт понимание — так же, как и владение клавиатурой.

M>Ув. прогеры! Пожалуйста, выскажите своё мнение по поводу этого интерфейса:

Вот, новый и улучшенный — теперь банановый!



Хочу сказать спасибо всем участникам — даже если ваше мнение было сильно отличным от моего, оно всё равно возымело эффект. В частности, быстрый выбор типа по F* — если бы не клаво-сяны, я бы не стал делать столь вычурный выбор.
Как и задумывалось, создание FK теперь обладает интеллектом — оно выводит факт ненужности человечества ссылаемую таблицу по имени колонки. Например, если колонка — SuperPersonID (или просто SuperPerson), найдётся таблица Person и на её ID создастся FK. Насколько я знаю, ещё ни один инструмент не предлагает такого удобства.
Типы — вы уже догадались, выбираются по функциональным клавишам (к чёрту хелп!). Причём в перечислении Keys их обнаружилось аж 24 , я сделал только для 12.
Шоткаты — введены. Типозависимые проперти вынесены в тэб и дизэйблятся, когда неприменимы. Коллэйт и прочая хрень — на тэбе 'etc'.
Если у вас всё ещё остался осадок или вы считаете, что некоторые элементы "могли бы быть и получше", не стесняйтесь — напишите. В конце концов, если на 100 мнений хотя бы 30 будет "против", это нельзя игнорировать (конечно, не в ущерб остальным 70-ти).

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

M>>Отвечаю в третий раз: не обременённый "интыпрайзом" прогер, тот же "автоматизатор бухгалтерии".
S>В третий раз спрашиваю: почему вы думаете, что этот прогер хорошо разбирается в различиях типов данных MS SQL?

Зачем спрашивать то, на что вы сами же даёте ответ?
S> Я не верю в создание таблиц людьми, не разбирающимися в вопросе.

Это инструмент сугубо для MS SQL Server. Но для его использования достаточно знаний хотя бы базовых SQL типов. Если кто-то не знает отличий, это не моя проблема.

S>Ок, я, кажется, вас понял. Вы действительно не владеете клавиатурой, поэтому баттхёрт.

А с какого перепоя я должен ею владеть?? Я вам не секретутка сколько набираю, столько и достаточно. Зато на мышке я — Паганини!

S>Кстати, путь Джобса, помимо всего прочего, включает фокус-группы и юзабилити-тестирование.

Чем я сейчас и занимаюсь — предварительное обсуждение удобства.

S> Кстати, вы обратили внимание, что риббон дружлюбнее к клавиатуре, чем тулбары+меню?

Как я мог обратить внимание, если пользую исключительно мышь?


S> "Вся винда" разработана для домохозяйки.
S>Среди программистов он значительно выше. В силу очевидной специфики их работы.

Это не означает ровным счётом ничего. Клавиатура — это общий инструмент, как нож. И только единицы могут его метать в цель закрытыми глазами. Вопрос: нафик мне эти "единицы", если подавляющее большинство юзеров тупо вбивают тексты двумя пальцами??


M>>Кроме того, не надо петь про слепые 10-пальцевые методы — едва ли трёх прогеров я видел в жизни, кто мог не глядя что-то там набирать.
S>Что я могу сказать — вам не повезло. Я лично в такое не верю.

Каждый волен выбирать заблуждения, которые ему нравятся. Но я же не могу принять вашу точку зрения, если мой прямой опыт и интуиция говорят об обратном? НЕ БЫВАЕТ много профессионалов, см. пример про нож. Вы лишь судите по миру с колокольни "а вот я могу — значит все умеют!".

S>А иметь я хочу текстовый редактор...

Не-не-не... это в ветку "лечимся сами" У меня совершенно однозначно будет GUI, но с помощью "mouse-disabled people".

S> с продвинутым автодополнением и коррекцией ошибок, который не слишком путается у меня под ногами, и учитывает контекстную информацию

Прекрасный пример для немерлового PEG'а! Подкиньте ребятам идею.

S>Ничего, не переживайте. С опытом придёт понимание — так же, как и владение клавиатурой.

эээ... я так и не понял, кто должен не переживать Я не переживаю — я пишу. Клавой владею ровно настолько, насколько требует моя профессия. Прыгать выше Ж — напрасная трата времени.
Между прочим, там уже готова новая версия, велкам оценить!

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

M>>Ув. прогеры! Пожалуйста, выскажите своё мнение по поводу этого интерфейса:

M>Вот, новый и улучшенный — теперь банановый!

M>

M>Хочу сказать спасибо всем участникам — даже если ваше мнение было сильно отличным от моего, оно всё равно возымело эффект. В частности, быстрый выбор типа по F* — если бы не клаво-сяны, я бы не стал делать столь вычурный выбор.
M>Как и задумывалось, создание FK теперь обладает интеллектом — оно выводит факт ненужности человечества ссылаемую таблицу по имени колонки. Например, если колонка — SuperPersonID (или просто SuperPerson), найдётся таблица Person и на её ID создастся FK. Насколько я знаю, ещё ни один инструмент не предлагает такого удобства.
M>Типы — вы уже догадались, выбираются по функциональным клавишам (к чёрту хелп!). Причём в перечислении Keys их обнаружилось аж 24 , я сделал только для 12.
M>Шоткаты — введены. Типозависимые проперти вынесены в тэб и дизэйблятся, когда неприменимы. Коллэйт и прочая хрень — на тэбе 'etc'.
M>Если у вас всё ещё остался осадок или вы считаете, что некоторые элементы "могли бы быть и получше", не стесняйтесь — напишите. В конце концов, если на 100 мнений хотя бы 30 будет "против", это нельзя игнорировать (конечно, не в ущерб остальным 70-ти).

1. Все эти F1-F12 ломают список и неудобно читать. Лучше уж их справа сделать
2. Unique по идее должен быть рядом с Nullable
3. Scale и size относятся к типу данных, но куда-то от него унесены
4. У FK непонятно что таблица, а что аттрибут таблицы.
5. Непонятно по какому принципу PK вынесет в таб, а FK отдельно красуется.
6. Зачем defaul и Name у FK оформлены как гиперссылки?
7. В целом не продуманы сценарии использования ни для мыши, ни для клавиатуры.

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

M>Это инструмент сугубо для MS SQL Server. Но для его использования достаточно знаний хотя бы базовых SQL типов. Если кто-то не знает отличий, это не моя проблема.
Ок, воля ваша.
S>>Ок, я, кажется, вас понял. Вы действительно не владеете клавиатурой, поэтому баттхёрт.
M>А с какого перепоя я должен ею владеть?? Я вам не секретутка сколько набираю, столько и достаточно. Зато на мышке я — Паганини!
Невозможно не научиться чему-то, занимаясь этим каждый день много лет.

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

S>> Кстати, вы обратили внимание, что риббон дружлюбнее к клавиатуре, чем тулбары+меню?
M>Как я мог обратить внимание, если пользую исключительно мышь?
Ну так вот — риббон заботливо сохранил впечатанные в спинной мозг рефлексы клавиатурных пользователей. Например, Alt+F-A всё ещё Save As. Это к вопросу о революционности UI.

M>Это не означает ровным счётом ничего. Клавиатура — это общий инструмент, как нож. И только единицы могут его метать в цель закрытыми глазами. Вопрос: нафик мне эти "единицы", если подавляющее большинство юзеров тупо вбивают тексты двумя пальцами??
Забавно, забавно. Вы, надо полагать, опираетесь на какие-то факты?
Давайте посмотрим в лицо реальности. "Большинство пользователей" показывают результат в 35 wpm и выше — это примерно 170 символов в минуту.
То есть три комбинации в секунду. Это вполне достаточный скилл для того, чтобы порвать любую мышь, т.к. клавиатурой не нужно никуда целиться.

M>Каждый волен выбирать заблуждения, которые ему нравятся. Но я же не могу принять вашу точку зрения, если мой прямой опыт и интуиция говорят об обратном? НЕ БЫВАЕТ много профессионалов, см. пример про нож. Вы лишь судите по миру с колокольни "а вот я могу — значит все умеют!".
Профессионал, простите, это выше 200 wpm, т.е. под 600 символов в минуту. Я же вам объясняю — многие вокруг меня умеют гораздо лучше, чем я.
Просто мышь настолько хуже в производительности программиста, что прямо даже непонятно, как такие программисты ухитряются существовать.

M>Не-не-не... это в ветку "лечимся сами" У меня совершенно однозначно будет GUI, но с помощью "mouse-disabled people".
Вы, наверное, что-то перепутали. Это не я к вам пришёл с просьбой разработать софт. Это вы пришли ко мне за советом, как сделать лучше.
S>> с продвинутым автодополнением и коррекцией ошибок, который не слишком путается у меня под ногами, и учитывает контекстную информацию
M>Прекрасный пример для немерлового PEG'а! Подкиньте ребятам идею.
Возможно. Я не настолько знаком с архитектурой современных текстовых редакторов, чтобы понять, где там место PEG, а где — базе знаний.
M>эээ... я так и не понял, кто должен не переживать Я не переживаю — я пишу. Клавой владею ровно настолько, насколько требует моя профессия. Прыгать выше Ж — напрасная трата времени.
Воля ваша.
M>Между прочим, там уже готова новая версия, велкам оценить!
Там уже оценили. Согласен с большинством комментариев.

Использование функциональных кнопок — спорный момент.
Вопросы про него:
1. Ваш список умеет навигироваться стандартным способом? Если я начну набирать "va" — он споцизионируется на VarChar? Обратите внимание, что в вашем случае для однозначного выбора типа достаточно двух нажатий.
2. Функциональные кнопки работают независимо от фокуса, или только пока фокус в списке?
Дальнейшие непонятности:
3. Что означают цветовые кодировки в списке типов?
4. По-прежнему невозможно догадаться, куда ведут ссылки Default и Name. Как нажать их с клавиатуры?

Здравствуйте, Аноним, Вы писали:

А>1. Все эти F1-F12 ломают список и неудобно читать. Лучше уж их справа сделать

Согласен. Сделал "абы было", на выравнивание нужно отдельно время.

А>2. Unique по идее должен быть рядом с Nullable

По идее чего?
Я шёл от частоты используемости, да и само unique — это не универсальное свойство — зависит от типа. Потому в Specific.

А>3. Scale и size относятся к типу данных, но куда-то от него унесены

Всё лежит рядом. Слева — тип, справа — доп. тюнинг. Выносить эти два поля я решил нецелесообразным, т.к. и они — не для всего, да и помимо них есть свойства. Вобщем, тэбы справа — это настройка типов слева.

А>4. У FK непонятно что таблица, а что аттрибут таблицы.

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

А>5. Непонятно по какому принципу PK вынесет в таб, а FK отдельно красуется.

По принципу частоты. FK — куча, PK — один на таблицу. Да и тот создаётся автоматом, зачем ему мусолить глаза?

А>6. Зачем defaul и Name у FK оформлены как гиперссылки?

См. изначальный пост: default очищает поле, Name — создаёт имя для FK.

А>7. В целом не продуманы сценарии использования ни для мыши, ни для клавиатуры.

Какие конкретно сценарии? Напишите шаги и покажите, что нелогичного.

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

S>Невозможно не научиться чему-то, занимаясь этим каждый день много лет.

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

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

В вашем тоне слово "слушать" звучит как "подпрыгнуть и быро сделать". Реальность такова, что видя даже обоснованные идеи, я буду долго и крепко думать, прежде чем воплощу в тырфейсе.

S>Просто мышь настолько хуже в производительности программиста, что прямо даже непонятно, как такие программисты ухитряются существовать.

Ещё больший вопрос в рентабельности программиста вызывает его узколобость с которой он преподносит личные навыки, начисто игнорируя окружение.
Это мне напоминает emacs/vi маньяков, противопоставляющих свои навыки работе простого редактора — им даже невдомёк, насколько узок их круг и насколько тупо/лениво/упрощённо остальное сообщество пользователей.
Спор "мышь vs клава" настолько туп, что я бы рекомендовал его даже не начинать — просто есть мышь и люди ею пользуются.
Кроме того, я бы не стал брать на работу прогера, который не способен удерживать в голове главные моменты проекта. А главное уже написано:

Понимаете, я не делаю СТРАШНЫЙ УСКОРИТЕЛЬ создания колонок! Я делаю УДОБНЫЙ тырфейс

M>>Не-не-не... это в ветку "лечимся сами" У меня совершенно однозначно будет GUI, но с помощью "mouse-disabled people".
S>Вы, наверное, что-то перепутали. Это не я к вам пришёл с просьбой разработать софт. Это вы пришли ко мне за советом, как сделать лучше.

Верно. Но сделать лучше ДЛЯ БОЛЬШИНСТВА. Клава — важный инструмент, но по удобству и простоте мышь стоит намного выше.

S>Использование функциональных кнопок — спорный момент.

эээ... ну и? Я не знаю, куда дальше развить сию мысль. Выбрал функциональные, потому что они — функциональные, бубёныть! И мне в этом диалоге нужны их функции.

S>Вопросы про него:
S>1. Ваш список умеет навигироваться стандартным способом?

Да. Там есть ошибка — я внёс [F*] в начало, сделаю в конце и всё будет ОК.

S> Обратите внимание, что в вашем случае для однозначного выбора типа достаточно двух нажатий.

Каких двух? Нажимаешь F* и всё, выбор сделан.

S>2. Функциональные кнопки работают независимо от фокуса, или только пока фокус в списке?

Независимо.

S>Дальнейшие непонятности:
S>3. Что означают цветовые кодировки в списке типов?

Личные предпочтения. В сеттингах опционально можно задать цвет для каждого типа, чтобы визуально легче было находить. Цвет в RRGGBB.

S>4. По-прежнему невозможно догадаться, куда ведут ссылки Default и Name. Как нажать их с клавиатуры?

Не надо догадываться — надо читать хинты (есть на обоих) или хелп. С клавы их нажать невозможно, именно поэтому не надо парить мозг юзеру и тупым, простым движением мыши сделать всю работу.

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

S>>Невозможно не научиться чему-то, занимаясь этим каждый день много лет.
M>Месье хочет намекнуть, что профессионал в готовке еды, вождении авто, завязывании шнурков и прочей бытовой ерунды?
Нет. Но с вашими утверждениями согласен. Все эти практикуемые ежедневно вещи приводят к неизбежному росту скиллов в тренируемой области.
Невозможно водить машину пять лет, проехать 80000 км, и так и не улучшит свои навыки по сравнению с первым уроком вождения.

M>Отнюдь. Тогда зачем выпежониваться и выставлять напоказ трепологические навыки, скатываясь на личность собеседника? Мои набирательные способности не вызывают у меня нареканий, почему же вам они — шило в жопе?
Я про ваши способности ничего сказать не могу. Это вы всё время рассказываете про то, как вам неудобна клавиатура. Делаю вывод, что невладение клавиатурой вызывает баттхёрт именно у вас.
M>Я по-прежнему настаиваю, что мыша является наиболее удобным и очевидным манипулятором, на который и затачивается GUI.
Это слишком общее утверждение, которое, очевидно, не может быть справедливо для всех сценариев и аудиторий.
Заметьте, что до сих пор все компьютеры комплектуются клавиатурой, и не все — мышью.
Бесклавиатурные новинки сосредоточены вовсе не на мыши, а на touch experience.

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

M>Ещё больший вопрос в рентабельности программиста вызывает его узколобость с которой он преподносит личные навыки, начисто игнорируя окружение.
Я говорю не с позиции личных навыков, а с позиции стандартов индустрии, выработанных годами и дорогостоящими исследованиями.

M>Это мне напоминает emacs/vi маньяков, противопоставляющих свои навыки работе простого редактора — им даже невдомёк, насколько узок их круг и насколько тупо/лениво/упрощённо остальное сообщество пользователей.
M>Спор "мышь vs клава" настолько туп, что я бы рекомендовал его даже не начинать — просто есть мышь и люди ею пользуются.
Можете и не начинать, какие проблемы. Это же ваше приложение. Меня можно вовсе не слушать — а попробовать внедрить инструмент вашей целевой аудитории и посмотреть на feedback. Я пытаюсь вас предостеречь от типичных ошибок, которые совершают начинающие UI девелоперы.

M>Верно. Но сделать лучше ДЛЯ БОЛЬШИНСТВА. Клава — важный инструмент, но по удобству и простоте мышь стоит намного выше.
По простоте — да. По удобству — нет. Зависит от кривой обучения. Поймите, для мыши добиться существенного прогресса в скорости нельзя. После первой недели использования пользователь перестаёт промахиваться из-за сдвига мыши нажатием кнопки, и дальнейшего роста скиллов практически не происходит.
Клавиатура позволяет дорасти от 15 слов в минуту до 35 без существенного напряжения; большинство должностей, где нужно набирать тексты требуюот от 50 слов в минуту; передовики производства выходят на мощности от 80 до 200.

S>>Использование функциональных кнопок — спорный момент.

M>эээ... ну и? Я не знаю, куда дальше развить сию мысль. Выбрал функциональные, потому что они — функциональные, бубёныть! И мне в этом диалоге нужны их функции.
Вам, как я понял, они как раз не нужны. Вы же мышью пользуетесь.

M>Да. Там есть ошибка — я внёс [F*] в начало, сделаю в конце и всё будет ОК.
Это хорошо.
S>> Обратите внимание, что в вашем случае для однозначного выбора типа достаточно двух нажатий.
M>Каких двух? Нажимаешь F* и всё, выбор сделан.
Нажимаешь nc — выбран nchar. Нажимаешь nu — выбран numeric. Это быстрее, чем нажать F*, т.к. в привычку слепого набора F не входят. А для самых частых типов вроде integer и varchar вообще достаточно одной буквы.

M>Независимо.
Это, наверное, хорошо. По крайней мере совпадает с user experience.
M>Личные предпочтения. В сеттингах опционально можно задать цвет для каждого типа, чтобы визуально легче было находить. Цвет в RRGGBB.
Сомневаюсь, что пользователи станут инвестировать своё время в настройки, которые позволяют им незначительно ускорить владение мышью, вместо того, чтобы научиться выбирать тип за одно-два нажатия кнопок. При этом при работе в команде настройки не разделяются, т.е. каждый должен настроить это под себя. Сел за машинку соседа — упс, там другой список типов, другие цвета. Таким образом вы гарантируете отсутствие повышения удобства при обучении продукту.

S>>4. По-прежнему невозможно догадаться, куда ведут ссылки Default и Name. Как нажать их с клавиатуры?
M>Не надо догадываться — надо читать хинты (есть на обоих) или хелп. С клавы их нажать невозможно, именно поэтому не надо парить мозг юзеру и тупым, простым движением мыши сделать всю работу.
Имхо, контролы, требующие наведения мыши и чтения хинтов — и есть "парить мозг юзеру". Вы делаете интерфейс для казуалов. Для них он должен быть понятен, это самое главное. Именно это для них удобство. Но вы можете думать по-другому. Рассудит нас только тестирование в поле.

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

M>Ещё больший вопрос в рентабельности программиста вызывает его узколобость с которой он преподносит личные навыки, начисто игнорируя окружение.
Вот прямо сейчас я сижу в Building 33. Выступает некий Saurabh Bhatia. Program Manager, то есть даже не программист.
Показывает, как писать приложения под Office 15 в Visual Studio 11.
Печатает текст раза в полтора быстрее чем я. Но нет, это лично мои навыки, которые я в силу узколобости преподношу, начисто игнорируя окружение.

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

M>Здравствуйте, Аноним, Вы писали:

А>>1. Все эти F1-F12 ломают список и неудобно читать. Лучше уж их справа сделать

M>Согласен. Сделал "абы было", на выравнивание нужно отдельно время.

А>>2. Unique по идее должен быть рядом с Nullable

M>По идее чего?
M>Я шёл от частоты используемости, да и само unique — это не универсальное свойство — зависит от типа. Потому в Specific.

По идее, что nullable и unique являются ограничителями недопустимых данных. Сюда же можно отнести и тип данных и размер.
Все эти параметры выставляются обычно при создании, а меняются очень редко и с оговорками на валидность записанных в таблицу данных.

А>>3. Scale и size относятся к типу данных, но куда-то от него унесены

M>Всё лежит рядом. Слева — тип, справа — доп. тюнинг. Выносить эти два поля я решил нецелесообразным, т.к. и они — не для всего, да и помимо них есть свойства. Вобщем, тэбы справа — это настройка типов слева.
Рядом, только в центр этого воткнут FK, а если вкладку другую открыть, то совсем не рядом.

А>>4. У FK непонятно что таблица, а что аттрибут таблицы.

M>Я не понял про какой атрибут речь, а вообще логика проста: сначала выбираем наибольшее — таблицу, потом уже поле в таблице. Это вызывает трудности?

Это я туплю и котлеты с мухами мешаю. Таблица = сущность. Поле/столбец = атрибут.
Трудностей не вызывает при условии, что изначально там вместо Person была подпись что-то типа [Select Table] и так же с выбором поля. Собственно, эта трудность может возникнуть только один раз, а потом привыкнешь

А>>5. Непонятно по какому принципу PK вынесет в таб, а FK отдельно красуется.

M>По принципу частоты. FK — куча, PK — один на таблицу. Да и тот создаётся автоматом, зачем ему мусолить глаза?

А вообще, разве PK относится к полю, а не к таблице? Особенно мне интересен составной PK.

А>>6. Зачем defaul и Name у FK оформлены как гиперссылки?

M>См. изначальный пост: default очищает поле, Name — создаёт имя для FK.

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

А>>7. В целом не продуманы сценарии использования ни для мыши, ни для клавиатуры.

M>Какие конкретно сценарии? Напишите шаги и покажите, что нелогичного.

Пример сценария. Создание новой колонки таблицы.
Пользователь определился, что ему нужно поле с именем Name, типом varchar размером в 50 и хочет добавить это самое поле.
Клавиатура (делаю предположение из расположения элементов, может там табуляция и другая):
Попадаем в список выбора типа данных, понимаем, что не имя поля сначала вбиваем и настраиваемся настраивать собственно тип хранимых данных. Выбрали благополучно varchar, жмём таб и тут попадаем на ввод имени столбца (не ввели до конца одну информацию и приходится уже вводить другую). Ну, да ладно. Ввели имя, переходим к следующему элементу, а там необязательный параметр default, который должен подходить под ограничения, которые мы еще собственно и не ввели до конца. пропускаем элемент и идём дальше. Попадаем на галочку для FK, потом на имя таблицы, потом на имя поля, потом на TabControl, всё это благополучно пропускаем и попадаем наконец на галочку для ввода Size, включаем, потом выставляем нужное значение 50.
Мышка:
Неудобства примерно такие же, как и у клавиатуры, но они уже в плане бегания глазами по экрану в поисках нужного элемента. Тут уже пользователь будет выбирать последовательность ввода, но если порядок имя поля -> тип данных может быть у каждого разный, то после varchar, большинство людей захочет таки определить какого размера он собственно нужен.

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

S>Невозможно водить машину пять лет, проехать 80000 км, и так и не улучшит свои навыки по сравнению с первым уроком вождения.

Разве я сказал, что медленно набираю? Я сказал, что мышь — удобнее.

S>Это слишком общее утверждение, которое, очевидно, не может быть справедливо для всех сценариев и аудиторий.

Очевидно, Кэп! Так я и не пытаюсь. Для такого сложного ГУЯ как колонка основной манипулятор — мышь, клава требуется в единичных случаях — задать имя или ограничить varchar. Смешно, но даже scale я использовал раза два за всю жизнь.

M>>Ещё больший вопрос в рентабельности программиста вызывает его узколобость с которой он преподносит личные навыки, начисто игнорируя окружение.
S>Я говорю не с позиции личных навыков, а с позиции стандартов индустрии, выработанных годами и дорогостоящими исследованиями.

Это вдвойне забавно слышать. Вот сидишь ты, Синклер, за клавиатурой и вещаешь мне вещи, о которых я не подозревал целую жизнь — оказывается, все 20 лет за компом я провёл ... эээ... не с той стороны? Не теми руками? Не с той мышью? Понимаешь, мои руки держат мышь и мне это чертовски удобно. И тут кто-то с той стороны экрана мне объясняет как надо правильно есть бутерброд! Самому не смешно? Стандарты, исследования... струйня все эти твои исследования, если даже такой усреднённый прогер как я в них не вписывается. Как не вписывается куча юзеров, которых я наблюдал — они не жмут F5 для рефреша, а топчут тулбар. Не набирают Ctrl+X, а вызывают контекстное меню(!) и в нём ищут строчку "Cut". Да, смотрится дико и неэффективно, но... им это УДОБНО! И я даже не пытаюсь это обосновывать/оспаривать (выставляя свои навыки слепой печати) — я принимаю это как порядок вещей и ориентирую тырфейс на мышь.

S>Поймите, для мыши добиться существенного прогресса в скорости нельзя.

А зачем он нужен? Взял в руку, води да щёлкай! Откуда здесь взяться проблемам?

S>Клавиатура позволяет дорасти от 15 слов в минуту до 35

ЧТО вы собрались вводить на форме с 10 элементами? "Войну и мир" штоле? Кроме того, форма — это не текст, для навигации кейбардой нужны ТАБ, ЕНТЕР, ПРОБЕЛ, стрелки... нажимаь такие клавиши быстро — нет необходимости, да и ошибок можно наляпать. Мышь же — безотказный манипулятор, где курсор — там и срабатывает.

M>>эээ... ну и? Я не знаю, куда дальше развить сию мысль. Выбрал функциональные, потому что они — функциональные, бубёныть! И мне в этом диалоге нужны их функции.
S>Вам, как я понял, они как раз не нужны. Вы же мышью пользуетесь.

Вот, для вас стараюсь может и сам буду юзать. В простейших случаях оно так и будет: ввод имени, F*, Enter — всё, создано.

M>>Каких двух? Нажимаешь F* и всё, выбор сделан.
S>Это быстрее, чем нажать F*, т.к. в привычку слепого набора F не входят.

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

M>>Личные предпочтения. В сеттингах опционально можно задать цвет...
S>Сомневаюсь, что пользователи станут инвестировать своё время в настройки

Не колышет абсолютно. Моя задача — дать фичу, захотят — всегда есть возможность настройки.

S> Сел за машинку соседа — упс, там другой список типов, другие цвета. Таким образом вы гарантируете отсутствие повышения удобства при обучении продукту.

Не надо садиться за машинку соседа, ПК — индивидуальная вещь, как зубная щётка. И когда ты за неё сядешь, ВСЁ в ней будет "не так" — от курсора до цвета окон. Поэтому... правильно — БЕРЁМ МЫШЬ и делаем всё визуально.

M>>Не надо догадываться — надо читать хинты
S>Имхо, контролы, требующие наведения мыши и чтения хинтов — и есть "парить мозг юзеру".

Не надо наводить тень на плетень! ОДИН раз навёл, запомнил, дальше используешь не привлекая мозг вообще. Это не "казуальный" инструмент, это ЕЖЕДНЕВНЫЙ. И как кое-кем было сказано, "чем больше работаешь, тем больше навык".

Здравствуйте, Аноним, Вы писали:

А>По идее, что nullable и unique являются ограничителями недопустимых данных. Сюда же можно отнести и тип данных и размер.

Таким макаром можно ВСЁ засунуть на одну большую форму. Зачем? Я смотрю на то, что сам часто использую. Тот же collate мне вообще в пень не упёрся, а это тоже "ограничителями недопустимых данных".

А>Все эти параметры выставляются обычно при создании, а меняются очень редко и с оговорками на валидность записанных в таблицу данных.

Вот именно, что меняются — редко, а задаются — часто! Потому и стоят в начале.

M>>Вобщем, тэбы справа — это настройка типов слева.
А>Рядом, только в центр этого воткнут FK, а если вкладку другую открыть, то совсем не рядом.

Ну и чему это мешает? Вы хотите возле каждого типа привесить десяток модификаторов типа?

А>Это я туплю и котлеты с мухами мешаю. Таблица = сущность. Поле/столбец = атрибут.
А>Трудностей не вызывает при условии, что изначально там вместо Person была подпись что-то типа [Select Table]

Для чайников будет документация.

А>А вообще, разве PK относится к полю, а не к таблице? Особенно мне интересен составной PK.

Философия принадлежности PK меня пока не заботит Хуже того — составные PK я даже не дам создавать.

M>>См. изначальный пост: default очищает поле, Name — создаёт имя для FK.

А>Это совсем непонятно и оформление не соответствует событию.

До возникновения HTML вы и понятия не имели, что делать с синим подчёркнутым текстом. Ничего — научились! Тут тот же принцип. Причём тыкать в линки как раз придётся оч редко — не заостряйте на них внимание.

А> Выглядит как гиперссылка, значит должно что-то открывать и куда-то переходить, а тут поведение кнопки.

Кнопка Save тоже выглядит как дискетка, хотя оные уже лет 15 как не существуют. Ничего, не вызывает когнитивный диссонанс?

А>Пример сценария. Создание новой колонки таблицы.

Всё катастрофически запутано и высосано из пальца. Особенно это:
А>Мышка: Неудобства примерно такие же...

Итак, как всё происходит на самом деле: кликаем на создание колонки, появляется мой супердиалог
1. Фокус уже стоит на поле Name — вводим.
2. Мышой ли, функциональными ли, выбираем тип — один клик в обоих случаях. Тырфейс внизу справа тут же высвечивает поля, допустимые для данного типа (size, unique, etc).
3. Если удовлетворён, жмёшь OK — работа сделана.
Нет — лазаешь TAB'ом (если мазохист) или мышкой (если нормальный) и докликиваешь нужное.
КАК ПРАВИЛО самое частоиспользуемое уже видно, лазить по тэбам смысла нет.
И главное — всё делается одной рукой, на расслабоне — мы никуда не торопимся, все контролы видны, назначение — очевидно.

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

M>Как не вписывается куча юзеров, которых я наблюдал — они не жмут F5 для рефреша, а топчут тулбар. Не набирают Ctrl+X, а вызывают контекстное меню(!) и в нём ищут строчку "Cut". Да, смотрится дико и неэффективно, но... им это УДОБНО! И я даже не пытаюсь это обосновывать/оспаривать (выставляя свои навыки слепой печати) — я принимаю это как порядок вещей и ориентирую тырфейс на мышь.

Давно я не видел таких людей. Контекстные менюшки с пунктами "cut/copy/paste", конечно, делаются, но и клавиатурными комбинациями дублируются для нормальных людей.

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

А>> Выглядит как гиперссылка, значит должно что-то открывать и куда-то переходить, а тут поведение кнопки.
M>Кнопка Save тоже выглядит как дискетка, хотя оные уже лет 15 как не существуют. Ничего, не вызывает когнитивный диссонанс?
Не вызывает, зато гиперссылка действительно вызывает непонимание. По-моему, большинство рекомендаций Sinclair справедливы.

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

M>куча юзеров, которых я наблюдал — они не жмут F5 для рефреша, а топчут тулбар. Не набирают Ctrl+X, а вызывают контекстное меню(!) и в нём ищут строчку "Cut".

Эти люди не должны допускаться к модификации схем баз данных.

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

M>Здравствуйте, Аноним, Вы писали:


M>До возникновения HTML вы и понятия не имели, что делать с синим подчёркнутым текстом. Ничего — научились! Тут тот же принцип. Причём тыкать в линки как раз придётся оч редко — не заостряйте на них внимание.
M>Кнопка Save тоже выглядит как дискетка, хотя оные уже лет 15 как не существуют. Ничего, не вызывает когнитивный диссонанс?
Поймите, что вы работаете не в вакуум. Неважно, что было до изобретения HTML. Вот, скажем, мышку вообще изобрёл Иван Сазерленд, и очень недавно по галактическим масштабам. Может быть, мы под этим предлогом откажемся от поддержки мыши? Или будем её использовать нестандартным образом?

У пользователей есть наработанные рефлексы. Они подробно описаны в любом UX гайдлайне по платформе, для которой вы разрабатываете. Нарушать эти гайдлайны — плохая идея. Синий подчёркнутый текст прочно ассоциируется с определённым поведением, в выработку этих ассоциаций пользователь вложил тысячи часов использования всех приложений, кроме вашего. И дискетка сейчас ассоциируется не с дискеткой, а с командой Save. Поэтому придавать дискетке в UI какое-то другое значение — тоже плохая идея.

M>Итак, как всё происходит на самом деле: кликаем на создание колонки, появляется мой супердиалог
M>1. Фокус уже стоит на поле Name — вводим.
M>2. Мышой ли, функциональными ли, выбираем тип — один клик в обоих случаях. Тырфейс внизу справа тут же высвечивает поля, допустимые для данного типа (size, unique, etc).
M>3. Если удовлетворён, жмёшь OK — работа сделана.
M> Нет — лазаешь TAB'ом (если мазохист) или мышкой (если нормальный) и докликиваешь нужное.
То, что Tab-ом у вас может пользоваться только мазохист, это не вина таба. Это ваша личная вина, за то, что вы нарушили конвенции, к которым пользователь привык. Например, он привык к тому, что порядок заполнения формы совпадает с порядком таб-ордера, и этот порядок — слева-направо, сверху-вниз. Почитайте что-нибудь по usability, про то, в каком порядке пользователь сканирует интерфейс глазами.

M>КАК ПРАВИЛО самое частоиспользуемое уже видно, лазить по тэбам смысла нет.
M>И главное — всё делается одной рукой, на расслабоне — мы никуда не торопимся, все контролы видны, назначение — очевидно.
Назначение очевидно только для того, кто придумал этот интерфейс. Для всех остальных этот интерфейс — китайская грамота. Весь смысл UX гайдлайнов — в том, чтобы пользователь мог вырабатывать навыки, совместимые между разными приложениями. Запоминать, что в одном приложении Ctrl-X — это Cut, а в другом — Close, никто не будет. Это лишняя модальность.
Запоминать, что в одном приложении ссылка — это ссылка, в в другом — кнопка, легче, но тоже требует усилий. Причём совершенно непонятно, ради чего. Для того же имени FK нужно просто всегда генерировать имя в соответствии со встроенными правилами, и автоматически изменять его при смене настроек, от котороых он сгенерился. Кроме случая, когда пользователь руками ввёл какое-то значение — тогда его нужно сохранять, из уважения к потраченным пользователем усилиям.

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

F>Давно я не видел таких людей.

Так в том и прикол, что какой бы ты ни был умный и программирующий, в реальности найдётся два десятка "программастов", которые активно юзают мышь. И я их понимаю — незачем тренироваться в вещах, которые не являются необходимыми для работы.

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

C>Эти люди не должны допускаться к модификации схем баз данных.

Я не прокурор, мне важно, чтобы было удобно.

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

S> Синий подчёркнутый текст прочно ассоциируется с определённым поведением, в выработку этих ассоциаций пользователь вложил тысячи часов использования всех приложений, кроме вашего.

Я согласен с тем, что обычный юзер будет долго тупить над "нестандартной ссылкой". Но прогер (особ. русский) тем и отличается, что способен "методом тыка" освоить любую приблуду. А её "нестандартность" — это вопрос привычки.
Конечно, в позиции мелкософта хорошо сидеть и умно разводить руками над своими "руководствами" (придавая сами себе солидность тем, что эти руководства пишут). Только возникает два смешных ньюанса:
1. ПОЧЕМУ тогда в самой же "законодательнице юзабилити" такие похабные приложения? Разве они не проходят всестороннее тестирование? Разве у них не сидят дотошные очкарики, тыкающие в "руководство"? Как может фирма, выпускающая эти "подобия стандартов", сама же их нарушать?
2. А кто сказал, что эти "рекомендации" вообще правильные?? Уже то, что самих сценариев использования — МИЛЛИОНЫ, просто смешно думать, что "одна на всё" рекомендация способна их покрыть!

В принципе, я тоже поддерживаю мнение, что желательно всё делать стандартным. Но надо так же понимать, что юзер юзеру рознь. В моём случае ЦА достаточно умная, чтобы знать что следует за каждым кликом.
Если отказываться от ссылок, значит придётся либо делать вместо них кнопку, либо дополнительную кнопку справа от поля. Более очевидно, но менее удобно, т.к. сначала нужно глазами пробежать по бесполезной надписи, затем поле ввода, и только затем — маленький квадратик "сделай мне чудо!". Вопрос: будем жрать кактус, но зато по фэншую? Альтернатив-то я не вижу! (таких, которые бы затмевали по удобству ссылку)


M>> Нет — лазаешь TAB'ом (если мазохист) или мышкой (если нормальный) и докликиваешь нужное.
S>То, что Tab-ом у вас может пользоваться только мазохист, это не вина таба. Это ваша личная вина

Не надо инсинуаций! Достаточно поглядеть на форму, чтобы понять — это вам не телефон вбить! В смысле, что создаётся достаточно сложная структура и будь ты хоть сенсей клавы, НЕВОЗМОЖНО идеально подобрать проход по всем элементам, чтобы они и не мусолили глаза, и не занимали целую простыню, и были хорошо узнаваемы/выделяемы, и не лезли там, где неприменимы, и быстро выбирались, и т.п. Странно, что вы, товарищ Синклер, это не понимаете.
И опять повторюсь: 1) Поддержка клавы — сугубо опциональная, тырфейс в основном рассчитан на мышь. 2) Я не собираюсь делать доступ ко всем элементам в одно нажатие, это глупо — элементов слишком много, чтобы держать в голове все шоткаты или прыгать по ВСЕМ НИМ tab'ом. Эту мысль прочитать два раза и запомнить. СТРУКТУРА — СЛОЖНАЯ.
Хотя... если вы считаете, что матумба настолько несуразен в своих попытках, всегда есть возможность объективно доказать, что вы не только способны говорить умные вещи (это-то всегда легко), но и воплощать их в дело (чем, собсно, и отличаются настоящие профессионалы). Набросайте хотя бы на листке как может выглядеть создание колонки (с учётом всего сказанного выше) и скан в студию. Уж если мой тырфейс окажется намного хуже, клянусь — я не буду за него цепляться и сделаю как советуют мудрые саксаулы. Или аксакалы.

S> Например, он привык к тому, что порядок заполнения формы совпадает с порядком таб-ордера

Вот-вот! ДЛЯ ПРОСТЫХ форм а-ля "имя-фамилия-мэйл".

S>Запоминать, что в одном приложении ссылка — это ссылка, в в другом — кнопка, легче, но тоже требует усилий.

Что забавно, вот это "в одном приложении ссылка — это ссылка" означает практически единственную вещь — браузер. Ну будет в моём окошке весьма редко нужная ссылка — что страшного-то? Или рассуждать — все умные, а запомнить, что ссылка генерит имя — всё, тупим как Джамшут? Лицемерие получается...

S> Причём совершенно непонятно, ради чего. Для того же имени FK нужно просто всегда генерировать имя в соответствии со встроенными правилами, и автоматически изменять его при смене настроек, от котороых он сгенерился. Кроме случая, когда пользователь руками ввёл какое-то значение — тогда его нужно сохранять, из уважения к потраченным пользователем усилиям.

На этот умный сценарий (который, кстати, воплощён) я отпарирую элементарным человеческим фактором: набрал имя поля, создал FK — имя сгенерилось автоматом. Потом переименовал поле, а FK уже трогать нельзя — ТАМ ВБИТО! Но вбито-то не то — нужна дёргалка, генерящая новое имя. Так что как ни прыгай, ссылка ли, кнопка ли, нужны.

Вобщем, я не такой ярый сторонник ссылки, как может показаться но если у вас нет ей альтернатив, это решение можно считать "лучшим из худшего".

Здравствуйте, matumba, Вы писали:
M>1. ПОЧЕМУ тогда в самой же "законодательнице юзабилити" такие похабные приложения? Разве они не проходят всестороннее тестирование? Разве у них не сидят дотошные очкарики, тыкающие в "руководство"? Как может фирма, выпускающая эти "подобия стандартов", сама же их нарушать?
Очевидно, потому, что не все приложения успевают обновлять в соответствии со стандартами. Похабных приложений, кстати, у них не так уж и много.
M>2. А кто сказал, что эти "рекомендации" вообще правильные?? Уже то, что самих сценариев использования — МИЛЛИОНЫ, просто смешно думать, что "одна на всё" рекомендация способна их покрыть!
А вы, кстати, вообще читали сами эти "подобия стандартов"? Дело не в том, что они правильные или неправильные. Это как выбор правостороннего либо левостороннего движения.

M>В принципе, я тоже поддерживаю мнение, что желательно всё делать стандартным. Но надо так же понимать, что юзер юзеру рознь. В моём случае ЦА достаточно умная, чтобы знать что следует за каждым кликом.
Вы пытаетесь сделать "удобный" инструмент. Это значит, что нужно заботиться о своей аудитории, а не заставлять её выучивать ваше нестандартное приложение.

M>Если отказываться от ссылок, значит придётся либо делать вместо них кнопку, либо дополнительную кнопку справа от поля. Более очевидно, но менее удобно, т.к. сначала нужно глазами пробежать по бесполезной надписи, затем поле ввода, и только затем — маленький квадратик "сделай мне чудо!". Вопрос: будем жрать кактус, но зато по фэншую? Альтернатив-то я не вижу! (таких, которые бы затмевали по удобству ссылку)
Я вам их привёл.

M>Не надо инсинуаций! Достаточно поглядеть на форму, чтобы понять — это вам не телефон вбить! В смысле, что создаётся достаточно сложная структура и будь ты хоть сенсей клавы, НЕВОЗМОЖНО идеально подобрать проход по всем элементам, чтобы они и не мусолили глаза, и не занимали целую простыню, и были хорошо узнаваемы/выделяемы, и не лезли там, где неприменимы, и быстро выбирались, и т.п. Странно, что вы, товарищ Синклер, это не понимаете.
Я-то как раз понимаю, что вы решаете не очень сложную задачу. И таб ордер подобрать так, чтобы вообще не надо было отрывать руки от клавиатуры, и чтобы ничего не мусолило глаза, не представляет особенной проблемы. Просто вы исходите из набора неверных предположений, поэтому всё у вас вот так, как оно есть.

M>Хотя... если вы считаете, что матумба настолько несуразен в своих попытках, всегда есть возможность объективно доказать, что вы не только способны говорить умные вещи (это-то всегда легко), но и воплощать их в дело (чем, собсно, и отличаются настоящие профессионалы). Набросайте хотя бы на листке как может выглядеть создание колонки (с учётом всего сказанного выше) и скан в студию. Уж если мой тырфейс окажется намного хуже, клянусь — я не буду за него цепляться и сделаю как советуют мудрые саксаулы. Или аксакалы.
Знаете, я вам не верю.

M>Вот-вот! ДЛЯ ПРОСТЫХ форм а-ля "имя-фамилия-мэйл".
Для любых форм.
S>>Запоминать, что в одном приложении ссылка — это ссылка, в в другом — кнопка, легче, но тоже требует усилий.
M>Что забавно, вот это "в одном приложении ссылка — это ссылка" означает практически единственную вещь — браузер.
Нет. Все остальные приложения тоже используют ссылки для ссылок, а не для того, чтобы изобразить из них кнопки.

S>> Причём совершенно непонятно, ради чего. Для того же имени FK нужно просто всегда генерировать имя в соответствии со встроенными правилами, и автоматически изменять его при смене настроек, от котороых он сгенерился. Кроме случая, когда пользователь руками ввёл какое-то значение — тогда его нужно сохранять, из уважения к потраченным пользователем усилиям.

M>На этот умный сценарий (который, кстати, воплощён) я отпарирую элементарным человеческим фактором: набрал имя поля, создал FK — имя сгенерилось автоматом. Потом переименовал поле, а FK уже трогать нельзя — ТАМ ВБИТО! Но вбито-то не то — нужна дёргалка, генерящая новое имя. Так что как ни прыгай, ссылка ли, кнопка ли, нужны.
Я же вам написал — автогенерённые FK нужно менять автоматически при переименовании поля. Это стандартная практика в диалогах с автозаполнением. Что именно вам непонятно?

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

S>Здравствуйте, matumba, Вы писали:
M>>1. ПОЧЕМУ тогда в самой же "законодательнице юзабилити" такие похабные приложения?
S>Очевидно, потому, что не все приложения успевают обновлять в соответствии со стандартами.

Что зн. обновлять?? Их ПИСАТЬ надо в соответствии со своими же стандартами! Прежде, чем на экране появится хоть одна кнопка, должен быть обсуждён хотя бы бумажный прототип. Очевидно, что если бы они вообще обсуждались, мы бы никогда не увидели их лажовеньких тырфейсов. Тот же "древовидный" Explorer — полное ублюдство по сравнению с Windows Commander/FAR.

M>>2. А кто сказал, что эти "рекомендации" вообще правильные?? Уже то, что самих сценариев использования — МИЛЛИОНЫ, просто смешно думать, что "одна на всё" рекомендация способна их покрыть!
S>А вы, кстати, вообще читали сами эти "подобия стандартов"? Дело не в том, что они правильные или неправильные. Это как выбор правостороннего либо левостороннего движения.

Что-то читал, но по-моему уснул. Мнение мелкософта о применении контролов мне интересно не больше мнения индусов о конце света — просто дополнительный источник для личных размышлений. Были бы ВСЕ их тырфейсы идеальны, я бы точно выучил весь их "гайд" по юзабилити.

S>Вы пытаетесь сделать "удобный" инструмент. Это значит, что нужно заботиться о своей аудитории, а не заставлять её выучивать ваше нестандартное приложение.

В данном случае вы раздуваете из мухи слона. Линки, как я уже говорил, будут использоваться крайне редко — не вижу смысла препираться из-за двух контролов, когда вся эта форма чуть ли не 5% будущего приложения. Всё остальное там вполне узнаваемо, а "нестандартного" — разве что выбор типа, но я это уже аргументировал — так удобнее.


S> Альтернатив-то я не вижу! (таких, которые бы затмевали по удобству ссылку)
S>Я вам их привёл.

Процитировать можно? Не помню ни единого предложения, только критика "ссылки никуда не ведут".

S>Знаете, я вам не верю.

Прекрасный метод спора. С одной стороны — мой полностью готовый интерфейс, с другой — словоблудие критика. Ну и что мне сравнивать-то? Из критики колонки не слепишь, так что нам либо нужно сравнить два тырфейса (с убедительным преимуществом вашей раскладки), либо я остановлюсь на своём варианте и проверю его на практике.

S>Я же вам написал — автогенерённые FK нужно менять автоматически при переименовании поля. Это стандартная практика в диалогах с автозаполнением. Что именно вам непонятно?

Непонятно, кто вам дал право менять имя FK, если юзер меняет название колонки. Ведь правило именования — это не требование, это рекомендация. Именование вообще может вырезать часть имени колонки!
Я предпочитаю, чтобы юзер лишний раз кликнул — он подтверждает свои намерения и хочет новое имя взамен старого.

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

S>> Альтернатив-то я не вижу! (таких, которые бы затмевали по удобству ссылку)
S>>Я вам их привёл.
M>Процитировать можно? Не помню ни единого предложения, только критика "ссылки никуда не ведут".

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

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

M>Что зн. обновлять?? Их ПИСАТЬ надо в соответствии со своими же стандартами! Прежде, чем на экране появится хоть одна кнопка, должен быть обсуждён хотя бы бумажный прототип. Очевидно, что если бы они вообще обсуждались, мы бы никогда не увидели их лажовеньких тырфейсов. Тот же "древовидный" Explorer — полное ублюдство по сравнению с Windows Commander/FAR.
Ясно. То есть вы не только о гайдлайнах не имеете представление, но и о том, как устроен процесс разработки UI в майкрософт. При этом берётесь их осуждать.
Я вас разочарую: при таком подходе вы никогда не научитесь проектировать UI.

M>Процитировать можно? Не помню ни единого предложения, только критика "ссылки никуда не ведут".
Убрать ссылки вообще. Они не нужны.

M>Непонятно, кто вам дал право менять имя FK, если юзер меняет название колонки. Ведь правило именования — это не требование, это рекомендация. Именование вообще может вырезать часть имени колонки!
Внимательнее читайте. Если имя FK было автоматически сгенерировано — то при изменениях мы имеем полное право его автоматически же перегенерировать. Если нет — оставляем таким, как есть. Если пользователю в прошлый раз не понравилось то, что ему сгенерировали, то ему и в следующий раз не понравится.
M>Я предпочитаю, чтобы юзер лишний раз кликнул — он подтверждает свои намерения и хочет новое имя взамен старого.
Я уже понял, что вы предпочитаете, чтобы юзер лишний раз кликнул. И не один раз.

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

S>Ясно. То есть вы не только о гайдлайнах не имеете представление...

Синклер, вы не еврей случаем? Ваша нить спора постоянно заканчивается персоной собеседника, причём не в лучшем свете. Такое ощущение, что вы один здесь — самый умный/хитрый, а остальные — так, пришли вам помолиться.
Другие не дурее вас, уж какие-никакие тексты по юзабилити читали (иначе никто бы не понял, зачем вообще есть форум "юзабилити"). Отсюда, налицо ваша поганая методология закидывания говном собеседника, хотя люди сюда приходят за советами, а не оценки их личной лени/глупости/недальновидности. Прекращайте эти штучки, они неконструктивны как минимум.

S>Убрать ссылки вообще. Они не нужны.

Это не выход, это отмазка в стиле "давайте не есть картошку, потому что её чистить надо". Если с очисткой Default ещё можно смириться, то генерация FK — необходима, а делать это кнопкой — можно, но это будет ни на грош не удобнее/интуитивнее линка — юзеру придётся показать хинт "Автогенерация имени для FK", чтобы он понял её назначение. Ещё один довод в пользу линка: он находится слева, т.е. сразу в зоне внимания юзера. Контролы справа просто выпадают из внимания, туда можно клать совсем уж "ненужные" вещи.

M>>Непонятно, кто вам дал право менять имя FK, если юзер меняет название колонки. Ведь правило именования — это не требование, это рекомендация. Именование вообще может вырезать часть имени колонки!
S>Внимательнее читайте. Если имя FK было автоматически сгенерировано — то при изменениях мы имеем полное право его автоматически же перегенерировать. Если нет — оставляем таким, как есть. Если пользователю в прошлый раз не понравилось то, что ему сгенерировали, то ему и в следующий раз не понравится.

Ну и в чём здесь удобство?? Я сделал FK, чуть изменил автосгенерённое имя, потом сменил имя колонки или ссылаемую таблицу, а дальше что? Вспоминать добрым словом программиста? А у меня один клик — всё, новое имя сделано и ровно тогда, когда оно понадобилось юзеру (помимо того, что оно в первый раз автогенерится)

M>>Я предпочитаю, чтобы юзер лишний раз кликнул — он подтверждает свои намерения и хочет новое имя взамен старого.
S>Я уже понял, что вы предпочитаете, чтобы юзер лишний раз кликнул. И не один раз.

Чушь, не стоило напрягаться ради этих инсинуаций.

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

F>Сделай ссылки лейблами, а рядом помести кнопки с нужными названиями, по которым будет понятно, что произойдет после клика.

В принципе, достаточно распространён интерфейс примерно такого вида:

         ┌───────────────┐
Default: │              ⌫│ (U+232B ERASE TO THE LEFT)
         └───────────────┘

Иконка удаления на правом краю поля ввода ясно даёт понять, что произойдёт при клике в неё.

Для автогенерации можно тоже нарисовать какую-нибудь понятную иконку:

      ┌───────────────┐
Name: │              ⚡│ (U+26A1 HIGH VOLTAGE SIGN)
      └───────────────┘