Здравствуйте, 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, большинство людей захочет таки определить какого размера он собственно нужен.