Как визуально представить размер файла
Это будет немного субъективно, я боюсь, но я оценил бы совет Коллектива.
Наше веб-приложение перечисляет документы, которые могут загрузить пользователи; стандартный материал навигатора файла:
Type Name Created Size ----------------------------------- PDF Doc 1 01/04/2010 15 KB PDF Doc 2 01/04/2010 15 MB
В настоящее время мы перечисляем размер файла как текст, но я хотел бы улучшить это при наличии некоторого способа показать визуально, является ли файл крошечным, нормальным или огромным.
Причина этого состоит в том так, чтобы пользователи могли просканировать список быстро и определить файлы, которые, вероятно, займут много времени, загружая.
Мои опции в настоящее время:
- Большие размеры шрифта для больших файлов (недостаток: расположение может стать неопрятным),
- Значки (как индикатор мощности сигнала Wi-Fi; недостаток: тяжелее просканировать)
- Сохраните все размеры в КБ, таким образом, количество обнуляет, указывает на размер (недостаток: пользователи должны вычислить "дружественный" размер в головах),
Я знаю, что это - вполне незначительная вещь, но я ценил бы чьи-либо мысли о вопросе!
Править: Спасибо за ответы!
Из того, что Вы сказали, я думаю что:
- Мне действительно нравится идея Robert сказать пользователям примерно, сколько времени она возьмет для загрузки файла
- Как кто-то указал, если я использую панель или значок "мощности сигнала", который производит впечатление "максимального" размера файла
- Мне нравится заштриховывать текст - более сильный для больших файлов
Я собираюсь пойти с подходом комбинации:
- Универсальный размер шрифта
- Более темный текст для больших файлов
- Подсказка, говоря пользователям примерно, сколько времени это возьмет для загрузки
- Крошечная часть текста, в скобках, после размера, описывая, насколько большой это, например:
15 KB (tiny) 2 MB (small) 20 MB (big) 300 MB (huge)
Я буду видеть, могу ли я поставить снимок экрана здесь того, как это смотрит, когда у меня есть прототип. Еще раз спасибо за обратную связь!
8 ответов
Если бы это был я, я бы показывал размер файла обычным способом, но также отображал приблизительное время загрузки (предположим, 1,5 Мбит DSL для ваши расчеты).
Как насчет индикатора размера в виде индикатора выполнения?
Другой способ - шкала серого: маленькие файлы - светло-серые, большие - черные.
А как насчет использования цветов? Что-то вроде:
- зеленый, если размер файла меньше 1 МБ
- желтый, если размер файла от 1 МБ до 10 МБ
- красный, если размер файла превышает 10 МБ
или любой другой масштаб, соответствующий типу файлов вы должны иметь дело с ... Вы можете поместить эти цвета либо на фон, либо на цвет текста строки, описывающей ваш файл, или на значок рядом с размером ...
Как насчет стержня, длина которого зависит от размера. Это похоже на идею значка сигнала Wi-Fi, но сканирование было бы проще.
Цвета начинаются с зеленого и переходят к красному по мере увеличения длины.
Если у вас есть только один шаг диапазона (например, только килобайт или мегабайт, или только мегабайт или гигабайт), я бы использовал размер + наименьшую единицу. например. 15000кб, 15кб. Если вам нужно сделать, kb, mb, gb, тогда это не сработает.
Как насчет простого + ++ +++ или $ $$ $$$ после размера, чтобы показать kb, mb, gb?
Если у вас есть место, я бы согласился с вашей идеей сохранять все размеры файлов в постоянных единицах, чтобы порядок величины был обозначен количество занятых мест. С выровненными по правому краю числами это упростит сканирование на определенный порядок.
Имейте в виду, что при таком подходе вы получаете примерно три места, потому что вы удаляете столбец единиц измерения, а вместо этого помещаете единицы в заголовок столбца размера файла, так что это не займет много места. Чтобы сэкономить немного больше места, рассмотрите возможность отображения размеров в МБ с разрешением 0,1 МБ. Для продолжительности загрузки с сегодняшним широкополосным доступом, если учесть время отклика сервера и вариацию, все, что меньше 0.Кажется, что 1 МБ будет иметь примерно такую же продолжительность. Это займет не больше времени, чем загрузка новой веб-страницы, и пользователи не ожидают / не нуждаются в оценках продолжительности для этого. Вы можете записать его как «менее 0,1» для файлов размером менее 50 КБ. Возможно, даже разрешение до 1 МБ будет достаточно, если вам действительно нужно место.
Линейное графическое представление размера файла (например, гистограмма) лучше для оценки относительного времени загрузки. Однако я не вижу, чтобы он работал хорошо, когда продолжительность загрузки составляет три или более порядков. Пользователи, скорее всего, захотят различать загрузку за 5 и 10 минут, поэтому вам нужна визуально заметная разница примерно в 2 МБ. Я бы сказал, что вам нужно как минимум 3 пикселя на 2 МБ для гистограммы, что в значительной степени исключает представление файлов размером в ГБ или более.
Вы можете попытаться линейно представить ГБ, МБ и КБ с отдельной графикой, но такие дисплеи могут быть заведомо трудными для чтения и более сложными для сканирования (например, многоручные высотомеры в большинстве случаев отказались от использования в самолетах из-за ошибок чтения) . Я бы не стал пробовать что-то подобное, если ваши пользователи не прошли обучение или не имеют большого опыта работы с этим.
Попытка ранжировать или категоризировать размеры файлов с помощью значков, цветов, размера шрифта или количества символов проблематична, если вы не знаете правильные точки останова для ваших пользователей. Однако вы, вероятно, не можете знать, потому что порог приемлемой продолжительности будет варьироваться в зависимости от пользователя, его оборудования и их ситуации (сколько времени у них есть).Я бы не использовал красный цвет для любого размера файла, если вы не хотите, чтобы некоторые пользователи думали, что файл настолько велик, что загрузка может повредить их компьютер или вызвать другие технические проблемы.
Коды, подходящие для ранжирования, такие как размер шрифта и количество символов, также могут быть проблематичными, поскольку пользователи могут предположить, что они линейно связаны со временем, тогда как вам, вероятно, потребуется использовать логарифмическое преобразование. Запись размеров в постоянных единицах не вызывает этой проблемы, потому что ясно, что количество разрядов логарифмически связано с размером, даже для пользователей, которые не знают, что такое логарифм. Если вы хотите попробовать какой-то символ ранжирования, я предлагаю представлять размер объемом трехмерных тел (например, кубов различных размеров). Это может помочь пользователям понять, что один шаг означает нелинейное увеличение размера. Конечно, любое графическое кодирование, использующее более одного измерения, может иметь проблемы с межстрочным интервалом в вашей таблице.
Если вы не можете использовать постоянные единицы, то хорошей альтернативой будет графическое различение символов кБ, МБ, ГБ. Я бы подумал об использовании для этого толщины шрифта. Он в некоторой степени поддается сканированию, но его реальная функция состоит в том, чтобы увеличить вероятность того, что пользователи заметят разные блоки, а не в поиске файлов определенного диапазона размеров. Это нормально, если пользователи все равно собираются загрузить файл, но просто хотят иметь возможность спланировать время загрузки.
На самом деле, если задача действительно заключается в том, чтобы пользователи находили файлы определенного диапазона размеров, сортировка или фильтрация списка по размеру файла (по умолчанию или по выбору пользователя), вероятно, является лучшим решением.
Мне нравится идея KB, т.к. большие числа будут выделяться. Затем установите ограничения и, возможно, используйте цвета css для выделения ... зеленый цвет короче, чем темнее красный, тем длиннее и т. Д.
Есть много-много способов сделать это, хотя логарифмическая шкала определенно будет необходимо. Я предлагаю использовать поле, в котором есть символ, который больше и повторяется больше для каждой степени 1000 или 1024. Примерно так:
Type Name Created Size
-------------------------------------
PDF Doc 0 01/04/2010 15 B
PDF Doc 1 01/04/2010 15 KB .
PDF Doc 2 01/04/2010 15 MB ::
PDF Doc 3 01/04/2010 15 GB |||
PDF Doc 4 01/04/2010 15 TB TTTT
PDF Doc 5 01/04/2010 15 PB PPPPP
PDF Doc 6 01/04/2010 15 EB EEEEEE