Pull to refresh

Comments 175

А что со сторами, почему не redux? Спасибо.
Год назад redux не был таким популярным. Сейчас мы не испытываем необходимости в нем, чистый Flux нас устраивает.
Сторы представляют из себя обычные классы, наследуют EventEmitter.
Ну раз обучение бесплатное, то после окончании летней школы курс выложите или это останется тайной? Просто темы интересные, а каждую неделю ездить в Москву накладно.
По мере обкатки формата подумаем над публикацией материалов.
И еще хотелось бы спросить, можно ли получить задание, не регистрируясь или зарегистрироваться формально, чисто для получения задания? Челлендж ради спортивного интереса, а регистрироваться не хочется, т.к. я точно не буду проходить курсы школы.
Мы пока работает над очным форматом. В будущем не исключаем онлайн.
Не, Вы меня не совсем поняли или я не правильно сформулировал вопрос. Я про задание вступительного экзамена.
То есть хочу поучаствовать, но уже без дальнейших действий, и чтоб не мешать остальным участникам.
Оставьте заявку – мы вам отправим вступительное задание.
почему-то когда из старого письма пытаешься получить выписку он говорит что ссылка устарела и предлагает перейти по новой, которая ведет на страницу авторизации, но открывается белый экран.
В ближайшее время исправим эту ошибку. Пока можете перейти на любую другую страницу сайта и авторизоваться в интернет-банке через боковую панель.
я уже нашел этот способ. Но найти выписку было непросто через боковое меню.

Ух и люблю же я подобные статьи! Ребятки, есть несколько вопросов:


  1. Почему выбрали именно Fluxible? Я, признаться честно, впервые о нём услышал, поэтому и спрашиваю. В доках мелькает слово reducer, в статье говорится про сходство декоратора c connect из redux, из чего я сделал вывод, что они схожи. Не могли бы Вы вкратце описать разницу, плюсы/минусы? [упс, уже ответили]
  2. Не поделитесь своим render-logger'ом?
  3. Откуда Вы взяли цифры в главе про оптимизацию на сервере? Бенчмарки делали или на глаз?
  4. Как Вы решили проблему, когда Вам необходимо передать в props метод компонента с прибитыми аргументами, но bind использовать-то нельзя? Я
    нашёл выход в оборачивании метода в мемоизированный метод и прокидывании аргументов через замыкание
    @memoize()
    foo(i) {
    return () => this.props.actions.bar(i);
    }
    render() {
    return <div onClick={this.foo(666)} />;
    }

Спасибо.

2. Планируем выложить на github. Ссылкой поделюсь здесь.
3. Использовали бенчмарк, генерировали дерево компонентов.
4. Один из вариантов: записать значение в атрибут тега и получить в обработчике события.
2. Опубликовали:
https://www.npmjs.com/package/react-render-logger
Не могу не поругаться. Переход на новый интерфейс сделал возможность использования интернет-банка с телефона сильно затруднительным, а использование с обычного компьютера — неудобным.

1. Чистый заход на главную страницу — 100 запросов, 9 мегабайт трафика. Если давно не заходил с телефона, а Wi-Fi рядом нет — будет медленно. Да, я очень быстро увижу странцу с информацией, логотипами, увижу кнопку входа, но она не будет работать — мне все равно придётся ожидать, пока сайт догрузится.

2. Объём файлов со скриптами — 4 мегабайта. Представьте теперь нагрузку на CPU, когда браузер их парсит и выполняет. На телефоне годовой давности неприятно подтормаживает. Эффект от выбора действий я часто вижу только через ~5 секунд.

Ожидаемый эффект: сразу после нажатия на любую кнопку интерфейс блокируется = действие принято,
Наблюдаемый эффект: ничего не происходит, через 5 секунд наблюдается реакция.

3. Интерфейс адаптирован под мобильные устройства. Для десктопа я такое считаю неприемлемым и неудобным: хочется видеть меньше интерактива и больше предсказуемости.

4. Общие неудобства интерфейса: вгоняет в ступор пункт меню «карты» — я ожидаю здесь увидеть список своих карт, а не предложения банка. Кнопки входа и выхода неочевидны.
Присоединяюсь, новый интернет банк стал неюзабельным тормозом. Внезапно не все ваши клиенты имеют пару ксеонов и 10G каналы до вашего ЦОДа.
Спасибо, что хоть старую версию (2015) не отключили.
Спасибо за подробный отзыв. Мы недавно запустили новый сайт и сейчас активно работаем над оптимизацией и улучшением UX.
На данный момент главная страница со всеми ресурсами весит 3 мб в gzip, возможно ваш браузер по какой-то причине получил несжатые ресурсы.
3мб? Это серьезно считается адекватным размером для одной страницы сайта, который должен быть доступен с мобильного устройства?
Включите в хроме тротлинг на Regular 2G, посмотрите сколько времени займет загрузка на интернете, который может застать вас в самый интересный момент.
Я уже молчу о том сколько это будет стоить на тарифе не ориентированном на мобильный интернет.
Проблему с размером решаем. Улучшаем процесс сборки клиентских пакетов, делаем динамическую догрузку скриптов.
Динамическая догрузка скриптов — это как раз тот самый вечный жёлтый прогрессбар, который не даёт ничего сделать на полностью отрендеренном сайте, пока не вздремнёшь полчасика?

Проблема у вас архитектурная, и это очевидно. Страницы просто не должны столько занимать и так долго грузиться, ни с динамической догрузкой, ни без неё. У вас не гугл-мапс, у вас интернет-банк, в котором конечному пользователю нужны полторы цифры, три кнопки и две галочки.
Желтый прогрессбар появляется при загрузке данных из внешних сервисов. Динамическую догрузку скриптов делаем для уменьшения времени первоначальной загрузки сайта (загрузки первой страницы), чтобы заранее не грузить логику, которая не используется на запрашиваемой странице.
После загрузки главной страницы

image


2.8 MiB минифицированного JS. И судя по риторике это "логика, которая используется на запрашиваемой странице". Т.е. следует вас понимать как: "для работы нашей главной страницы вашему браузеру необходимо прожевать ~ 3 MiB JS-ов"? При этом на странице я вижу пару формочек (функционал которых вполне можно вынести в отдельные файлы и грузить по требованию) и десяток другой картинок. Зачем для этого 3 MiB скриптов? оО

А теперь попробуйте ради интереса посмотреть на gmail.com и ужаснитесь ещё больше: там количество запрашиваемых скриптов вообще переваливает за 10 мегабайт!

gmail-у быть огромным ещё простительно, ибо это один из лучших почтовых клиентов (т.е. серьёзное и сложное UI), плюс у него:


  • есть мобильное приложение, где не требуется подгружать 10 MiB скриптов
  • есть мобильная версия (5.3 KiB)
  • большая часть функционала доступна напрямую сразу после загрузки

Хотя, конечно, 10 MiB и для gmail-а как-то слишком уж много, ИМХО. Не понимаю, чего они туда понапихали.

У Тинькофф тоже есть мобильное приложение. Причем для всех популярных платформ, включая Windows.

>большая часть функционала доступна напрямую сразу после загрузки
Скажите, пожалуйста, что значит «большая часть функционала», и после загрузки чего?

После загрузки SPA. Написание новых писем в один клик, чтение писем в один клик, фильтрация, зачем-то hangouts, зачем-то звонки в 1 клик, метки… Практически всё (или всё), что я в gmail знаю и использую доступно сразу после загрузки в 1 или 2 клика мыши. Без дозагрузки какого-нибудь модуля. Т.е. по сути большая часть функционала gmail-а представляет из себя один "модуль", делить который на отдельно загружаемые подмножества лишняя морока и проблемы\тормоза для посетителя. Но это тоже есть, к примеру настройки догружаются by demand. Каждый из вышеперечисленных пунктов может быть куда замороченнее, чем можно подумать на первый взгляд. К примеру написание письма содержит визивиг, загрузку файлов, какую-нибудь интеграцию с google drive-ов, словари (контакты, имейлы, ещё что-нибудь...). В общем углубляясь в нюансы, оказывается, что там довольно много всякого. И учитывая что это почтовый клиент, это всё доступно в 1-2 клика. Пользователь не ожидает дозагрузки такого функционала.


Помимо прочего gmail умеет работать без сети. Если к этому моменту он загрузился, конечно же. Он доотправит письмо, когда появится сеть. Причём самостоятельно. Если во время написания письма — не будет связи, не беда. Не будет доступен google drive, upload… Не так критично. Новые письма будут не видны. Но в целом offline работоспособность в наличии.


Не думаю, что это применимо к главной странице Тинькофф.ру. Там должен грузиться из коробки framework с базовыми потрохами, вроде роутеров, и пара модулей из главной страницы (несколько форм на главной всё таки есть). Сами модули потребуют ещё десятка (всякие нестандартные контролы, словари, ещё что-нибудь). Это всё должно легко уместиться до 1 MiB, ИМХО.

> есть мобильное приложение… включая Windows.

Это очень условное утверждение. Формально приложение есть, но по факту, там походу теперь только баланс можно смотреть. Например при переврде с карты, надо ввести cvv код. Но поля для его ввода просто нет. Можно долбиться очень долго и непонимать, почему платеж отклоняют.
Оно не обновлялось ооооочень давно. Уже пару лет висит надпись «Мы разрабатываем новую крутую версию. Уже очень скоро, будет готово».
Походу они забили на это приложение…
Потому что этой проблемы раньше не было. Но после появления новой web версии отвалился WP клиент. Кстати, этот же глюк был и в web версии, но его поправили за несколько дней.
Вы про приложение для виндофонов? Я постараюсь узнать, какие планы насчет его развития.
У меня тоже негативный опыт использования мобильного приложения: год назад оно просто падало при логине (сейчас, кстати, не падает). Но тогда я не стал разбираться с причиной, т.к. интернет-банком было пользоваться вполне удобно, а просто удалил приложение.
Ну да, ребят, я сейчас на LTE ждал первичного отображения секунд 10. Как по мне, никакие технологии, украшательства и прочее не достойны такого размера.
ТРИ МЕТРА С ГЗИПОМ? О_О
Матерь божья. Я тут недавно сходил с ума от того что у нас проект весит 900кб с гзипом, пытаясь понять почему же мы так над юзерами то издеваемся, а тут трешка у интернет-банкинга! Где половина юзеров скорее всего желает зайти на сайт, залогиниться и чекнуть счет/последние операции. Я вот прям читал статью и чувствовал, что что-то тут не так.
Хоть пользователей не ругаете — это хорошо. Если отбросить в сторону вопросы производительности, то готов ещё указать замечания по дизайну, которые, на мой взгляд, делают работу с сайтом некомфортной:

1. Постоянно присутствующие плашки, которые отнимают 1/3 — 1/4 вертикального пространства браузера. Прикручивая страницу вниз, ожидаешь, что они уедут вверх, но этого не происходит. Даже развернув браузер на полный экран, я все равно не могу видеть информационные блоки целиком — приходится постоянно скроллить вверх-вниз, чтобы ознакомиться с продуктами.

Не бойтесь, что пользователь не всегда видит меню. Пользователю естественно проскроллить страницу вверх, если нужно перейти к меню. Также пользователь при скролле ожидает естественной прокрутки страницы.

Временная полумера для меня: блокировка объектов соответствующих классов через ABP (длинный класс ui-что_то_там-fixed). Кстати, всё чаще замечаю, что использую ABP не для вырезания рекламы, а для блокировки нежелательного для меня функционала веб-сайтов. В числе последних — facebook, pin (настойчивое предложение зарегистрироваться).

2. Нелогичное поведение + элементарные баги. Например, страница https://www.tinkoff.ru/business/

В блоке «Бесплатное приложение и интернет-банк» акцент привязан к положению скролла на странице, ещё и с ошибкой.
В блоке ниже («Управляйте деньгами») — уже к фокусу мышью.
Ещё ниже — никакого акцента нет.

Я бы отказался от интерактивного акцента вообще — он раздражает и мешает получать информацию.

3. Информация на странице идёт в навал, причём нет чёткого разделения между блоками подаваемой информации. Сайт банка — не новостная лента в соцсети.

Вот пример удобной подачи информации — я считаю, что именно к нему нужно стремиться:
https://t.tinkoff.ru/documentation/
Добавьте к нему History API — люди только спасибо скажут.

4. Крупный текст. Нет необходимости плашкой на полэкрана писать, что я оплачиваю onlime. Достаточно небольшого заголовка сверху с логотипом.

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


Статистика: http://www.webpagetest.org/video/compare.php?tests=160623_Y4_1082,160623_NZ_1083,160623_JV_1084
Видео: http://www.webpagetest.org/video/view.php?id=160623_ce3f4c6a879cc8999445944e1b96e8ef18ca4420


Да, страница появляется быстрее, но пока пройдут все анимации и закончатся скачки ею всё равно пользоваться невозможно. Но даже если закрыть на это глаза — больше трёх секунд приходится ждать, пока хоть что-то появится на экране. Для сравнения, простая форма входа может появляться меньше чем за секунду и быть сразу полностью функциональной: http://www.webpagetest.org/video/view.php?id=160515_4f193e07f4c37dc3b72dd3799dd27397551690a2

Действительно, мобильные фишки в десктопе жутко раздражают. Я ни когда не пользовался старой версией, но мне не удобно, когда вместо привычных инпутов, которые легко заполнить, появляются какие-то скрывающиеся-появляющиеся поля, причём если случайно кликнул где-то — они опять закрываются и нужно всё вводить заново. Иногда не подхватывает пароль из браузера. В общем — приходится много лишних действий совершать. Вместо излишне ускоренного входа (за который вы зачем то так боритесь?) вы создаёте пользователям проблемы с простейшей авторизацией.
А когда нужно отвлечься к документам и вернуться всего через мгновение, я снова получаю ненавистное окно ввода логина и пароля, после которого всё сбрасывается и интерфейс загружается снова.

Расположение элементов — плюс, много лишней анимации и непривычные элементы — жирный минус. Из-за этих и ещё некоторых мелочей есть желание отказаться от банка в целом, но борюсь с собой, так как понимаю — бета, надо потерпеть и надеяться на лучшее.
Это болезнь индустрии такая. По сути там хватило бы простейшего интерфейса без всех этих анимированных интерфейсов, т.к. пользователю нужно совершить простейшие операции, в которых анимация процесса дело последнее, все равно ждем SMS с информацией о транзакции.
Новый ужасен, старый был прекрасен. Зачем вы все испортили…
UFO just landed and posted this here
Присоединяюсь, три действия вместо одного. Конечно возможно это защита от какого нибудь брутфорса, но неудобно — факт.
солидарен, клик в поле сильно раздражает. была б какая нибудь страница с обычной авторизацией, зашел, нажал вход и готово.
Столько согласных, присоединившихся и солидарных)
Добавлю еще, ув. PhilNehaev, у меня перестал работать LastPass. При попытке выполнить автозаполнение хотя бы логина, поле остается пустым. Поле с паролем тем более не заполняется. Очень прошу это исправить
Про проблему с Lastpass знаем. Уже в процессе решения.
и 1password так же отвалился
Зато теперь можно пользоваться интернет-банком и без авторизации. Но я согласен, для клиентов банка процедуру входа надо упростить.
Еще прекраснее был пред-предыдудущий. Там можно было один раз настроить то, что хочешь видеть на главной и частые операции делать в 1 клик после логина.
поддерживаю.
надеюсь хотя бы предыдущий будет постоянно поддерживатся?(а лучще бы вернули предпредущий)
Избранные и последние платежи доступны после авторизации в разделе «Платежи и переводы». Сейчас платформа — это не только интернет-банк. Но посыл понятен: после авторизации пользователь хочет сразу иметь возможность оплатить без перехода. А что с «Событиями»? Их интересно видеть сразу после логина?
я в банк захожу всего за несколькими операциями:
1. Изменить лимиты по картам
2. Сделать платеж
3. Задать какой то вопрос в поддержку, или заказать справки(что по сути одно и тоже, так как выписки по счету делаются только по запросу)

Соотвественно,
1. Что бы изменить лимиты нужно зайти в карту и потом зайти в лимты и менять, причем часть лимтов в профиле, часть в настройках карты(например почему то платежи в интернет-банке можно править только через карту, а остальные и в профиле и в карте, пока искал долго матерился)
2. Платежи примерно также по удобству, но там мне сложно представить что нужно поменять.
3. Вопрос в поддержку для заказа справок, сейчас появилась кнопка, где можно сразу написать запрос. Как только выкатили новый банк не смог найти пункт «контакты», так как при масштабе 125% он просто исчезал(и сейчас исчезает с экрана, но остаются ...) а поддержка отвечает что работает только при масштабе 100%(прямо как во всеми любимых банках :) )

Если мне нужно рассказать других продуктах, можно же их сделать на странице банка, а не интернет банка. Может приведут примеры, но я не видел, что бы в клиент банк пытались запихнуть информацию обо всех продукты банка. О предложения или новости да, но ипотека, страхование, для бизнеса, это точно нужно в интернет банке физ лица?
В том то и дело, что это больше не интернет-банк в чистом виде. Платформа поглотила, объединила интернет-банк и портал. Теперь с её развитием все финансовые услуги будут предоставлены в одном месте.
Вас же не смущает, что в офисе банка можно не только заплатить за коммуналку, но и оформить ипотеку?
По разделу Платежи я бы мог что-то изменить к лучшему, но нужны конкретные пожелания.
Вас же не смущает, что в офисе банка можно не только заплатить за коммуналку, но и оформить ипотеку?

Если при этом время ожидания в очереди в кассу повысится в пять раз, я не буду ходить в офис банка, а найду банкомат. Если же «по причине создания единой платформы» в банкомат можно будет попасть, лишь отстояв очередь в кассу, я сменю банк.
Тот момент когда, лучшее враг хорошего.
Старый банк, главное, работал.
В новом вообще отсутствуют «автоплатежи» в списке избранных в правой панели. В WebDeveloper видно, что список возвращается с сервера, а в интерфейсе всё чисто.
Написал в службу поддержки, объяснил девушке всё по телефону — прислали отписку в стиле КО месяц назад, а воз и ныне там.
Для работы с автоплатежами приходится заходить на старую версию сервиса.
Если я правильно понял проблему, то постараюсь помочь.
В панели справа отображаются все платежи. Избранные имеют пометку в виде звезды. Автоматические имеют пометку в виде круга с буквой «А».
Другой вариант увидеть платежи — зайти в раздел «Платежи и переводы». И в самом верху под шапкой мы видим список платежей. Заголовок кликабельный и позволяет выбрать «Последние», «Избранные» или «Автоматические» платежи. Этот выбор кстати не слишком интуитивен, хотим его заменить другим решением.
Если не удастся найти нужные платежи, пишите в личку, обязательно разберемся.
> Автоматические имеют пометку в виде круга с буквой «А».
Да, я в курсе, как оно должно быть (служба поддержки и скриншот прислала для образца), но их там нет :)
В разделе «Платежи и переводы», где положено, их тоже нет. Можно добавить новый, а посмотреть созданные ранее (еще в старой версии банка) нельзя.
Ситуация была мной полностью описана и получен отличный ответ: «Информация проверена. На текущий момент, создавать автоплатеж можно сразу по оплате, а можно по уже имеющемся шаблонам. При первом варианте, автоплатеж в личном кабинете не отображается.»
В старом банке было предложение создания автоплатежа (типа банера), которым я и воспользовался. Уже не знаю, первый это вариант, или второй из перечисленных в ответе :)
Старые версии интернет-банка пока работают. 2011 это https://www.tinkoff.ru/bank/, 2015 это https://www.tinkoff.ru/mybank/
Смотрели ли на Polymer (https://www.polymer-project.org/) и если смотрели, то почему отказались?
Да, смотрели. На сервере нельзя рендерить. На нем есть реально работающие сложные приложения в production?
> На сервере нельзя рендерить.
Ок, но кстати зачем? SEO?
http://stackoverflow.com/questions/33643670/pre-render-polymer-js-on-server-side-for-better-so
Но в целом да, мысль ясна.

> На нем есть реально работающие сложные приложения в production?
Есть куча разного на https://builtwithpolymer.org/, но наверное из больших/сложных — https://gaming.youtube.com/

Кстати, спасибо за инфу и вообще — было любопытно почитать.
>Ок, но кстати зачем? SEO?
SEO + UX
Не подумайте что доколупываюсь, но что имеется ввиду под UX? Любопытно.
А то из того, что приходит в голову первым, на сервере рендерят либо для очевидного SEO, либо чтоб не слать данные на клиента по какой-то причине.
Ну или graceful degradation — если вдруг хотим поддерживать сильно старые/медленные браузеры, которым только html и минимум JS и CSS уровнем пониже, хотя ИМХО для таких случаев проще не усложнять а сделать совсем отдельный сайт.
То и понимается. Впечатление о скорости загрузки сайта — это ведь тоже UX? Конкретно в данном случае я говорю о том, что информация на сайте становится доступна пользователю намного раньше, чем загружается сайт. Не было бы серверного рендеринга — пришлось бы ждать.
Ок, не будем углубляться в дебри терминологии. Speed включать в UX — и ладушки.
Я просто тут оставлю:
https://developers.google.com/speed/pagespeed/insights/?url=Tinkoff.ru
ИМХО рендерить на сервере один из способов, и возможно не самый дешевый. Грузить и рендерить то, что видно в первую очередь было бы не сильно медленней, но это уже на вкус и на цвет.
Скорость загрузки страницы не влияет на пользовательский опыт взаимодействия?
Уоу, уоу, полегче.
На пользовательский опыт влияет все — и размер окна, и какая погода и прочее.
Просто обычно (ИМХО) под UX поднимают мета-штуки, типа «меньше больших квадратных кнопок лучше чем больше круглых».
А чисто технические метрики — скорость, размер, отзывчивость, потребление памяти и прочее, идут отдельным пунктом, потому как любой UX-исследователь даже не задумаясь скажет, в какую сторону должны графики смотреть.
ИМХО UX — это «мы две страницы объединили в одну чтоб уменьшить количество кликов для достижения цели», а не «мы два запроса объединили в один, чтоб быстрее было».
Я, вроде, сказал ИМХО?

Я вот понимаю под UX user experience — т.е. впечатление пользователя от сайта. А скорость загрузки и работы сайта — один из важнейших показателей удовлетворенности пользователей.

Т.е. если картинки пережать с лучшим сжатием без потери качества и начать отдавать JS минифицированный и GZip-ом, это, получается, UX-мероприятие?

Не вполне уверен, что такое UX-мероприятие. Решил обратиться к первоисточнику:


Там явно фигурирует быстродействие, во втором абзаце. Если расмотреть пятиуровневую модель, то быстродействие относится к пятому уровню — "желания и ожидания" от продукта.

Под UX-мерприятием, ввиду отсутствия термина, подразумевалось действие улучшающее UX продукта.

Уважаемый, мне кажется, Вы не правы.
С лично моей точки зрения, приведенный мною пример — исключительно техничекское ускорение работы продукта — не является частью UX, и уж тем более не самого верхнего уровня.
С тем же успехом можно отнести качество связи, быстродействие компьютера, скорость обновления монитора и подобные к UX, что ИМХО уже достаточно явно не имеет никакого отношения к вопросу.

Но мне, в целом, пофиг — как я сказал с самого начала. Просто не удивляйтесь, когда вам повстречается какой-нибудь UX-researcher и вместо того чтобы сжимать css он будет несколько недель наблюдать за поведением пользователей и задавать разные глупые вопросы например чего, собственно, люди хотят на самом деле и как, с вашей точки зрения, вы помогаете им решать их вопросы.
Непонятно, как одно другому противоречит.
Не надо путать теплое и мягкое.
Вот именно. Вы почему-то считаете, что UX — это только кнопочки двигать. А другие, я, например, считаем, что не только. У вас есть еще какие-нибудь аргументы кроме абстрактных предположений о действиях абстрактных UX-рисерчеров?
(миролюбиво) Да разве ж я против? На здоровье. Называйте что угодно как угодно и используйте любые методы для достижения любых результатов во имя любых целей.

Просто ИМХО UX — это когда уже все банальные вещи испробованы и не сильно помогают. А делают его сразу те, кто обжегся и прошел несколько итераций «выкинуть все и сделать как надо».

Машина легче, потребляет меньше топлива и быстрее едет по шоссе, значит она имеет лучший UX — так, что ли?

Если же включать все, что влияет на пользовательский опыт — то где, собственно, остановиться?
Включать ли потребление памяти браузера? Энергоэффективность? Прочие оптимизации не затрагивающие потребление? Исправление багов? Мытье монитора у пользователя?
Это больше не на миролюбие походит, а на снисходительность.
>Включать ли
Несомненно включать. И потребление памяти браузера, и энергоэффективность, и исправление багов. Не всё из вашего списка относится к UX непосредственно сайта, но, тем не менее, все это имеет весьма непосредственное отношение к UX.
Машина легче, потребляет меньше топлива и быстрее едет по шоссе, значит она имеет лучший UX — так, что ли?

Еще бы. Вот для вас пользовательский опыт использования какой машины был бы лучше — той которая собирает все кочки на дороге или той, которая имеет классную подвеску и идет плавно?

И кстати, скорость загрузки сайта — это не только часть UX, но и часть SEO, если вы не знали. Вам ранки не только и не столько за семантическое ядро ставят. Есть целая туча факторов, один из которых — скорость загрузки сайта.

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

Не претендую, но вроде где-то было исследование что чем быстрее сайт открывается, тем больше на нем люди времени проводят.
Вплоть до того, что улучшение на милисекунды давали существенные результаты.
По этому вопросу, ИМХО — всего лишь соотношение затрат и выгоды.

Цифры обманчивы, особенно когда я сам ими занимаюсь; по этому поводу справедливо высказывание, приписываемое Дизраэли: «Существует три вида лжи: ложь, наглая ложь и статистика».
— Марк Твен, 5 июля 1907 г.

Игнорируете статистику? На здоровье.
/me отходит в сторону чтоб не заразиться.

Игнорирую статистику из уст маркетологов.

99 / 100Удобство для пользователей

Вполне неплохо
Что-то странно как-то считает этот гуглспид, мне всегда казалось что вконтакте довольно таки удобный и быстрый. А оказывается что только удобный
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fnew.vk.com%2Fdm&tab=mobile
58 / 100Скорость
98 / 100Удобство для пользователей
Эм, кхм, по первому пункту (99/100 Удобство) — вроде как говорили о скорости, не?
По этому параметру, мягко говоря, нужно работать. (47 и 60, мобила и десктоп)

> странно как-то считает этот гуглспид
Да на здоровье, мне не жалко — спрашиваем гугл про page speed и вперед:
http://www.webpagetest.org/result/160623_SH_193K/
12 секунд на полную загрузку и 4 секунды на начало рендера.
Быстро это или нет? Какова роль пре-рендера на сервере? Вопросы, вопросы…

Тот же new.vk.com, кстати, всего лишь в два раза быстрее.
Я написал про удобство и скорость. Сравнил с new.vk.com. Заметил, что баллы не сильно отличаются. Отметил это как странное. А вы тут огород городите… в котором бузина, а в Киеве дядька.
Кому-то из разработчиков попадется задача по ускорению загрузки. Всего лишь.

Вконтакт очень хорошо оптимизирован, так что это скорее претензии к гуглевому PageSpeed

Откуда инфа, что он хорошо оптимизирован?

Я сидел и разбирался, как он работает.

Страница отрендеренная на сервере (хотя бы частично) быстрее отобразится в браузере клиента.
Сторы. Модели данных, которые содержат UI логику.

Я аж вспотел.

Честно говоря ожидал что-то большее в архитектуре чем это
image
Может быть я туповатый, но ни картинка, ни описание под ней не дали мне достаточного понимания архитектуры. Хотя вот же она. Или подождите… не совпадают с картинкой тамошние идеи «Stores contain the application state and logic.»

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

Самое интересное как всегда обошли стороной. Какие проблемы, почему писать отдельные контроллеры, какие еще сложности, как и почему решали… Ну интересно ведь?

Раз уж вы на джаваскрипте бакенд запилили, то Вы наверняка встретились с некоторыми особенностями этого языка при применении его в банковской логике. Тоже интересно. Как складываете числа в джаваскрипте? А база данных какая?

P.S. Хотел оплатить ТСЖ с сайта тинькофф, а там нет моего ТСЖ… И перевода по произвольным реквизитам нет(или не нашел?). В общем по юзабельности пока далеко до альфы, но примерно на уровне сбербанка. Хотя последние готовят тоже свою версию этого онлайн сервиса.

P.P.S. Всё вышенаписанное является субъективным мнением
На JS написан только тот бекенд, который крутится на ноде и рендерит UI. На 99% это тот же код, что и на клиенте. Банковской логикой заправляют совсем другие бекенды =)
Я так и не понимаю этих выкрутасов с серверной нодой, что бы рендерить вьюхи на серваке :) Не выгоднее ли рендерить вьюхи чем то пошустрее?
UFO just landed and posted this here
Уже есть бэкенд на Java/C#. На C# точно есть у Тинькова. Значит есть и разработчики. Программистов они ищут через тот же Luxsoft. Так что для них это не проблема.
Использование ноды там, где все упирается не в IO — странный выбор. Тем более в банке. В принципе я против смешивания фронта и бэка, так как у каждого свои особенности. А всю эту ересь с общим кодом уже прошли на Silverlight и Java Applets много лет назад.

Просто навскидку — вcю node_modules перед релизом проверяете? ;) Или хотя бы чексуммы пакетов храните?

Модули контролируем с помощью npm shrinkwrap.
Фронт и бэк мы не смешиваем, у нас full stack front-end.
1. Модули храните в репозитории? Аудит кода модулей?
2. Если на сервере надо что-то поставить то это уже затрагивает кучу всего — балансировка, аутентификация, развертывание. При том что профит сомнительный судя по отзыву ниже.
Как вариант — микросервисы+сайты. Набор небольших подгружаемых приложений + ссо для безшовной навигации. Сможете даже фронт как микросервисы обновлять частями.
1. Есть локальное зеркало и приватный репозиторий NPM на базе Sonatype Nexus. Аудит по необходимости делаем, новые модули добавляем редко.
2. Развертывание сервера с приложением – процесс несложный. Аутентификация происходит на внешних API. Сейчас фронт tinkoff.ru работает с 5 банковскими сервисами.
Объясните как рендерить вюьхи для SPA приложений на C#/Java? Я сам пишу на C#, но не знаю ни 1 фронтендовой библиотеки которая легко рендерится на сервере без ноды. Я вижу только один вариант — подключить V8 и рендерить через него (то есть по сути тоже самое что nodejs).
UFO just landed and posted this here
Немного пофантазирую… Буду считать, что разработчиков на всех языках завались.

а) Предположим, что js медленнее. Скорее всего просто докупят оперативки и делов-то)) Клиентов не так уж и много, это ж не соц сеть. А разработка гораздо быстрее, веселее и не пахнет бабушкой.

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

Итого со счетом 2:0 выигрывает жаваскрипт.
Аплодисменты и фейерверки!

Хотя с другой стороны…

а) в синтетическом тесте N выигрывает C#, значит и рендер будет быстрее
б) в сишарпах и джавах есть суперские классы, интерфейсы и вообще нет таких фич, как потеря this, и прочее. В общем по-человечески сделаны языки, а не на коленке за пару недель.

В итоге выигрывает сишарпы с разгромным счетом 0:2.
Ура!

Тут можно было бы привести аксиому эскобара… Но я не уверен, что она тут 100% подходит. Есть идеи?
Жду комментарии минусующих.
1. Количество оперативки не ускоряет ваш код :) Его ускоряют эффективные алгоритмы, многопоточность, работа с памятью, низкоуровневые оптимизации и тд.
2. На JS то же много чего понаписано. И?
3. TechEmpower вполне красноречиво отражает положение дел. Уверяю вас, обычный код, который будет на проде будет еще хуже.
4. Суперские класс и тд. делают жизнь JIT или AOT компилятора гораздо проще, позволяя использовать больший спектр оптимизаций.

Что бы понять уровень оптимизаций, которые можно проводить на том же C#, советую посмотреть это шикарное видео:
ASP.NET Core Kestrel: Adventures in building a fast web server — Damian Edwards, David Fowler
Kestrel еще недавно выдавал 700к в секунду. Послле всех оптимизаций — в районе 500kk.
1. Сравните сервер с 512мб памяти и 512гб памяти. Наверняка будет быстрее там где больше.
2. На js не написано столько бекенда как на остальных языках по объективным причинам.
3. Что это вы написали даже не знаю к чему относится. Рендер у с# медленнее или что?
4. Тоже не понял что это: опровержение того, что в джаве есть классы, фабрики, интерфейсы, а в js нет, или что. в огороде бузина, а в киеве дядька.

1. Вы прикалываетесь?
2. Не пишут, потому что инструмент не подходящий.
3. Там видна разница между производительностью Node и JVM/JAVA. C# там бесполезно смотреть из-за старой реализации на тормозном Mono.
4. Видимо вы не очень понимаете основы. Я надеюсь вы знаете почему 'use strict' положительно сказывается на производительности?

В целом думаю вам стоит начать с основ, что бы хотя бы составить представление чем вы пользуетесь.
1. Многопоточный рендеринг.
2. Настроенный JVM даст прикурить 95% платформ по производительности. Особенно если написать эффективный код с низким GC pressure.
3. Можем докинуть F# и тут будет очень интересно поглядеть. В свое время на нем реализовали NDjango.

Лучше-хуже — зависит от потребностей. Но может я не сталкивался и не понимаю всей прелести рендеринга на ноде со стороный сервера. Что такого надо нарисовать в UI на JS, что бы это рендерить на серваке.
Могу предположить, что могут быть случаи когда хочется получить готовый шаблон а не тянуть шаблон и данные на клиента, но не проще тогда взять любой шаблонизатор на текущей инфраструктуре бэкенда, и использовать его для создания вьюх?
Это отчасти ответ-размышоение к вопросу Diverclaim: Прекомпилированный partial-view через RazorEngine чем не вариант?

UFO just landed and posted this here
1. asp.net core + razor. Каждый запрос может рендериться параллельно.
2. Не согласен. Вот binary-trees
Это простая адаптация GCBench. В compute JS не особо конкурент JVM/CLR языкам. Он бы мог потягаться на задачках с асинхронным io и минимумом многопоточности.
3. https://github.com/Hill30/NDjango

Можно пример убер быстрого современного шаблонизатора на JS?
UFO just landed and posted this here
1. Это не релиз. Там есть баги с линуксовыми либами как раз по части работы со строками. На WinServer летает. Вопрос был про многопоточность.

2. Покажите как JS уделает Java на этом тесте. Бинарные деревья вполне здоровый бенч. Потому что тот же парсинг может использовать деревья выражений и тд. Я вот вижу что Node медленнее почти в 5 раз.

3. Вы хотели пример парсера на F#?

100мс на шаблонзатор? Это вы так пошутили? :) У меня в проекте сервер обрабатывает запрос за 20-25 мс включая парсинг и это на связке WebApi2 + RazorEngine.

С++ кстати быстрее в 13 раз на обработке бинарных деревьев. Но это ведь все не показатели, и однопотоный сервак будет всегда быстрее многопоточного, с производительным GC, оптимизациями, нормальной моделью памяти и тд и тп.

Предлагаю продолжать эти дискуссии в личке, после того как вы сможете написать оптимально тест на бинарные деревья используя JS и отстав от C++/gcc7 всего в два раза :)

Я выше уже сказал — JS — однопоточный асинхронный код для легких сервисов. В Compute JS в принципе не конкурент.

Дак покажите современный убер быстрый парсер то?
UFO just landed and posted this here
1. ViewEngine — это парсинг дерева выражений, обработка и форматирование выходных данных(конкатенация строк).
Все эти задачи можно сделать эффективнее на Java, C#, F#. С++ и в самом деле дорого.

Многопоточность — реалистичный пример тут даже считать не надо.

Просят денег не просто так. Потому что это разные области и просто знания языка — мало. Проблема не в языке/платформе, а в том, что вы считаете возможным затыкать дыры в штатном расписании теми, чья специализация отличается. Можно легко переучить с C# на Java или даже на Go или Erlang если есть понимание общих принципов.
Фронт и бэк разделяются и все взаимодействие через апи. Один является потребителем другого, но первый должен строить апи исходя из необходимости второго.

А в целом перфоманс ноды хорошо виден на TechEmpower.

Сейчас вы мне напоминаете тех парней, который тащили серверные языки в браузер. Сейчас тащат браузерные штуки на сервер, с теми же лозунгами. Исход ИМХО будет одинаков. JS шикарен для UI. Но для бэкенда есть более здравые опции(хотя бы тот же Go).

Мне кажется он вообще не понял нас и будто ведет переписку сам с собой игнорируя большую часть сообщений и коверкая смысл. Главный смысл — бекенд должен быстро работать, всё остальное от лукавого. Есть самый быстрый штук под названием urweb-postgres. На языке Ur.
fun equal [ts ::: {Type}] (eqs : $(map eq ts)) (fl : folder ts) (r1 : $ts) (r2 : $ts) : bool =
    @foldR3 [eq] [ident] [ident] [fn _ => bool]
     (fn [nm ::_] [t ::_] [r ::_] [[nm] ~ r] isEq x y acc =>
         acc && @eq isEq x y)
     True fl eqs r1 r2



Мне больше всего вот этот кусочек нравится
[[nm] ~ r]
Перевести можно Юридическому лицу в разделе Организациям.
Банковская логика реализована в отдельных системах, работа с которыми идёт через API.
Вот спасибо добрый человек, реально так и есть. Смог найти через поиск, а в нативном мобильном клиенте оно еще удобнее. Здорово, что нет комиссии, прям не могу понять почему так — у других же есть.
Очевидно, чтобы вас привлечь. Не думаю, что такое счастье ещё долго продолжится. Лесенки со вкладами уже почикали.

В подборе ипотеки можете писать, что по выбранному региону данных вообще нет?

Если коротко, то можем.
Мы сейчас активно работаем над развитием ипотечного продукта, а в будущем будем улучшать текущий калькулятор.
А что на CSS?

Какие плагины PostCSS используете, кроме Автопрефиксера?
Используем LESS, кроме автопрефиксера есть CSSO.
А чем линтите CSS и инлайните картинки?
Инлайнит Webpack, линтинга для CSS нет.
Я просто спрашиваю, так как обычно Автопрефиксер усиливают линтером Stylelint (у Фейсбука и ГитХаба он есть) и postcss-assets или postcss-inline-svg (инлайн SVG со сменой цвета). Но понимаю, что вы пока решили сосредоточится на JS.
«воу воу воу, помедленнее, я записываю...» — послышалось, где-то в офисе ткс
Вы вообще проверяли как работает ваш новый чудосайт на плохом интернете или у людей из других стран? У меня до России RTT 300-400мс. В итоге видимо из-за того, что вы юзаете изоморфный рендеринг, при навигации по сайту у меня получается вот такое вот издевательство:
10/10 UX Would Visit Again
image

Эта гифка уже записана с быстрыми кликами, но вчера при первом использовании я реально не понимал почему у меня ничего не происходит после клика, после чего я понажимал по другим разделам, и затем у меня произошла вот такая вот замечательная цепочка из открытий страниц. Вы может еще и проиводительность анимаций только на последних макбуках тестируете?
Это не из-за изоморфного рендера. После первоначальной загрузки сайт работает как одностраничное приложение, без запроса HTML с сервера. С проблемой разберемся.
Извиняюсь, что вопрос не по теме поста. Подскажите, пожалуйста, а каким инструментом вы создали такую гифку?
На винде — ScreenToGif 2
На маке то ли licecap, то ли какая-та другая прога, я уже забыл.
Спасибо, что выложили обзор своих выстраданных решений, пока другие компании сидят и тихо скрывают свои военные тайны.
Если все проекты на единой платформе, то почему страхование требует отдельной регистрации? Или данный проект все-таки отдельно?
Данный проект пока с отдельной регистрацией.
1) Потому что СК должна быть отдельной от банка компанией.

2) Чтобы не позорить банк свой тупой работой. Говорю как клиент обоих ресурсов.
1. Вижу, появление кнопки «Войти» через 10 секунд вы исправили. Молодцы. Но уберите уже из-под неё иконку оплаты коммуналки, незанятого места на экране вагон, а вы её загнали прямо под самую нужную кнопку главной страницы.

2. Жутко. Невероятно. Медленно. Старый банк летал на любых устройствах, этот же тупит на любом интернет-соединении, включая проводное. Однажды попробовал зайти в новый банк с мобильника, пожалел об этом сразу, т. к. в этом храме имени Вечного Жёлтого Прогрессбара не удалось сделать вообще ничего.

3. Где сумма задолженности по выписке, самая нужная цифра кредитного счёта? Как я, тупой пользователь, должен догадаться, что она спрятана под кнопку «Пополнить», если раньше она всегда разворачивалась по клику на сумму общей задолженности?

4. Если шариться по банку, не разворачивая браузер на весь экран, всплывашки заезжают под правое меню, в слове «дополнительную» буква «ю» улетает на следующую строку. Тестируйте на всех вариантах ширины, а не только типовых.

5. По виду контролов вообще непонятно, что это. Поля ввода ужасны. Если не знать, что при смене пароля надо ввести пароль дважды, об этом хрен догадаешься, потому что второе поле выглядит как надпись.

6. Размер элементов настолько невменяемый, что даже простейшие операции теперь требуют скролла. Раньше операции в интернете (пожалуй, самая часто дёргаемая галочка) включались и выключались легко и просто, теперь их ещё и поискать надо, потому что они где-то внизу страницы настроек, под Офигенно Важными Услугами «смс-банк» и «страхование долга».

Короче, ни одного плюса в новом банке мной не замечено. А вот минусов — хоть отбавляй.
> Короче, ни одного плюса в новом банке мной не замечено. А вот минусов — хоть отбавляй.

Зато технофильству раздолье )
через год запустят новую версию, не волнуйся.
Блин, сделайте текстбоксы с логином и паролем, чтобы были видны одновременно, а не по очереди, неудобно получается работать с хранилками паролей.
А мне нынешний вариант понравился. Анимации подтормаживают в эдже на ноуте с i7, но зато повторить предыдущий платеж стало очень легко и удобно. Пароли от банка в браузере не храню, поэтому проблема с автозаполнением для меня не актуальна. Анимации бы правда пошустрее сделать.
Кстати, на люмии 1520 тоже хорошо работает.
UFO just landed and posted this here
По оценке интерфейса (раз уж стали сравнивать новую и старую версию), оставлю здесь очень простые, но вполне рабочие критерии сравнения:

0. Интерфейс должен решать задачу пользователя. Если не прошли этот пункт, дальше можно не оценивать.
1. Скорость, с которой решается задача пользователем. Количество кликов, капч, окон с вопросами и тд.
2. Количество ошибок на пути решения. Расположенные рядом кнопки удалить и запостить, вводящие в заблуждение подписи к полям и тд.
3. Скорость обучения пользователя работе с интерфейсом. Сначала привычка: стандартные контролы и подходы повышают скорость обучения. Логичные и заточенные под задачу клиента интфейсы так же повышают скорость.
4. Общая удовлетворенность пользователя от интерфейса. Вопрос привычки, ощущений и тд.

Впервые увидел эти(или подобные) критерии, кажется, у В.Головача. И с тех пор использую в работе и жизни. Без лишнего холивара прохожусь по критериям, сравниваю принимаю решение. Пункты 1-4 могут рассматриваться в любом порядке.

В плане UX идеалом я считаю вконтакте:


  • Весь рендер выполняется на сервере, динамика реализована путем POST запросов, которые возвращают HTML, вставляемый в нужное место.
  • Никаких библиотек, всё написано на чистом яваскрипте.
  • Никакой минимизации и объединения ресурсов, система навигации умеет подгружать скрипты и стили динамически по необходимости
  • Серверная часть написана на С, что обеспечивает минимальное время отклика
  • поддерживается как навигация через ajax, так и полностью серверный рендер. Т.е. при навигации с сервера подгружаются куски HTML в нужные места DOM, но если обновить страницу, то она придет сразу целиком. Идеальное решение для SEO.

Из минусов:


  • клиентский яваскрипт представляет из себя жуткий спагетти, написанный без внимания к каким-либо стандартам и даже без use strict
  • серверная часть тоже должна быть весьма, весьма сложна...
Красиво. Технологично. Неюзабельно.
Ок, надо вам маркетплейс на исходной странице — да пожалуйста. Но сделайте просто интернет-банк на другой. Не надо эти свистелки и перделки тем, кто и так ваш клиент.
Мы знаем о них. Правда. Знаем.
Нам всего лишь надо воспользоваться тем, за что уже заплатили, а не смотреть анимашки на мелком экране смарта с edge-интернетом.
я старый клиент, и считаю этот банк лучшим, но блин каждый интернет банк хуже предыдущего, а этот меня заставляет страдать. я знаю, вы самые крутые и сможете победить эти тормоза и глюки, буду держать за вас пальчики, и спасибо, за такую открытость, думаю такие отзывы как мой откроют вам глаза и помогут в результате, сделать, что бы не сбоило и летало.
молодцы! получилось неплохо.

Но где инновации? что делают все эти 30 человек на фронте? Это статья о том как вы умеете пользоваться stackoverflow, запускать webpack и рендерить react на сервере?

Если вкратце, то весь этот текст можно было заменить на одно предложение: «мы почитали документацию реакта, поизучали npm на наличие пакетов и научились рендерить react на сервере под express.»

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

Все таки в команде 30 фронтендеров, можно уже начать что-то изобретать, как это делают другие разработчики (airbnb, yandex (bem и не только) и др.), а не просто использовать готовое. Например, тот же backbone или redux, разработали не 30 человек, а всего лишь один.

А что сделали вы?

кстати, если уж убиваться, по инновациям и новомодным подходом, то почему вы все таки выбрали express, а не более современный и перспективный koa? или допустим hapi?

почему все таки не webcomponents, вроде это еще щас моднее и прогрессивнее?
Было бы интересно почитать про мобильное приложение в подобном же ключе.
Скажите пожалуйста, каким образом у вас сделан чат с поддержкой, что он упорно не хочет работать в браузере из под Linux и при этом, если я случайно нажал на него, то это окошко с вращающимся кругом уже не закрыть?
Отправьте на fb@tinkoff.ru скриншот и подробное описание проблемы (браузер, на какой странице, авторизованы или нет).
Уже отправлял. Ещё раз, конечно, отправил, но чё-то не верю что вы запаритесь из-за линуксоидов. В принципе интересен не сам чат, а то как вы умудрились сделать так, чтобы он работал в зависимости от платформы )
Отправил ещё тогда скриншот и подробное описание. Сначала каждые несколько дней приходила СМСка, что для решения проблемы потребуется чуть больше времени. В какой-то момент СМСки перестали приходить. В ЛК проблема помечена как пофикшенная. По факту всё как было, так и осталось — в линуксе чат не работает.
Когда API будет? Фронтэенд нам ваш нафиг не нужен, а вот выписки импортировать без участия человека нужно до зарезу. Сколько можно мартышкиным трудом заниматься.
Почитал ругань на размер и тормоза. Моя догадка по поводу виновника: ES6 + Babel. Скажите, зачем вы решили писать на ES6, если оно еще такое сырое и порождающее столько проблем? Могу предположить, что год назад этот выбор казался логичным, так как вы ожидали, что за год поддержка ES6 сильно улучшится. Но этого не произошло. Если так, что что бы вы выбрали сейчас?
Размер складывается не из-за ES6 и Babel. Это вопрос сборки модулей. Сейчас выбрали бы тоже ES6.

Это всё библиотеки. react + диспатчер + underscorejs какой-нибудь + прочие плюшки — вот скомпилированный js и вылез за мегабайт.

Любопытно, когда люди обсуждают привлекательность «свистелок и перделок», а я уже неделю не могу посмотреть выписку по кредитке (пишут, что «нет операций»), причем по допкредитке все операции видны. Вчера хотел заплатить взносы в ПФР. А вот фиг вам! КБК должен быть 20 символов, ввожу верный КБК (руками, копи-пастой, чертом-в-ступе) — нет, неверный у вас КБК, он должен быть 20 символов, а у вас 20.

По мне так пусть на голом хтмл, но работает. А оно не работает. И это только два больших косяка.

image
Посмотрел регулярку на это поле: ^(0|\d{20})$
И ваше значение проходит проверку.
Можете прислать в личку данные платежа, кроме личных? Я проверю платеж.
Вам не нужны данные платежа. Просто введите 39210202140061100160 в поле КБК — этого достаточно.
Дело в том, что я пробовал. На своем боевом аккаунте. Заполнил только поле КБК, нажал оплатить, поле КБК валидно.

Поэтому и пытаюсь уточнить детали.
Я делаю тоже самое. Могу сбросить видео (уже сделал) через службу поддержки. На всяк пожарный, проводку пытаюсь сделать здесь — https://www.tinkoff.ru/payments/legal/transfer-taxes/.
Теперь понятно. Для такого перевода следовало выбрать перевод «Организациям / В бюджетные организации»: https://www.tinkoff.ru/payments/legal/transfer-nontaxes/
Спасибо за выявление проблемы. Мы сделаем предупреждение о том, что поле КБК не подходит для данного вида перевода. И в дальнейшем будем работать над объединением таких переводов в один универсальный.
Абсолютно на всех сайтах использую новые версии, если появляется даже бета, но у вас новая версия просто кошмар. Впервые хожу по ссылкам на старую версию. Что это за мода везде адаптировать под мобайл? Такое ощущение, что сайт делали для слабовидящих. Слониный шрифт, куча пустого места, чтобы что-то найти нужно 10 метров проскролить. В общем, надеюсь, старую версию не прикроют.
Полностью согласен с коллегами выше, ваш очередной новый Интернет-Банк 2016 просто эпикфейл и при этом еще хватает… трезвонить везде какие мы молодцы, что каждые полгода-год меняем интерфейс на менее удобный для пользователя.
Вы видимо не понимаете, что пользователь в большинстве своем консервативен, и что даже небольшие изменения пагубно сказываются на понимании интерфейса, а уж Такие… ну да пофиг с этим саппорт разбираться будет (с непониманием клиентов), Мавр свое дело сделал.

Такое впечатление, что разрабатывался интерфейс под локальную гигабитную сеть и для мониторов разрешением 4K не меньше, а на остальных просто… забили, ну как ваш шеф любит говорит… на нищебродов.

Вы вообще в курсе, что во многих конторах, особенно не с миллиардной выручкой или из-за жесткого бюджета не то что 4K мониторы до сих пор в офисе на 720p сидим и ваш мегадизайн тупо не помещается в него да и грузится в браузерах неахти (причина выше уже описана).

Резюмируя, выражаю респект за пополнение лексикона с перечнем крутых буржуйских терминов, но не более.
Банк у вас замечательный, но новый интерфейс абсолютно оивратительный. Пользуюсь старым и друзей всех на него перевел.
(очередной коммент про UX-погрешности в очередной новой версии интерфейса Тинькофф банка)

ждём следующих версий интерфейса.
нам нравится раз в квартал переучиваться пользоваться вашим интерфейсом!

подпись: ваши клиенты(
это то, что внутри. а я про то, что внешне…
Зашел выбрать новые категории повышенного кэшбэк. Искал интуитивно в действиях по карте (вроде в старом ИБ было там). Не нашел, облазил всё. Полез в рассылке искать письмо, чтобы пойти по ссылке. А оказывается это в «Бонусы» засунули. С какой стати? Ну ладно.

Захожу туда и мне на полном серьезе предлагают выбрать категории для апреля, мая и июня. Во-первых, уже первое июля, во-вторых, эти категории я уже давно выбрал и изменить их нельзя (вроде как), зачем предлагать ещё раз? Едва заметил, что есть две «как бы вкладки», обе с одинаковым названием «Активные категории», переключился на вторую — слава яйцам, там новые категории.

Ребята, вы где такое обновление интуиции скачали?
Спасибо, добрый человек! Я-то думал, что туда теперь вообще никак, кроме как через письмо, не попасть.
Ещё один вопрос. Не про ИБ, а про мобильный клиент. У вас нет в планах сделать возможность эмитировать карту для NFC в том случае, если это доп. карта? Понятное дело речь про смартфон не владельца счёта, а владельца доп.карты.

Смотря что понимать под бекендом. Сама платформа, серверная часть, крутится на Node.js, как и с самого начала было.

Я имел в виду на чем написаны сервисы реализующие бизнес-логику, работу с БД и т.д.
Вроде был ASP.NET MVC. По крайней мере вакансии такие были.

В основном API, если я ничего не путаю, реализуется на Scala. Но и оно — это прослойка между конечными пользователями и множеством внутренних систем, написанных на разных языках с использованием различных стеков.


На node.js, насколько мне известно, у нас нет ничего, что общалось бы с данными клиентов напрямую.

Я сам сижу на angular+mobx и мне интересно (качественно пока мне никто не ответил)


  1. Redux и аналоги — сторы, которые чаще требуют отдельной регистрации функционала(редьюсера). Я бы хотел использовать компонент(возможно многократно с разными источниками данных) без ручной работы регистрации редьюсера и выделения места в сторе. Есть примеры?
  2. Продолжая первый пункт. Часто слышал этакую фразу: Не стоит все тянуть в стор. Мы используем mobx и там нет деления хранить в сторе или активной модели, или все в компоненте. Есть ли у вас аналогичное и как решаете?
  3. Возможно у вас проще. Angular использует di. Теоритически на сервере(ssr) можно запустить множество копий приложения для формирования клиенту первичного html. Каждая копия будет независима, di позволяет делить область доступности. Такая ситуация вполне может произойти. Стор у вас скорее всего глобальный, получается что множество копий ссылаются в один набор данных. Как решаете или ограничиваетесь тем, что одна копия=один node?

Ps: вас ругают за размер файла. Возможно предположу что кроме code split стоит рассмотреть tree shaking. Как понимаю у вас свои ui компоненты, возможно они плохо поддаются механизму tree shaking

Sign up to leave a comment.