archelon

Спросить у Maciej Kuciara
Вам, программистам, это в голову не приходит?

Сразу disclaimer: я не дизайнер, но достаточно часто принимаю их работу. Все что ниже - моё imho.

Хотелось бы узнать как правильно составить ТЗ именно с технической точки зрения, то есть что бы потом дизайн/PSD макет можно было отдать верстальщику и он не сказал, а где здесь...?

Главное что должно быть в ТЗ - описание функционала и бизнес сценариев.
Есть мнение что лучше не использовать размытие шрифтов, т.к идеально их сверстать кроссбраузерно невозможно.

Например был такой вопрос от дизайнера: Какую ширину контента делать ? 960 или 1000?

Правильный ответ 960 или 990, т.к 1000 в некоторых старых браузерах может не вписаться на экран 1024x768 при наличии вертикальной прокрутки. Впрочем вопрос достаточно холиварный.

Какие критерии должны быть к обычным фиксированным макетам?

Кроме очевидных вещей (должен быть реализован весь запрошенный функционал) - крайне полезно посмотреть как ведет себя макет в случаях:
a) если контента нет вообще (к примеру как выглядит лента новостей если новостей нет) - очень часто забывают отрисовать.
b) если контент есть, но строковые величины крайне велики (заголовок новости 1000 символов) - очень часто рисуют все красиво, но в реальности контента на порядки больше и все едет, либо появляется обрезка, там где её быть не должно.
c) если контент есть, но строковые значения крайне малы. (заголовок новости 5 символов)

Какие критерии должны быть к адаптивным макетам/мобильным?

Все изложенное выше + по сути нужны N вариантов дизайна под N разрешений которые Вы считаете нужным поддерживать.
Делая адаптивный дизайн - нужно понимать что сделать качественный адаптив - это примерно x2-x4 к стоимости услуг дизайнера. Адаптив сделанный тяп-ляп бесполезен и даже вреден.
Отдельно про мобильную версию: изучите свою аудиторию. Если Ваши клиенты пользуются современными смартфонами - мобильная версия нафиг не нужна, лучше сделайте мобильные приложения под ios/android.

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

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

freelansim.ru/freelancers?q=drupal

Делайте на php-фреймворке. Любой перечисленный движок не предоставляет требуемый функционал.

#home-nav ul > li:first-child:after {
   display: none;
}

https://toster.ru/search?q=%D1%81%D0%BA%D1%80%D0%B...

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

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

С точки зрения фриланса, лучше взять готовый известный продукт, типа opencart. Может быть пару модулей к нему написать. Во фрилансе большинство заказчиков хочет "быстро, дешево и с хорошей поддержкой". Завтра вы уйдете в другой проект, и кто будет разбираться в вашем коде?

А при устройстве на работу - работа бывает разная. Большинство хотят чтобы вы знали хотя-бы один крупный фреймворк - типа zend, symfony, yii, lavarel. Знаете один - сможете в приемлемое время разобраться и с другим. А конкретную CMS хотят в основном те, у кого уже есть ряд продуктов на этой CMS.

Конечно ложь. Реклама бывает прямая и косвенная. Прямая - вы башляете adwords, косвенная - вы башляете авторам статей которые их пишут потом площадкам которые их размещают. Хорошо без статей. Но всё равно даже за то что бы поспамить ссылками на форумах надо заплатить.
Так что клиент у вас всё равно тыщу баксов отдаст, только не напрямую.

на D7 вы также сможете отмечать пункты на карте и выводить на общей карте все ваши пункты с ссылками на страницы этих городов.
вам потребуются модули drupal 7:
views,
geofield,
google maps.

Почитайте отчёт совместного исследования MasterCard и UsabilityLab, посвященного юзабилити процесса покупки в интернет-магазинах:
newsroom.mastercard.com/ru/files/2015/06/MasterCar...

По скриншоту видны следующие недочеты:

1. Слишком много полей формы, чтобы получить адрес доставки. Достаточно одного поля "Адрес". При желании можно прикрутить сервис DaData.
   
2. Если пользователь уже авторизован и уже вводил свой адрес, не нужно повторно просить его вводить всё заново. Можно добавить возможность выбирать любой из адресов, на которые уже осуществлялась доставка. Аналогично с Ф.И.О. и прочими контактными данными.
   
3. Вместо трёх полей "Фамилия", "Имя", "Отчество" может быть одно "Ф.И.О." или что-то вроде "Как к Вам обращаться".
   
4. Всё вышеперечисленное служит одной единственной цели - получить минимальное число требуемых действий для оформления заказа. Не смотря на минимум действий, пользователь должен получить максимум информации о том, что, откуда и куда он заказывает.