Pull to refresh

Comments 27

А теперь, пожалуйста, от слов – к делу!

Как мне это всё сделать?

Подкиньте технической информации в топку топик. Как, например, приоритезировать ajax-запросы в javascript (это вообще возможно)? Опубликуйте свои инструменты – все посмотрят и начнут их использовать, доработают или переработают.
Статья, я думая, достигла цели «указать на проблему», и даже «указать в сторону решений проблемы». Это уже много.
Разве ссылок + view source не достаточно, для умного человека? Хаять легко — уверен, что при видимом интересе несколько человек опишут технические моменты. IT — это широкая, быстроизменяющаяся, сфера, и нет смысла описывать все know-how, если они не нужны.
Принципы и подходы показаны. А что, конкретно, сделать — это слишком широкий вопрос (Честно честно).

Не факт, что это направление, реально кому-то интересно. А трудоёмкость создания подобных вещей раза в 3 выше, чем при традиционных подходах.
У меня к примеру, внутренняя дока, по куску, который описывает принципы построения domain model, для dirty read занимает 50 килобайт (это не статья, а выжимка).
Отличная статья. Я сам испытываю большое раздражение видя индикатор загрузки, когда ожидаются совсем не то, что мне нужно именно в этот момент.
Полтора года назад, когда я только начал, пересмотрел все доступные (на тот момент) фреймворки. К сожалению, самое близкое, что было найдено — google closure library.
Толстая модель с чтением грязных данных, ленивая загрузка с кэшированием, использование объектной модели контролов вместо шаблонов, нотификации, ивенты, предугадывание поведение пользователя…
При доведении цели SUBJ к абсолюту приходится использовать совершенно другие patterns, чем при обычном подходе.

Автор на столько скромен, что самое интересное написал в разделе с пометкой «можно не читать» ;)
Несмотря на то что по скорости работы претензий к seesu.me не возникало, дизайн у сайта крайне неудобный и непонятный, можно сказать худший из всех плееров которыми я пользовался.
Ну и соответственно дико видеть какие-то советы по дизайну от автора этого сайта…
Он не подходит под ваши сценарии/привычки — и только. А мне, например, подошёл лучше обычных винампообразных плееров.
советы не про абстрактный дизайн, а про создание интерфейсов с которыми можно быстро взаимодействовать — о том, к чему у вас претензий нет ;)

интересно было бы узнать почему идеи Джефа Раскина не позволяют создавать удобные унтерфейсы, или в чем приложение противоречит его идеям
В том-то и дело что в результате оптимизации работы интерфейса им стало неудобно пользоваться. И в посте есть и про дизайн, просто в тесной сцепке с производительностью, например:
«Комбинация трех этих подходов и относительно фиксированное расположение, высота и ширина визуальных блоков позволяют осуществлять комфортное и крайне быстрое перемещение внутри приложения, формирующееся в привычку.»

Хотя я наверно ошибся с термином, точнее будет сказать не дизайн, а интерфейс — взаимодействие с пользователем.
а в чем собственно неудобство?
Очень непонятный механизм управления — практически на каждом шагу приходится некоторое время искать и думать что же тут надо/можно нажать чтобы получить результат.
Я не дизайнер и не могу сказать какие конкретно элементы интерфейса создают такой эффект, но как вы видите из других комментариев, так сайт воспринимаю не только я.

Могу только привести примеры — хочу послушать музыку 90х, выбираю «90х» и сразу затык — куда дальше? После раздумий — нажимаю «Композиции/лучшее» — и опять неясно куда дальше нажать… После раздумий и экспериментов оказывается что нужно опять нажать «лучшее», после чего появляется список песен и не играет — нужно самому ткнуть на любую композицию.
Ну и конечно кнопка «Следующий» при проигрывании трека отлично «заметна и понятна» для новичка.
«какие-то советы по дизайну от автора» автор вроде бы и не давал по дизайну советов, он рассказал о своих наработках в технологии быстрого взаимодействия с интерфейсом.
Интерфейс НЕ дизайн.
Хотя я тоже ничего не понял, куда нажимать сразу. Но обсуждение дизайна выходит за рамки статьи.
это комментарий ненависти заколебавшегося пользователя интернета.

Честно говоря, ненавижу сайты, которые загружаются моментально, но без контента. Вместо него крутится индикатор загрузки, и зачастую крутится неприемлимо долго, так что я всё равно ухожу с сайта. Кроме того у меня отключен яваскрипт в целях безопасности, и такими сайтами просто невозможно пользоваться. Мне наплевать на 100500 рюшечек, виджетов, кнопочек; я пришел на сайт за нужной мне информацией (которая чаще всего текстовая). Отдельно посылаю лучи ненависти платформе gawker.
Вы описали ситуацию под названием «Плохо» с картинки
habr.habrastorage.org/post_images/44e/74a/813/44e74a813a70bdc1da54885d31d26100.png
интерфейсы, сделанные подобным образом, действительно вызывают крайне неприятные ощущения.

В статье я рассказываю как сделать хорошо
Да, я это понял. Я рад что ещё есть люди у которых голова используется не только для приема пищи. Но к сожалению иногда сложно провести черту между плохо и хорошо. Тот же T-Mobile загружает навигацию и структуру быстро, а данные счета (то зачем я вообще пришел) не загружает вообще (там какая то 500 ошибка в логах). Для обычного же юзера это выглядит будто страница загрузилась, всё работает, и нужные данные вот-вот будут, но он не понятия не имеет, что сервер чихнул и их не будет никогда.
Эту статью стоит прочитать только из-за экспертов, ее комментирующих :)
Если интересует конкретика, то был доклад на UX'2010 на тему того, что быстро, а что медленно в интерфейсах
webo.in/articles/ux2010/usability-time/
Этот подход отлично работает с юзерами на медленном канале. Если канал большой, то почти моментально загружающиеся и «прыгающие» блоки (на seesu в том числе) очень раздражают. Хочется воскликнуть «Ну загрузись уже что ли в конце концов и покажи через секунду красивую страничку без уродливых пустых блоков!».
Вряд ли это только мой взгляд. Возможно, конечно, что дело в плохом дизайне seesu.
«Этот подход отлично работает с юзерами на медленном канале»
Этот подход отлично работает с юзерами на медленном канале, с юзерами сервисов с медленными серверами, с юзерами сервисов использующих api других сервисов, у которых есть throttling. Этот подход превосходно работает с быстрыми серверами, мгновенно выполняющими запросы так, что страница наполняется данными прямо во время короткой анимации переходов между экранами. (можно поправить css в сису, увеличив время, и увидеть, что именно так всё и происходит))

"«прыгающие» блоки (на seesu в том числе) очень раздражают"
В seesu нет прыгающих блоков — "… фиксированное расположение, высота и ширина визуальных блоков ..."

«Если канал большой, то почти моментально загружающиеся… »
Возможно вы просто пропустили вторую часть, но я там пишу про то, что вконтакте, например, запрещает присылать больше одного запроса в секунду, discogs запрещает загружать больше одной картинки в секунду. Чтобы отобразить полностью страницу нужно отправить больше одного запроса.

Таким образом какой бы широкий канал у вас не был — ждать вам всё равно придётся и если не пользоваться этими правилами, то ждать придётся всегда и долго.

«Ну загрузись уже что ли в конце концов и покажи через секунду красивую страничку без уродливых пустых блоков!»
Очевидно, что большой канал вас всё-таки не спасает.
Смысл подхода в том, что не нужно ждать пока выполнятся все запросы, наполняющие страницу — можно мгновенно перейти на другую страницу. После перехода данные для выбранной страницы будут загружены в первую очередь.
Посыпаю голову пеплом, вы правы, я не прав. Я вспомнил, что меня дико раздражает в интерфейсе: попробуйте зайти на любую страницу неанглоязычного музыканта из-под хрома с включенным автоматическим переводом этого языка (в данном случае финского) — гугл пытается перевести названия песен и этим дико бесит.
Можете вставить волшебный мета-тег в head?
ого, не знал про такой, обязательно добавлю. спасибо!
Для первого посещения страницы время для отображения информации, видимой на первом экране стало больше или меньше?
Мне кажется больше. Ведь вместо 1 запроса, уже будет оправлен сразу 1, а потом еще несколько. Больше всего это будет заметно на мобильном интернете.
Не понял о чем точно идет речь. Какие действия произвёл пользователь, как перемещался по страницам и какие запросы в каком порядке в этом предполагаемом случае отправлены?
Речь о первом посещение сайта. По описанной схеме: сразу идет запрос на получение самой страницы, после её получения — запросы на получение данных. Так будет дольше, чем если загрузить все сразу.
Если вы говорите о случае, когда вы загружаете структуру (шаблон) страницы отдельно, каждый раз заново, и всё это в приложении где вся логика интерфейса находится на клиентской стороне, то их можно загружать параллельно с данными. Но этом вообще речи не идёт.

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

Посмотрите сами seesu.me/o, можете попробовать засечь время за которое отображается структура страницы без данных :)
Чисто технически сайт seesu.me выполнен на высшем уровне, но похоже из Раскина вы почерпнули только технический аспект работы программ, большая часть идей книги «Интерфейс» осталась явно за бортом.
О каких конкретно, оставшихся за бортом, идеях идет речь?
Режимы в интерфейсе. Отключите звук в колонках, потом представьте что вы забыли как пользоваться вашим сайтом и попробуйте догадаться будет ли играть звук если нажать на круглую кнопку с треугольником. Т.е. один элемент управления делает 2 абсолютно противоположных действия, причем невозможно чисто по внешним признакам определить что именно он будет делать если его активировать.
Кнопка воспроизведения, с режимом (а ещё с индикатором и устройством выключателя света), которая не обязана своим видом помогать что будет происходить (нет я не строил интуитивно понятный интерфейс — Раскин против) и есть оставшаяся за бортом большая часть идей? Серьёзно?
Нет. Я пошутил. Догадаться о том, играет ли музыка можно только по анимации эквалайзера, сама кнопка не несет полезной информации. Совсем. Если вы думаете иначе — это заблуждение, но слава богу я не смогу вам ничего доказать потому что я всего лишь некомпетентный почти анонимус с хабра.
Only those users with full accounts are able to leave comments. Log in, please.