Новая Яндекс-почта

[ermouth]

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

Стало почти прекрасно и наконец-то быстро.

Но есть один косячок, аналогичный гуглопочте (не в таких масштабах). В списке отправитель письма и тема набраны одним кеглем и одним цветом, поэтому и на Яндексе, и на Гмэйле список мог бы читаться лучше.

Сейчас вот так:

У Яндекса безусловно круче, чем у Гугла, в гмыле вообще жопа. Но можно ещё лучше. Вот так например у Яндекса:

И так у Гмэйла.

По Яндексу разница не так заметна на шоте, но хорошо заметна если поюзать. Гмэйл от такой замены становится значительно удобнее.

Так вот, я что думаю. Может мне плагин к хрому выставить, который правит интерфейсы этих почт? А, френды?

Comments

[mihalp.livejournal.com]

Я честно говоря вообще не понимаю откуда ты такие скрины гуглопочты взял? :) У меня отправитель и тема письма в одну строчку, а не как у тебя в две... Или я чего-то не до понимаю? :)

[ermouth.livejournal.com]

у меня трёхпанельный режим, "Разделение по вертикали"

[morfizm.livejournal.com]

Я уже много лет использую Аутлук (+remote desktop для доступа к почте с других компов). Очень рад, что мне не надо тратить время на все эти улучшения/ухудшения веб интерфейсов, установку плагинов и пр. гемор. :)

[dennyrolling.livejournal.com]

когда делали новый интерфейс гмыла то мы его внутри догфудили. одна из самых больших проблем этого интерфейса была в том что не было способа сделать "компактную" моду (ну не написали еще). сначала я просто подправлял три-четыре класса в страничке, но быстро достало и я написал на пять строчек гризманки скрипт, который иногда приходилось подправлять.

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

[dennyrolling.livejournal.com]

ну у тебя все еще впереди! мы просто заранее привыкаем :)

[morfizm.livejournal.com]

У меня совсем нет уверенности, что я буду использовать e-mail через несколько лет :)

[ermouth.livejournal.com]

я полагаю емэйл проиграет соцсетям почти везде. останется может как транспортный протокол – к которому инерфейсом, хабом, "ящиком" станет интерфейс соцсети.

[oleghka.livejournal.com]

Плюсую.

[morfizm.livejournal.com]

Мне кажется, чуть иначе. Концепция e-mail-а начнёт трансформироваться так, чтобы из клиентов (web и не web) можно было прозрачно работать с трафиком соцсетей. В этом случае e-mail останется именно как client experience, а протокол отомрёт и будет заменен соц.сетями.

[ermouth.livejournal.com]

я плохо себе представляю, как это будет для не-веб клиентов. пока – даже с магазинами типа винстора или аппстора – скорость доставки обновлений к десктопным приложениям совсем никакая.

мне кажется, десктопные агрегаторы обречены – они просто _не в состоянии_ предоставлять такое-же удобство и следовать за трендами при таком ритме обновлений сервисов и их функционала.

[morfizm.livejournal.com]

Десктопные агрегаторы будут другие. У них часть функционала будет напрямую с web-а, причём caching locally будет делаться автоматически, через фреймфорк, в котором ты пишешь софт, руками не надо будет писать. Сейчас просто никто в это не вкладывает, потому что все осваивают недопаханный веб в ширину. Когда они немножко slow down и начнут оптимизировать performance, availability etc, переместят фокус на devices.

[ermouth.livejournal.com]

не вкладывают? охохо, Дима )

как раз веб и вкладывает. local storage, как вполне себе рабочий механизм, поддерживается всеми браузерами, в тч мобильными. http://www.w3schools.com/html/html5_webstorage.asp

там конечно царит некоторый разнобой, но есть вполне себе библиотеки, которые устраняют шероховатости.

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

и это всё инициализируется и начинает работать в три-четыре строчки _буквально_.

плюс режим веб-аппа для страничек, это кэширование, работа оффлайн и тп.

и это всё при объёме коди в сотни килобайт в плохих случаях.

десктопные приложения просто не поспевают )

[morfizm.livejournal.com]

Спасибо за инфо - многое интересно, посмотрю!

Насчёт развития: я же про это и говорю, десктопные/нативные приложения сейчас никто не развивает, *потому что* все снимают low hanging fruits с web dev'а и привинчивают костыли вроде локальных кешей. С точки зрения UX происходит такая штука: если пять лет назад Ajax было очень круто, и значительно ускоряло experience (по сравнению с медленной загрузкой страницы), то сейчас (а) интернет стал побыстрее, (б) добавился cloud и лёгкий scale'инг для server-side, (в) добавилось куча фреймфорков-конструкторов, из которых делают тормозню. Баланс сместился в обратную сторону и для пользователя нагромождённое client-side web приложение нередко тормознее, чем light-weight страничка, генерируемая на сервере.

Реальный же perf. improvement будет, как всегда, when we go native, а чтобы это было рентабельно, нужно упереться в потолок клиентских нагромождений + подождать, пока разовьются инструменты, именно компилирующие клиентскую часть под конкретный девайс (а не использующие browser).

[ermouth.livejournal.com]

Это очень грубая модель. И вот почему.

Выбор между доставкой страницы и доставкой только данных (или где-то посередине) по-хорошему должен производиться исходя из факторов:
– загруженности сервера
– ширины канала до клиента и пинга до него
– доступных ресурсов клиента.

Сейчас не существует платформы, которая позволяла бы это делать хоть в сколь-нибудь автоматическом режиме. Она появится – и немедленно – тогда, когда node.js станет способен создать внутри себя объект "Браузер" или что-то типа этого. Тогда станет возможным на лету автоматом определять, какая часть приложения буде исполняться на клиенте, а какая на сервере. Так примерно опера-мини работает, но там водораздел сразу жестко обозначен.

Все остальные платформы (и подходы) кроме node.js что есть сейчас под это могли бы подойти – для этой задачи фуфло. Сложное и негибкое – я детально вникал.

Про клиента.

На клиенте тормозню – типа как на jquerymy было – добавляет в первую очередь хреновый рендерер (и неучёт этого факта). Скажем, в хроме гарантировано вызывают тормоза при промотке тени большого радиуса. На айпаде этой проблемы нет.

Также проблемы вызывает неучёт стратегии перерисовки браузера.

Практически никогда тормозню не добавляет сам скрипт. Тормозит почти всегда перерисовка – я точно знаю, о чём говорю, собаку на этом съел (кста ты меня и промотивировал в своё время детально этим озаботиться). Нередко тормозит какой-нибудь самопальный велосипедик, типа как на гугл-вэйве было или в гугл-плюсе сейчас – там они сами собирали механику промотки ленты, и она полное говно.

Вот в перерисовке поле деятельности огромное. Я просто видел с какой скоростью могут выполнять растрирование софтварные промышленные растровые процессоры в полиграфии, так вот браузеры к ним даже не приближаются пока. Там разница в скорости кое-где – порядки. А это не аппаратная реализация даже.

Ждать развития компиляторов для десктопов тоже не стоит – в яваскрипте задел ещё раза в три по скорости, так что вот его компиляторы и будут оптимизироваться. Они и сейчас кста очень хороши.