Ув. прогеры! Пожалуйста, выскажите своё мнение по поводу этого интерфейса:
Это моя попытка создать удобный инструмент для управления таблицами (в MS SQL, многобазовость вряд ли предвидится). На картинке — форма редактирования колонки таблицы. Чтобы сразу не хотелось кинуться калом, объясню принципы, которыми я руководствовался:
1. 99% действий за 1% кликов.
2. Самое нужное и часто используемое — в начале.
3. Экзотика — в наименьшем приоритете (а-ля "а вот мы часто пользуемся гео-данными!"). Некоторых функций вообще может не быть, будут добавляться только при большом спросе.
Это часть будущего проекта а-ля "EMS MS SQL Manager", но сильно упрощённого (интерфейсно) для быстрого решения наиболее частых задач, так что ваша помощь будет неоценима.
Спасибо!
PS
Чекбокс на Size — сделать поле maximum size. Линк Default — очистить поле.
Я бы сделал DropDown (именно DropDown, а не DropDownList) вверху и динамически появляющийся (UserControl?) набор своств под ним. Сейчас у вас большинство ЭУ использованы не по назвачению.
Name первым (слева сверху). Type радиогруппой (и не обязательно в 1 столбец) — типов же не бывает одновременно несколько. M>Чекбокс на Size — сделать поле maximum size. Линк Default — очистить поле.
Слишком загадочно. Чекбокс — это вкл/выкл, линк — куда-то перейти. Специфические действия лучше делать кнопками с иконкой справа от едита.
Здравствуйте, Osaka, Вы писали:
O>Name первым (слева сверху).
Тут было соображение экономии места: типов может быть немало, поэтому под них желательно отвести максимальный вертикальный размер. Форма — часто используемая, поэтому вряд ли мы услышим "оопс! где же тут поле 'name'?!" , т.е. вопрос привычки.
O> Type радиогруппой (и не обязательно в 1 столбец) — типов же не бывает одновременно несколько.
Радиогруппа имеет смысл на 3-5 элементах. Двадцать элементов в 3-5 столбцах запутают любого. Плюс, как вы заметили, типы не идут тупо по алфавиту — вычленены наиболее общеупотребительные (есессно, я дам возможность менять порядок). Может даже имеет смысл их давать разным цветом (строковые — синие, цифровые — зелёные и т.п.). И здесь ЛистБокс одновыбирабельный.
M>>Чекбокс на Size — сделать поле maximum size. Линк Default — очистить поле. O>Слишком загадочно.
Matumba> "Форма — часто используемая".
Прицел идёт на ежедневное ковыряние, а не исследования "ну чо, как тут у вас это делается?". Чекбокс максимального размера именно "включает максимальный размер" и запрещает его указывать числом. Вопрос привычки.
O> линк — куда-то перейти. Специфические действия лучше делать кнопками с иконкой справа от едита.
Экономия места. Лишние элементы замусоривают тырфейс, а линк — некий аналог "текстовой кнопки", только без бордюра. Опять же, вопрос привычки.
Мне нравится, что вы подходите к тырфейсу "классически", т.е. как бы подошёл неподготовленный человек. Но видимо мне надо было сделать замечание, что это не тулза для чайников "ща я тут нафотошоплю!" — это ежедневный инструмент профессионала, т.е. который знает что он делает. Плюс, опять обращу внимание на принцип построения: минимум кликов, максимум пользы, самое частоделаемое должно быть самым быстроделаемым:
1. Набрали имя
2. клик на типе
3. (уточнили размер для строковых)
4. УЖЕ МОЖНО ЖАТЬ [OK]!
Re: Просьба оценить форму для колонок таблицы.
От:
Аноним
Дата:
08.05.12 09:48
Оценка:
Здравствуйте, 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 клика, такой вариант уже быстрее. И это не считая позиционирования мышки и поиск типа в списке. А ведь вам еще руку и обратно на клавиатуру придется переносить после закрытия окна (или выбора типа).
Выскажусь как представитель якобы целевой аудитории. То есть разработчик БД, постоянно занимающийся "управлением таблицами" и "редактированием колонок". :) Полностью согласен с 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.
Здравствуйте, 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, проблема не в том, чтобы ускорить набивку, а в том, чтобы разобраться, куда нажимать.
Им ваша форма никак не помогает.
Так что вы делаете инструмент, который пытается попасть строго между двух возможных аудиторий.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
, т.е. вопрос привычки.
Чекбокс максимального размера именно "включает максимальный размер" и запрещает его указывать числом. Вопрос привычки.
Я согласен с некоторой долей AI в форме, но строго опционально через конфиг программы.
На батоны-чекбоксы — есть. 