Наряду с использование атрибута rel=«canonical» для указания поисковому боту на дублирование контента, теперь возможно использовать для HTML ссылок значение rel=“next” и rel=“prev” для обозначения положения текущей страницы в отношении соседних в рамках навигационного блока. В рамках веба встречаются различные варианты использования постраничной навигации — статья, разделенная на несколько страниц, либо категория товаров распределенных по нескольким страницам, либо ветка форума, разделенная на последовательность URL-ов. Теперь, включив rel=“next” и rel=“prev” в верстку страниц, мы можем указать Google:

• Создать консолидированный индекс страниц, чтобы ссылки не рассеивались между отдельными страницами page-1.html, page-2.html, и так далее
• При поиске направить пользователя на наиболее релевантную страницу среди всех остальных, например в начало статьи, разбитой на несколько страниц

В продолжении тематики, решил сделать свой вариант:

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

В жизни многих айтишников наступает момент, когда их светлые головы посещает идея начать свое дело. Айтишники — существа логичные; и логика говорит им: работать на дядю или тетю со временем становится невыгодно и бесперспективно. «Создам… скажем, веб-студию» — говорит он себе.

Продравшись сквозь бюрократические дебри, наш компьютерный гений открыл фирму, создал и раскрутил свой сайт, взял пару-тройку заказов… и энтузиазм его несколько поубавился. Потому что на сцену вышел новый персонаж — Его Высочество Клиент. Тот самый, про которого ClientsFromHell, Zadolba.li и проч.

Айтишник — умнейший человек. В технических вопросах, да и не только — настоящий профи. Но кое-чему он научиться просто не мог — а именно: договариваться. А когда? Он провел почти всю жизнь среди более-менее близких людей — семьи, одноклассников, однокурсников, коллег. Тех, кому волей-неволей пришлось принимать его таким, как есть. Ему не приходилось выцыганивать скидку, блефовать с конкурентами, прессовать поставщиков и умасливать клиентов.

Я расскажу о двух книгах, которые будут неплохим подспорьем молодому предпринимателю. Они посвящены искусству переговоров в критических ситуациях.

Очередная поп-психология, «сделайте глубокий вдох и подумайте о вечности»? Нет же! Обе книги написали профессиональные переговорщики: автор первой тренирует антитеррористические подразделения ФБР, авторы второй специализируются на критически важных переговорах в бизнесе.



Итак, два пособия:
Марк Гоулстон — «Я слышу вас насквозь» (в оригинале — «Просто слушай»).
Патерсон, Гренни, Макмиллан — «Есть серьезный разговор».

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

Начнем с внешних факторов. Критерии выбора внешних ссылок:

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

Hello world! Меня зовут Слава, я работаю верстальщиком в агентстве Coalla. Эта статья не о разжигании холивара и рассуждения о том, какой браузер лучше, как бы всем легко жилось без Internet Explorer’a, а мой недавний полезный опыт по установке всех необходимых браузеров и их версий на одну операционную систему, а именно на Microsoft Windows 7 Ultimate x64.

В конце апреля я делал доклад на РИФ 2012 про этапы проектирования пользовательского интерфейса. Так как видео нет, попробую представить доклад в виде слайдов с моими комментариями.



Я расскажу как процесс разработки сайта или приложения выглядит с точки зрения дизайнера. Как вы сможете только за счет интерфейса улучшить впечатление пользователя от вашего стартапа.

В любой профессии есть тонкая прослойка людей, которые являются действительно высококлассными специалистами. Не исключение и область фронт-енд разработки — здесь также есть выдающиеся личности. К их мнению прислушиваются, за ними следят в блогах и социальных сетях и читают их книги. В процессе своей работы они рождают различные оригинальные решения или техники, которые мгновенно расходятся по миру веб-разработки и остаются актуальными не один год. Они создают удобные онлайн-сервисы для верстки, пишут полезные js-библиотеки, совершенствуют браузеры, пропагандируют веб-стандарты и оказывают непосредственное влияние на их развитие. Они могут называть себя front end engineer, front-end developer, web developer, web designer, UI Designer, browser compatibility expert или просто css lover, но для большинства из нас они — звезды мирового фронт-енда, которые делают интернет таким, каким мы его знаем. На Хабре довольно часто появляются обзоры интересных решений, техник и новостей из мира веб-разработки с указанием западных авторов, однако далеко не все знают что-нибудь о них кроме имени. Мне захотелось вкратце рассказать для широкой публики о некоторых из этих товарищей.

Введение

Мне очень нравится Дмитрий Потапенко. С ним можно найти не так много видео на Ютубе, но я пересмотрел все. Если кто не знает — это человек, владелец около 15 магазинных и ресторанных сетей, ведет бизнес в РФ, Болгарии и Чехии, под ним работают 7000 человек, суммарный оборот $140 млн в год. До кучи, в прошлом — двухкратный чемпион мира по каратэ, в 25 лет стал вице-президентом Грюндиг по СНГ.
В общем, крутой мужик.

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

Стратегия важнее тактики

Стратегические просчеты невозможно компенсировать тактическими успехами.
«О войне», фон Клаузевиц

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

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

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

Кто ответит за дизайн?

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

Бен Гуджер — бывший разработчик Mozilla, работающий сейчас в Google в команде Chrome — считает, что автообновление является одной из наиболее важных функций Chrome.

Автообновление — это одна из убийственных особенностей Chrome. Оно волшебно, потому что оно непрерывно обновляет всю платформу разработки незаметно и часто. Его поддержка повлияла на то, как мы структурируем наш процесс разработки. Это также была одна из первых функций Chrome. Если вспомнить историю проекта задолго до того, как он был публично запущен в 2008 году, проект автообновления был одним из первых, над которым мы начали работать. Идея заключалась в том, чтобы дать людям пустое окно с автообновителем. После того, как они его устанавливали, пустое окно постепенно превращалось в браузер. И сегодня — через пять лет после того, как наш автообновитель начал обновлять практически пустое окно, которое едва могло загружать веб-страницы — теперь это инструмент для предоставления невероятно сложной веб-технологической платформы на компьютерах наших пользователей, который, в свою очередь, позволяет разработчикам веб-приложений создавать удивительный новый онлайновый опыт. Я никогда раньше не видел такого эффективного механизма обновления платформы.

Здравствуйте.

Хотел поделиться с широким читателем информацией о реализации Friendly URL на своих проектах.

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

Наверное многие стартаперы знают, как развиваются рынки по теории Джеффри Мура — от новаторов к раннему большинству(прагматикам), прыгая через пропасть.

Оказалось, эта теория применима не только к рынкам, а также к развитию, собственно, людских сообществ. Вот у нас в Копини теория сработала в этих двух плоскостях.

Питер Гасстон, автор книги по CSS3, опубликовал статью под названием The future of CSS layouts, перевод которой специально для читателей хабра представлен ниже.

Несмотря на все поразительные возможности CSS, их недостаточно для реализации фундаментальных принципов разметки страницы. Однако, дополнительные возможности для создания более динамических страниц уже начинают появляться.

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

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

Консорциум W3C и создатели браузеров в курсе этих проблем и работают над рядом решений. Лидером среди них является (как не удивительно) Internet Explorer. Похоже, что IE10 будет предвестником новой эры CSS разметки, которая позволит создавать отличные, динамические и привлекательные сайты, используя недосягаемые ранее возможности.

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

Вчера была опубликована хорошая статья «Веб-дизайн. Каждому устройству свое представление». Несмотря на неплохие размышления, к сожалению, вывод в ней довольно глупый. А именно:

«Нужно определить, какими устройствами могут пользоваться ваши посетители, проработать и создать для этих устройств представление вашего сайта, определить устройство посредством проверки заголовков браузеров, и отправить наиболее подходящее представление.»

Почему это глупо

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



Это скриншот из презентации «Beyond the mobile web by yiibu» (очень рекомендую).

Во-вторых, если вы не facebook или yandex, скорее всего, вы не потянете создание и поддержку разных версий сайта для каждого устройства. Да и это не имеет особого смысла. Потому что ситуация становится похожа на реалии пятнадцатилетней давности. Тогда делали сайт «под браузер», а сейчас автор предлагает делать сайт «под устройство».

Как сделать один сайт для всех устройств

Оригинал опубликовал Лео Бабаута на сайте Zen Habits. Я его вольно перевел и немножечко адаптировал. Сразу оговорюсь, я не претендую на точность перевода. Моей задачей было перевести не точно, а понятно. Приятного чтения и применения!

«Это про привычки и делание, а не про систему и инструменты»

Чтобы закрепить основы продуктивности и организованности, сохраняя всё настолько простым, насколько возможно, я разработал свою собственную систему продуктивности: Zen To Done (ZTD).

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

Одно из первых приложений, которое мы собираемся выпустить на базе фреймворка Вебасист — это приложение «Поддержка» для организации поддержки клиентов.

На наш взгляд, «идеальное» приложение для работы службы поддержки должно быть абстрагировано от природы запросов (тикетов). В потоке запросов должно быть можно обрабатывать и пресейл-вопросы, и сообщения в форуме, и заказы на туры, и заявки на приемку в ремонт аппаратуры. Приложение должно обеспечивать работу с потоком запросов, распределенных по разным отделам, где в каждом отделе настроен свой рабочий процесс (воркфлоу). Должен быть REST API, должно быть можно оказывать поддержку пользователей из своего любимого почтовика, а не обязательно через веб-интерфейс — приложение должно самостоятельно маршрутизировать все взаимодействия.

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



Приглашаем к дискуссии в комменты к посту или в блог на сайте Вебасиста.

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

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

Введение

Восемь лет назад у меня была идея открыть сеть ресторанов быстрого здорового питания в городе Красноярске. Я достаточно долго проработал в сфере общепита, начиная от официанта, бармена, повара до помощника директора + было неплохое видение будущего бизнеса. При этом отсутствовали всего лишь знания и опыт в области предпринимательства и необходимые денежные средства. Мелочь :-) Но я был полон энтузиазма и намерения воплотить задуманное.

На блоге одного из создателей Aquaria и Spelunky есть любопытный пост с советами для тех, кто испытывает проблемы с доведением до конца своих игровых проектов. Этот список советов оказался для меня своего рода «зеркалом», в котором отражены многие проблемы, с которыми сталкивался я сам, и я был удивлен тем, насколько хорошо автору удалось уловить суть этих проблем и предложить свои решения, зачастую бескомпромисные.

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