Път на курсора над менюто
Говорим за падащи менюта, в които елементите се избират просто чрез движение на мишката, без щракване. Това е начинът, по който работи във всички усъвършенствани прозоречни среди.
Представете си отворено вертикално изскачащо меню с избран горен елемент, което води до подменю, което веднага се отваря вдясно (за простота нека приемем, че има много места отдясно и отдолу).
Всички елементи от това подменю, с изключение на първия, са разположени под курсора на мишката и ако преместите мишката директно върху някой от тях, показалецът неизбежно ще премине през долните елементи на първото меню. Така че на теория тези елементи трябва да бъдат незабавно маркирани и подменюто, отворено от първото, трябва да бъде затворено.
Но това не се случва. Всички нормални прозоречни среди имат специална логика, която следи това движение и ако то "изглежда" като движение към подменю, го държи затворено. Това се прави, защото за човек е по-трудно и по-бавно да движи мишката строго в хоризонтална и вертикална посока и почти всички хора, когато изберат елемент от подменюто, движат мишката, макар и не точно направо, но много подрязват ъглите.
Самата логика на програмата, между другото, е доста сложна, едно изчакване за затваряне на менюто тук не е достатъчно. В крайна сметка, ако потребителят премести мишката по-вертикално, за да отвори друго подменю, тогава забавянето при затварянето на първото ще го забави. Освен това, ако преместите мишката по прекия път обратно от подменюто към главното меню, подменюто трябва да се затвори незабавно (проверете!).
Между другото, няма такава логика в падащите менюта на уеб страниците. Браузърите не могат да го приложат, защото няма един стандартен начин за създаване на меню, а за браузъра това е просто част от скрипт и HTML с различна степен на изящество. Но уеб разработчиците не го правятимплементирайте го в скриптове, защото, казано направо, програмирането е глупаво.
Това е една от причините, поради които падащите менюта в мрежата са значително по-трудни за използване: те винаги се опитват да избягат изпод ръката ви.
P.S. Между другото, това е още една илюстрация на факта, че програмирането на контролите на потребителския интерфейс е трудно.
Коментари: 14
Нещо не наблюдавам такова поведение в Windows XP. Подменюто се затваря веднага.
Има ли точка в менюто за уеб? само ако е в 2.0, и то с разтягане.
ПС: Иване, най-после сложи лого на фида си! и тогава чета и не винаги виждам някого :)
Освен това, ако преместите мишката по прекия път обратно от подменюто към главното меню, подменюто трябва да се затвори незабавно (проверете!).
Отметнато - В Windows XP забавянето е същото, както ако задържа курсора на мишката над отварящото меню, така че да се отвори, но след това свалих мишката (т.е. не бих поставил курсора на мишката върху дъщерното меню) и изчаках, докато това дъщерно меню се затвори.
Времето за изчакване не е за затваряне на менюто, а за отваряне при задържане на курсора на мишката върху родителския елемент. Ако искате детето да се отвори веднага, просто щракнете върху него, ако щракнете върху него, изчакайте зададения в системата интервал. И - да, затварянето не работи в прозорците веднага, ако преместите мишката в обратна посока от отворената страна. Възможно е да работи на вашия екран (какво е това между другото? gnome?).
тук всичко е просто. ако мишката се движи, не правете нищо. веднага щом мишката спре - отворете ново меню. :)
отидете на Icq=214889076, да поговорим.
Да, това означава, че се запалих по Windows за обратното движение. Фалшива памет, явно :-).
И да, имам Gnome.
Прочетох този запис в FF (Win), веднага го проверявам: има банално изчакване за затваряне на подменюто. Меню 2-рониво се затваря приблизително една секунда, след като мишката напусне родителския елемент от менюто на 1-во ниво. Когато се движите през елементите на менюто от 1-во ниво, те се маркират, но съответното подменю от 2-ро ниво не се отваря, докато не се затвори предварително отвореното подменю и докато курсорът не спре на който и да е елемент (т.е. изчакването за отваряне също е изчакване, но по-малко, около половин секунда).
Тоест, да, системата не е съвсем тривиална (и съм напълно съгласен с последните ви два абзаца), но не и ракетната наука.
Има ли нужда някой от такава сложна логика? Потребителят се чувства много по-комфортно, когато нещата се държат както трябва, а не прилага нечия луда идея за използваемост. Вероятно това е причината Microsoft глупаво да се ограничи до таймаут.
Е, вече се справихме с Windows - всичко наистина е както всички пишат.
Но що се отнася до Firefox, не бих проверявал поведението на системата с него, защото XUL, въпреки че се опитва да съобрази максимално това поведение, не работи навсякъде. Сега проверих в моя Ubuntu: Firefox също не затваря моментално дъщерните менюта, когато се премести към родителя. A Gnome'ovskoe меню - затваря.
Има подозрение, че имате - като антракт :-)
Тоест, ако направите класация, че такива неща (безспорно интересни сами по себе си) попадат в третия, дори в четвъртия ешелон. Баналната цветова схема или шрифт за интерфейса е много по-важна.
Точно по Прутков - хвърляйте камъни във водата, гледайте кръговете, в противен случай това ще бъде загуба на време :-)
Еха. Намерих това в xfce, да. Ако карате по диагонал, тогава (о, чудо!) Менюто не се превключва. И ако преместите мишката надолу и след това надясно, тя веднага се скрива.
ps: да живее ubuntu!
Нека ви разкажа малко за това как си го представям. :) Таймерът започва вв момента, в който елемент от менюто е избран с мишката. Ако не е избран друг елемент по време на определеното време за изчакване (докато мишката може да се движи в текущия елемент), затворете старото подменю и отворете подменюто на текущия елемент. Имплементира се просто и се държи доста предвидимо за потребителя.
Когато компанията, в която работя, трябваше да коригира подобно глобално изскачащо меню за интранет, аз реших проблема по различен начин, без да включвам js само с css. Около всеки блок от менюто направих прозрачна защитна зона от няколко десетки пиксела, при натискане върху която менюто няма да се свие (тоест всъщност показалецът на мишката остава в този блок). Това елиминира проблема с изрязаните ъгли и неволното движение на показалеца на мишката извън границите на изскачащия блок (особено спешен проблем за потребителите с тъчпад). Тази схема работи вече 3 месеца и досега няма оплаквания. Разбира се, подходът е доста примитивен, но е лесен за изпълнение и ефективен в рамките на решаваната задача :)