Повторюсь: робот вам в ответ на ретвит скажет: «чтобы отправить эти деньги, нужно подключиться к Twym». И в процессе последующего подключения Твиттера и Яндекс.Денег будет немало напоминаний про отправку денег, включая выставление лимитов вашими же руками.
Так что человек, прошедший по этим шагам, будет понимать, что сейчас он отдаст деньги. И если он их все-таки отдаст, значит, он пошел за халявой обычным путем, и это никак не связано со способом, которым он отдает деньги.
Ну, позовут вас сделать ретвит и получить деньги. После этого робот скажет «чтобы отправить эти деньги, нужно подключиться к Twym». Потом скажет вам несколько раз про отправку денег на каждом шаге и даже предложит установить лимиты на отправку денег.
В таких условиях гораздо меньше рисков пройти мимо явного посыла «ты сейчас отдашь эти деньги», чем при обычных разводках типа «кинь 100 рублей на номер счета в какой-нибудь платежной системе и получишь вдвойне».
Ну, давайте допустим, что нечестное приложение сделает это один раз. Оно не знает установленных вами лимитов, поэтому наверняка попробует провести сумму, выходящую за их рамки. Робот вам ответит, что «лимит нарушен». Вы тут же узнаете, что кто-то пытается твитить от вашего имени. В твите всегда есть информация о том, из какого приложения оно отправлено.
Репутация приложения будет навсегда порушена из-за попытки утащить деньги у одного пользователя.
То есть, это должно быть очень сомнительное приложение с минимумом пользователей, которому вы почему-то доверили свой твиттер. Которому, может быть, один раз, при удачном для него стечении обстоятельств удастся утащить пару сотен рублей.
Конечно, пользователю, привязавшему к Твиттеру свой счет в Яндекс.Деньгах (в данном случае — через Twym), нужно быть внимательнее, чем просто пользователю Твиттера. С этим никто не спорит. Но это относится вообще ко всем пользователям, использующим дополнительные приложения для платежей.
И сейчас в мире становится все больше сервисов, сделанных на основе API, потому что это позволяет людям платить, не уходя из своего контекста.
Это стандартная возможность API современной платежной системы — пользователь имеет право принять решение о том, что в отдельных приложениях он хочет платить «в один клик», без подтверждения паролями. И в этот момент он обычно осознает, какие суммы ему могут потребоваться и выставляет лимиты, при которых он спокойно себя чувствует.
Такая возможность особенно актуальна, когда нужно время от времени проводить небольшие платежи без лишних телодвижений.
Думаю, что никто из шутников сейчас не имеет такого количества денег на счету. А даже если бы и имел, есть лимиты Яндекс.Денег и самого пользователя (см. выше).
Более того, при подключении Твима есть дефолтный лимит — 500 рублей в сутки. И поменять его можно только вручную в процессе подключения, вполне осознанно.
А чтобы не проходили «забытые платежи», для каждого такого потенциального платежа установлено время жизни — 16 часов. Если в течение 16 часов отправитель не подключится к Твиму, то платеж «протухнет» и надо будет писать новый твит.
Если человек «по приколу» создает распоряжения на миллионные платежи, значит, у него должно быть достаточно хорошее чувство юмора, чтобы потом посмеяться, когда деньги отправятся :)
Мы действительно говорим на разных языках. Вы не понимаете, почему для меня это важно, мотивация совершенно не та. Смысл не в том, чтобы выполнить требования заказчика (я сама себе заказчик зачастую), а в том, чтобы как можно раньше понимать, где могут быть подводные камни с точки зрения реализации и вложений.
Речь не о том, чтобы проектировать, исходя из ограничений. Речь о том, что еще до разработки финального прототипа хорошо бы осознавать, как его будут реализовывать. Иначе модель может оказаться красивой, но настолько дорогой и/или долгой, что ее не выпустят. Или выпустят, но по дороге оторвут что-нибудь (особенно если вы аутсорсер). Если вы понимаете условия реализации, то можете и работать с ними по-человечески. Например, сделать в нужный срок разумную часть того, что хотелось бы, а потом прикрутить остальное. Качество только выигрывает в таких случаях.
И потом — вы же начинаете с архитектуры в любом случае. Да, детали взаимодействия вы продумаете потом, но что мешает бэк-энду посмотреть на вашу блочную схему и начать пилить внутренности?
Ну, вот в нашей реальной жизни in-house дизайнеров это очень удобная и важная штука :) Потому что на этапе продумывания общего концепта нужны именно наброски, которые можно крутить очень быстро, параллельно обсуждая с разработчиками и бизнесом. Удобство — это самое важное, но если думать только о нем, то можно сделать прототип, который в итоге не будет реализован по бизнесовым или технологическим причинам.
Не согласна, блочная схема дает верхний уровень представления об устройстве интерфейса.
Вы говорите исключительно про использование, но при реальном старте разработки интерфейса гораздо больше факторов, влияющих на итоговое решение. Блочная схема нужна как минимум для того, чтобы свести верхнеуровневую картинку про бизнес-цели, дизайн и основное техрешение. Еще раз — это не замена, это просто первый уровень погружения.
Кстати, блочную схему вполне можно сделать с простой динамикой — тот же balsamiq дает такую возможность.
Balsamiq, конечно, для блочных схем, но простейшую динамику в нем тоже можно делать. Есть же возможность связывать элементы и страницы линком. Грубо говоря, в нем можно делать схематичный прототип.
На ранних стадиях обсуждения фичлиста и техрешения нужна хотя бы условная визуализация, блочной схемы на этом этапе вполне достаточно. А прототип можно и нужно делать параллельно, чтобы он был готов к моменту старта разработки.
В условиях разработки сервисов для уже существующего продукта это точно лучше работает.
На мой взгляд, приличное содержательное письмо должно состоять из нескольких коротких абзацев с подзаголовками, желательно с одной, максимум двумя ссылками в каждом.
А уведомление о каких-либо событиях вообще должно быть по определению очень коротким и содержать суть события (т.е. если уведомление о сообщении, то сообщение крайне желательно помещать в текст письма).
Помимо того, про что уже сказали выше, напрягает:
— каша из ссылок (куча ссылок в одном абзаце),
— мелкий серый текст на полписьма (FlyingBlue этим грешит, например),
— все содержание — одной здоровой картинкой, а под ней ссылка на отписку (при отключенных картинках видно только эту ссылку, ага).
Раньше всё было гораздо сложнее — если счет блокировали, то нужно было заверять у нотариуса документы, а потом отправлять их почтой в Россию, дождаться, пока их получат Я.Деньги, а потом счёт закрывали (тот самый «железный аргумент») и сразу после этого можно было свои деньги вывести.
А теперь всё проще:
1) можно пройти идентификацию довольно быстро — т.е. не нужно заверять у нотариуса ничего, можно просто прийти в Контакт, Анелик или офис Я.Денег,
2) спокойно дальше пользоваться счётом, т.к. теперь Яндекс.Деньги ориентированы не только на Россию.
Так что если у кого-то деньги заблокированы, то сейчас как раз удобный момент для возвращения в систему.
Зря вы сравниваете вектор в горизонтальном пейджинге и расположение элементов в общей структуре страницы.
В первом случае действительно есть четко заданное направление, к которому мы привыкли.
Во втором (пример с блогом) — происходит расстановка акцентов: в блоге важнее удобный просмотр постов, а меню является вспомогательным элементом, поэтому оказывается в правой колонке.
Про рабочий стол можно вообще много всего предположить, но это тоже не будет связано с горизонтальным вектором пейджинга в вебе.
Так что человек, прошедший по этим шагам, будет понимать, что сейчас он отдаст деньги. И если он их все-таки отдаст, значит, он пошел за халявой обычным путем, и это никак не связано со способом, которым он отдает деньги.
В таких условиях гораздо меньше рисков пройти мимо явного посыла «ты сейчас отдашь эти деньги», чем при обычных разводках типа «кинь 100 рублей на номер счета в какой-нибудь платежной системе и получишь вдвойне».
Репутация приложения будет навсегда порушена из-за попытки утащить деньги у одного пользователя.
То есть, это должно быть очень сомнительное приложение с минимумом пользователей, которому вы почему-то доверили свой твиттер. Которому, может быть, один раз, при удачном для него стечении обстоятельств удастся утащить пару сотен рублей.
Конечно, пользователю, привязавшему к Твиттеру свой счет в Яндекс.Деньгах (в данном случае — через Twym), нужно быть внимательнее, чем просто пользователю Твиттера. С этим никто не спорит. Но это относится вообще ко всем пользователям, использующим дополнительные приложения для платежей.
И сейчас в мире становится все больше сервисов, сделанных на основе API, потому что это позволяет людям платить, не уходя из своего контекста.
Такая возможность особенно актуальна, когда нужно время от времени проводить небольшие платежи без лишних телодвижений.
Более того, при подключении Твима есть дефолтный лимит — 500 рублей в сутки. И поменять его можно только вручную в процессе подключения, вполне осознанно.
А чтобы не проходили «забытые платежи», для каждого такого потенциального платежа установлено время жизни — 16 часов. Если в течение 16 часов отправитель не подключится к Твиму, то платеж «протухнет» и надо будет писать новый твит.
Речь не о том, чтобы проектировать, исходя из ограничений. Речь о том, что еще до разработки финального прототипа хорошо бы осознавать, как его будут реализовывать. Иначе модель может оказаться красивой, но настолько дорогой и/или долгой, что ее не выпустят. Или выпустят, но по дороге оторвут что-нибудь (особенно если вы аутсорсер). Если вы понимаете условия реализации, то можете и работать с ними по-человечески. Например, сделать в нужный срок разумную часть того, что хотелось бы, а потом прикрутить остальное. Качество только выигрывает в таких случаях.
И потом — вы же начинаете с архитектуры в любом случае. Да, детали взаимодействия вы продумаете потом, но что мешает бэк-энду посмотреть на вашу блочную схему и начать пилить внутренности?
Вы говорите исключительно про использование, но при реальном старте разработки интерфейса гораздо больше факторов, влияющих на итоговое решение. Блочная схема нужна как минимум для того, чтобы свести верхнеуровневую картинку про бизнес-цели, дизайн и основное техрешение. Еще раз — это не замена, это просто первый уровень погружения.
Кстати, блочную схему вполне можно сделать с простой динамикой — тот же balsamiq дает такую возможность.
На ранних стадиях обсуждения фичлиста и техрешения нужна хотя бы условная визуализация, блочной схемы на этом этапе вполне достаточно. А прототип можно и нужно делать параллельно, чтобы он был готов к моменту старта разработки.
В условиях разработки сервисов для уже существующего продукта это точно лучше работает.
А уведомление о каких-либо событиях вообще должно быть по определению очень коротким и содержать суть события (т.е. если уведомление о сообщении, то сообщение крайне желательно помещать в текст письма).
Помимо того, про что уже сказали выше, напрягает:
— каша из ссылок (куча ссылок в одном абзаце),
— мелкий серый текст на полписьма (FlyingBlue этим грешит, например),
— все содержание — одной здоровой картинкой, а под ней ссылка на отписку (при отключенных картинках видно только эту ссылку, ага).
Здесь не в яркости дело, мне кажется.
А теперь всё проще:
1) можно пройти идентификацию довольно быстро — т.е. не нужно заверять у нотариуса ничего, можно просто прийти в Контакт, Анелик или офис Я.Денег,
2) спокойно дальше пользоваться счётом, т.к. теперь Яндекс.Деньги ориентированы не только на Россию.
Так что если у кого-то деньги заблокированы, то сейчас как раз удобный момент для возвращения в систему.
хорошо забытые старыеновые рынки. Написано же, что ввод со временем будут расширять.Сама по себе возможность легально работать с Яндекс.Деньгами очень ценна для многих моих друзей из СНГ. А ввод можно расширить со временем.
В первом случае действительно есть четко заданное направление, к которому мы привыкли.
Во втором (пример с блогом) — происходит расстановка акцентов: в блоге важнее удобный просмотр постов, а меню является вспомогательным элементом, поэтому оказывается в правой колонке.
Про рабочий стол можно вообще много всего предположить, но это тоже не будет связано с горизонтальным вектором пейджинга в вебе.