Comments 27
А теперь, пожалуйста, от слов – к делу!
Как мне это всё сделать?
Подкиньте технической информации втопку топик. Как, например, приоритезировать ajax-запросы в javascript (это вообще возможно)? Опубликуйте свои инструменты – все посмотрят и начнут их использовать, доработают или переработают.
Как мне это всё сделать?
Подкиньте технической информации в
Статья, я думая, достигла цели «указать на проблему», и даже «указать в сторону решений проблемы». Это уже много.
Разве ссылок + view source не достаточно, для умного человека? Хаять легко — уверен, что при видимом интересе несколько человек опишут технические моменты. IT — это широкая, быстроизменяющаяся, сфера, и нет смысла описывать все know-how, если они не нужны.
Принципы и подходы показаны. А что, конкретно, сделать — это слишком широкий вопрос (Честно честно).
Не факт, что это направление, реально кому-то интересно. А трудоёмкость создания подобных вещей раза в 3 выше, чем при традиционных подходах.
У меня к примеру, внутренняя дока, по куску, который описывает принципы построения domain model, для dirty read занимает 50 килобайт (это не статья, а выжимка).
Разве ссылок + view source не достаточно, для умного человека? Хаять легко — уверен, что при видимом интересе несколько человек опишут технические моменты. IT — это широкая, быстроизменяющаяся, сфера, и нет смысла описывать все know-how, если они не нужны.
Принципы и подходы показаны. А что, конкретно, сделать — это слишком широкий вопрос (Честно честно).
Не факт, что это направление, реально кому-то интересно. А трудоёмкость создания подобных вещей раза в 3 выше, чем при традиционных подходах.
У меня к примеру, внутренняя дока, по куску, который описывает принципы построения domain model, для dirty read занимает 50 килобайт (это не статья, а выжимка).
Отличная статья. Я сам испытываю большое раздражение видя индикатор загрузки, когда ожидаются совсем не то, что мне нужно именно в этот момент.
Полтора года назад, когда я только начал, пересмотрел все доступные (на тот момент) фреймворки. К сожалению, самое близкое, что было найдено — google closure library.
Толстая модель с чтением грязных данных, ленивая загрузка с кэшированием, использование объектной модели контролов вместо шаблонов, нотификации, ивенты, предугадывание поведение пользователя…
При доведении цели SUBJ к абсолюту приходится использовать совершенно другие patterns, чем при обычном подходе.
Автор на столько скромен, что самое интересное написал в разделе с пометкой «можно не читать» ;)
Полтора года назад, когда я только начал, пересмотрел все доступные (на тот момент) фреймворки. К сожалению, самое близкое, что было найдено — google closure library.
Толстая модель с чтением грязных данных, ленивая загрузка с кэшированием, использование объектной модели контролов вместо шаблонов, нотификации, ивенты, предугадывание поведение пользователя…
При доведении цели SUBJ к абсолюту приходится использовать совершенно другие patterns, чем при обычном подходе.
Автор на столько скромен, что самое интересное написал в разделе с пометкой «можно не читать» ;)
Несмотря на то что по скорости работы претензий к seesu.me не возникало, дизайн у сайта крайне неудобный и непонятный, можно сказать худший из всех плееров которыми я пользовался.
Ну и соответственно дико видеть какие-то советы по дизайну от автора этого сайта…
Ну и соответственно дико видеть какие-то советы по дизайну от автора этого сайта…
Он не подходит под ваши сценарии/привычки — и только. А мне, например, подошёл лучше обычных винампообразных плееров.
советы не про абстрактный дизайн, а про создание интерфейсов с которыми можно быстро взаимодействовать — о том, к чему у вас претензий нет ;)
интересно было бы узнать почему идеи Джефа Раскина не позволяют создавать удобные унтерфейсы, или в чем приложение противоречит его идеям
интересно было бы узнать почему идеи Джефа Раскина не позволяют создавать удобные унтерфейсы, или в чем приложение противоречит его идеям
В том-то и дело что в результате оптимизации работы интерфейса им стало неудобно пользоваться. И в посте есть и про дизайн, просто в тесной сцепке с производительностью, например:
«Комбинация трех этих подходов и относительно фиксированное расположение, высота и ширина визуальных блоков позволяют осуществлять комфортное и крайне быстрое перемещение внутри приложения, формирующееся в привычку.»
Хотя я наверно ошибся с термином, точнее будет сказать не дизайн, а интерфейс — взаимодействие с пользователем.
«Комбинация трех этих подходов и относительно фиксированное расположение, высота и ширина визуальных блоков позволяют осуществлять комфортное и крайне быстрое перемещение внутри приложения, формирующееся в привычку.»
Хотя я наверно ошибся с термином, точнее будет сказать не дизайн, а интерфейс — взаимодействие с пользователем.
а в чем собственно неудобство?
Очень непонятный механизм управления — практически на каждом шагу приходится некоторое время искать и думать что же тут надо/можно нажать чтобы получить результат.
Я не дизайнер и не могу сказать какие конкретно элементы интерфейса создают такой эффект, но как вы видите из других комментариев, так сайт воспринимаю не только я.
Могу только привести примеры — хочу послушать музыку 90х, выбираю «90х» и сразу затык — куда дальше? После раздумий — нажимаю «Композиции/лучшее» — и опять неясно куда дальше нажать… После раздумий и экспериментов оказывается что нужно опять нажать «лучшее», после чего появляется список песен и не играет — нужно самому ткнуть на любую композицию.
Ну и конечно кнопка «Следующий» при проигрывании трека отлично «заметна и понятна» для новичка.
Я не дизайнер и не могу сказать какие конкретно элементы интерфейса создают такой эффект, но как вы видите из других комментариев, так сайт воспринимаю не только я.
Могу только привести примеры — хочу послушать музыку 90х, выбираю «90х» и сразу затык — куда дальше? После раздумий — нажимаю «Композиции/лучшее» — и опять неясно куда дальше нажать… После раздумий и экспериментов оказывается что нужно опять нажать «лучшее», после чего появляется список песен и не играет — нужно самому ткнуть на любую композицию.
Ну и конечно кнопка «Следующий» при проигрывании трека отлично «заметна и понятна» для новичка.
«какие-то советы по дизайну от автора» автор вроде бы и не давал по дизайну советов, он рассказал о своих наработках в технологии быстрого взаимодействия с интерфейсом.
Интерфейс НЕ дизайн.
Хотя я тоже ничего не понял, куда нажимать сразу. Но обсуждение дизайна выходит за рамки статьи.
Интерфейс НЕ дизайн.
Хотя я тоже ничего не понял, куда нажимать сразу. Но обсуждение дизайна выходит за рамки статьи.
UFO just landed and posted this here
Вы описали ситуацию под названием «Плохо» с картинки
habr.habrastorage.org/post_images/44e/74a/813/44e74a813a70bdc1da54885d31d26100.png
интерфейсы, сделанные подобным образом, действительно вызывают крайне неприятные ощущения.
В статье я рассказываю как сделать хорошо
habr.habrastorage.org/post_images/44e/74a/813/44e74a813a70bdc1da54885d31d26100.png
интерфейсы, сделанные подобным образом, действительно вызывают крайне неприятные ощущения.
В статье я рассказываю как сделать хорошо
Эту статью стоит прочитать только из-за экспертов, ее комментирующих :)
Если интересует конкретика, то был доклад на UX'2010 на тему того, что быстро, а что медленно в интерфейсах
webo.in/articles/ux2010/usability-time/
Если интересует конкретика, то был доклад на UX'2010 на тему того, что быстро, а что медленно в интерфейсах
webo.in/articles/ux2010/usability-time/
Этот подход отлично работает с юзерами на медленном канале. Если канал большой, то почти моментально загружающиеся и «прыгающие» блоки (на seesu в том числе) очень раздражают. Хочется воскликнуть «Ну загрузись уже что ли в конце концов и покажи через секунду красивую страничку без уродливых пустых блоков!».
Вряд ли это только мой взгляд. Возможно, конечно, что дело в плохом дизайне seesu.
Вряд ли это только мой взгляд. Возможно, конечно, что дело в плохом дизайне seesu.
«Этот подход отлично работает с юзерами на медленном канале»
Этот подход отлично работает с юзерами на медленном канале, с юзерами сервисов с медленными серверами, с юзерами сервисов использующих api других сервисов, у которых есть throttling. Этот подход превосходно работает с быстрыми серверами, мгновенно выполняющими запросы так, что страница наполняется данными прямо во время короткой анимации переходов между экранами. (можно поправить css в сису, увеличив время, и увидеть, что именно так всё и происходит))
"«прыгающие» блоки (на seesu в том числе) очень раздражают"
В seesu нет прыгающих блоков — "… фиксированное расположение, высота и ширина визуальных блоков ..."
«Если канал большой, то почти моментально загружающиеся… »
Возможно вы просто пропустили вторую часть, но я там пишу про то, что вконтакте, например, запрещает присылать больше одного запроса в секунду, discogs запрещает загружать больше одной картинки в секунду. Чтобы отобразить полностью страницу нужно отправить больше одного запроса.
Таким образом какой бы широкий канал у вас не был — ждать вам всё равно придётся и если не пользоваться этими правилами, то ждать придётся всегда и долго.
«Ну загрузись уже что ли в конце концов и покажи через секунду красивую страничку без уродливых пустых блоков!»
Очевидно, что большой канал вас всё-таки не спасает.
Смысл подхода в том, что не нужно ждать пока выполнятся все запросы, наполняющие страницу — можно мгновенно перейти на другую страницу. После перехода данные для выбранной страницы будут загружены в первую очередь.
Этот подход отлично работает с юзерами на медленном канале, с юзерами сервисов с медленными серверами, с юзерами сервисов использующих api других сервисов, у которых есть throttling. Этот подход превосходно работает с быстрыми серверами, мгновенно выполняющими запросы так, что страница наполняется данными прямо во время короткой анимации переходов между экранами. (можно поправить css в сису, увеличив время, и увидеть, что именно так всё и происходит))
"«прыгающие» блоки (на seesu в том числе) очень раздражают"
В seesu нет прыгающих блоков — "… фиксированное расположение, высота и ширина визуальных блоков ..."
«Если канал большой, то почти моментально загружающиеся… »
Возможно вы просто пропустили вторую часть, но я там пишу про то, что вконтакте, например, запрещает присылать больше одного запроса в секунду, discogs запрещает загружать больше одной картинки в секунду. Чтобы отобразить полностью страницу нужно отправить больше одного запроса.
Таким образом какой бы широкий канал у вас не был — ждать вам всё равно придётся и если не пользоваться этими правилами, то ждать придётся всегда и долго.
«Ну загрузись уже что ли в конце концов и покажи через секунду красивую страничку без уродливых пустых блоков!»
Очевидно, что большой канал вас всё-таки не спасает.
Смысл подхода в том, что не нужно ждать пока выполнятся все запросы, наполняющие страницу — можно мгновенно перейти на другую страницу. После перехода данные для выбранной страницы будут загружены в первую очередь.
Посыпаю голову пеплом, вы правы, я не прав. Я вспомнил, что меня дико раздражает в интерфейсе: попробуйте зайти на любую страницу неанглоязычного музыканта из-под хрома с включенным автоматическим переводом этого языка (в данном случае финского) — гугл пытается перевести названия песен и этим дико бесит.
Можете вставить волшебный мета-тег в head?
Можете вставить волшебный мета-тег в head?
Для первого посещения страницы время для отображения информации, видимой на первом экране стало больше или меньше?
Мне кажется больше. Ведь вместо 1 запроса, уже будет оправлен сразу 1, а потом еще несколько. Больше всего это будет заметно на мобильном интернете.
Мне кажется больше. Ведь вместо 1 запроса, уже будет оправлен сразу 1, а потом еще несколько. Больше всего это будет заметно на мобильном интернете.
Не понял о чем точно идет речь. Какие действия произвёл пользователь, как перемещался по страницам и какие запросы в каком порядке в этом предполагаемом случае отправлены?
Речь о первом посещение сайта. По описанной схеме: сразу идет запрос на получение самой страницы, после её получения — запросы на получение данных. Так будет дольше, чем если загрузить все сразу.
Если вы говорите о случае, когда вы загружаете структуру (шаблон) страницы отдельно, каждый раз заново, и всё это в приложении где вся логика интерфейса находится на клиентской стороне, то их можно загружать параллельно с данными. Но этом вообще речи не идёт.
Речь идёт о приложениях в которых шаблоны, (структуры страниц) уже загружены к моменту когда пользователь начинает взаимодействовать с приложением. Эти принципы касаются и полноценных веб приложений и нативных приложений.
Посмотрите сами seesu.me/o, можете попробовать засечь время за которое отображается структура страницы без данных :)
Речь идёт о приложениях в которых шаблоны, (структуры страниц) уже загружены к моменту когда пользователь начинает взаимодействовать с приложением. Эти принципы касаются и полноценных веб приложений и нативных приложений.
Посмотрите сами seesu.me/o, можете попробовать засечь время за которое отображается структура страницы без данных :)
Чисто технически сайт seesu.me выполнен на высшем уровне, но похоже из Раскина вы почерпнули только технический аспект работы программ, большая часть идей книги «Интерфейс» осталась явно за бортом.
О каких конкретно, оставшихся за бортом, идеях идет речь?
Режимы в интерфейсе. Отключите звук в колонках, потом представьте что вы забыли как пользоваться вашим сайтом и попробуйте догадаться будет ли играть звук если нажать на круглую кнопку с треугольником. Т.е. один элемент управления делает 2 абсолютно противоположных действия, причем невозможно чисто по внешним признакам определить что именно он будет делать если его активировать.
Sign up to leave a comment.
Три правила проектирования интерфейсов с высокоскоростным пользовательским взаимодействием