Несколько предложений по юзабилити №2

Модератор: motyara

Аватара пользователя
Qwertiy
Охотник за багами
Сообщения: 1199
Зарегистрирован: Вс янв 31, 2010 12:12 am

Сообщение Qwertiy » Пт сен 24, 2010 1:44 am

Fuhrer писал(а):
Qwertiy писал(а):2. Зачем считать хэш файла, когда можно сравнить содержимое? Тем более, что сравнение содержимого можно остановить при первом несовпадении, а для сравнения хэша придётся прочитать весь файл целиком...
Сравнение даст ужасные результаты если оба файла находятся на одном винчестере, из-за необходимости дёргать головкой туда-сюда. При вычислении хэша чтение линейное и такой проблемы нет. Но для меня это не принципиально, можно и без этого.
Если правильно выбрать размер буфера, то всё будет хорошо... К тому же, это уже реализовано в синхронизации.

PS: Не забудьте прочитать последнее сообщение на предыдущей странице.

Аватара пользователя
Fuhrer
Охотник за багами
Сообщения: 127
Зарегистрирован: Ср мар 03, 2010 12:51 am

Re: Новый вариант диалога

Сообщение Fuhrer » Пт сен 24, 2010 3:51 pm

Qwertiy писал(а):Нельзя перетаскивать флажок на кнопку (но при желании можно написать).
Думаю, надо бы попробовать. Я уже не так уверен, что это будет лучше, но попробовать хотелось бы.
Qwertiy писал(а):2. Перетаскивание кнопки на флажок (тоже с изменением текста, но только её).
Этого не видно. То есть этого вообще не видно. Я имею ввиду то, что пользователь не будет перечитывать текст на кнопке, которую он тащит. И не догадается, и не сможет прочесть. Кроме того, во множестве случаев слово "всё" уходит за пределы окна, и его нельзя увидеть даже если специально вчитываться. Это не особая проблема, просто смена надписи на перетаскиваемой кнопке почти бесполезна.
Qwertiy писал(а):3. Нестандартная обработка стрелок в области кнопок.
Тут имхо всё отлично. Только не работает при нажатом шифте. Это делалось отдельными обработками нажатия клавиш?
Qwertiy писал(а):4. Обработка удерживаемого Ctrl.
Пожалуй, лучше не бывает.
Qwertiy писал(а):5. Возможность установить действие для непроходящих по основному условию файлов.
Это я предлагаю обсудить отдельно.

Диалог понравился, он заметно эргономичнее нынешнего. Но кое-что мне в нём не понравилось.
1. Информацию о файле-приёмнике и файле-источнике желательно показывать в одном окне, для лёгкости сравнения. Неплохо, если это влезет в само окно о замене. Тогда пользователь, принимая решение о замене (единичного файла), сможет использовать максимум данных при минимуме лишних телодвижений.
2. Вместо сравнения только размеров (кнопка под ссылками файлов), неплохо бы сразу сравнить и даты. Хотя бы даты изменения.
3. Если кнопка "Переименовать" вызывает новый диалог, она должна обзываться "Переименовать...". Хотя как по мне, то я бы переименовывал на месте. В следующем посте постараюсь показать свои идеи на эту тему.
4. Фраза "Удалить источник" встречается в тексте 3 раза. И это при том, что в случае копирования она вообще должна отсутствовать в этом диалоге. Кроме того, я бы вообще немного убрал бы эту опцию. В большинстве случаев вместо неё можно пропустить всё, а потом удалить остаток.

Рисунок кнопки "для всех" немного не влезает на самой кнопке.

Аватара пользователя
Fuhrer
Охотник за багами
Сообщения: 127
Зарегистрирован: Ср мар 03, 2010 12:51 am

Re: Несколько предложений по юзабилити №2

Сообщение Fuhrer » Пт сен 24, 2010 4:11 pm

Вот набросок того, что я рисовал.
Сразу предупреждаю, оно не готово даже в качестве примера.
Почему такой огромный ехе - не знаю.
Dial1.png
Dial1.png (5.64 КБ) 2051 просмотр
Dial2.png
Dial2.png (5.74 КБ) 2051 просмотр
Dial3.png
replace.7z
(1.6 МБ) 122 скачивания
Замечания.
1. Кнопки "Все" менее удобны, чем в последняя версии от Qwertiy.
2. Кнопки увеличенной высоты. Такие, например, применены в Double Commander. Диалог от этого не особо потолстел, а удобство увеличилось.
3. В основном виде окна всего 6 кнопок + две и именами файлов и возможностью их переименования.
4. Нижняя группа не отображается для диалога копирования.
5. Нужны дальнейшие усовершенствования и доработки.

Аватара пользователя
Fuhrer
Охотник за багами
Сообщения: 127
Зарегистрирован: Ср мар 03, 2010 12:51 am

Re: Несколько предложений по юзабилити №2

Сообщение Fuhrer » Пт сен 24, 2010 6:00 pm

Вот немного доделал предыдущее. Пока всё ещё ничего не работает - это скорее макет, чем пример.
capture_09242010_165639.png
capture_09242010_165639.png (5.2 КБ) 2048 просмотров
capture_09242010_165704.png
capture_09242010_165704.png (5.39 КБ) 2048 просмотров
capture_09242010_165720.png
capture_09242010_165720.png (11.54 КБ) 2048 просмотров
replace.7z
(1.6 МБ) 130 скачиваний

Аватара пользователя
Qwertiy
Охотник за багами
Сообщения: 1199
Зарегистрирован: Вс янв 31, 2010 12:12 am

Сообщение Qwertiy » Пт сен 24, 2010 11:06 pm

Fuhrer писал(а):
Qwertiy писал(а):Нельзя перетаскивать флажок на кнопку (но при желании можно написать).
Думаю, надо бы попробовать. Я уже не так уверен, что это будет лучше, но попробовать хотелось бы.
Это возможно, хотя я не очень представляю, как показать, что флажок находится над кнопкой... Заставить её помигать, что ли...
Fuhrer писал(а):
Qwertiy писал(а):2. Перетаскивание кнопки на флажок (тоже с изменением текста, но только её).
Этого не видно. То есть этого вообще не видно. Я имею ввиду то, что пользователь не будет перечитывать текст на кнопке, которую он тащит. И не догадается, и не сможет прочесть. Кроме того, во множестве случаев слово "всё" уходит за пределы окна, и его нельзя увидеть даже если специально вчитываться. Это не особая проблема, просто смена надписи на перетаскиваемой кнопке почти бесполезна.
Это сделано из чисто логических соображений, а не практических... Когда кнопка находится над флажком, он нажимается, но меняется только эта кнопка, а все остальные неизменны. Обратите внимание, что это действие не снимает флажок, если он был установлен до перетаскивания. В принципе, я думал сделать xor, но решил, что это было бы нелогично.
Fuhrer писал(а):
Qwertiy писал(а):3. Нестандартная обработка стрелок в области кнопок.
Тут имхо всё отлично. Только не работает при нажатом шифте. Это делалось отдельными обработками нажатия клавиш?
Да, это делалось обработкой события PreviewKeyDown, причём весьма криво. Действие делается с учётом того, что после этого система производит ещё одно действие (оно не заменяется, а процедура выполняется первой)

Код: Выделить всё

Private Sub Btn_PreviewKeyDown(ByVal sender As System.Object, ByVal e As System.Windows.Forms.PreviewKeyDownEventArgs) Handles BtnSkip.PreviewKeyDown, BtnReplaceSmall.PreviewKeyDown, BtnReplaceOld.PreviewKeyDown, BtnReplace.PreviewKeyDown, BtnRename.PreviewKeyDown, BtnOther.PreviewKeyDown, BtnDelete.PreviewKeyDown, BtnCancel.PreviewKeyDown, BtnAppend.PreviewKeyDown
  If Clickable Then
    Dim TabIndex As Integer = sender.TabIndex
    Select Case e.KeyData
      Case Keys.Right
        TabIndex += 0 '1
      Case Keys.Left
        TabIndex -= 0 '1
      Case Keys.Up
        TabIndex -= 2 '3
        If TabIndex < 0 Then TabIndex = 0
      Case Keys.Down
        TabIndex += 2 '3
        If TabIndex > 8 Then TabIndex = 8
    End Select
    For Each Ctrl As Control In Me.Controls
      If Ctrl.TabIndex = TabIndex Then
        Ctrl.Select()
        Exit Sub
      End If
    Next Ctrl
  End If
End Sub
Думаю, сюда можно добавить обработку Shift, хотя гарантировать не могу... Да и не очень вижу причин для использования Shift+Стрелка...
Fuhrer писал(а):
Qwertiy писал(а):4. Обработка удерживаемого Ctrl.
Пожалуй, лучше не бывает.
Мне тоже показалось, что так логичнее... Но, заметьте, Ctrl всё равно работает как переключатель, а не как флаг.
Fuhrer писал(а):
Qwertiy писал(а):5. Возможность установить действие для непроходящих по основному условию файлов.
Это я предлагаю обсудить отдельно.
Думаю, можно сворачивать соответствующую часть формы...
Fuhrer писал(а):Диалог понравился, он заметно эргономичнее нынешнего. Но кое-что мне в нём не понравилось.
1. Информацию о файле-приёмнике и файле-источнике желательно показывать в одном окне, для лёгкости сравнения. Неплохо, если это влезет в само окно о замене. Тогда пользователь, принимая решение о замене (единичного файла), сможет использовать максимум данных при минимуме лишних телодвижений.
2. Вместо сравнения только размеров (кнопка под ссылками файлов), неплохо бы сразу сравнить и даты. Хотя бы даты изменения.
3. Если кнопка "Переименовать" вызывает новый диалог, она должна обзываться "Переименовать...". Хотя как по мне, то я бы переименовывал на месте. В следующем посте постараюсь показать свои идеи на эту тему.
4. Фраза "Удалить источник" встречается в тексте 3 раза. И это при том, что в случае копирования она вообще должна отсутствовать в этом диалоге. Кроме того, я бы вообще немного убрал бы эту опцию. В большинстве случаев вместо неё можно пропустить всё, а потом удалить остаток.
1. На этот раз я не показываю окон, а только говорю о том, что именно надо сделать. С этим пунктом я согласился ещё в прошлый раз.
2. Не вижу смысла. Размер в большей мере позволяет судить об одинаковости файлов. Если же нужно заменить более старый, то есть соответствующая кнопка.
3. Насчёт многоточия согласен, хотя оно там не очень смотрится. Существующий диалог переименования меня вполне устраивает, надо только добавить в него выбор периименовываемого файла.
4. Надо сворачивать низ формы... При копировании соответствующий Enabled=False в целях единства интерфейса с диалогом при перемещении - нелогично помещать на это место разные кнопки. Кроме того, с помощью Enabled=False надо будет запрещать кнопки, задействованные в используемых правилах.
Fuhrer писал(а):Рисунок кнопки "для всех" немного не влезает на самой кнопке.
Он прекрасно помещается - там использовано BackgroundImageLayout = System.Windows.Forms.ImageLayout.Zoom, а на самом рисунке достаточно свободного места для рамки флажка. То, что так отображается дискета, является следствием преобразования рисунка из 256*256 в 63*63...

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

Аватара пользователя
Fuhrer
Охотник за багами
Сообщения: 127
Зарегистрирован: Ср мар 03, 2010 12:51 am

Re:

Сообщение Fuhrer » Пн сен 27, 2010 3:35 pm

Qwertiy писал(а): я не очень представляю, как показать, что флажок находится над кнопкой... Заставить её помигать, что ли...
Выделить красным жирным ободком. Можно не красным, а зелёным.
Qwertiy писал(а):В принципе, я думал сделать xor, но решил, что это было бы нелогично.
Да, было бы нелогично. Как есть сейчас - нормально, просто не очень необходимо.

Qwertiy писал(а):Думаю, сюда можно добавить обработку Shift, хотя гарантировать не могу... Да и не очень вижу причин для использования Shift+Стрелка...
Причины очевидны. Пока я правой рукой нащёлкиваю стрелками нужную кнопку, левая тянется к шифту и нажимает его. В идеале я могу нажать шифт в любой момент до нажатия Enter`a, а по факту я должен нажать шифт только после того, как закончу "ходить" стрелками. Иными словами, сейчас шифт меняет поведение стрелок, делая его менее предсказуемым, но не добавляя при этом никакой дополнительной пользы.
Qwertiy писал(а):
Fuhrer писал(а):
Qwertiy писал(а):4. Обработка удерживаемого Ctrl.
Пожалуй, лучше не бывает.
Мне тоже показалось, что так логичнее... Но, заметьте, Ctrl всё равно работает как переключатель, а не как флаг.
Ну и пускай. Всё равно флаг уже есть, а ложные срабатывания вряд ли здесь вероятны, учитывая размеры переключаемой кнопки.
Qwertiy писал(а):
Fuhrer писал(а): 4. Фраза "Удалить источник" встречается в тексте 3 раза. И это при том, что в случае копирования она вообще должна отсутствовать в этом диалоге. Кроме того, я бы вообще немного убрал бы эту опцию. В большинстве случаев вместо неё можно пропустить всё, а потом удалить остаток.
4. Надо сворачивать низ формы... При копировании соответствующий Enabled=False в целях единства интерфейса с диалогом при перемещении - нелогично помещать на это место разные кнопки. Кроме того, с помощью Enabled=False надо будет запрещать кнопки, задействованные в используемых правилах.
Да, единство интерфейса - важная вещь. Но использование неактивных элементов оправдано тогда, когда они имеют шанс стать активными в процессе жизни диалога. У нас же ситуация обратная - некоторые элементы в диалоге копирования никогда не смогут стать активными, и добавлять их туда только ради того, чтобы пользователь не пугался их отсутствия - это значит только путать пользователя возможностями, которых нет. Элемент интерфейса должен показывать пользователю те возможности, которые у него есть или могут появиться в результате его же действий. Сейчас же мы ему что-то показываем, что что-то есть, но как это можно активировать - не понятно. Даже если ему эта функция не нужна, у пользователя возникнет вопрос: а зачем здесь нарисована эта кнопочка?
Я предлагаю именно скрывать те элементы, которые никогда в пределах операции копирования и не смогут стать активными. Конечно, для этого их желательно пихать в конец диалога, как я и нарисовал.
Qwertiy писал(а): Что касается Вашего диалога, то мне кажется, он менее удобен, чем существующий...
Пока рано сравнивать его с чем-то существующим, т.к. он слишком недописан. Я надеялся Вам показать идею переименования без лишнего диалога, да моё видение группировки кнопок.
Qwertiy писал(а):А по сравнению с моим, в нём нет (как минимум) возможности применить "Удалить источник" только к текущему файлу.
Действительно, нет. Нужно подумать, есть ли заметная польза от использования этой функции в ручном режиме. На большом количестве файлов это даст заметное ускорение, но если речь идёт о таком числе файлов, которое можно перещёлкать руками, то может и функция не имеет ощутимого смысла?
Qwertiy писал(а): Что касается увеличенной высоты кнопок, то она мне никогда не нравилась (чисто визуально)...
Мне тоже визуально она не нравится, хотя дело, думаю, в привычке. Но удобство пользования возрастает значительно, а на размерах диалога это почти не сказывается.

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

Ответить