Pull to refresh

Comments 90

Ну как сказать «просто». Попробуйте с нуля реализуйте.

Колесо — просто, поэтому и гениально, а это просто отличное юзабилити, реализация которого необязательно должна быть простой, лишь бы пользователю было удобно.
Колесо само по себе бесполезно. Главным изобретением стали дороги общего пользования.
нет, человек сначала освоил подсечное земледелие и вырубил гигантские площади леса. Потом освоил стационарное земледелие (не помню, как называется) — и возникла проблема транспортировки. И только после того, как появилось достаточное количество места для того, чтобы было где катить колесо, оные колёса появились. Заметим, долгое время они конкурировали с волокушами и санями — потому что волокуши по всякой фигне лучше тащатся, чем колесо катится. И только после того, как было осознано, что по ровной поверхности колесо катится лучше, чем тащится, возникло понимание, что нужны дороги. Не себе лично, а всем.

И дороги стали первой настоящей инфраструктурной революцией. Именно дороги, а не колёса, потому что товары тягали на лошадях, на себе, по воде и на санях/волокушах, так что колесо означало лишь количественное улучшение и только в узком спектре условий.

А вот осознание необходимости совместной работы над развитием открытой инфраструктуры и гигантские инвестиции в неё (римские каменные дороги больше тысячи лет пролежали) — вот где главная сложность.

Однако, у майя и ацтеков были вполне инфраструктурная сеть дорог. А вот колеса никакого не изобрели.
Потому что им только тачки с колёсами делать и оставалось. Верховых животных не было, запрягать было некого.

Колесо — это локальная оптимизация волокуши, не более.
Запрягать было рабов.
Каменья для пирамид они же таскали как-то.
Вот как раз таскать камни для пирамид (речь про большие глыбы в многие десятки тонн) можно и нужно без колёс. Каким должно быть колесо, чтобы обеспечить меньшее трение в оси (!) для 10Т глыбы? На деревянных перекаточках самое то.

Для остальных же грузов колёса или не колёса — вопрос числа затрачиваемых усилий.

Качественные (а не количественные) изменения от колеса:

ручная транспортировка тяжёлых объектов (артиллерия, баллисты и т.д.)
скорость движения (в основном военное применение)
самодвижущаяся сила, толкающаяс колёса. А это уже XIX век.

Другими словами, я бы не был столь восторжен относительно значимости колеса в древнем мире.
Каменья для пирамид они же таскали как-то.

Использовали что-то наподобие полимербетона, и никаких глыб никуда не таскали.
Это египтяне.
А мексиканские из кусков известняка.
UFO landed and left these words here
Как раз реализовать такую идею очень легко. А вот придумать эту идею, видимо, очень трудно.
Нужно отлить этот пост из чугуния и бить им всех, кто не ставит задержку без такого алгоритма. в последний раз с таким столкнулся на сайте какого-то оператора.
В посте нехватает еще информации о том, что на Амазоне невыделеные пункты меню, над которыми находится мышка также получают второстепенное выделение, даже если мышка в «синем треугольнике». По нажатию эта категория становится текущей. Это позволяет избежать эфекта «глючности», когда мышка вроде как уже над другим елементом, а ничего не происходит.
Слава разработчикам, которые думают о пользователях!
Понапихают 100500 Jquery гениальных плагинов на сайт, а потом сами ноют, что у них Хром//ФФ/Сафари/Опера всю оперативку скушали=)
Да Вы не переживайте, года через два поддержку jQuery на аппаратном уровне включат в какой-нибудь чип (в ту же видеокарту — чего в нее еще не пихали?), и все радостно будут говорить, что уж теперь тормозов ждать неоткуда. :)
… и настанет время написать новый фреймворк, с пасьянсом и гейшами
Не включат — в jquery нет ровным счетом ничего.
Не успел дополнится. Основная вещь в jQuery — это sizzle — который скрывает детали браузеров в вопросе css-query. Да, querySelectorAll работает очень странно (работает наверное даже правильно, но очень странно относительно css). Вокруг него иногда удобны обёртки. Но и включать обёртки над стандартными API которые не требуют ничего лишнего и не такие сложные — это глупость.
Но поставить фокус в строку поиска они так и не додумались, и даже более того, если сразу после загрузки ткнуть в поиск и начать набирать текст, фокус может потеряться из поля ввода, и вместо набора текст получим прыжки по всей странице.
Круто, но не очевидно и иногда дает ложные срабатывания, т.к. настоящие люди двигают мышкой не по линейке. Курсор довольно часто следует за взглядом. Посмотрел на последнее слово в следующей строке — поехал туда курсором.

Можно еще отслеживать скорость курсора. Если он движется в направлении подменю, то можно еще немного потянуть время. Если же курсор почти остановился (даже в пределах фиолетового треугольника), то лучше переключить подменю. Правда, это еще менее очевидно.
Действительно, я всегда думал почему меню амазона так «лагает» %) Вот сейчас пробую нажать на Watch Now в Unlimited Instant Videos с минимальным путем и не получается.
Так оно так на амазоне и работает. Выбираешь подменю, быстро ведёшь курсор в выпадающий список — подменю не переключаются. Если вести курсор к выпадающему списку медленно, то происходит переключение подменю. Или я Вас не так понял?
Пардон, не успел исправить. Я не настоящий — вел себя так, как хотели разработчики =( Кстати, дочитав до ссылки на амазон в начале статьи и посмотрев их меню, как-то сразу догадался о зоне направления курсора. Но статья хороша — заставила взглянуть на юзабилити меню по новому.
Поддерживаю насчёт ложных срабатываний.
А вообще я, как типичный пользователь, не имеющий никакого отношения к веб-программированию, скажу: я бы хотел сам нажимать на каждый из пунктов и спокойно читать подпункты, не переживая за то, что случайно уведу мышку не туда и придётся опять искать этот пункт и место, где я остановился. Новаторство — это хорошо, но зачастую старое лучше и удобней.
Без задержки средний пользователь потратит больше времени, да еще и разозлится.
Иногда пункты в меню такие узкие и длинные, что это превращается в настоящую эпопею.
Значит, кто-то читал Брюса Тоньяццини. А он вроде бы говорил, что меню так ведёт себя в классических маках.
Действительно, так себя и ведет. Только не знаю, можно ли считать Mac OS X 10.8.2 классическим маком.
Кстати, остановка курсора отслеживается, насколько я вижу.
Значит, вернули (с маками не имел дела, а Тоньяццини в далёком 2000-м жаловался, что в OSX этот алгоритм прикрыли)
UFO landed and left these words here
Идея и суть статьи — прекрасна. Анимированные гифки же заставляют мою голову болеть…
Гифки уместны, безусловно, но их можно было бы скрыть и показывать по клику. Когда же пытаешься прочесть текст между двумя гифками, а вокруг все мельтешит, не знаю как у вас, но у меня неприятные ощущения.
Да нормально все, просмотрел все гифы, понял все, добавил в закладки на гитхабе. Быстро, удобно, весело.
Яндекс-закладки — поставьте такую штуку! А то сил нет попадать по многоуровневому меню.
Круто конечно, но зачем такое мелькание — если я не могу прочесть контент — зачем мне его показывать?
По-моему зеленое меню (вторая картинка) — работает какраз как надо
UFO landed and left these words here
хмм…
Может 'поженить' эти способы: добавить минимальную задержку (чтобы избежать мелькания) и дать пользователю возможность беглого просмотра
Вот именно так оно и работает на маках, и маленькая задержка есть, и треугольник.
Не так как надо. Вам придется очень точно вести мышку к подменю, иначе оно исчезнет. Исчезает-то оно без задержки.

Мелькание мешает, да. Можно поставить небольшую задержку (100 мс), чтобы при уверенном вертикальном перемещении подменю не мелькали с частотой 20 fps.
Решал такую же задачу несколько иначе, ограничился лишь версткой :).
Принцип: появляющийся блок до какой то степени перекрывает родителя и сестринские элементы родителя.
А значит можно не опасаться, что пользователь будет водить курсор по диагонали.
Но спасибо, вдруг пригодится этот плагин!
UFO landed and left these words here
Поймал себя на том, что всегда в подобных ситуациях вёл мышью по строке, чтобы не переключить случайно.
Самая большая печаль этого приёма — он где-то будет внедрен, а где-то — нет. И никогда не знаешь, как поведет себя меню на незнакомом сайте: можно ли вести курсор по диагонали или лучше все-таки везде сперва вести мышку вправо, а потом выбирать пункт под-меню.

Но прием классный, возьму себе на вооружение.
Скорее будет патент и новая волна судебных исков =)
Spread the world. Чтобы что-то внедрялось, нужно не только внедрять это самому, но и рассказывать другим. Я совершенно уверен, что это будет интересно любому веб-девелоперу, и чем проще будет механизм внедрения, тем чаще эта библиотека будет использоваться. Меня как UI-шника всегда бесили баги дропдаунов — как в веб-, так и в обычных приложениях.

В общем, пост в закладки.
Кстати, это проблема не только выпадающих меню, но и других кастомных контролов. Недавно на хабре обсуждали поведение кастомного Select.
А какой правильный ответ-то на вопрос о эквивалентном сопротивлении? Я завис.
Трудная задача, которая была популярна несколько лет назад среди инженеров-электриков, состояла в следующем: для образования двумерной бесконечной сети с квадратными ячейками соединяют бесконечно большое число одноомных сопротивлений. Следовательно, в каждом узле соединяются концы четырех сопротивлений. Чему равно эквивалентное сопротивление, между узлом и одним из четырех ближайших соседних узлов. Эта задача является удивительным примером мощности принципов симметрии и суперпозиции. Пользуясь внимательно принципом суперпозиции, вы можете решить эту задачу почти в уме.

Ответ: 0.5 Ом
офф. Кстати, интересно было рассмотреть решение этой задачи при предельном переходе — строим последовательность площадок с увеличивающимся диаметром, так чтобы нужные клеммы были в центре. Так вот, оказывается, в пределе можно получить абсолютно любое значение для сопротивления — это зависит от формы границы. Более того, подобное случается не только в вымышленном мире одноомных резисторов — электрические свойства графена также сильно зависят от формы его границы.
Долго вспоминал, где же я столкнулся с такой проблемой как пользователь — и вспомнил, IDE Eclipse! Не раз матерился, как быстро нажать File -> New -> Android Project. Приходилось аккуратненько тянуть курсор.
По крайней мере, в Mac OS 10.8 работает по абсолютно аналогичному алгоритму.
То, что реализовано на сайте академии хана, тоже имеет свою «особенность»: задержка при переходе от одного списка к другому срабатывает, только когда мышь двигается вдоль сторон синего треугольника, то есть по направлению вниз-вправо или вверх-вправо.
Если перемещать мышь вертикально, неизбежно возникают случайные подвижки влево-вправо, и меню может начать вести себя с точки зрения пользователя странно.
А кто-нибудь пробовал пользовать iOS вверх ногами? Попробуйте — забавные ощущения. Тоже, видимо, при обработке касаний учитывают, что пользователь тыкает так, чтобы видеть хоть чуть-чуть куда…
Парни, вы меня простите, я не веб-программист, и, уверен, не знаю многих деталей.
Но ведь это же очевидно с точки зрения юзабилити. неужели почему только амазон это смог придумать и реализовать?

Помидорами не бросайте, мне интересен конструктивный диалог.
В веб-программировании, да и вообще в программировании встречаются люди разной квалификации. А значит и поделки у всех разные. Уверяю вас, что найдется большое количество сайтов, где затронутая проблема вовсе не самая главная. А вообще ниже ответили, что подобное реализовано в GTK.
UFO landed and left these words here
Когда вы, как разработчик, в очередной раз пытаетесь перенести на клиента вычисления (шаблоны, положение мышки и меню и др) подумайте, как долго сможет наслаждаться вашим приложением пользователь, работающий автономно.
Амазон ребята с головой и проделали большую работу в плане оптимизации, чего и вам желаю!
Не хвастовства ради, но я еще в анчале статьи дагадался о способе решения. Спасибо за статью.
Спасибо за статью. Действительно очень интересный подход.
Только треугольник лучше вычерчивать не по высоте старого меню, а по высоте свежеоткрытого (если под меню находятся другие контекстно-зависимые ссылки, то опять же не по старому меню, а по всему участку справа). Так делают GTK и Unity Globalmenu.



А вот в Qt простая задержка без отслеживания курсора. «Если вы действительно ненавидите кого-то, научите его распознавать плохой кернинг плохие меню».
Очень жаль, что в борьбе за удобство главной страницы Амазон забыл про все остальные.
Например — раздел Your Kindle Library. При удалении книжки появляется надпись «Всё ок, удалено», но сама книга при этом остаётся в списке. Причём, когда наводишь мышь на её свойства, список внезапно перегружается с потерей страницы в пейджинге.
Ещё можно отметить дикое неудобство справочной системы.
Разумеется всё это вы уже сообщили в техподдержку Amazon?
К сожалению, ни одно из моих сообщений в техподдержку Амазона не дало положительного результата. Тематика сообщений касалась другого продукта Амазона, однако, факта это не отменяет. Я решил не бороться с судьбой, и теперь, когда я вижу очередной амазоновский баг, я просто посылаю им толстый луч диареи.
Если хотите — можете сообщить.
Спасибо, любопытный анализ, но вот подпись под скриншотом с Mac OS неверна.
По приведенной Вами ссыке как раз таки пишут, что путь обозначенный зеленой стрелкой сработает в Mac OS.
UFO landed and left these words here
Все так, тем не менее скриншот вводит в заблуждение. В статье подпись под скрином говорит, что в Mac OS (классической) зеленый путь сработает, тогда как в OS X (DP) сработает только оранжевый.
Автор же обобщает это до «из-за отсутствия задержки зелёный путь не сработает», что совсем не так. И вообще, какой смысл обсуждать баги developer preview osx пятнадцать лет спустя? )
UFO landed and left these words here
Мда, в Konqueror это меню вообще не работает.
В Opera тоже
Opera
Version
12.16
Build
1860
Platform
Linux
System
x86_64

CSS3 и JS и вещи прекрасные, но участь, скорее всего, будет такая же как у flash.
в Konqueror это меню вообще не работает
Попробуйте в lynx.
участь, скорее всего, будет такая же как у flash.
даешь статические странички без ничего и «хомяков» на перловом CGI! :)
Only those users with full accounts are able to leave comments. Log in, please.