О неумении называть сроки

Одна из бед представителей IT-профессий — неумение называть сроки. Если вы в своей работе используете выражения «Сегодня к вечеру будет готово», «Покажу в среду», «К утру скину результат», то срочно избавляйтесь от этой привычки.

Строго: время и ожидаемый результат. «В 14:00 опубликую новую версию прототипа», «макеты будут на вашей почте в 17:45, в среду», «в полдень я свяжусь с вами для уточняющих вопросов».

Тогда и люди, с которыми вы работаете, глядя на вас, не будут позволять себе оплатить ваши счета «в конце недели» или озвучить комментарии «в течение рабочего дня».

Почему опытные проектировщики превращаются в хороших менеджеров

protomanager

Если вы проектируете на фрилансе, то вам крупно повезло. В связи со спецификой вашей профессии, вы будете от клиента к клиенту естественным образом демонстрировать всё более высокий уровень оказания услуг.

Ведь делая прототипы, вы создаёте их на основе чёткого понимания того, что нужно пользователям будущего проекта. И чем полнее это понимание, тем полнее и понимание того, что нужно вашим собственным клиентам. В качестве наглядного примера в этой заметке я перечислю 10 эвристик от Якоба Нильсена, которые он сформулировал аж в 1990 году. И поясню, как знание этих и многих других вещей повлияло на мой подход к работе с клиентами на фрилансе. И при этом ни слова об интерфейсах. Итак.

1. «Информированность о состоянии системы. Пользователь всегда должен ориентироваться и хорошо понимать, что происходит в системе. Взаимодействие между пользователем и системой должно быть как можно более логичным и быстрым».
На первых переговорах я рассказываю клиенту обо всех этапах грядущей работы. Затем, когда мы проходим через все этапы, на ключевых точках я рассказываю, где мы находимся и что будем делать дальше. Также информированности о состоянии дел помогают анонсы точных дат и часов, когда будут предоставлены очередные итерации.

2. «Схожесть системы с реальным миром. Система должна общаться с пользователем на понятном ему языке. Использование слов, фраз и понятий, знакомых пользователю в реальном мире, намного предпочтительнее, чем использование специализированных терминов».
В процессе работы я редко использую термины «UX», «cjm», «источники трафика», «интерактивность». Разве что при работе с теми людьми, которые живут и работают в IT. Вместо этого я говорю «удобство использования», «то, как люди будут пользоваться проектом», «как посетители попадут на ваш проект» и «как будут двигаться блоки на страницах». Я стараюсь избегать абстракций и любое обсуждение провожу в рамках разговора о конкретном пользователе конкретной части интерфейса продукта.

3. «Свобода действий. Дайте пользователям возможность отмены действий, а также возврата к ранее отмененным действиям».
Одним из отражений этого правила в моей менеджерской деятельности стало появление в договоре пункта, в котором сказано, что количество итераций с комментариями в прототип не ограничено. Сами же прототипы публикуются под разными адресами, в папках с номерами версий, чтобы легко можно было вспомнить, каким путём мы дошли до того или иного состояния, и, при желании, откатиться назад.

4. «Единообразие и стандарты. Не путайте пользователя, описывая одни и те же вещи разными словами и терминами. Придерживайтесь единообразия и следуйте стандартам».
В процессе работы я использую ту же терминологию, что и на первых переговорах. Все переговоры проходят в одном формате (Скайп с демонстрацией экрана).

5. «Предотвращение ошибок. Сведите к минимуму количество условий, в которых могут быть допущены ошибки».
Предотвращать ошибки помогают проверенные временем методы ведения проекта. Например, если клиент собирается скинуть письмо с комментариями, когда найдёт для этого время, я заранее говорю ему, что быстрее нам будет созвониться на 15 минут и совместно всё обсудить, попутно задавая встречные вопросы. Не допустить ошибок я помогаю, не демонстрируя сырые версии прототипов, а также не забывая на каждом шаге обращать внимание клиента на те моменты в нашей работе, которые могли бы быть трактованы двояко. Например, если вы скажете, что результат работы продемонстрируете в среду, то клиент может подумать, что увидит его утром, а не ближе к полуночи, как это у нас заведено.

6. «На виду, а не в памяти. Не заставляйте пользователя запоминать большое количество объектов, действий и опций. Посетитель не должен держать в голове информацию, перемещаясь из одной части системы в другую».
Договорённости о переговорах, важные моменты в работе, изменения в сроках и прочие штуки формализуются и отправляются либо в письмах, либо в сообщениях в Скайпе. Также большое значение имеет заблаговременное личное напоминание клиенту о тех вещах, которые я от него ожидаю.

7. «Гибкость и эффективность. Не нагружайте опытных пользователей лишней информацией, предоставьте им возможность совершать часто повторяющиеся действия как можно быстрее и проще».
Для того, чтобы мне оплатили счёт, я сразу приложу этот счёт к письму с просьбой об этой операции. А заодно добавлю туда закрывающий акт. Клиенту только останется переслать письмо в бухгалтерию. Прототипы мои клиенты смотрят, просто перейдя по ссылке, по которой этот прототип размещён. Реквизиты моей компании я отправляю заранее, чтобы эту информацию всегда можно было легко найти в почтовом ящике.

8. «Эстетичный и минималистичный дизайн. Тексты не должны содержать бесполезной или устаревшей информации. Каждое лишнее слово делает восприятие все более трудным и лишает посетителя возможности найти то, за чем он пришел на сайт».
Этот пункт — упрощать всё и вся — проходит красной нитью сквозь всю мою работу. Функциональные требования и функциональные спецификации из огромных монстров превращаются в небольших понятных зверьков. Личные переписки становятся всё лаконичнее и предметнее. И, главное, — переговоры. Много лет назад я предлагал клиентам заполнять трёхстраничные брифы. Теперь же ту же информацию я получаю в течение получаса во время непринуждённой личной беседы. Причём, за эти полчаса я успеваю ещё узнать те вещи, о которых ни в одном брифе спросить невозможно.

9. «Понимание проблем и их решение. Сообщения об ошибках должны быть выражены на понятном пользователю языке, как можно более точно описывать проблему и предоставлять возможные варианты ее решения».
В работе встречается много мест, где необходимо принимать совместные решения. В этом случае я со своей стороны описываю все потенциальные последствия обоих решений, которые вижу, а клиент описывает своё видение. Мы принимаем во внимание все эти данные и склоняемся к варианту, который устраивает обоих. Здесь следовало бы многое рассказать о принципах работы «по одну сторону баррикад», но об этом ждите рассказа в одной из следующих статей Проектората.

10. «Справочные материалы и документация. Даже если система может использоваться без документации, в процессе работы с ней все же может потребоваться справочная информация. Подобные документы должны составляться таким образом, чтобы в них легко было найти необходимое».
Этот пункт даётся мне сложнее всего. На сегодняшний день существует небольшое количество статей, на которые я мог бы дать ссылки клиентам. Пример такой статьи: «Как в Проекторате оценивается адаптивное проектирование».

Помимо эвристик Якоба Нильсена (которые, кстати, субъективны и служат пищей для размышлений, а не прикладными рекомендациями), проектировщики сталкиваются и с множеством других правил, которые используют в работе. Примеров сотни. Приведу один. Призыв к действию. Когда мы проектируем лэндинги, мы подводим нашего посетителя к пику этой страницы: призыву к действию. Заполнить форму, отправить заявку, подписаться на рассылку. В работе менеджера понимание, где нужно использовать такой призыв к действию, играет большую роль. Если я отправляю письмо с результатами работы, то я сопровождаю его просьбой дать обратную связь до конкретного времени. А если я предлагаю провести переговоры, то я сопровождаю призыв к действию описанием, что это действие даст клиенту. В случае с переговорами я заранее описываю их регламент, чтобы стало понятно, какие вопросы будут затрагиваться.

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

Автор — Егор Камелев, собственник Проектората.

Список эвристик взят с Прожектора Rokee.

О количестве итераций с правками на этапе проектирования

Если вы проектировщик и говорите своему клиенту, что на этапе внесения правок в прототип вы готовы выполнить две-три итерации, а все остальные уже будут оцениваться отдельно, то на самом деле вы говорите следующее: «Я сделаю вариант, который вам скорее всего не понравится. И боюсь, что для того, чтобы довести его до нужного вам вида, мне придётся править его слишком много раз».

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

В результате с того момента, когда мы стали работать по такой схеме, количество итераций с правками в среднем сократилось аж в два раза. И это был один из многих успешных шагов на нашем пути к работе «по одну сторону баррикад» с клиентом.

Чтобы эта заметка не казалась оторванной от реальности, обратим внимание на две важные вещи:

1. Речь идёт о попроектной оценке, а не о почасовой;
2. Это правило сработает только с прямыми клиентами. На субподряде между проектировщиком и клиентом может оказаться менеджер, который не будет заинтересован в результате так же, как клиент. Когда мы работали с компаниями-партнёрами, зачастую у нас вообще не было прямого доступа к клиенту. В таких условиях, разумеется, нельзя работать по принципу бесконечных итераций, потому что они и правда могут стать бесконечными.

Распродажа электронных книг для проектировщиков

Сами не зная того, books.ru сделали нам неплохой подарок к новому году. До 2-го января электронные книги из особого перечня можно купить за любую цену, которую вы укажете.

Они-то думают, что раздают ненужные старые книги по программированию. Но для проектировщиков это возможность положить в свою электронную библиотеку всё ещё актуальную классику вроде «Об интерфейсе» Купера или «Как сделать сайт удобным» Круга (за которую на литресе просят 250 рублей) и при этом не разориться.

Опытные проектировщики и наши постоянные читатели знают, кого качать. Для всех остальных — контрольный список: Алан Купер, Билл Скотт и Тереза Нейл, Джесс Гарретт, Джеф Раскин, Джоэл Спольски, Дмитрий Кирсанов, Расс Унгер и Кэролайн Чендлер, Стив Круг, Якоб Нильсен.

Что нужно изучить, чтобы стать проектировщиком интерфейсов?

Два популярных вопроса покупателей наших курсов по прототипированию звучат так:

1. Насколько востребована профессия проектировщика? Насколько это перспективное направление?
2. Ваш курс был про использование инструментов. А что нужно пройти, чтобы научиться проектированию? UX-курсы?

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

Ответ на второй вопрос уже сложнее и отражает моё персональное мнение. Но я попробую обосновать свою позицию.

Сначала лирическое отступление номер один. Профессия эта сравнительно молодая и похожа на растущее ветвистое дерево, где каждая веточка отвечает за своё направление. Есть толстые ветки профессий вроде UX, UI, аналитиков, AB-тестировщиков, маркетологов и других. Есть такие же толстые ветки с тематиками: сайты, мобильные приложения, интерфейсы терминалов и прочие. Из толстых ветвей растут более тонкие веточки вроде «AB-тестировщик мобильных приложений на яблочной платформе» или «UI-дизайнер и верстальщик тем для вордпресса». Это дерево живое: оно находится в фазе быстрого роста. Каждый год появляются новые технологии, направления и методы работы. Точно так же какие-то из них исчезают, словно опадающие с дерева листья.

А теперь лирическое отступление номер два. Интернет появился в 1982 году. Чуть больше 30 лет назад. И если говорить о веб-интерфейсах, то нужно понимать, что все современные методологии их проектирования, родились в течение этого времени. И придумали их практики в рамках своих процессов разработки. И у каждого такого практика с его методологией — своя история, свои условия и факторы. Кто-то делал проекты на заказ за деньги, кто-то делал что-то для себя, при этом не обладая финансовыми ресурсами, кто-то же, наоборот, ни в чём себе не отказывал в плане финансов и сразу обладал большой командой. Большинство авторов методик и книг, на имена которых мы ссылаемся в работе, живут и здравствуют и продолжают заниматься профессиональной деятельностью, так же, как и мы с вами. Знать и понимать их методы — правильно и хорошо. Брать их за основу своей профессиональной деятельности — ошибка.

И лирическое отступление номер три. Существуют профессии с разными ценами ошибок в процессе их использования. Если музыкант в оркестре промахнётся мимо ноты, этого никто, кроме дирижёра, может, и не заметит. Если дизайнер сделает ошибку в номере телефона в рекламном буклете, компания может потерять какое-то количество денег. Если врач ошибётся с рецептом или у него дрогнет рука во время операции, то это может стоить человеческой жизни. А если архитектор накосячит с планом новой атомной электростанции, то… Чем выше цена ошибки в профессии, тем более комплексное требуется образование для её освоения. А после этого для допуска к каждой последующей должностной ступени требуется всё больше времени на практику.

Любое специальное образование в классическом понимании основывается на общем образовании. Вспомним наш пример с деревом. Корни — это школьная программа. Основание ствола — первые курсы в высших учебных заведениях. Ветви — третьи-четвёртые курсы. И, наконец, веточки и листочки — последние курсы. Чем выше стоимость ошибки в профессии, тем сложнее добраться до этих веточек, они находятся у самой верхушки дерева.

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

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

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

Вёрстка. Позволит понять основы языка гипертекстовой разметки. Также увидеть технические сложности, которые приходится преодолевать, верстая чужие дизайн-макеты.

Веб-дизайн. Первое знакомство с ним будет ещё на этапе изучения вёрстки. Здесь можно углубить знания по типографике, цветам, композиции. И познакомиться с основным инструментарием.

Программирование. Речь идёт об основах. Принципах объектно-ориентированного программирования, базовом синтаксисе, условных операторах, циклах, массивах и матрицах. Работе с базами данных. Понимании ключевых особенностей разных языков программирования.

SEO-оптимизация. Как проекты индексируются поисковыми системами, как происходит поисковая выдача, что такое мета-данные и прочие базовые штуки.

Основы бизнеса. Что такое спрос и предложение, рынки сбыта, реклама. Законодательство, связанное с коммерческой деятельностью, банки, платёжные гейты. Договоры, деловой этикет, бухгалтерия.

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

С этой основой уже можно выбирать себе специализацию. С этими знаниями вы сможете стать и UX-дизайнером, и UI-дизайнером, и аналитиком, и тестировщиком и кем угодно из тех сотен листочков нашего быстрорастущего дерева. Останется лишь добрать необходимых узкоспециализированных знаний на тех самых курсах для проектировщиков, которых сейчас пруд пруди, — и вперёд, повышать свою квалификацию на практике!

Ценообразование и процесс работы над адаптивными прототипами в Проекторате

Во-первых, мы не закладываем стоимость адаптивного прототипа в первоначальную оценку. То есть, сначала делаем прототип под определённое разрешение (какое именно — зависит от преобладающей аудитории (или потенциальной аудитории) тех или иных устройств). Сейчас это разрешение чаще всего — 1024 или 1200 пикселей по ширине. Метод mobile first использовался нами лишь однажды. Когда речь идёт о сложных проектах, стоимость прототипа может измениться в процессе работы, т.к. на лету появляются новые функциональные требования, поэтому неразумно включать в этот этап и оценку адаптивки.

Во-вторых, стоимость адаптивного прототипа будет зависеть от сложности интерфейсов. И речь идёт не о количестве страниц, а об их функциональной насыщенности. От 10% от стоимости проекта до 30%. За каждое дополнительное разрешение.

В-третьих, цена будет зависеть от количества брейкпойнтов, то есть от количества разных внешних видов для разных разрешений. Сейчас чаще всего они таковы: 320 (телефон в портретной ориентации), 480 (телефон в горизонтальной ориентации), 768 (планшет в портретной ориентации), ну а планшеты в горизонтальной ориентации уже входят в первоначальный прототип.

Итого, прототипирование адаптивки составит дополнительные 10—90% от стоимости первоначального прототипа.

Откуда берутся эти проценты?

Во-первых, сложность интерфейсов напрямую влияет на часы, которые будут потрачены на каждое новое разрешение.

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

В-третьих, Axure позволяет легко показать для одного и того же разрешения несколько разных вариантов адаптивки. Возможность сравнить разное поведение интерфейса в одних и тех же условиях позволяет сделать более объективный выбор.

По срокам: мы берём за основу процентную стоимость работы над адаптивкой и превращаем её в процентные сроки. То есть, от 10% до 90% от времени работы над основной версией будут затрачены на адаптивный прототип.

Как оценивать проекты: по часам или под ключ?

Почасовая или попроектная оценка при работе на фрилансе? Поделюсь своим опытом. Сразу оговорюсь, что я UX-дизайнер в чистом виде. То есть, со шрифтами не играюсь и Фотошопом не пользуюсь.
В своё время уйдя на вольные хлеба я назначил стоимость своего часа для клиентов. 1 000 рублей. Это было больше, чем в среднем по рынку, но в целом со мной не отказывались работать, ибо сарафанное радио. В портфолио было около сотни прототипов. Особенно интересовались студии. Всё было прозначно и красиво. Проблема всплыла через десяток проектов. Берём, например, прототип интернет-магазина или тематической социалки, которые появлялись, как грибы, лет пять назад. Когда ты их сделал уже несколько штук, каждый следующий проект не занимает много времени. Это раз. Не содержит в себе большинства граблей, ибо они собраны в прошлом. Это два. И получалось, что прототип интернет-магазина я делал в течение десяти-пятнадцати часов. Сюда входили и переговоры, и пара итераций с комментариями. Итого: 10-15к за работу, которую легко можно было бы продать под ключ за 50-70к. Увеличение стоимости часа до 4−5 тысяч рублей приводило к тому, что с тобой отказывались работать, ибо цена превышает среднерыночную в разы. Резюме по часам:

— За почасовую оплату лучше учиться на клиентах, ибо точность оценки рисков и объёмов работ увеличится только с увеличением работ в портфолио;
— На практике, делая работу за 10-15 часов многие спокойно называют 20-30 часов просто потому, что работа реально выглядит на эти 40-50 тысяч. Причём, тут до абсурда доходит. У меня были случаи, когда я платил дизайнеру по часам так, словно он работал по 15 часов в сутки в течение трёх дней. Было понятно, что на работу уходило гораздо меньше;
— Когда вы называете свою цену за час, её всегда будут сравнивать со средней ценой по рынку. И даже если вы очень хороши в своём деле, без рекомендаций с вами никто работать не будет, если речь идёт о стоимости 5+ тысяч рублей в час.

Теперь про попроектную оценку. Я перешёл на неё, как только понял, что меньше 3к в час с моими опытом и скоростью работы запрашивать не стоит. Теперь интересное. По типовым проектам на рынке тоже есть своя средняя стоимость. У фрилансеров одна, у студий другая, чуть побольше. Если у проектировщика не хватает опыта и паттернов, он будет называть среднюю стоимость по рынку, браться за эту работу и, собирая шишки и затягивая процесс из-за потока комментариев, приближать стоимость своего часа к той самой тысяче рублей. А если это уже десятый подобный проект, то он, наоборот сделает 50-тысячный проект сильно быстрее, чем за 10 часов, используя наработки и предвосхищая комментарии, таким образом приближая стоимость своего часа к отметке 5+ тысяч рублей. И вот вторые, которые опытные, даже могут позволить себе немного демпинговать, называя 40 вместо 50 и при этом за час зарабатывая в несколько раз больше, чем те, которые называют 50-60. Резюме по попроектной оценке:

— Нужен определённый опыт, чтобы не ошибаться в объёмах работ и потенциальных итерациях с комментариями (под опытом подразумевается именно похожий проект, сделанный и выпущенный в прошлом);
— Нужен доступ к клиенту. Работая на субподряде и общаясь только с менеджером проекта, вы не получите ответов на некоторые вопросы, влияющие на ценообразование. Редкие исключения есть. В качестве примеров могу привести Анну Третьякову из Елегиона или Елену Божек из московской компании Айпартнер;
— Из приятного: предоплата. Вы получаете часть денег перед началом работы. При работе по часам обычно платят по факту;
— Работая по рекомендациям, вы можете называть стоимости работ выше среднерыночных, что увеличивает стоимость вашего часа ещё больше. Сюда же, наверное, стоит добавить, что пользоваться ИП (или любой другой формой собственности), работая с ценниками больше 50к, удобнее и белее и пушистее.

Как проектируется постраничная навигация

Свод вопросов, которые проектировщики задают сами себе, работая над таким простым элементом, как постраничная навигация.

Приложения для проектирования на бумаге

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

Бесплатные приложения Marvel и POP умеют брать любые изображения, в том числе фотографии ваших бумажных набросков, и настраивать переходы между ними по нажатию на заданные области. Результатом можно поделиться.

Marvel поддерживает только айос. POP есть и для андроидов, но бесплатно можно завести не более 5 проектов.

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

Особенности дизайна новостных порталов

Дизайнер Анатолий Громов, автор редизайна Lenta.ru Александр Гладких, начальник проектировщиков и дизайнеров в Mail.Ru Group Юрий Ветров рассказали об особенностях дизайна новостных порталов.

Юрий: Хорошая типографика, естественно, дичайше важна для комфортного чтения и формирования своего лица у издания. Выйти за пределы Core Fonts for the Web достаточно легко — появляется всё больше хороших кириллических шрифтов для самых разных задач. А благодаря сервисам типа Google Web Fonts и Typekit их подключение технологически сравнительно несложно.

Правда, при попытке использовать их на практике возникает куча вопросов и проблем — рендеринг в разных браузерах на разных платформах, скорость загрузки шрифтовых файлов и их вес, деградация для Windows XP (для сервисов с большой посещаемостью). Не опозорьтесь в последний момент, проверьте, как отображается свёрстанный шрифт в Windows 7, Windows 8 и Mac OS. Ваша работа была бессмысленна, если комфортно прочитать статью можно только на скриншоте в вашем портфолио.

Secured By miniOrange