Несколько предложений по юзабилити №2
Модератор: motyara
- Max Diesel
- Автор программы
- Сообщения: 3431
- Зарегистрирован: Пт окт 12, 2007 3:26 pm
- Контактная информация:
Судя по всему подобные диалоговые окна надо сделать в виде плагинов, которые каждый мог бы выбрать по своему желанию... впрочем подозреваю что интерес этот аспект вызывает лишь при факте отсутствия такой технологии (соответственно в данном случае идею про плагины не нужно воспринимать всерьез). А вот Shift в следующем билде будет при факте его нажатости рассматриваться как установленный флаг "Применять ко всем", впрочем полагаю это единственное изменение в плане этого диалога, внедрение которого мной акцептовано.
Re:
Сам об этом подумалMax Diesel писал(а):Судя по всему подобные диалоговые окна надо сделать в виде плагинов, которые каждый мог бы выбрать по своему желанию...
Хоть какое-то усовершенствование - лучше, чем ничего.Max Diesel писал(а):А вот Shift в следующем билде будет при факте его нажатости рассматриваться как установленный флаг "Применять ко всем", впрочем полагаю это единственное изменение в плане этого диалога, внедрение которого мной акцептовано.
Макс, я так понимаю, что отчасти Ваше нежелание экспериментировать с интерфейсами связано с нежеланием тратить время на маловажные вещи? Если так, может стоит обдумать возможность привлечь сторонних разработчиков? Это несложная задача, если её правильно организовать.
- Создать Debug-версию программы, в которой данный диалог будет действительно реализован в виде плагина.
- Разработчики смогут понасоздавать своих версий диалога, с возможностью обмениваться рабочими версиями, а не эскизами-макетами.
- Пользователи, готовые помочь разработке, смогут скачивать и тестировать разрабатываемые элементы интерфейса. Это ключевой момент - десятки пользователей дадут гораздо больше полезной информации об удобстве, чем три обсуждающих мыслителя, как сейчас.
- Когда будет выработан один устраивающий большинство интерфейс, можно будет закрывать этот вопрос и интегрировать интерфейс в основную ветку программы.
- Исходный код программы раскрывать не нужно - только обсуждаемого диалога.
- В дальнейшем все подобные спорные места можно передавать на доработку общественности. Программа состоит из диалогов, и от их продуманности зависит в целом "user experience" - впечатление от пользования программой. Не мне Вам объяснять как много программ гибнут из-за непроработаности и недоделанности в мелочах. Именно внимание к мелочам вызывает уважение к хорошим продуктам.
- Max Diesel
- Автор программы
- Сообщения: 3431
- Зарегистрирован: Пт окт 12, 2007 3:26 pm
- Контактная информация:
Не три, а два... я вроде как в обсуждении не участвую.Fuhrer писал(а):десятки пользователей дадут гораздо больше полезной информации об удобстве, чем три обсуждающих мыслителя, как сейчас.
Не совсем верная формулировка... преобладающее большинство программ "гибнет" не из-за недоделанности в мелочах, а из-за стремления пользователей (порой параноидального) не платить разработчикам за софт. А недоделанность в мелочах - это вопрос времени, того самого времени которое разработчики зачастую не в силах прожить на добрых помыслах. В плане цен на ПО у меня свое мнение - цена на товар такого вида должна варьироваться в зависимости от дохода покупателя, то есть фиксированные цены - это особенность "физических" товаров. Когда-то рынок придет к этому принципу, но пока что идея лишь витает в воздухе. Впрочем это было лишь лирическое отступление от темы.Fuhrer писал(а):Не мне Вам объяснять как много программ гибнут из-за непроработаности и недоделанности в мелочах. Именно внимание к мелочам вызывает уважение к хорошим продуктам.
Ну а по теме - я конечно мог бы сделать плагинный принцип, но специфика его использования в данном случае предполагает лишь то, что диалог будет получать фиксированные значения и выдавать также фиксированные значения - никаких отклонений и специфических умений. При таком подходе получится ни что иное как "написание одного и того же слова в разных регистрах" (образно выражаясь). Также это создало бы значительные проблемы в части использования языковых файлов, а также по вопросу юникода. Поэтому идея хотя и выглядит интересной, но тем не менее у нее отрицательных черт значительно больше чем положительных.
Второй раз нажимаю правка вместо цитата.
См. сообщение далее.
UPDATE: А если точнее, то https://forum.unrealcommander.net/viewto ... 5846#p5846
См. сообщение далее.
UPDATE: А если точнее, то https://forum.unrealcommander.net/viewto ... 5846#p5846
Последний раз редактировалось Qwertiy Пн май 10, 2010 12:29 am, всего редактировалось 3 раза.
Re:
Ещё ironx присоединился на третьей странице. Даже свой вариант нарисовал. Вот я его и посчитал.Max Diesel писал(а): Не три, а два... я вроде как в обсуждении не участвую.
Согласен. Это увы, в наших странах пока за правило. Люди вынесли определённый менталитет с советского союза, их нельзя винить. Перестроится в один миг на новое мировоззрение - задача непростая, тем более, что никто толком не знает на что перестраиваться. Классическая система ценообразования, как Вы заметили, не совсем подходит для софта, а платить по другой схеме сейчас, увы, невозможно. Поэтому люди, чаще из жадности, а иногда и за неимением альтернатив, не платят вообще, чем платят то, что могут себе позволить.Max Diesel писал(а):Не совсем верная формулировка... преобладающее большинство программ "гибнет" не из-за недоделанности в мелочах, а из-за стремления пользователей (порой параноидального) не платить разработчикам за софт.
А ещё это вопрос числа пользователей. Именно удобство в одном диалоге может стать той мелочью, после которой пользователь скажет "Но ведь UC удобнее TC. Давай-ка я его куплю, тем более, и цена здесь адекватная". Звучит, может быть, и пафосно, но диалог замены - действительно важная вещь, как ни странно. Файловый менеджер - это прежде всего простейшие файловые операции: скопировать, переместить, удалить. И именно продвинутые опции замены/пропуска заменяемых файлов отличают UC (и TC) от простейшего Explorer`а. Диалог замены - это первый аргумент использовать UC, и пускай он будет веским аргументом.Max Diesel писал(а):А недоделанность в мелочах - это вопрос времени, того самого времени которое разработчики зачастую не в силах прожить на добрых помыслах. [/color]
Конечно, плагин будет самым элементарным и ничего умного он делать не будет. Этого и не требуется. В данном случае плагин - это возможность поиграться с интерфейсами, не более. Приведу логическую цепочку, которая наталкивает на мысль о плагине.Max Diesel писал(а):Ну а по теме - я конечно мог бы сделать плагинный принцип, но специфика его использования в данном случае предполагает лишь то, что диалог будет получать фиксированные значения и выдавать также фиксированные значения - никаких отклонений и специфических умений. При таком подходе получится ни что иное как "написание одного и того же слова в разных регистрах" (образно выражаясь). Также это создало бы значительные проблемы в части использования языковых файлов, а также по вопросу юникода. Поэтому идея хотя и выглядит интересной, но тем не менее у нее отрицательных черт значительно больше чем положительных.
- Усовершенствования интерфейса нужны, они ведут к прогрессу.
- У разных людей появляются разные идеи по усовершенствованию интерфейса.
- Для того, чтобы ими поделится, людям приходится создавать программки, демонстрирующие концепции, или вообще рисовать в фотошопе.
- Нарисованные концепции сложно оценить другим, т.к. для оценки удобства интерфейса им нужно пользоваться, а не смотреть на него. Насколько удобна картинка, можно только гадать.
- Даже демо-программки не дают возможности оценить. Понимание удобства приходит при реальной необходимости выбрать функцию, а не при представлении "вот здесь пользователь выберет вот это". Кроме того, только пользуюясь человек может понять, что одной функции нужно дать больше удобства выбора, а другой - не обязательно.
- Идеальным вариантом тестирования интерфейсов было бы интегрирование их всех в программу и использование по очереди, для сравнения. Дальше, основываясь на отзывах пользователей, можно было бы выбрать лучший вариант.
- Поскольку у Вас, как я понимаю, нет времени и желания разрабатывать малозначимые детали программы, эту задачу можно переложить на руки добровольцев.
- Поскольку программа, как я понимаю, с закрытыми исходными кодами, и возможности компилировать её у сторонних разработчиков нет, единственный способ вносить свою функциональность - через плагины.
- Создаётся тестовая версия программы, в которой отдельный диалог выполнен в виде плагина.
- Желающие создают свои плагины с вариантами реализации. Здесь многоязычность не слишком важна, к.т. разработчики общаются на одном общем языке.
- По прошествии некоего времени выбирается самый удачный вариант (возможно - два лучших), который(е) интегрируется в основную ветку программы. Этот этап учитывает переводы, а интеграцией занимается разработчик UC.
Да, согласен. Я заметил эту полезность, В этом плане предложенный мною "тултипный" вариант менее полезен. Мне нравится Ваше окошко сравнения, только вкладки в них считаю лишними, и способ вызова требует лишней прицельности.Qwertiy писал(а):И ещё, мой вариант позволяет не только посмотреть, но и скопировать информацию. Для большинства полей это не принципмально, но вот для имени файла - очень полезно.
За это спасибо!Max Diesel писал(а):А вот Shift в следующем билде будет при факте его нажатости рассматриваться как установленный флаг "Применять ко всем", впрочем полагаю это единственное изменение в плане этого диалога, внедрение которого мной акцептовано.
Но, может, ещё "Считать перемещённым" ("Удалить источник") добавите? Хотя бы в Другие действия.
По-моему, можно разрешить использование плагина в самой программе, а не создавать отдельную тестовую версию. А что касается локализации, то для каждого языка найдётся свой плагин, если его напишут в этой стране...Fuhrer писал(а):Отсюда схема действия видится таковой:
- Создаётся тестовая версия программы, в которой отдельный диалог выполнен в виде плагина.
- Желающие создают свои плагины с вариантами реализации. Здесь многоязычность не слишком важна, к.т. разработчики общаются на одном общем языке.
- По прошествии некоего времени выбирается самый удачный вариант (возможно - два лучших), который(е) интегрируется в основную ветку программы. Этот этап учитывает переводы, а интеграцией занимается разработчик UC.
Пожалуйста, прочитайте всё моё сообщение. Так получилось, что я, когда отправил исходный вариант, то решил его дополнить, но заметив, что Вы в это время просматриваете форум, решил сделать "Цитата" и дописать это. Только вот вместо "Цитата" нажал "Правка"... Потом был очень рад, что в Опере я могу получить ту страницу, в которой его писал (с заполенным полем).Fuhrer писал(а):Да, согласен. Я заметил эту полезность, В этом плане предложенный мною "тултипный" вариант менее полезен. Мне нравится Ваше окошко сравнения, только вкладки в них считаю лишними, и способ вызова требует лишней прицельности.Qwertiy писал(а):И ещё, мой вариант позволяет не только посмотреть, но и скопировать информацию. Для большинства полей это не принципмально, но вот для имени файла - очень полезно.
Многовато информации для всплывающей подсказки... Да и форму загромождать не стоит - не так уж часто пользователя будет интересовать вся информация о файле... Считаю, что надо сделать два столбца с кнопкой "Открыть" под каждым.Fuhrer писал(а):Если ещё радикальнее, можно вообще эту информацию выводить тултипом или в каком-то всплывающем окне, без элементов управления. Навёл мышь - увидел инфу. Правда, нужно учесть, что на сенсорном дисплее "мышь" не наведёшь, там её нет. Это нужно учесть. Короче, я за сокращение лишних нажатий и активных зон. Можно такую информацию вообще постараться вместить в основное окно, если постараться. Хотя это может быть перебором.
И ещё, мой вариант позволяет не только посмотреть, но и скопировать информацию. Для большинства полей это не принципиально, но вот для имени файла - очень полезно.
А как же первая и последняя кнопки (буквы)? Их же всего 2. Впрочем, это не важно - при двух столбцах кнопку "Ok" всё равно придётся переместить... Переименовать в "Закрыть" тоже можно, хотя как-то редко такая кнопка попадается в Windows.Fuhrer писал(а):Я о том, что эти кнопки воспринимаются как единый блок, и не важно, какая из них на каком месте.
...
Во-первых, мне кажется здесь уместнее "Закрыть".
При чётком разделении способа выбора группы и элемента внутри группы такой подход позволяет сократить количество теребуемых действий, поэтому это удобнее. И ещё - единообразие стиля.Fuhrer писал(а):1. Как так оказалось, что два радиобатона и кнопка удобнее просто двух кнопок? Ведь каждый из блоков "Пропустить" и "Считать перемещённым" можно заменить на две кнопки.
Реакция на Enter вполне предсказуема. Не вижу здесь противоречий. Чекбокс - действительно спорный момент... Но он почти никогда не понадобится...Fuhrer писал(а):2. Навигация по радиокнопкам неизбежно сложнее, чем по кнопкам, ведь нужно применять и Tab, и стрелки. Как подействует "Enter" в каждом конкретном положении (когда курсор на радиокнопке) - не совсем очевидно, даже если кнопки правильно подсвечиваются. Добавьте сюда неопределённость с чекбоксом - и получите ад неопределённости и сложности при ответе на простой вопрос о замене файла.
Tab - лишнее. Стрелки влево и вправо его заменяют. Так что одной руки достаточно. И Shift почти не нужен.Fuhrer писал(а):Оно то да, но каких клавиш? Стрелки, Tab, Enter, Shift. При этом, нажатие на стрелку меняет значение, что уже важно.Qwertiy писал(а):1. Любой выбор с клавиатуры - не более чем за 5 клавиш, включая последний Enter для подтверждения.
С изменением значений не поспоришь, но такова природа переключателей...
Но он намного шире! И вообще, не представляю, что можно не попасть мышью по переключетелю...Fuhrer писал(а):По-моему, один одинарный левый щелчёк в моём варианте все же лучше. Кроме того, мои маленькие кнопочки 25 пикселей в высоту, а Ваши радиобаттоны - 17, на моей системе по крайней мере. Это меньше в полтора раза.Qwertiy писал(а):Любой выбор с помощью мыши - не более чем за 1 одинарный (флажок "Применить ко всем") и 1 двойной щелчок (RadioButton).
Пусть так. Просто Ваш вариант отражает выполняемое действие, а мой - его причину/суть.Fuhrer писал(а):"Считать перемещённым" - слишком расплывчасто. Какое кому дело что там считает программа? Пускай считает, что файлы - это розовые пони которые перемещаются по радуге, это никого не волнует. Волнует то, что программа делает. И если она УДАЛИТ файл, пускай она это чётко, жирно, и прямо напишет, незачем строить и себя саму невинность.
Флажок остался, но он почти не нужен. Кстати, если пожертвовать вариантом "Дописать все" и добавить переключатели к Переименовать, то его можно убрать.Fuhrer писал(а):Исключительно с целью удобства выбора и понятности. Извините, но мне кажется Вы пошли в обратном направлении. Кроме того, флажок таки остался.Qwertiy писал(а):Вы сами хотели отсутствие необходимости использовать флажок "Применить ко всем".
Со сравнением по содержимому - это предусловие, задаваемое в предыдущем диалоге. Если Вы посмотрите код (FrmQuestion.vb)Fuhrer писал(а):Однозначно. Притом, нужны варианты не только со сравнением по содержимому, но и без.Qwertiy писал(а):Вы согдасны с тем, что "Считать перемещённым" - полезная функция.
Код: Выделить всё
If CompareFiles(Not AutoCmp) AndAlso AutoCmp AndAlso AutoPsevdoReplase Then
Result = FileCopyDialogResult.PseudoReplace
Return FileCopyDialogResult.PseudoReplace
End If
If ForAll Then Return Result
Me.ShowDialog()
Что же касается возможности применить его ко всем без сравнения, то она есть. Просто выбрать переключатель "Все" в группе "Считать перемещённым" и подтвердить выбор.
UPDATE: В этом куске кода баг... Должно быть так:
Код: Выделить всё
If CompareFiles(Not AutoCmp) AndAlso AutoCmp AndAlso AutoPsevdoReplase Then
Return FileCopyDialogResult.PseudoReplace
End If
If ForAll Then Return Result
Me.ShowDialog()
Кроме функционального отличия есть ещё и отличие в интерфейсе, и оно огромно!Fuhrer писал(а):Ну не стоило ради добавления одной функции вносить эти богомерзкие радиобаттоны.
Max Diesel писал(а):Ну а по теме - я конечно мог бы сделать плагинный принцип, но специфика его использования в данном случае предполагает лишь то, что диалог будет получать фиксированные значения и выдавать также фиксированные значения - никаких отклонений и специфических умений. При таком подходе получится ни что иное как "написание одного и того же слова в разных регистрах" (образно выражаясь). Также это создало бы значительные проблемы в части использования языковых файлов, а также по вопросу юникода. Поэтому идея хотя и выглядит интересной, но тем не менее у нее отрицательных черт значительно больше чем положительных.
Если реализовать в лоб, то да. Но это можно легко обойти. Всё-таки скачайте "Запрос при копировании.7z" (1 скачивание - это, как я думаю, Fuhrer) и посмотрите на реализацию (хотя там немного не так).
Просто опишу простой алгоритм, позволяющий использовать разные диалоги с разными возможностями.
1. Для каждой новой очереди (перед копированием/перемещением) создаётся свой чистый экземпляр диалога, или используется метод Clear() уже существующего.
2. Каждый раз при возникновении конфликта вызывается метод ShowDialog(Source, Dest), который возвращает одно из следующих значений: ЗаменитьПриёмник, УдалитьИсточник, ПропуститьИсточник, Дописать, Переименовать, ПереименоватьИсточник, ПереименоватьПриёмник, ПереименоватьИсточникВ, ПереименоватьПриёмникВ, Отмена.
3. В случае возврата значений ПереименоватьИсточникВ и ПереименоватьПриёмникВ с помощью метода GetNewName() получить новое имя файла.
4. В случае возврата других видов переименования - показать диалог переименования.
5. Также диалог должен предоставлять возможность проверить, установлено ли переименовать все, для случая автоматического переименования средствами UC, а не диалога.
Собственно, это всё. Пункты "Более старые", "Более мелкие" и т. д., а также флажок "Применить ко всем" обрабатываюся самим диалогом и он сам решает, что после "Применить ко всем", ему надо не отображаться, а сразу просчитать, что надо сделать и вернуть соответствующее значение.
Можно диалогу предоставить больше возможных возвращаемых значений, но в любом случае, этих достаточно для полноценной реализации как имеющихся, так и дополнительных возможностей.
Re: Несколько предложений по юзабилити №2
Можна и так, если в этом нет технических сложностей.Qwertiy писал(а):По-моему, можно разрешить использование плагина в самой программе, а не создавать отдельную тестовую версию.
Я его увидел, просто у меня сил не хватило прокомментировать и его. Кстати, по Вашей ссылке открылась предыдущая версия. Сравните.Qwertiy писал(а):Пожалуйста, прочитайте всё моё сообщение.
Упс... Уже ничего полезного не осталось. Кроме того, ваша ссылка вместе с сообщением, на которое она ссылается, вгоняет меня в рекурсию.
Восстановлю текст Вашего сообщения, откомментирую.
Ага. Не успел. События развиваются быстрее, чем я их успеваю описать. Ладно, по теме будет в следующем посте.
Извините пожалуйста
То, что на первом скриншоте - ещё одна моя ошибка... Кажется, я превратил эту страницу в хаосFuhrer писал(а):Ага. Не успел. События развиваются быстрее, чем я их успеваю описать. Ладно, по теме будет в следующем посте.
Читайте https://forum.unrealcommander.net/viewto ... 5846#p5846.
- Max Diesel
- Автор программы
- Сообщения: 3431
- Зарегистрирован: Пт окт 12, 2007 3:26 pm
- Контактная информация:
Да, тогда три... в лавине Ваших с Qwertiy сообщений сообщения других сливаются с фоном...Fuhrer писал(а):Ещё ironx присоединился на третьей странице. Даже свой вариант нарисовал. Вот я его и посчитал.
Дело еще и в том, что диалоговые окна у меня зачастую выполняют по-нескольку задач, например окно диалога создания каталога используется кроме этой цели еще в 9-ти подобных случаях (добавление в избранное, создание файла, переименование таба и тд.), такая же особенность и у диалога замены файлов. Соответственно вытащить в плагин конкретное его предназначение - дело проблемное.Fuhrer писал(а):
- Усовершенствования интерфейса нужны, они ведут к прогрессу.
- У разных людей появляются разные идеи по усовершенствованию интерфейса.
- Для того, чтобы ими поделится, людям приходится создавать программки, демонстрирующие концепции, или вообще рисовать в фотошопе.
- Нарисованные концепции сложно оценить другим, т.к. для оценки удобства интерфейса им нужно пользоваться, а не смотреть на него. Насколько удобна картинка, можно только гадать.
- Даже демо-программки не дают возможности оценить. Понимание удобства приходит при реальной необходимости выбрать функцию, а не при представлении "вот здесь пользователь выберет вот это". Кроме того, только пользуюясь человек может понять, что одной функции нужно дать больше удобства выбора, а другой - не обязательно.
- Идеальным вариантом тестирования интерфейсов было бы интегрирование их всех в программу и использование по очереди, для сравнения. Дальше, основываясь на отзывах пользователей, можно было бы выбрать лучший вариант.
- Поскольку у Вас, как я понимаю, нет времени и желания разрабатывать малозначимые детали программы, эту задачу можно переложить на руки добровольцев.
- Поскольку программа, как я понимаю, с закрытыми исходными кодами, и возможности компилировать её у сторонних разработчиков нет, единственный способ вносить свою функциональность - через плагины.
Хм... у меня складывается ощущение что эта функция нерациональная, так как файлы могут совпадать по имени и размеру, но по содержанию отличаться - в такой ситуации чтобы убедиться в факте отсутствия внутренних отличий необходимо побайтово сравнить файлы, а для больших файлов это может быть весьма долгим процессом и соответственно в такой ситуации было бы рациональнее зная какой файл по сути является более актуальным (в данном случае перемещаемый) просто производить замену и экономить на этом ресурсы требуемые для прочтения результирующего файла.Qwertiy писал(а):может, ещё "Считать перемещённым" ("Удалить источник") добавите? Хотя бы в Другие действия.
И я, и Fuhrer считаем её полезной и нужной. Да и Вы раньше не были против (https://forum.unrealcommander.net/viewto ... 5314#p5314). Что касается побайтового сравнения, то в моём варианте оно возможно... Кроме того, я просил добавить соответствующую опцию (https://forum.unrealcommander.net/viewto ... 5303#p5303).Max Diesel писал(а):Хм... у меня складывается ощущение что эта функция нерациональная, так как файлы могут совпадать по имени и размеру, но по содержанию отличаться - в такой ситуации чтобы убедиться в факте отсутствия внутренних отличий необходимо побайтово сравнить файлы, а для больших файлов это может быть весьма долгим процессом и соответственно в такой ситуации было бы рациональнее зная какой файл по сути является более актуальным (в данном случае перемещаемый) просто производить замену и экономить на этом ресурсы требуемые для прочтения результирующего файла.Qwertiy писал(а):может, ещё "Считать перемещённым" ("Удалить источник") добавите? Хотя бы в Другие действия.
PS: Всё-таки посмотрите предложенный мной диалог.
Это действие, при использовании кнопки, должно выполняться независимо от совпадения размера/содержимого.Max Diesel писал(а):Хм... у меня складывается ощущение что эта функция нерациональная, так как файлы могут совпадать по имени и размеру, но по содержанию отличатьсяQwertiy писал(а):может, ещё "Считать перемещённым" ("Удалить источник") добавите? Хотя бы в Другие действия.
Связь с содержимым - только через флажок диалогом ранее.
Смысл в том, что в слова никто не читает по буквам, а кнопки - по словам. Но это не важно.Qwertiy писал(а):А как же первая и последняя кнопки (буквы)? Их же всего 2.
Нет, ну конечно можно догадаться какая кнопка нажмётся Enter'ом, но и всё-таки это не очевидно. Обычно, в диалогах, где присутствует элементы с памятью (радиобаттоны, чекбоксы) есть одна кнопка, которая реагирует на Enter. И тогда, как и положено, она подсвечивается жирным контуром. Она же и нажимается при двойном щелчке на радиобаттоне, если это какой-нибудь всплывающий диалог с вариантами ответа. У Вас же кнопок несколько, все равносильные, и какую из них программа посчитает выбранной Enter'ом - пользователь не знает. Он может надеятся, но он явно он не увидит какую кнопку он нажал.Qwertiy писал(а):Реакция на Enter вполне предсказуема. Не вижу здесь противоречий.
Пример типичного использования Default Button:
Ага! То есть программа-пример в этом плане не отражает задумку автора? Если так, тогда пользование диалогом действительно приобретает смысл. Правда, нестандартная обработка нажатий на стрелки ([<--],[-->]) потребует привыкания к ней со стороны пользователя, что не есть хорошо. Да и нагромождение элементов пугает не меньше моих микрокнопок. Но уже какой-тто смысл есть. Поехали дальше.Qwertiy писал(а):Tab - лишнее. Стрелки влево и вправо его заменяют.
Да, Shift - это слабое место. Есть смысл в том, чтобы пользователь нажимал Enter без лишних условий. Но только в случае неувеличения количества действий до нажатия Enter.Qwertiy писал(а):И Shift почти не нужен.
Речь не идёт о "не попасть". Речь о том, сколько времени и усилий тратится на то, чтобы попасть. Очевидно, что чем меньше элемент, тем сложнее на него навести мышь быстро. А если быстро не получится, придётся медленно. Чего я и пытаюсь избежать.Qwertiy писал(а):Но он намного шире! И вообще, не представляю, что можно не попасть мышью по переключетелю...
Ну а что сложнее для попадания - моя кнопка или Ваш радиобаттон - спорить не буду, ибо кому как. Наверно, кнопка сложнее. Ну на то она и более ответственна. Уменьшенная вероятность случайно заменить все файлы в очереди вместо одного - скорее фича, чем баг.
Это то, что нужно, но не совсем. Я имел ввиду удалять исходник при совпадении всех атрибутов. Этот же диалог предлагает только при совпадении имён. Аналогично в диалоге синхронизации каталогов есть возможность сравнить файлы по всем внешним признакам, не сравнивая по содержимому. Это чрезвычайно полезная функция. Почти всегда, если у файлов разное содержимое, то и некоторые из их атрибутов отличны. И наоборот: если все атрибуты одинаковы, то одинаково и содержимое. Это относится ко всем архивам, видеофайлам, как правило и к текстовым файлам.Qwertiy писал(а):Что же касается возможности применить его ко всем без сравнения, то она есть. Просто выбрать переключатель "Все" в группе "Считать перемещённым" и подтвердить выбор.
И ещё одно замечание касательно сравнений файлов. Я считаю очень неправильным вынесение настроек "При совпадении имён и размеров сравнивать по содержимому" и "При совпадении по содержимому считать файл перемещённым" за пределы диалога. По сути, это обязывает пользователя продумать такие варианты перед запуском копирования. Это не есть хорошо. А если он не догадался, или забыл? А если он это понял уже посреди процесса, после появления 25-го диалога? Отменять и начинать заново, что ли? Я считаю, все эти варианты нужно интегрировать в диалог, если они вообще будут в программе. Кроме того, возможен бездиалоговый запуск копирования (у меня Drag`n`Drop так работает, например), когда копирование начинается вообще без лишних переспрашиваний.
То, что оно огромно, я вижу. Не вижу я в этом отличии положительных черт. Объясните, пожалуйста, Спасибо, что поддерживаете идею о плагине. Мне кажется, это действительно может оказаться неплохой затеей.Qwertiy писал(а):Кроме функционального отличия есть ещё и отличие в интерфейсе, и оно огромно!
Re:
Ну насчёт "диалогом ранее" я уже пофыркал в предыдущем посте, здесь повторяться не буду.Qwertiy писал(а):Это действие, при использовании кнопки, должно выполняться независимо от совпадения размера/содержимого.Max Diesel писал(а):Хм... у меня складывается ощущение что эта функция нерациональная, так как файлы могут совпадать по имени и размеру, но по содержанию отличатьсяQwertiy писал(а):может, ещё "Считать перемещённым" ("Удалить источник") добавите? Хотя бы в Другие действия.
Связь с содержимым - только через флажок диалогом ранее.
А насчёт условий... Мне кажется, есть смысл рассматривать три варианта:
1. У файлов одинаковые имена. Содержимое никого не интересует.
2. Одинаковые имена и все атрибуты. Под атрибутами я понимаю всю информацию о файле, не включая его путь, права, и содержимое. То есть это его даты (создания, изменения), размер, и собственно, файловые атрибуты в понимании FAT/NTFS. Если эти данные совпадают (а их можно мгновенно получить для файла любого размера), тогда можно с большой долей вероятности делать вывод о том, что файлы одинаковы.
3. Сравнение по содержимому.
Все три варианта нужно чётко указать пользователю, чтобы он хорошо понимал на основании какого из трёх сравнений программа принимает решение о действии. Что самое сложное, эти же три вида сравнения можно применить не только для удаления исходника, но и для других операций (замена, пропуск, дописывание). Правда, не во всех случаях это рационально, нужно продумать возможные применимые в жизни варианты и дать пользователю возможность их выбрать.