О рецензенте
Коллис Тайед – соучредитель и генеральный директор Evato. Он начинал работать в качестве веб-дизайнера, делая макеты в Photoshop и нарезая их для разработки большинства ранних сайтов Envato. Сейчас Коллис больше времени проводит, планируя, разрабатывая стратегии и работая с электронной почтой, но веб-дизайн всегда будет в его сердце!
Выбор платформы: технические решения для переделки вашего сайтаАвтор: Рэйчел ЭндрюРецензенты: Райан Карсон, Харли Финкельштейн
Этот раздел написан для тех, кто участвует в планировании работ по переработке сайта. В предыдущем разделе Пол Боуг рассматривал бизнес-сторону полной переделки и поэтапной доработки вашего сайта. В этом разделе мы обсудим некоторые технические проблемы, с которыми вы можете столкнуться в своей работе. Для переделывания интерфейса сайта не всегда требуется полностью переписывать код. Мы дадим вам несколько советов, как утрясти этот вопрос.
Прежде чем окунуться с головой в глобальное переделывание сайта, мы, по совету Пола, должны узнать все о существующем сайте и серверах, которые им управляют. При переработке системы очень легко потерять ценную информацию. Поэтому даже если вы полностью переделываете сайт или выбираете новую платформу, узнайте все, что только можно, о существующем сайте, чтобы не повторять ошибок ваших предшественников.
Прежде чем что-то предпринять, вы должны вникнуть во все технические требования. Возможно, переработка сайта добавит новые функции, которые нужно будет поддерживать. Например, для сайта электронной коммерции вам нужно знать, как принимаются платежи по Интернету и какие сервисы нужны для этого. Хостинг, который вы используете, должен удовлетворять техническим требованиям нового сайта или доработке существующей платформы. Поэтому не забудем подумать о том, как выбрать хороший хостинг.
Начало работы над проектом – прекрасный момент, чтобы оценить существующий сайт и убедиться, что как специалист вы в хорошей форме. В конце этого раздела вы найдете идеи о средствах разработки, контроле версии и об изменении версии существующего сайта. Как и в предыдущем разделе, мы обсудим здесь многое, только не слишком подробно. Формат книги не позволяет. Наша главная цель – заставить вас задуматься о различных аспектах сайта и выбрать те основы, которые вы будете применять в своей дальнейшей работе
Для кого этот раздел?
Неважно, с кем и для кого вы переделываете сайт: привлекаете ли подрядчиков для создания собственного сайта или работаете в команде разработчиков в качестве нетехнического специалиста, этот раздел – для вас. Изучив ее, вы поймете процесс переделывания, и это принесет вам пользу.
Возможно, вы тот, кто занимается разработкой сайта постоянно либо для себя (в этом случае заказчик вы сами), либо для стороннего заказчика или работодателя. В этом случае все в этом разделе будет для вас интересным. Для разработчика переделывание сайта – это фантастическая возможность. Сайт или приложение, которые у вас есть сейчас, имеют не только сильные и слабые стороны, но и базу пользователей, и посещаемость. Все это вы сможете изучить.
Проигнорировав на свой страх и риск эти данные, в конечном итоге вы просто воссоздадите те же самые проблемы, которые существуют и сегодня, либо не включите необходимые пользователям важные функции. Когда вы занимаетесь кардинальной переделкой сайта, у вас есть возможность узнать о его болевых точках и проблемах от пользователей и владельца. Система управления контентом (CMS[9]) очень сложная, поэтому сайт не обновляется? Клиенты интернет-магазина постоянно звонят и просят помочь им сделать заказ? Дизайн ограничивает возможность добавления текста и фотографий? Если вам удастся решить эти проблемы – создать CMS, которой люди будут пользоваться с удовольствием, или наполовину сократить количество звонков от обескураженных покупателей, – вы получите бескрайнюю благодарность вашего клиента или начальника. Согласитесь, приятно знать, что ваша работа улучшает чью-то жизнь или помогает развить бизнес.
Если разработкой сайта занимается подрядчик, этот раздел все равно будет интересен для вас. Мы не станем слишком глубоко копаться в технических темах. Общее понимание вопросов, которые обсуждаются в этом разделе, сделает ваше общение с разработчиками легким и непринужденным.
Теперь допустим, что ваша роль – нетехническая. К примеру, вы работаете исключительно над графическим дизайном, либо занимаетесь управлением проекта, либо копирайтингом. Опять же понимание того, что делают разработчики, только поможет общению.
Узнать все о действующей платформе
Как уже было сказано, все, что вы знаете о сайте, который собираетесь переделывать, очень важно. Поэтому нужно не только проанализировать сайт самому, но и поговорить с людьми, которые им пользуются: с его владельцами, посетителями и теми, кто его поддерживает.
Поинтересуйтесь, что им нравится в существующем сайте. Это может быть все, что угодно. Например, клиенту нравится, как выглядит сайт и как в нем представлен бренд, или, возможно, он находится на хороших позициях в поисковой выдаче. Пользователи могут сказать, что сайт удобный и можно обойтись без всяких прибамбасов, которые так любят заказчики.
Поговорите с теми, кто обновляет контент и узнайте, что они думают о функциях существующего сайта. Если вы решите сменить платформу, берите на карандаш все, чем люди пользуются в своей работе. У многих она строится полностью вокруг системы. Бывает, что, отняв у людей возможность вести отчетность по заказам или делать записи в блог, вы явно усложните им жизнь. Если вы не заменяете эти функции, то вам лучше предоставить систему более высокого качества!
В каждой системе есть вещи, которые сводят пользователей с ума. Но даже если вы обслуживаете сайт, не считайте себя знатоком в них. Много раз я сталкивался с тем, когда недостаточно подкованные технически пользователи думали, что неполадки в системе возникли по их вине и поэтому молчали. И всякий раз, когда не удавалось сохранить данные, они думали: «Опять я это сделал!» – и повторяли все заново. Вместо того чтобы поднять проблему, пользователи списывали ее на то, что не умеют пользоваться компьютером.
Но даже если пользователь и виноват, а система допускает постоянную потерю данных, ваша задача – принять превентивные меры. И все же вопиющие ошибки часто не регистрируются по несколько месяцев, а пользователи предпочитают молчать и месяцами работать с ними. Если вы собираетесь сохранять уже существующую систему, отыщите и исправьте эти болевые точки. Поверьте, те, кто пользуется системой каждый день, смогут тогда вздохнуть спокойно.
Есть системы, которыми люди пользуются в своей ежедневной работе постоянно. Так вот неплохо было бы отследить этот процесс. Что они делают изо дня в день? Очень часто человек даже не в курсе, что новая система может избавить его от изнурительной работы. Я видел пользователей, которым приходилось по несколько раз вводить в систему одни и те же данные. К примеру, они вводили одну и ту же информацию в разные места или копировали данные из одного документа в другой, тогда как очень простым решением стала бы автогенерация отчетов или добавление в CMS скрипта, который копирует данные из одного места в другое. Если вы будете просто смотреть на сайт с управляемым контентом или систему электронной коммерции, то ничего не увидите. Садитесь с рядом с администратором и наблюдайте, как пользователи работают в системе.
Если вы переделываете сайт, то придется решать не только видимые проблемы. Вам нужен сайт с такими функциями, которых у него нет сейчас? Хотите продавать онлайн? Решили наконец-то, что сайту нужна система управления контентом? Текущей CMS сложно пользоваться, или она не поддерживает контент, который вы хотите создавать?
Если вы будете знать, каких функций не хватает сайту, то решите, нужно ли вам сменить систему или дорабатывать ее дальше. Как только вы поймете, как пользователи и администраторы работают с сайтом или приложением, можете начинать собирать техническую информацию для переработки
Сбор технических требований
В предыдущем разделе мы обсуждали требования к сайту. Здесь мы поговорим о том, как выполнить их технически. Остерегайтесь заявлений типа: «Мы хотим, чтобы все было так, как в текущей системе» – если только не вы ее создали! Если клиент этого хочет, убедитесь, что вы получили подробную информацию обо всем том, что должно быть в новой системе.
Рисунок 2.1. Любой, кто выбирает CMS, столкнется с массой опций. Чтобы решить, что сработает для вашего проекта, нужно понимать технические требования
Не сделаете этого – готовьтесь к тому, что перед самым запуском вас спросят: «А как эта система поддерживает задачу, которую пол-офиса делает каждый день?» (хоть это и не так на самом деле). И таким образом заставят вас вносить значительные дополнения в проект. Знаю это по своему опыту!
Управление контентом
Почти всем сайтам требуется та или иная форма управления контентом. Это может быть обновление страниц, добавление продукта в магазин или редактирование текста в приложении. В какой степени клиенту необходимо управлять контентом и кто будет его редактировать? В этом разделе мы будем использовать термин CMS в очень широком смысле, для описания любого инструмента редактирования контента – от простого текстового редактора до полнофункциональной корпоративной CMS бизнес-уровня.
Вот некоторые мысли по поводу выбора CMS:
• Всем ли редакторам (контент-менеджерам) нужны одинаковые права доступа?
• Будут ли управлять контентом специальные сотрудники или это станет частью работы других людей?
• Нужно ли поддерживать многоязычность?
• Какой тип контента будет редактироваться?
• Какие нужны средства редактирования?
Всем ли редакторам (контент-менеджерам) нужны одинаковые права доступа?
Итак, для работы на сайте нужен один редактор (например, владелец малого бизнеса) или несколько? Если второй вариант, то все ли редакторы будут иметь равные права? Или один будет иметь доступ к каким-то разделам системы, а другие нет?
Вот несколько сценариев:
• Сайтом большой компании управляет один человек, который утверждает весь контент, а в подготовке контента принимают участие несколько сотрудников. Клиент хочет, чтобы эти редакторы могли создавать контент и отправлять его на рассмотрение. После одобрения, он публикуется управляющим редактором.
• Компания хочет, чтобы отдел кадров мог публиковать и снимать вакансии на сайте и вел раздел, который касается вопросов найма сотрудников. У этих пользователей не должно быть прав для внесения изменений в другие разделы.
• Владелец сайта электронной коммерции не хочет, чтобы его редакторы имели доступ к собранным в системе отчетам по продажам или информации о покупателях. В то же время он хочет, чтобы его бухгалтер имел доступ к данным о продажах, и ни к каким другим больше.
• Владелец сайта хочет, чтобы все желающие могли писать в блог, но не трогали контент других разделов.
Будут ли управлять контентом специальные сотрудники, или это станет частью работы других людей?
Очень важно понять, что могут люди, которые создают и редактируют контент. Речь здесь не только о технических умениях, к примеру хорошо ли они знакомы с CMS, но и о том, насколько они чувствуют дизайн и контролируют, как все выглядит. Также проверьте их копирайтерские способности. Если вначале контент пишет опытный копирайтер, а после поддержкой занимаются владелец или сотрудник, не занимающийся копирайтингом, то CMS должна помочь импонять, что и как писать. Об этом – в статье «Ваша CMS как куратор дизайна и контента»[10].
Нужно ли поддерживать многоязычность?
Даже если вы запускаете одноязычный сайт, но в ближайшем будущем нужно будет поддерживать несколько языков, подготовьтесь к этому заранее. Добавить на сайт поддержку нескольких языков гораздо сложнее, чем заложить эту функцию сразу. Конечно, это требование ограничивает выбор вариантов готового ПО.
Если сайт нужно переводить, выясните, как будет проходить этот процесс, чтобы поддерживать его в системе. Переводчики будут просто переводить весь контент в Word-документах или чем-то подобном, а потом отправлять редактору, чтобы он вносил их в систему? Не будет ли переводчику проще читать и переводить контент прямо в CMS?
Какой тип контента будет редактироваться?
У большинства сайтов, которым требуется CMS, относительно статические страницы и четкая стандартная древовидная структура. Наиболее логично создавать такой контент постранично, чтобы администраторы легко могли найти страницы для редакции.
В некоторых сайтах основная функция – блог и несколько поддерживаемых страниц. Тогда вы с заказчиком можете остановиться на использовании такой CMS, как WordPress. В ее ядре – функциональный и качественный блог, в ней также можно добавлять отдельные страницы.
Чем больше сайт, тем серьезнее требования к контенту. Например, сейчас мы переделываем сайт для фестиваля искусств. Многие годы фестиваль остается привлекательным за счет подборки ценных видео– и аудиоматериалов, а также тысяч высококачественных фотографий, которые ежегодно снимают профессиональные фотографы
В сайтах с постраничной структурой предполагается, что контент-редакторы будут каждый раз отыскивать в архивах важный материал и перезагружать его заново на сайт. В данном случае это не лучший способ. Вместо этого мы создали отдельный медиасервер, со средствами поиска и маркировкой материалов. Все это для того, чтобы их было легко находить и вставлять в страницу. CMS готовит фотографии нужных размеров, включая те, что нужны для адаптивного дизайна. Изучив архивы материалов и, оценив их объем, мы поняли возникающие в связи с этим проблемы. Это позволило нам предложить такое решение.
Есть сайты, которые больше похожи на веб-приложения, неважно, система ли это электронной коммерции, или традиционные приложения. Эти системы ориентируются не на постраничную структуру (хотя они и могут включать в себя некоторые страницы), а на различные виды контента, требующие обновления.
Слишком часто в таких системах небольшие тексты (например, текст на кнопке) жестко кодируются в самом приложении. И поэтому только разработчик может изменять текст в призыве к действию. В идеале должно быть так, чтобы рядовые пользователи могли его редактировать.
A/B-тестирование
На некоторых сайтах, в особенности на тех, что продают товары, вам нужно тестировать разные версии страниц, чтобы узнать, какой контент, макет страницы или взаимное расположение блоков приводит к большему числу конверсий.
В зависимости от типа сайта конверсии[11] могут быть такие: покупка товара через сайт, подписка на получение пробной версии продукта, на e-mail-рассылку или заполнение формы. Если потребуется такой вид тестирования, как он будет осуществляться с помощью CMS? Если часть посетителей нужно отправить на одну версию страницы, а остальных – на другую, здесь не обойтись без стратегии. Об этом виде тестирования вы можете прочесть на сайте Smashing Magazine в исчерпывающей статье «Исчерпывающее руководство по А/В тестированию»[12] либо на сайте СилаУма (примеч. ред.)
Электронная коммерция
Добавить функцию электронной коммерции на сайт может оказаться простым делом. Возможно, достаточно будет всего лишь поставить несколько кнопок «Купить сейчас» платежной системы PayPal[13]. Но могут быть и трудности, например, если вам придется настраивать свой магазин на поддомене готовой платформы онлайн-магазина или разрабатывать свой собственный. Конечно, сегодня процесс продажи товара напрямую через сайт не надо усложнять. Но все же есть над чем поломать голову, когда вам предстоит сделать правильный выбор в зависимости от вида продукции. В этом разделе мы пробежимся по некоторым из вариантов. Несомненно, вам будет это на руку, если вы в первый раз внедряете функцию электронной коммерции – ведь это все равно что ступить на необитаемый остров.
Что продаем?
Может быть, в вашем онлайн-магазине продаются товары, которые отправляются покупателю по почте или с курьером? Или, возможно, товары, которые поставляются электронно, такие как электронные книги, музыка или ПО. Также транзакциями на сайте могут быть пожертвования или подписка на сервис. Если товары скачиваемые, то подумайте над тем, как они будут доставляться клиенту после оплаты.
Как покупать?
Один ли товар будет продаваться (например, электронная книга), или посетители смогут просматривать товары и добавлять разнообразные позиции в свою корзину? Можно ли будет выбрать товар по характеристикам (например, футболку по размеру и цвету)? Нужно ли делать категоризацию товаров, чтобы упростить их поиск? Товар будет ограничиваться одной категорией или его можно будет найти в нескольких? Пригодятся ли ярлыки и ссылки среди дополнительных или связанных товаров (скажем, позволяющие владельцу продвигать аксессуары к продукции)?
Будут ли на сайте специальные предложения – «При покупке одной вещи, вторая – в подарок!», «Скидка 20 %», «Две вещи по цене одной!», «Купите Х, получите Y за полцены!»? Реализовать подобные предложения в созданной по заказу системе может быть достаточно непросто. А если вы используете коробочную CMS, то нужно знать, сможет ли она поддерживать их.
Дьявол (как и бюджет) в деталях. Из всех сайтов, над которым я работал, наиболее склонны к расширению рамок функционала онлайн-магазины. При планировании подумайте обо всех заданных выше вопросах. Конечно, есть много чего заманчивого и желание иметь как можно больше всевозможных функций велико. Но если вы создаете CMS самостоятельно и не хотите использовать коробочные решения, то лучше старайтесь разрабатывать более простые вещи. Ведь это значительно сэкономит вам время.
Рисунок 2.2. Вещь, которая, кажется простой, на самом деле может иметь ряд опций (например, футболка может быть женской или мужской и разных размеров)
Учетная запись и отслеживание заказа
У пользователей может быть опыт использования учетной записи (аккаунта) и отслеживания заказов. Возникают вопросы: обязательно ли пользователям создавать учетную запись? Смогут ли они отслеживать свои заказы и видеть их путь от «В обработке» до «Отгружено»? Аккаунт должен иметь такие основные функции управления, как восстановление забытого пароля или обновление контактных данных.
Как принимать оплату?
Вероятно, вам понадобится принимать платежи от покупателей по кредитным и дебетовым картам. Есть несколько вариантов, разных по сложности и цене. Обычно платежи обрабатываются с помощью платежной системы, аккаунта продавца и платежного шлюза и программы-посредника SaaS (программное обеспечение как услуга). Принимать платежи онлайн через платежную систему – легко. Плюсы здесь в том, что создать аккаунт несложно, а интеграция может быть различной: от простого варианта – встраивания кода кнопки на страницу, до полной интеграции с вашей системой.
На платежном рынке есть и другие игроки, но большинство из них действуют в немногих странах. Причина в том, что большая часть законов о процедуре оплаты в каждой стране имеет свою специфику. Если вы будете принимать регулярные платежи, то вам могут пригодиться Chargify и Recurly. И хотя сейчас они доступны только в США[14], Stripe выглядит многообещающе как метод принятия платежей онлайн.
Чтобы напрямую принимать платежи по карте, избегая посредников, вам нужно завести аккаунт онлайн-продавца. Это позволит принимать платежи по кредитке и переводить деньги на ваш банковский счет. Если у вас есть действующий банковский счет для офлайновых продаж, вероятно, вы не сможете воспользоваться им для онлайновых транзакций. Транзакции через Интернет не совсем безопасны, поэтому прежде чем начать выполнять их, свяжитесь со своим банком. Банк посоветует защитить свой платеж, в большинстве случаев через провайдера платежных сервисов PSP (payment service provider), иногда называемым платежным шлюзом.
Рисунок 2.3. Stripe.com – это новый игрок на рынке, предлагающий простой способ приема платежей
Но что вы точно не должны делать, так это сохранять данные кредитной карточки, чтобы позже ввести их в терминал офлайн. Это противоречит условиям коммерческого договора. Поэтому, пока банк не даст вам свое письменное согласие и вы не выполните требования PCI DSS[15] (о них мы расскажем позже), просто не делайте этого.
Платежный шлюз
Платежи через шлюз позволят вам принимать оплату от клиентов по карте, проверять ее номер и состояние счета, а после этого безопасно переводить платеж в ваш банк. Взаимодействовать со шлюзом можно двумя способами:
• Через страницу платежей
Пользователь переходит с вашего сайта на защищенную страницу провайдера платежного сервиса и вводит данные карты.
• Через интеграцию по API[16]
Пользователь вводит данные своей карточки на вашем сайте (на странице с сертификатом защиты, который поддерживает протокол SSL), и эти данные затем отправляются в шлюз. Ваш сайт в этом случае служит посредником; пользователь не в курсе, какие транзакции проводит банк, а видит их только на вашем сайте.
Преимущества интеграции платежной страницы в том, что ваш сайт вообще не имеет отношения к данным карты, поэтому вы не несете ответственность за безопасность клиента. Но есть один большой минус. Это то, что вы уже не сможете контролировать процесс оплаты, потому что на финальном этапе требуется собрать все данные и отправить их на платежный сервер. Кроме того, редко встречается возможность настроить страницу оплатыв своем фирменном стиле или даже просто вставить в нее логотип.
Необходимость уводить клиента с сайта очень беспокоит многих владельцев магазинов. Они боятся, что пользователи будут отменять транзакцию до того, как попадут на платежную страницу WorldPay или другого сервера. Но если отправлять клиентов на сайт известного банка для введения данных карты, то они будут больше доверять вам.
Скажу о себе. Когда на каком-то незнакомом сайте (например, мелкого розничного торговца) меня просят ввести данные моей карты, я начинаю нервничать и думать, а что с ними будут делать? Высветится номер моей карты в открытом виде на экране? Сохранятся ли ее данные в базе на сервере сайта?
Даже если страница имеет сертификат защиты и подтверждения о безопасности передаваемых данных, я все равно не имею понятия, что будет с моими данными, когда я кликну «Подтвердить». Но если в финале я окажусь на знакомой странице PSP, то буду спокоен за безопасность своих данных и за то, что они не попадут на сомнительный сайт. Я больше доверяю WorldPay, чем заурядному магазину виджетов.
Еще один плюс платежной страницы в том, что, если правила оплаты по карте изменяются, они будут обрабатываться на стороне провайдера PSP. Например, один из наших клиентов требовал 3D-Secure (на такой основаны технологии Verified by Visa и MasterCard SecureCode), чтобы принимать платежи Maestro. 3D защита требует от пользователей подтверждать платеж на странице своего банка, прежде чем он будет разрешен.
Если бы мы использовали API, нам нужно было бы изменить код, чтобы интегрировать 3D защиту. Но так как мы пользовались платежной страницей, мы просто уведомляли PSP, которая включала эту функцию для нашего аккаунта.
Все эти моменты подтолкнули владельцев многих сайтов к использованию платежных страниц. Они поняли, что нести ответственность за данные кредиток – только лишняя головная боль. Платежные страницы интегрируются со многими коробочными системами. После того как платеж сделан, пользователь перенаправляется обратно на ваш сайт, а специальный код позволяет идентифицировать пользователя и транзакцию и обрабатывать необходимые данные о совершенном заказе (например, поставить в базе данных отметку «Оплачено» или обеспечить клиенту доступ к цифровой продукции).
Преимущество полной интеграции API в том, что вы можете контролировать процесс оплаты от начала до конца, в том числе оформлять страницы оплаты в своем стиле. Но вы также несете ответственность за безопасность данных пользовательских карт, и правила требуют, чтобы вы подтвердили, что используете передовые технологии.
PCI DSS
Стандарт безопасности данных индустрии платежных карт (The Payment Card Industry Data Security Standard (PCI DSS)) представляет собой совокупность 12 детализированных требований, которые распространяются на все компании, принимающие оплату по картам. Это относится не только к транзакциям онлайн. Обычный офлайновый магазин, который принимает платежи онлайн, должен тоже подчиняться требованиям PCI DSS для обоих способов оплаты: офлайн и онлайн.
Если вы принимаете онлайн-платежи через платежную страницу, но не получаете, обрабатываете или храните данные по картам, то вы можете заполнить сокращенный PCI DSS опросник (SAQ A), чтобы подтвердить, что ваш PSP совместим с PCI DSS. Если как средство интеграции вы используете API, то он полностью должен соответствовать PCI DSS (даже если вы не сохраняете данные карты) и включать ежеквартальные проверки безопасности, подтверждающих постоянное соблюдение требований.
В данном разделе мы не рассматриваем детали совместимости с PCI DSS, но если вы занимаетесь разработкой сайта, на котором платежи принимаются не через платежную страницу, тогда ознакомьтесь с ними или воспользуйтесь услугами тех, кто разбирается в данной теме.
Хранение данных карты
Я настоятельно советую вам не хранить данные карты на сервере клиента, даже в зашифрованном виде. Хранение данных требует совместимости с PCI DSS и поддержки сервера, а также Сети, в которых эти данные будут находиться в безопасности.
Если вам будет нужен доступ к ним, чтобы списать абонентскую плату, например вы можете поискать платежный шлюз, который предлагает сервис хранения данных. Если же вы собираетесь сохранять данные карты только для использования оплаты в один клик (как это делает Amazon), будьте осторожны! Вы в самом деле хотите взять на себя ответственность за данные вашего клиента? Хотите иметь дело с дополнительными и текущими расходами по поддержанию совместимости?
Валюта и местные налоги
Вполне возможно, что вам придется отчитываться по местным налогам, или НДС в Европе. Конечно, достаточно сложно разобраться в том, какие налоги нужны, но вы должны быть уверены, что ваша система обработает их правильно. Например, моя компания владеет скачиваемым продуктом, мини-CMS, которая называется Perch. Наша компания зарегистрирована в Великобритании, поэтому мы должны взимать налоги с британских покупателей. Еще нам нужно взимать НДС с покупателей из Евросоюза, пока у них есть действующий регистрационный номер плательщика НДС. Если покупатели из страны, которая не входит в состав Европейского Союза, мы не должны брать с них НДС. Итак, система должна уметь подтверждать номер налогоплательщика, а также правильно рассчитывать цены с или без НДС.
Большинство магазинов принимают оплату в одной валюте. Для того чтобы принимать платежи в разных валютах, чтобы посетители могли выбирать нужную им, смотреть соответствующие цены и вносить оплату, вам понадобится ввести нужную валюту в свой аккаунт продавца.
Рисунок 2.4. Платежная страница сайта. Включает НДС, скидку и приблизительную цену в долларах США. Несмотря на то что продается всего лишь один продукт, нужно принимать во внимание несколько величин
Другой вариант – это показывать цены в разных валютах, а оплату принимать только в местной. Вы можете обновлять курсы валют либо вручную, либо автоматизировать процесс с API. Если покупатели платят только местной валютой, то они должны быть в курсе, что стоимость показана чисто для информации и что реальная цена может слегка отличаться (из-за неустойчивых валютных курсов).
Обязательно посоветуйтесь с бухгалтером, когда будете иметь дело с деньгами, особенно, если вы принимаете платежи в иностранной или разной валюте. Если с самого начала знать, как обращаться с платежами и валютными курсами, то в будущем никаких проблем не возникнет.
О доставке
Если вы продаете физический товар, который нужно отправлять каким-то образом, вы должны включить расходы на транспортировку и, возможно, организовать отслеживание заказов. Так как вы продаете онлайн, то можно привлечь покупателей из других стран. Вам нужно решить, как рассчитать отправку в разные пункты и как вы будете доставлять товар: только в пределах вашей страны или в другие тоже.
Обычно онлайн-продавцы предлагают бесплатную доставку при заказе от определенной суммы. Также они практикуют доставку через разные службы доставки, такие как почта и курьерские службы (в зависимости от того, когда клиент хочет получить свой товар). Не забудьте учесть эти моменты, когда будете разрабатывать свой сайт.
Цифровые продукты
Покупатели ожидают, что они скачают цифровые продукты (такие как электронные книги, музыка и ПО) сразу же после их покупки. Доставка может быть оформлена в форме ссылки или страницы для скачивания в своем профиле (вместе с лицензионным кодом если нужно).
Система должна обезопасить продукты до их приобретения и обеспечить в аккаунте клиента область, где они будут доступны (или как минимум отправлять ссылку на e-mail). Также можно генерировать код продукта. Опять же системы-посредники могут обеспечивать весь этот функционал в рамках оплачиваемых услуг.
Отчет и другие функции
Ваш клиент хочет обрабатывать заказы сразу же, как только они поступят, и вероятно, отмечать отправленные позиции, как только они будут обработаны. Возможность выгружать данные по заказам в CSV-файл, будет полезна как при организации e-mail-рассылки, так и при выгрузке платежных данных в офлайновую систему учёта продаж.
Вот ряд других вопросов, которые надо задать себе или заказчику:
• Нужно ли вам контролировать остатки через сайт?
• Как вы будете поступать с заказами, которые выполнены частично?
• Должен ли сайт генерировать счета и товарные накладные или это будет происходить в офлайне?
Интеграция с другими системами
Многие сайты не существуют автономно, а интегрируются с другими системами и сервисами. Интеграция реквизитов доступа (т. е. логина и пароля) от сети-посредника довольно стандартная процедура, и, возможно, вам будет нужно связываться с системой-посредником для контроля остатков и учета, особенно это касается магазинов электронной коммерции.
Несколько лет назад мы разрабатывали сайт для университета, который позволял студентам и персоналу обновлять свои данные и запрашивать определенные анкеты из офиса университета. По этой причине нужно было обеспечивать логинам защиту. Для обычного сайта мы бы использовали свои собственные идентификационные классы с CMS. Но здесь нам пришлось работать с уже существующими логинами студентов. Эта информация сохранялась в LDAP (облегченный протокол службы каталогов), поэтому наш сайт должен был идентифицировать пользователей с помощью университетского сервера LDAP.
Так мы создали новый интерфейс для нашей стандартной CMS-системы, который идентифицировался через сервер LDAP. Когда работаешь с такой системой-посредником, написать код ничего не стоит.
Много времени ушло именно на то, чтобы получить доступ к серверу LDAP и понять, как подтверждается вход в систему. Мы использовали свою собственную CMS и создали идентификационный интерфейс, что упростило процесс написания кода.
В следующий раз мы разрабатывали обычную систему электронной коммерции для магазина одежды, торгующего онлайн. В нем продавались разнообразные дизайнерские модели в ограниченных количествах. Часто рубашки определенного размера и дизайна были представлены лишь в одном экземпляре. Из-за того, что рубашки продавались одновременно и в офлайн-магазинах, и онлайн, нужно было вести обновляемый учетный реестр. Если вещь продавалась онлайн, ее сразу же надо было убирать с полок обычных магазинов, а если она была куплена в обычном магазине, то информация на сайте должна была сейчас же обновляться.
Вообще, установка этой функции вызывает явные проблемы (за вещь, которую только что продали онлайн, кто-то может уже расплачиваться на кассе обычного магазина). Лучшее, что мы могли сделать, так это обеспечить одновременную двустороннюю связь между сайтом и системой электронно-кассовых продаж.
EPOS[17] была разработана другой компанией, и нам пришлось работать с ее разработчиками, чтобы скомпоновать две системы. Мы ждали по три недели, пока эти разработчики соберут нужные ресурсы и выполнят наш запрос.
С этим мы ничего не могли поделать, и очевидно, что это время необходимо было включать в расписание проекта.
Ясность в нашем общении и представление четкой и полной информации, тестирование интерфейса, помогли свести к минимуму риск задержки. Но если вы знаете, что без посредников не обойтись, уточните, как они работают и сколько времени им нужно, чтобы обработать тот или иной запрос. Вы сможете тогда планировать свои действия с оглядкой на них.
Очень важно с самого начала узнать все о системах-посредниках, которые вам нужны. Не забывайте об этих важных задачах. Это упростит вам выбор технологии и коробочного ПО. Также это необходимо учитывать и при планировании сроков проекта как в своей компании, так и у партнеров.