1) Я отказался от overflow hidden для body по какой-то причине (уже не помню). Посмотрите как сделали Вконтакте — просто двигают отрицательным margin-top внутренний контейнер.
2) Тестируйте с разными DOCTYPE документа. от него зависит высота экрана и что-то может отвалиться
3) Я вам ночью постараюсь прислать ссылку на рабочий пример модальных окон, который мне очень понравился. Как я сделал решение для своего сайта можете посмотреть на orgup.com/e244 (внизу ссылка «Обратная связь» + постер сделан по похожей схеме, но имеет особенность сжиматься на маленьких разрешениях экрана)
4) Помните, что на разных операционных системах в разных браузерах разная ширина скролла (а в мобильном мире она равна нулю)
5) Не забудьте про вызов модальных окон из модальных окон
6) Помните, что вы молодец! Мне есть чему у вас поучиться, и слепо доверять моим советам не следует
Слишком дорогая операция. Если DOM содержит большое количество элементов или они просто используют много эффектов, то появление модального окна будет сопряжено с нежелательными эффектами да и скорость появления будет страдать
Хороший у вас сервис. Мы сами планировали такой разработать, но как только увидели ваш, а он тогда только запустился, отступили. А как заметили тиньковскую систему, окончательно убедились, что эта грандиозная идея уже работает. А чуть позже узнали, что еще 5 крайне крупных банков разрабатывают аналоги.
Я думаю, что на этом рынке будет также тесно как сейчас на оффлайновом, что конечно же будет играть только на руку покупателям.
К сожалению, сейчас возможностей интеграции со своими порталами нет.
Партнерка сейчас продумывается, но она стоит в планах еще чуть дальше, чем API. Точные сроки я назвать не могу, но осенью будет.
Что на эти события мы билеты не продаем, но их можно купить на кассире.ру. Сейчас мы агрегируем данные с кассира и нескольких других источников для удобства пользователей.
Сегодня сделаем расшифровку под каждой кнопкой «купить билет» для таких событий. Спасибо за наводку :)
Предлагаю вернутся к истоку вопроса о капче. То что сервис посещают боты и обходят механизмы защиты — проблема программиста, а не пользователя.
Капча была придумана как защита от ботов. В статье же мы видим, как капча может убить сервис. Так ли нужна она на самом деле? Может просто стоит полностью отказатся от капчи?
Давайте попробуем решить вопрос.
Чем больше посещаемость сервиса, тем меньше капча на нашем сервере будет спасать от ботов. Потому что найдутся и кто просто хочет все поломать, со временем найдутся и специально заточенные антикапчи — ресурс то популярный.
В этой ситуации спасет свой велосипед. Учитывая специфику сервиса, можно подготовить умное решение, которое не будет затрагивать интересы пользователя, не будет перекладывать на него обязанности программиста. Хитрых решений много на хабре: флеш, Js, анализ активности и прочие, и прочие.
Но изобретать свой веловипед дорого. Дорого, потому что это время программиста, которое должно оплачиватся. И на начальном этапе, когда сервис только запустился, просто нет денег, чтобы делать свою умную защиту.
Тут нам на помощь приходит reCaptcha или решение программиста чистить базу данных ручками и не ставить вообще никакой защиты.
Так что вот мои выводы:
Для новых версисов или рекапча, или ничего
Для популярных сервисов — свое решение, которое не заставляет пользователей делать лишние движения.
И вот еще одна мысль пришла. Например, мы используем решение на флеше или JS. А ведь не у всех пользователей есть JS и флеш. Может мы начнем терять пользователей? Никак нет. Ведь никто не измерял, сколько пользователей мы теряли на том, что они не могут ввести капчу, потому что она дурная и настройки выкручены по максимому. Может активность наоборот станет больше? А может и не станет.
Вывод: пока не попробуешь — не узнаешь.
У этого закона на налог за домены есть и положительная сторона: держать много доменов станет не так выгодно, а значит киберсквоттерством и перехватом не оплаченных доменов будет заниматься не так выгодно.
Потому что дополнительный клиент это еще и отличная возможность пиара мобильных технологий Вконтакте. Обязательно кто-то из разработчиков потом воспользуется этим API и для своего проекта. К тому же как не пообсуждать с друзьями девелоперами, что Вконтакт дает возможность заработать 3 миллиона рублей на команду.
По моему, у этих конкурсов сразу две цели: пиар в среде разработчиков (в меньшей степени пользователей) и поиск новых интересных идей.
Хороший фильм. Только в серединке немного депрессивный, когда рассказывают, как технологии убивают что-то сокровенное в искусстве. Но всё кончилось хорошо! =)
другой программист может не знать о существовании вашей обертки и написать кучу кода, указав все ручками.
С другой стороны нагородив кучу кода, который поддерживает фрагмент, который нужен этому программисту, он не испортит, то что уже работает. Хотя программисты бывают разные =)
Не могли бы написать, какой вы видите структуру функции recognize?
К сожалению, нет. Не думаю, что я приведу достойный пример данной функции =)
Например, я бы выделил такие общие задачи как показать всплывающее сообщение или редиректнуть пользователя на определенный урл.
Да Вы правы, общие задачи я бы тоже выделил в отдельные функции. Только еще бы разделил всплывающие сообщения на ошибки и уведомления.
И еще добавил в стандартный функционал бы доставку серверного лога для dev версии проекта для разработчиков.
Да, я согласен, и REST и WS нужно использовать. Но к сожалению, рест описывает не столько ответ сервера, сколько сам запрос. DELETE, GET, POST, PUT облегчат обращение к серверной части, но клиентскую надо еще будет писать.
Кстати, WebSocket работает в
Google Chrome (начиная с версии 4.0.249.0);
Apple Safari (начиная с версии 5.0.7533.16);
Mozilla Firefox (начиная с версии 4);
Opera (начиная с версии 10.70 9067);
и других менее используемых браузерах. Если нам нужны пользователи, которые сидят на «классических» браузерах, придется делать для них дублирующий функционал стандартными методами.
Да, все что решает jQuery можно написать самостоятельно и не охватывает архитектуру. Но всё же это такой хороший помощник, позволяющий не кодить самые «нудные» места.
Если мы захотим избавится от jQuery — архитектура должна нам позволять заменить этот компонент, каким либо другим достаточно быстро.
Будет время подискутировать пишите в этот топик или в личку — буду очень рад. :)
Могу помочь советами:
1) Я отказался от overflow hidden для body по какой-то причине (уже не помню). Посмотрите как сделали Вконтакте — просто двигают отрицательным margin-top внутренний контейнер.
2) Тестируйте с разными DOCTYPE документа. от него зависит высота экрана и что-то может отвалиться
3) Я вам ночью постараюсь прислать ссылку на рабочий пример модальных окон, который мне очень понравился. Как я сделал решение для своего сайта можете посмотреть на orgup.com/e244 (внизу ссылка «Обратная связь» + постер сделан по похожей схеме, но имеет особенность сжиматься на маленьких разрешениях экрана)
4) Помните, что на разных операционных системах в разных браузерах разная ширина скролла (а в мобильном мире она равна нулю)
5) Не забудьте про вызов модальных окон из модальных окон
6) Помните, что вы молодец! Мне есть чему у вас поучиться, и слепо доверять моим советам не следует
Тогда я понял, что универсальное решение для любого сайта да ещё и с возможностью настроек будет очень громоздким как в js так и в css.
Я думаю, что на этом рынке будет также тесно как сейчас на оффлайновом, что конечно же будет играть только на руку покупателям.
Партнерка сейчас продумывается, но она стоит в планах еще чуть дальше, чем API. Точные сроки я назвать не могу, но осенью будет.
Сегодня сделаем расшифровку под каждой кнопкой «купить билет» для таких событий. Спасибо за наводку :)
Мы думаем над открытием API для продажи билетов, чтобы организаторы могли продавать билеты на своих сайтах и даже в социальных сетях.
Но все идеи сразу мы не осилим, пока будем идти по заложенному плану.
И при чем здесь поисковые боты? Мы же говорили про защиту от спам ботов и защиту от отказа в обслуживании.
Капча была придумана как защита от ботов. В статье же мы видим, как капча может убить сервис. Так ли нужна она на самом деле? Может просто стоит полностью отказатся от капчи?
Давайте попробуем решить вопрос.
Чем больше посещаемость сервиса, тем меньше капча на нашем сервере будет спасать от ботов. Потому что найдутся и кто просто хочет все поломать, со временем найдутся и специально заточенные антикапчи — ресурс то популярный.
В этой ситуации спасет свой велосипед. Учитывая специфику сервиса, можно подготовить умное решение, которое не будет затрагивать интересы пользователя, не будет перекладывать на него обязанности программиста. Хитрых решений много на хабре: флеш, Js, анализ активности и прочие, и прочие.
Но изобретать свой веловипед дорого. Дорого, потому что это время программиста, которое должно оплачиватся. И на начальном этапе, когда сервис только запустился, просто нет денег, чтобы делать свою умную защиту.
Тут нам на помощь приходит reCaptcha или решение программиста чистить базу данных ручками и не ставить вообще никакой защиты.
Так что вот мои выводы:
Для новых версисов или рекапча, или ничего
Для популярных сервисов — свое решение, которое не заставляет пользователей делать лишние движения.
И вот еще одна мысль пришла. Например, мы используем решение на флеше или JS. А ведь не у всех пользователей есть JS и флеш. Может мы начнем терять пользователей? Никак нет. Ведь никто не измерял, сколько пользователей мы теряли на том, что они не могут ввести капчу, потому что она дурная и настройки выкручены по максимому. Может активность наоборот станет больше? А может и не станет.
Вывод: пока не попробуешь — не узнаешь.
Хотя, сам закон я считаю полнейшим бредом.
По моему, у этих конкурсов сразу две цели: пиар в среде разработчиков (в меньшей степени пользователей) и поиск новых интересных идей.
С другой стороны нагородив кучу кода, который поддерживает фрагмент, который нужен этому программисту, он не испортит, то что уже работает. Хотя программисты бывают разные =)
К сожалению, нет. Не думаю, что я приведу достойный пример данной функции =)
Да Вы правы, общие задачи я бы тоже выделил в отдельные функции. Только еще бы разделил всплывающие сообщения на ошибки и уведомления.
И еще добавил в стандартный функционал бы доставку серверного лога для dev версии проекта для разработчиков.
Web Services Eventing (WS-Eventing)
WS-Addressing Submission
и им подобные стандарты?
Кстати, WebSocket работает в
Google Chrome (начиная с версии 4.0.249.0);
Apple Safari (начиная с версии 5.0.7533.16);
Mozilla Firefox (начиная с версии 4);
Opera (начиная с версии 10.70 9067);
и других менее используемых браузерах. Если нам нужны пользователи, которые сидят на «классических» браузерах, придется делать для них дублирующий функционал стандартными методами.
Если мы захотим избавится от jQuery — архитектура должна нам позволять заменить этот компонент, каким либо другим достаточно быстро.
Будет время подискутировать пишите в этот топик или в личку — буду очень рад. :)