Не сталкивался ли кто с использованием принципа "увеличение высоты выделенной строки в списке/Гриде”? То есть:
— Есть Список (Таблица, Грид)
— "выделенная" строка выделяется не только цветом (обычное решение), но и – дополнительно – увеличением её высоты (по сравнению в не-выделенными строками).
Вариант – "увеличение высоты выделенной строки" применяется не дополнительно к выделению цветом, а вместо него.
Здравствуйте, Glenn, Вы писали:
G>Не сталкивался ли кто с использованием принципа "увеличение высоты выделенной строки в списке/Гриде”? То есть: G>- Есть Список (Таблица, Грид) G>- "выделенная" строка выделяется не только цветом (обычное решение), но и – дополнительно – увеличением её высоты (по сравнению в не-выделенными строками). G>Вариант – "увеличение высоты выделенной строки" применяется не дополнительно к выделению цветом, а вместо него.
Здравствуйте, Glenn, Вы писали:
G>Не сталкивался ли кто с использованием принципа "увеличение высоты выделенной строки в списке/Гриде”? То есть: G>- Есть Список (Таблица, Грид) G>- "выделенная" строка выделяется не только цветом (обычное решение), но и – дополнительно – увеличением её высоты (по сравнению в не-выделенными строками). G>Вариант – "увеличение высоты выделенной строки" применяется не дополнительно к выделению цветом, а вместо него.
Мне кажется неудачным такое решение — менять ширину шрифта выделенного текста.
(А изменение высоты влечёт и изменение ширины; но, к примеру, жирность тоже меняет ширину у пропорциональных шрифтов).
Потому что при этом текст не только выделяется, но и выбивается из колонки подобных ему.
Особенно, если ширина колонки подобрана минимально, чтобы вмещать текст. Например, время в формате hh:mm.
И тут вдруг, в одной строке, текст вылез за рамку.
Варианты решения:
— моноширинная гарнитура, в чьём семействе жирное и обычное начертание имеют одинаковую ширину (к сожалению, это не у всех гарнитур так — из-за чего, например, "дышит" табуляция в IDE).
— компенсация трекингом (уплотнение увеличенного текста или разрежение обычного)
Перекуём баги на фичи!
Re[2]: Использование принципа "увеличение высоты текущей строки в списке”
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Glenn, Вы писали:
G>>Не сталкивался ли кто с использованием принципа "увеличение высоты выделенной строки в списке/Гриде”? То есть: G>>- Есть Список (Таблица, Грид) G>>- "выделенная" строка выделяется не только цветом (обычное решение), но и – дополнительно – увеличением её высоты (по сравнению в не-выделенными строками). G>>Вариант – "увеличение высоты выделенной строки" применяется не дополнительно к выделению цветом, а вместо него.
К>Мне кажется неудачным такое решение — менять ширину шрифта выделенного текста. К>(А изменение высоты влечёт и изменение ширины; но, к примеру, жирность тоже меняет ширину у пропорциональных шрифтов).
К>Потому что при этом текст не только выделяется, но и выбивается из колонки подобных ему.
К>Особенно, если ширина колонки подобрана минимально, чтобы вмещать текст. Например, время в формате hh:mm. К>И тут вдруг, в одной строке, текст вылез за рамку.
К>Варианты решения: К>- моноширинная гарнитура, в чьём семействе жирное и обычное начертание имеют одинаковую ширину (к сожалению, это не у всех гарнитур так — из-за чего, например, "дышит" табуляция в IDE). К>- компенсация трекингом (уплотнение увеличенного текста или разрежение обычного)
хм, а я об этом никогда и не думал; меня интересовал только параметр "font size".... Я и не думал о том чтобы изменить ВЫСОТУ шрифта без изменения ШИРИНЫ.
Glen
Re[3]: Использование принципа "увеличение высоты текущей строки в списке”
Здравствуйте, Glenn, Вы писали:
G>хм, а я об этом никогда и не думал; меня интересовал только параметр "font size".... Я и не думал о том чтобы изменить ВЫСОТУ шрифта без изменения ШИРИНЫ.
Ну вот я и говорю: в таблицах игра с высотой шрифта (и, пропорционально, с шириной) — не лучшая идея.
В списках, где нет акцента на вертикальной сетке, — ещё куда ни шло.
И то, если при этом скачет не только высота шрифта, но и высота всей строки, — выбор другой строки (мышкой или клавиатурной навигацией) приведёт к подёргиванию строк, что не очень радует глаз.
Перекуём баги на фичи!
Re[4]: Использование принципа "увеличение высоты текущей строки в списке”
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Glenn, Вы писали:
G>>хм, а я об этом никогда и не думал; меня интересовал только параметр "font size".... Я и не думал о том чтобы изменить ВЫСОТУ шрифта без изменения ШИРИНЫ.
К>Ну вот я и говорю: в таблицах игра с высотой шрифта (и, пропорционально, с шириной) — не лучшая идея.
К>В списках, где нет акцента на вертикальной сетке, — ещё куда ни шло. К>И то, если при этом скачет не только высота шрифта, но и высота всей строки, — выбор другой строки (мышкой или клавиатурной навигацией) приведёт к подёргиванию строк, что не очень радует глаз.
А вот гляньте (здесь — это Silverlight-приложение) пример такого списка.
Как по-Вашему — это "подёргивание" — "терпимо" или нет?
Glen
Re[5]: Использование принципа "увеличение высоты текущей строки в списке”
Здравствуйте, Glenn, Вы писали:
G>А вот гляньте (здесь — это Silverlight-приложение) пример такого списка. G>Как по-Вашему — это "подёргивание" — "терпимо" или нет?
У меня в мунлайте это глючит и дёргается, произвольно меняя или не меняя шрифт.
Как оно в оригинальном силверлайте работает, могу догадаться...
Пока курсор над элементами списка, это выглядит приемлемо, словно водишь лупой над текстом. Как только курсор с элементов уведён, то суммарная высота списка уменьшается, текст дёргается вверх. Это неприятно.
Здравствуйте, Glenn, Вы писали:
G>А ЗДЕСЬ увеличивается ещё и ВЫСОТА самого списка при попадании в него крсора. В результате и надпись "After" тоже съезжает вниз. G>Мне кажется — "менее болезненным" будет МОЙ вариант, при котором по крайней мере контур ListBox-а (и всё что под ним) остаётся на месте...
http://files.rsdn.ru/4783/hoverzoom2.htm
Зафиксировал высоту списка. Дёргание текста теперь локализовано...
Не смог с разбегу сделать честный listbox с тем же эффектом, ну да бог с ним пока. (В принципе, там и скролл можно присобачить; и реакцию на выбор, и даже навигацию клавиатурой, хотя это уже будет скрипт, а не чистый css).
Ну, не могу сказать, что мне такой контрол шибко нравится.
Перекуём баги на фичи!
Re[5]: Использование принципа "увеличение высоты текущей строки в списке”
Здравствуйте, Glenn, Вы писали:
G>А вот гляньте (здесь — это Silverlight-приложение) пример такого списка. G>Как по-Вашему — это "подёргивание" — "терпимо" или нет?
И какую задачу оно решает? Для слабовидящих лучше всё и сразу увеличивать, а размеры строк должны быть адаптированы под размер курсора/пальца/... и смысла в упрощении прицеливания быть не должно. Вообще встречал где-то давно увеличение высоты выделенной строки (не той, что под мышкой сейчас находится, а именно на которую с клавиатуры перешли или по которой мышой кликнули), но там не шрифт менялся, а объем информации. В выделенной строке появлялась еще строка (соответственно, другим шрифтом, чтобы не путать пользователя), в которой содержалась более подробная информация (возможно, какое-то описание элемента или url). Где-то еще попадалось, что добавлялась строка с "гиперссылками" типа: "изменить | удалить", для проведения операций над выделенным элементом.
Так же, если и использовать эту штуку, то:
— хотя бы один элемент должен быть всегда выделен, а иначе начнутся появления/исчезания скроллбаров;
— оно должно в итоге приносить пользу для пользователя, а не просто на экране мельтешить. Сейчас с тем же успехом можно элементы под мышкой подсвечивать другим цветом и эффект будет тот же. Если у людей проблемы с чтением списка, то тут шрифт во всём списке менять нужно, а не заставлять человека водить мышкой по экрану, аки пальцем по книге;
— высота выделенной строки не должна быть близка к высоте двух обычных строк, т.к. строки прыгать при навигации начнут слишком сильно.
Re[6]: Использование принципа "увеличение высоты текущей строки в списке”
Здравствуйте, pu4koff, Вы писали:
P>Здравствуйте, Glenn, Вы писали:
G>>А вот гляньте (здесь — это Silverlight-приложение) пример такого списка. G>>Как по-Вашему — это "подёргивание" — "терпимо" или нет?
P>И какую задачу оно решает?
Сценарий использования такого решения (в морйм приложении) я описал вот здесь
Надо сказать, ТАМ об этом просил сам Заказчик.
А эту дискуссию на форуме я затеял чтобы узнать — кто и в каких условиях ещё (кроме меня) применял этот вот приём.
Glen
Re[7]: Использование принципа "увеличение высоты текущей строки в списке”
Здравствуйте, Glenn, Вы писали:
G>Надо сказать, ТАМ об этом просил сам Заказчик. G>А эту дискуссию на форуме я затеял чтобы узнать — кто и в каких условиях ещё (кроме меня) применял этот вот приём.
Диалог Windows XP "Add or Remove Programs" так делает. Имхо, юзабельно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[8]: Использование принципа "увеличение высоты текущей строки в списке”
Здравствуйте, Кодт, Вы писали:
.>>Диалог Windows XP "Add or Remove Programs" так делает. Имхо, юзабельно. К>Имхо, ужасно! Там, правда, всё приложение ужасно, включая и заморозки на старте, и тормозливость в навигации.
Эээ... Так тормозящий интерфейс в любом виде ужастен... Если абстрагироваться от тормозов, то сам такой изменяющийстя список юзать можно в некоторых случаях.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[10]: Использование принципа "увеличение высоты текущей строки в списке”
Здравствуйте, ., Вы писали:
.>Здравствуйте, Кодт, Вы писали:
.>>>Диалог Windows XP "Add or Remove Programs" так делает. Имхо, юзабельно. К>>Имхо, ужасно! Там, правда, всё приложение ужасно, включая и заморозки на старте, и тормозливость в навигации. .>Эээ... Так тормозящий интерфейс в любом виде ужастен... Если абстрагироваться от тормозов, то сам такой изменяющийстя список юзать можно в некоторых случаях.
да; так может кто назвать ЕЩЁ примеры использования этого подхода?
Glen
Re[7]: Использование принципа "увеличение высоты текущей строки в списке”
Здравствуйте, Glenn, Вы писали: G>Сценарий использования такого решения (в морйм приложении) я описал вот здесь
G>Надо сказать, ТАМ об этом просил сам Заказчик.
1. А почему так получалось, что надо вычитывать кучу строк? Не было варианта как-то сократить список вариантов сразу при поиске?
2. Почему нельзя было увеличить шрифт сразу всем строкам — чтобы не уставали глаза?
3. Что именно "вычитывали" в этих строках пользователи? Точное написание? Искали определённые ключевые слова?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Использование принципа "увеличение высоты текущей строки в списке”
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Glenn, Вы писали: G>>Сценарий использования такого решения (в морйм приложении) я описал вот здесь
G>>Надо сказать, ТАМ об этом просил сам Заказчик. S>1. А почему так получалось, что надо вычитывать кучу строк? Не было варианта как-то сократить список вариантов сразу при поиске? S>2. Почему нельзя было увеличить шрифт сразу всем строкам — чтобы не уставали глаза? S>3. Что именно "вычитывали" в этих строках пользователи? Точное написание? Искали определённые ключевые слова?
“1. А почему так получалось, что надо вычитывать кучу строк? Не было варианта как-то сократить список вариантов сразу при поиске?”
“3. Что именно "вычитывали" в этих строках пользователи? Точное написание? Искали определённые ключевые слова?”
Тот поиск был “нечетким”(fuzzy), в котором например найденное строковое значение совсем не обязательно строго содержит поисковый запрос в качество подстроки (как это принято в “простых” поисках.)
Можно привести аналогию с поиском в том же google – когда Вы просматриваете результаты некоего сложного поиска. “Сложного” — то есть такого где Вы заранее не знаете как будет «с точностью до символа” выглядеть найденный результат. В этом случае Вы именно “вчитываетесь” в каждый из найденных Результатов Поиска, чтобы понять – это “то” или “не то”
” 2. Почему нельзя было увеличить шрифт сразу всем строкам — чтобы не уставали глаза?”
Тогда уменьшилось бы количество строк отображаемых тем ListBox-ом одновременно. Так сказать – “вытащили хвост – голова увязла” :)
Наращивание высоты текущей строки как раз и должно было решить вот это противоречие: c одной стороны, текст должен быть (для более легкого чтения) размером побольше; а с другой стороны – такой “высокий” текст занимает много места, уменьшая количество информации которое можно “впихнуть в экран”
Перекуём баги на фичи!
