Pull to refresh

Comments 44

Это какое-то издевательство! Вообще нет смысла куда либо вставлять задержки, если от этого не зависит работа алгоритма.
Помнится постоянно приходилось убирать подобную задержку открытия меню «Пуск» для комфортной и быстрой работы.

А те дебилы, которые бросают себе на счёт по 100 рублей это вообще прогульщики кунсткамеры…
К сожалению «дебилов, которые бросают себе на счёт по 100 рублей» очень много и мы их немного «переучили — теперь они бросают по 500.

Ну меню пуск вы открываете за день >100 раз, а оплату производите даже не каждый день — задержка в ней — не так страшно. А само тестирование — это да, согласен, издевательство.
Мне интересно чем они руководствуются? Они в свой бензобак так же по 5 литров заливают?

Я всегда думал, что КИВИ тормозят от экономии на железе и использования Flash. А оказывается это заговор! :)
Сбер-онлайн при платежах/переводах стал тормозить по 2-3 минуты (последние месяца два такая ситуация). Привычка уже, тыкнуть кнопку и переключиться на другую вкладку, спокойно читая что-нибудь, краем глаза поглядывая на индикатор вкладки. Забудешь — вышибет сессию (5 минут что-ли там...).
Они решили заговор на полную катушку использовать!
Всем кто мыслит в эту сторону (фейковых задержек) предлагаю установить замок на дверь с задержкой, чтоб побольше дома бывали…
Лучше такой замок на дверь туалета поставить
Причём на вход — ооочень надо, но приходится ждать…
Это глюк — перезагрузка страницы работает без потерь и результат виден сразу же :)
Такие глюки при финансовых операциях, имхо, не очень уместны.
Верно, но оно хотя бы работает при перезагрузке, а не просто теряет данные, и на том спасибо.
UFO just landed and posted this here
Веду один проект, где есть клиенты, пополняющие счёт на сто рублей два раза в день, вместо того, чтобы делать это раз в месяц и даже получать бонус за это. Менеджеры не смогли их переубедить. Говорят, привыкли так.

P.S.: А, да. Извините, если доставляю вам неудобства, заправляясь на сто рублей. :(
Один пользователь завел новый аккаунт и по воле случая попал в группу A

Читер!

А вообще, любая заминка в интерфейсе — зло. Любая длительная операция должна сопровождаться какой-либо анимацией и работающей кнопкой «отмена».
сопровождаться какой-либо анимацией и работающей кнопкой «отмена»


Так и есть. Пока выполняется ajax-запрос (который тормозит) у пользователя «крутится анимация».
А у меня есть позитивный пример применения задержек. В одной нашей системе (не веб, просто сетевое корпоративное приложение) обновление определенного списка могло занимать 0.5-1секунду времени, т.е. выполняться относительно медленно. Раздраженные пользователи сразу как видели, что список не обновляется «мгновенно» (приложение «задумывается»), начинали беспорядочно кликать левой кнопкой мыши по кнопке обновления списка «чтобы он открылся быстрее», но на самом деле список открывался и сразу происходил новый перезапрос данных из БД, и все это продолжало тормозить, пока пользователь не переставал кликать левой кнопкой. Был применен «лайфхак»: после открытия списка при попытке повторного обновления пользователю еще 3 секунды с момента последнего обновления списка все еще показывался старый список, т.е. данные не перезапрашивались из БД. По словам пользователей «список стал обновляться гораздо быстрее».
Блокировать же кнопки надо, пока идёт асинхронная операция.
Там синхронная операция, но когда она заканчивается, кнопка разблокируется, а юзер продолжает ее тыкать и происходит повторное нажатие.
В эти 0.5-1 секунду, когда идёт реальный запрос, видно как-то неактивность кнопки (смена стиля) или ещё какие-то признаки текущего процесса, а не просто подвисание? Если видно — то пользователь сам себе буратино.
Не буду рассказывать о том, как плохо то, что вы сделали (и про то, как легко делается асинхронщина в свежем шарпе даже при таркетинге на .NET 2.0), скажу лишь что лечится следующим костылём:
1) в начале операции отключаем кнопку
2) делаем свои дела, пользователь тыкает в замёрзший интерфейс
3) по окончании операции создаём одноразовый таймер на 1мс, по срабатыванию которого включаем кнопку обратно

При такой схеме все оконные события, пришедшие от истерично нажимающего кнопку пользователя будут обработаны после разморозки интерфейса, но до включения кнопки обратно.
Собственно, а зачем замораживать интерфейс? Кнопка делается неактивной, при этом оконные сообщения она не принимает. А операцию вообще отдельным потоком лучше делать. Но даже если не делать (она заведомо будет не дольше пары-тройки секунд), сообщений в очереди не появится.
Но это я про нативный клиентский софт говорю, как там с вебом — не знаю.
>>Не буду рассказывать о том, как плохо то, что вы сделали
Ну и что же тут особо плохого? Что 3 секунды не видно «супер актуальные данные»? В клиент-серверных системах клиент, как правило, никогда не видит актуальные данные, т.к. пока он на них смотрит, они могут кем-то в это время изменяться (мгновенные обновления а-ля совместное редактирование документов в гугл-докс, как правило, в системах подобного рода не делают, т.к. сложно, да и мешает зачастую).

>>создаём одноразовый таймер на 1мс
Ну не меньший велосипед, чем у меня. BTW, тыкать в кнопку можно и с периодом > 1 мс.

>>как легко делается асинхронщина в свежем шарпе
Ну у нас система не на C# написана, но обсуждение вообще не об этом.
Ну и что же тут особо плохого?
Плохого то, что у вас весь гуй заморожен и не реагирует на оконные события. Если операция продлится чуть больше, винда вообще скажет, что приложение не отвечает, и предложит его закрыть.
Вы не внимательно прочитали первый комментарий или я плохо объяснил.
Был применен «лайфхак»: после открытия списка при попытке повторного обновления пользователю еще 3 секунды с момента последнего обновления списка все еще показывался старый список, т.е. данные не перезапрашивались из БД

Имелось в виду, что GUI разморожен, кнопка обновления списка доступна, но при ее нажатии в течение 3-х секунд с момента последнего реального перезапроса данных пользователю показываются данные из кэша, т.е. просто не происходит перезапрос данных из БД. Замораживать GUI на 3 секунды я бы не додумался.
Так у вас же операция синхронная. То есть, в UI-потоке.
Синхронная, синхронная. Только между базой и юзером есть еще кэш. И метод UpdateList, который вызывается при щелчке на кнопке работает примерно так:
{
Eсли разница между текущим временем и прошлым перезапросом > 3 c то
{ запросить данные из БД в кэш;
запомнить текущее время } // Срабатывает не чаще 1 раза в 3 секунды
Показать данные из кэша // Срабатывает при каждом клике на кнопке
}
Уж все вроде разжевал, пора закрывать ветку :)
Вот пока идёт «запросить данные из БД в кэш;» UI-поток заморожен, перерисовка окна не работает, кнопки не нажимаются. А если эта операция по каким-либо причинам (перенагруженность БД, сетевые задержки, etc) будет длиться достаточно долго, то Windows начнёт ругаться на «приложение не отвечает».
Ну это само собой)) Я ж поэтому и написал, что запрос из БД может выполняться 0,5-1 с, т.е. и не настолько долго, чтобы приложение выпало в «не отвечает», но и не настолько быстро, чтобы казаться мгновенным для юзера.
Мы добавили sleep и пользователям стало несколько тяжелее делать оплату, появилась подсознательная лень. Не платить пользователи тоже не могли. Они стали закидывать на счет не 100 рублей как раньше, а 500 — чтобы лишний раз не проходить через «тормозную оплату».

Это произвело интересный, но весьма ожидаемый эффект — имея больше средств на счете, пользователи стали их больше тратить. Ну и соответственно стали больше пополнять. В результате добавления sleep на 1500 миллисекунд продажи сервисы заметно выросли. Невероятно но факт.


Огорчает меня это. Люди начали больше тратить не потому что им что-то нужно, а потому что «ну раз уж закинул денег, почему бы и нет»…
Цель любого бизнеса — максимизация прибыли!
Неправда. У коммерческой компании могут быть и другие цели.
Например — доля рынка.
Или максимум стоимости.
Или максимум доходов акционеров.

не будем упрощать 8-)
Все это и есть прибыль. Читайте первый абзац в Уставе любой коммерческой организации.
Ничего подобного.
Уставов читал много, даже своих собственных было достаточно совершенно разных.

К тому же, устав — это еще не все 8-)
Чтобы получше это прочувствовать — сейчас как раз очень удобный момент, старт дивидендного сезона. Любой акционер целого сонма компаний может прочитать Устав, посмотреть на результаты деятельности, на законы… А потом наслаждаться тем, как менеджмент и мажоры на все это радостно плюют.

Возвращаясь к теме, известно много очень успешных компаний, которые никогда не были прибыльными. То есть, всегда были убыточными. Среди ойтишных таких особенно дофига. Нужны примеры, или сами вспомните?
Коммерческая компания без прибыли называется мыльный пузырь.
Вы можете ездить в лимузинах, запускать ракеты в космос, иметь фешенебельный офис в Нью-Йорке, а за спиной ваших программистов могут быть миллионы строчек кода, но компания так и будет мыльным пузырем.

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

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

Примеров — навскидку приходят на ум Твиттер и Групон. Да и ФБ вряд ли прибылен.

Больше того, начиная с какого-то размера бизнеса, само понятие прибыли становится здорово философским. так, что даже и определение не вдруг подберешь. Уж не говоря о том, чтобы эту самую прибыль сколько-то корректно посчитать…
Информативно… Нет, не шучу.
UFO just landed and posted this here
UFO just landed and posted this here
Люди не считают свои деньги, и не контролируют траты, поэтому так и происходит. По-хорошему, нужно иметь полную бухгалтерию своих доходов и расходов, текущих и запланированных. Чтобы на счету была каждая копейка. Каждую трату вносить в расходную книгу. Тогда личные финансы станут более упорядоченными; бесполезные траты уменьшатся, а полезные — возрастут. Но ведение такого учета требует усилий и самодисциплины. Если возможно — люди от этого отказываются. В результате появляются необдуманные расходы, спонтанные покупки, на которых и можно играть бизнесменам.

Хорошая школа — попытаться прожить на официальный прожиточный минимум. Это возможно, но требует немалых усилий. Полный учет всех расходов при этом обязателен.
Это возможно, но требует немалых усилий.

Возможно просуществовать, но полноценной жизнью это сложно назвать.
Радость от спонтанных покупок тоже часть жизни, мы же не роботы. Подарки, донейты тоже приносят радость, хотя (что часто) не приносят никакой пользы.
Интересно, а вот в интерфейсе Apple Developer задержки — баг или фича?
Sign up to leave a comment.

Articles