Доступа к багтреккеру нету, напишу тут.
Неприятная мелочь: shift+insert не вставляет из клипборда урл в строку браузера в Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.20 Safari/537.36 OPR/15.0.1147.18 (Edition Next)
3. Все файлы на продакшине, как css так и js сливаются в один.
Так и выходит, как вы говорите, всего 2 файла — 1 css и один js, но для девелопмента это неприемлимо, так как править файлы по нескольку десятков килобайт — удовольствие еще то.
Кроме того, разбивка на файлы бывает и больше, может быть так, что в отдельные файлы выносятся стили для текста и для основной разметки макета, а также стили, которые использует javascript. Также бывает еще файл basis.css, в котором после ресета устанавливаются основные отступы, начертания, кегль и размеры шрифта.
Также при создании макетов и отправке их на верстку нужно обращать внимание на наличие стилей для:
— Заголовков 1-3 уровня в контенте;
— Нумерованных и маркированных списков;
— Таблиц, названий и заголовков таблиц;
— Элементов форм, также верстать поля форм заполненными, чтобы можно было сразу видеть стиль текста.
Также стоит проверить стили для:
— strong,
— em,
— dl, dt, dd
— blockquote
Обязательно нужно указать какими должны быть активные ссылки (и другие кликабельные элементы), посещенные, при наведении курсора.
Это необходимо для того, чтобы потом, при заполнении сайта контентом не возникало проблем.
Требования к структуре каталогов, например:
htdocs (тут лежат все файлы .html)
└─-- (каталог «-» дефис, файлов не содержит)
├─css
├─img
├─js
├─plugins
│ ├─jquery
│ ├─jquery-fancybox
│ └─swfobject
└─swf
Файлы .html называть именами соответствующих *.psd файлов.
Именование CSS-файлов:
— reset.css — css-ресет.
— style.css — основные стили, которые относятся ко всему сайту и главной странице.
— inner.css — выносить стили, которые относятся к внутренним страницам, если нужно что-то переопределить.
— form.css — стили форм.
— pages.css — стиль постраничного вывода (страницы 1 2 3 4… 11 12)
— debug.css — временный файл используется программистами для правок верстки, которые потом должен пересмотреть верстальщик и вынести/подправить соответствующим образом.
— ie.css — стили для ИЕ.
— ie6.css — для ИЕ6.
В основных файлах не использовать хаков, только валидный CSS. Все что касается ИЕ — в отдельные файлы и подключать через Conditional Comments.
2. Если Вы посмотрите, то на скрине поиск картинок делается через Google Images API в отдельном слое. Если Вы находитесь на третьей странице поиска с выбранным минимальным размером, то после перезагрузки нужно либо устанавливать вручную, либо придумывать, чтобы сразу туда перебрасывало, что тоже как бы неудобно.
По поводу усложнения кода, ну не знаю, у меня это виглядит примерно так:
Соответственно передать нужно 4 параметра: id товара, url изображения, название картинки и описание. Два последних необязательны.
3. Ну не знаю на счет FTP. Я себе не представляю девочку, которая будет заливать фотки в какие-то каталоги. А если не туда зальет? Если не так назовет? Если файлы битые будут? Если будет BMP и TIFF? Если размеры фоток будут слишком мелкие? Кто ей об этом скажет? Когда клиент начинает работать над сайтом и девочка (менджер по рекламе) начинает заполнять новыми товарами и коллекциями каталог… От слов маркированный список, заголовок первого уровня, предпочтительно ввести УРЛ для страницы и т. п. ее лицо начинает удивляться, я боюсь даже говорить об FTP.
Использование FTP для заливки контента — это только при инициализационном наполнении сайта разработчиком и то если пакетная загрузка всего каталога, например. Иначе — веб-интерфейс без шага влево и вправо.
Контент — ну рерайтить как-то автоматически. Или искать на другом языке, а через Google Translate API переводить на нужный язык. Очень удобно с русского на украинский, например:-)
1. Должна быть загрузка изображений по урлу с другого сайта (без сохранения на локальный компьютер).
2. Загрузка должна осуществлятся в фоне, пока оператор продолжает искать изображения для товара (другие ракурсы и т. п.).
3. Ну и конечно стоит делать пакетную загрузку изображений с помощью swfupload, например. Чтобы с локального компьютера можно было добавить целый каталог.
P. S. После реализации такого поиска картинок через Google Images, стоит задуматься, как искать контент для карточки товара и как его автоматически рерайтить.
Все доходы должны быть отображены в книге учета доходов и расходов.
Конечно, можно не вписывать некоторые продажи в эту книгу, но тогда появляется одно «но».
Если человек, которому вы продали товар и выдали чек (но не вписали его в книгу доходов и расходов) будет из налоговой — т.е. попадете под контрольную закупку — тогда штраф и довольно большой. Если я не ошибаюсь выставляют порядка 10% от оборота.
Возможны и другие варианты обнаружения скрытия доходов, например, если простой человек обращается в Общество по защите прав потребителей и начинает с вами ссориться. А дальше и до налоговой дойдет.
Сейчас на Украине очень часто практикуются контрольные закупки. В оффлайновых магазинах регулярно с сентября 2009 года, а значит скоро доберутся и до интернет-магазинов.
Несколько — это не каша. Вы на каждом сайте в исходники смотрите? :-)
Я нет, только тогда, когда есть что-то интересное, но там и неразрывные пробелы непроблема.
Кроме того, исходники смотрю Firebug'ом, ему любая каша под силу.
Не знаю как вы, но я очень часто (имея телефон с кнопками, а не с тачскрином) набираю/звоню не глядя на клавиатуру: есть быстрый набор от 2-ки до 9-ки, плюс ответ, удержание и возврат к разговору без единого взгляда на клавиатуру.
Если пользоваться только тачскринами — тут без взглядов никак не обойтись, что не совсем удобно, особенно на улице/прогулке/в магазине, когда нужно быстро сделать звонок (а возможности долго концентрироваться нет), позвонить, тем, кто звонил, а вы не ответили.
Добавил товары в корзину, нажал на «оформить заказ». Попал на страницу где написано, что нужно зарегистрироваться (ссылка) или авторизироваться (не ссылка и не форма).
Лучше было бы показать форму авторизации сразу и по центру, чтобы было заметно, а не справа и возможность оформить заказ без авторизации.
Соответственно, если человек имеет аккаунт — он войдет и оформит заказ «под собой». Если нет у него аккаунта — он заполнит данные о себе о доставке и т. п., плюс введет свой е-мейл. На основании этих данных вы создаете пользователя и получаете заказ в магазине. Если вдруг пользователь уже зарегистрирован (при оформлении заказа вводит е-мейл, который есть в базе) — после оформления заказа просим его ввести пароль или предлагаем его восстановить на эл. почту.
Это логичнее, удобнее и минус один шаг регистрации.
Нужно стараться не делать в долг. А если и делать, тогда только то, что не жалко потерять/потратить даром время/силы/нет работы, либо делать только тем, кто 100% отдаст деньги (все так на первый взгляд выглядят, да? :-) ). Работу делать по этапах, за каждый этап — предоплата.
Если сложилась ситуация с задолженностью — нужно иметь рычаги влияния: отключить сайт или приостановить работу почты. Второе предпочтительнее для исполнителя, имеет больший вес, так как без почты нормально работать уж никак.
Если рычагов влияния нет — тогда ждать и напоминать о себе. Напоминать как можно чаще. Звонить, приходить в гости, писать письма. Договариваться — это реальный выход. Если ждать денег нет смысла, и вы это понимаете — брать их услуги/товары и продавать/использовать самим. Так вы получите хоть что-нибудь, чем будете вообще без денег.
Если забрать нечего, денег нет, не хотят рассчитываться — тогда суд (если сумма большая или есть штатный юрист, иначе — не рентабельно, забот много, расходов много, а 100%-уверенности в позитивном решении нет). Бывают ситуации, когда фирмы не могут рассчитаться, они осознанно идут на суд. А это способ затянуть время, на 6 месяцев, на год, полтора.
Образование клиентов 1.0 обходится слишком дорого для контактного лица исполнителя, в первую очередь.
Дорого в эмоциональном плане, потому что нужно корректно донести свою точку зрения через «непробиваемую стену» и никого не обидеть, а сделать это порой очень и очень сложно.
Дорого это и для фирмы-исполнителя, потому что времени на такие проекты уходит много, нервов много, выхлоп от такого сотрудничества — сомнителен. Лучше клиентов 1.0 обходить стороной — себе дешевле.
Выбрал — менее 10%, хотя это тоже слишком оптимистичный результат. Думаю верстать нужно, пока ниже 2 не опустится.
Сегодня под ИЕ6 верстаем, но слишком не заморачиваемся. Если не критично для дизайна — то полупрозрачности PNG через CSS заменяем на обычные PNG8 (скажем для всплывающих окошек с тенями, звездочек рейтинга, которые должны быть на разных фонах /звездочки в ИЕ6 превращаются в квадратики ;-)/ и т.п.). Сайты визуально более ущербны получаются, но основное требование — полное соответствие функционала, чтобы можно было совершить покупку, сделать заказ, отправить отзыв и т.п.
— каждый язык на отдельном домене, например: site.ru, site.ua, site.com
— движок у всех сайтов один — все лежит в одном DOCUMENT_ROOT (все домены — алиасы для основного)
— по домену определяем язык
— для выбранного языка используем свой локализированный конфиг
— подгружаем свои CSS (если, скажем, есть заголовки-картинки с текстом)
— подключаемся к БД и пользуем таблицы с префиксом языка ru_, en_ ua_, либо вообще к другой БД
— включаем свой google analytics
— ЧПУ для каждого сайта можно делать свой, так как структура сайта и контент независимы у каждой версии
— Все картинки лежат в том же DOCUMENT_ROOT
Преимущества такого подхода:
— Каждая языковая версия может кардинально отличаться по структуре. Пример: Компания — официальный дилер фирм на территории Украины, которые имеют свои представительства в России, Польше, Беларуси и т.п. Кроме того, Компания — производитель продукции, которой интересуются не только жители Украины, но и зарубежья. Соответственно для сайта на укр. языке нужно показывать весь каталог товаров (дилерские в т.ч.). На сайте в зоне .ru, который рассчитан на Россию, нужно продвигать только собственную продукцию, потому как дилерская не интересна. Сайт на английском языке — сайт, скажем для инвесторов, который должен быть только с общей информацией о Компании, чтобы дать возможность ознакомиться с производственными мощностями.
— Не будет «многоязычности» на локализированом сайте: когда весь сайт на русском, а некоторые товары либо блоки на английском, потому что не дописаны.
— Возможность четко распределить обязанности по поддержке каждой языковой версии сайта на отдельных людей в Компании.
— Если поломают структуру на одной версии — на другой все будет в порядке.
Минусы подхода:
— Если сайты не сильно различаются на разных версиях — производится дублирование контента (картинки для товаров загружаются по нескольку раз)
— Добавить еще один язык не сможет Компания сама — необходимо участие разработчика.
Может еще какие-то минусы видите? Прошу комментировать.
Если заказчик неудачный и хочет агрессивно гнуть свою линию, то тут никакие бонусы не спасут. Ни СЕО, ни реклама, ни повторная разработка. Потому что он будет постоянно вас держать в тонусе и не даст спокойно работать. Мне кажется от таких заказчиков лучше отказаться вовремя, если и не вовремя, и даже с финансовыми потерями.
Неприятная мелочь: shift+insert не вставляет из клипборда урл в строку браузера в Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.20 Safari/537.36 OPR/15.0.1147.18 (Edition Next)
но твиттер ответил:
Sorry, that page doesn’t exist!А все из-за #! в заголовке статьи.
1. Все запросы к каталогу «-» обрабатывает nginx.
2. Для всех файлов стилей используется minify
3. Все файлы на продакшине, как css так и js сливаются в один.
Так и выходит, как вы говорите, всего 2 файла — 1 css и один js, но для девелопмента это неприемлимо, так как править файлы по нескольку десятков килобайт — удовольствие еще то.
Кроме того, разбивка на файлы бывает и больше, может быть так, что в отдельные файлы выносятся стили для текста и для основной разметки макета, а также стили, которые использует javascript. Также бывает еще файл basis.css, в котором после ресета устанавливаются основные отступы, начертания, кегль и размеры шрифта.
— Заголовков 1-3 уровня в контенте;
— Нумерованных и маркированных списков;
— Таблиц, названий и заголовков таблиц;
— Элементов форм, также верстать поля форм заполненными, чтобы можно было сразу видеть стиль текста.
Также стоит проверить стили для:
— strong,
— em,
— dl, dt, dd
— blockquote
Обязательно нужно указать какими должны быть активные ссылки (и другие кликабельные элементы), посещенные, при наведении курсора.
Это необходимо для того, чтобы потом, при заполнении сайта контентом не возникало проблем.
Требования к структуре каталогов, например:
Файлы .html называть именами соответствующих *.psd файлов.
Именование CSS-файлов:
— reset.css — css-ресет.
— style.css — основные стили, которые относятся ко всему сайту и главной странице.
— inner.css — выносить стили, которые относятся к внутренним страницам, если нужно что-то переопределить.
— form.css — стили форм.
— pages.css — стиль постраничного вывода (страницы 1 2 3 4… 11 12)
— debug.css — временный файл используется программистами для правок верстки, которые потом должен пересмотреть верстальщик и вынести/подправить соответствующим образом.
— ie.css — стили для ИЕ.
— ie6.css — для ИЕ6.
В основных файлах не использовать хаков, только валидный CSS. Все что касается ИЕ — в отдельные файлы и подключать через Conditional Comments.
По поводу усложнения кода, ну не знаю, у меня это виглядит примерно так:
Соответственно передать нужно 4 параметра: id товара, url изображения, название картинки и описание. Два последних необязательны.
3. Ну не знаю на счет FTP. Я себе не представляю девочку, которая будет заливать фотки в
Использование FTP для заливки контента — это только при инициализационном наполнении сайта разработчиком и то если пакетная загрузка всего каталога, например. Иначе —
Контент — ну рерайтить
Как еще оптимизировать работу оператора:
1. Должна быть загрузка изображений по урлу с другого сайта (без сохранения на локальный компьютер).
2. Загрузка должна осуществлятся в фоне, пока оператор продолжает искать изображения для товара (другие ракурсы
3. Ну и конечно стоит делать пакетную загрузку изображений с помощью swfupload, например. Чтобы с локального компьютера можно было добавить целый каталог.
Конечно, можно не вписывать некоторые продажи в эту книгу, но тогда появляется одно «но».
Если человек, которому вы продали товар и выдали чек (но не вписали его в книгу доходов и расходов) будет из налоговой — т.е. попадете под контрольную закупку — тогда штраф и довольно большой. Если я не ошибаюсь выставляют порядка 10% от оборота.
Возможны и другие варианты обнаружения скрытия доходов, например, если простой человек обращается в Общество по защите прав потребителей и начинает с вами ссориться. А дальше и до налоговой дойдет.
Сейчас на Украине очень часто практикуются контрольные закупки. В оффлайновых магазинах регулярно с сентября 2009 года, а значит скоро доберутся и до интернет-магазинов.
Я нет, только тогда, когда есть что-то интересное, но там и неразрывные пробелы непроблема.
Кроме того, исходники смотрю Firebug'ом, ему любая каша под силу.
Если пользоваться только тачскринами — тут без взглядов никак не обойтись, что не совсем удобно, особенно на улице/прогулке/в магазине, когда нужно быстро сделать звонок (а возможности долго концентрироваться нет), позвонить, тем, кто звонил, а вы не ответили.
Вот уже несколько шагов в этом направлении: www.geeky-gadgets.com/touchscreen-inflatable-buttons-21-07-09/
Видео: www.youtube.com/watch?v=Smai_Z_galE
Лучше было бы показать форму авторизации сразу и по центру, чтобы было заметно, а не справа и возможность оформить заказ без авторизации.
Соответственно, если человек имеет аккаунт — он войдет и оформит заказ «под собой». Если нет у него аккаунта — он заполнит данные о себе о доставке
Это логичнее, удобнее и минус один шаг регистрации.
Если сложилась ситуация с задолженностью — нужно иметь рычаги влияния: отключить сайт или приостановить работу почты. Второе предпочтительнее для исполнителя, имеет больший вес, так как без почты нормально работать уж никак.
Если рычагов влияния нет — тогда ждать и напоминать о себе. Напоминать как можно чаще. Звонить, приходить в гости, писать письма. Договариваться — это реальный выход. Если ждать денег нет смысла, и вы это понимаете — брать их услуги/товары и продавать/использовать самим. Так вы получите хоть что-нибудь, чем будете вообще без денег.
Если забрать нечего, денег нет, не хотят рассчитываться — тогда суд (если сумма большая или есть штатный юрист, иначе — не рентабельно, забот много, расходов много, а 100%-уверенности в позитивном решении нет). Бывают ситуации, когда фирмы не могут рассчитаться, они осознанно идут на суд. А это способ затянуть время, на 6 месяцев, на год, полтора.
Дорого в эмоциональном плане, потому что нужно корректно донести свою точку зрения через «непробиваемую стену» и никого не обидеть, а сделать это порой очень и очень сложно.
Дорого это и для фирмы-исполнителя, потому что времени на такие проекты уходит много, нервов много, выхлоп от такого сотрудничества — сомнителен. Лучше клиентов 1.0 обходить стороной — себе дешевле.
Сегодня под ИЕ6 верстаем, но слишком не заморачиваемся. Если не критично для дизайна — то полупрозрачности PNG через CSS заменяем на обычные PNG8 (скажем для всплывающих окошек с тенями, звездочек рейтинга, которые должны быть на разных фонах /звездочки в ИЕ6 превращаются в квадратики ;-)/ и т.п.). Сайты визуально более ущербны получаются, но основное требование — полное соответствие функционала, чтобы можно было совершить покупку, сделать заказ, отправить отзыв и т.п.
Преимущества такого подхода:
— Каждая языковая версия может кардинально отличаться по структуре. Пример: Компания — официальный дилер фирм на территории Украины, которые имеют свои представительства в России, Польше, Беларуси и т.п. Кроме того, Компания — производитель продукции, которой интересуются не только жители Украины, но и зарубежья. Соответственно для сайта на укр. языке нужно показывать весь каталог товаров (дилерские в т.ч.). На сайте в зоне .ru, который рассчитан на Россию, нужно продвигать только собственную продукцию, потому как дилерская не интересна. Сайт на английском языке — сайт, скажем для инвесторов, который должен быть только с общей информацией о Компании, чтобы дать возможность ознакомиться с производственными мощностями.
— Не будет «многоязычности» на локализированом сайте: когда весь сайт на русском, а некоторые товары либо блоки на английском, потому что не дописаны.
— Возможность четко распределить обязанности по поддержке каждой языковой версии сайта на отдельных людей в Компании.
— Если поломают структуру на одной версии — на другой все будет в порядке.
Минусы подхода:
— Если сайты не сильно различаются на разных версиях — производится дублирование контента (картинки для товаров загружаются по нескольку раз)
— Добавить еще один язык не сможет Компания сама — необходимо участие разработчика.
Может еще какие-то минусы видите? Прошу комментировать.
Если заказчик неудачный и хочет агрессивно гнуть свою линию, то тут никакие бонусы не спасут. Ни СЕО, ни реклама, ни повторная разработка. Потому что он будет постоянно вас держать в тонусе и не даст спокойно работать. Мне кажется от таких заказчиков лучше отказаться вовремя, если и не вовремя, и даже с финансовыми потерями.
Задача профессионала сделать качественный сайт, который бы работал, не взирая на то, насколько испорчен заказчик.