20% онлайн-времени пользователи проводят в социальных сетях
В отчете компании ComScore отмечается, что на долю социальных сетей пришлось 20% времени проводимого интернет-пользователями по всему миру.
Аудитория социальных сетей составляет 82% всех пользователей глобальной сети в возрасте старше 15 лет. Общая интернет-аудитория в мире превысила 1,2 млрд человек.
В октябре 2011 года 55% мировой аудитории интернета пользовались Facebook, пользователи работали с Facebook 75% времени, проводимого в социальных сетях.
В октябре с Twitter работали примерно 10% интернет-пользователей. Аудитория этого сервиса за год выросла почти на 60%.
Больше всего в соцсетях присутствуют пользователи в возрасте 15-25 лет, в среднем они проводили в социальных сетях по 8 часов в месяц.
Русский Твиттер за 4 месяца вырос в 2 раза
Яндекс подсчитал, что на данный момент число русскоязычных аккаунтов в Twitter составляет 1,85 млн. При этом сервис в нашей стране быстро растёт: за последние четыре месяца эта цифра выросла почти вдвое. Ещё в августе это был миллион.
В 2010 году кириллические слова редко оказывались в мировых трендах Twitter, а в этом году это явление стало частым. Например, это были слова «Путин», «ЧП», «выборы», ряд других.
24 дек. 2011 г.
22 дек. 2011 г.
Оранжерея знаний с MediaWiki
Автор: Стас Фомин, заместитель директора по информационным технологиям, компания CUSTIS (http://belonesox.moikrug.ru)
Управление знаниями — область довольно молодая, с неясно очерченными границами, включающая как программную, так и социальную инженерию. Упоминания knowledge management в Интернете и публикациях часто склоняются к крайним взглядам.
Взгляд «Библиотекарский». Знания — это то, что хранится целостно в некоторой библиотеке, куда нужно все занести, каждый элемент детально описать и каталогизировать, «составить карточки», далее выдавать по атрибутным запросам. Управление заключается в контроле над этим процессом. Это основа разного рода систем документооборота и прочих библиотек, выдаваемых за «базы знаний».
Взгляд «Менеджерский». «Библиотека» — это утопия, основной объем знаний всегда остается в головах сотрудников, поэтому надо занимать «проактивную» позицию, шевелить людей, сбивать их в сообщества, проводить собрания‑семинары-конференции. Для этого нужны специально обученные люди, сводящие ищущих со знающими, занимающиеся «фасилитацией» общения и оргвопросами, — и все это представляет разновидность обычного организационного менеджмента. Типичный пример популярной книги Learning to Fly.
К сожалению, русский перевод‑калька «управление знаниями» не совсем соответствует исходному понятию. «Управление» ближе к «контролю», а management тут — скорее «забота и обеспечение». А ожидаемая цель Knowledge Management — не бесконечный затратный процесс с «ручным приводом, бурлаками и аниматорами», а обеспеченное инфраструктурой состояние организации, когда с минимальными накладными расходами знания фиксируются и распространяются по всем доступным каналам, где спрашивающие эффективно получают ответы и знакомятся с экспертами по своим темам.
При этом важно нащупать работающий компромисс между крайними точками разных граней.
Грань «ПЗУ vs. ОЗУ» — все ли должно быть на 100% формально зафиксировано, разложено по полочкам, прошито семантическими связями? К этому стремятся тяжелые системы управления требованиями. Или пусть все будет в головах, просто нужно больше общаться? Это Agile- подход.
Грань «полнота или актуальность?» Надо ли стремиться к широте в ущерб актуальности, или бороться за целостность? «Обо всем, с ошибками» или «точно, но о малом»?
Субъективность «авторского взгляда» или выстраданные компромиссы?
Передача знаний — «PUSH vs. PULL»: «толкать в людей» или дать им свободу «тянуть то, что им нужно»?
Синхронные или асинхронные процессы?
А получившаяся инфраструктура должна быть достаточно удобна для массового использования без существенной мотивации, ведь премиями или угрозой штрафов и увольнения пользователя можно заставить работать со сколь угодно неудобной системой, а тут ожидается: «счастья всем, даром, и пусть никто не уйдет обиженным».
Откуда же ждать таких систем и инструментов? Ведь полно примеров неработающих дорогих систем, установленных и внедренных, но которыми сотрудники так и не стали пользоваться. И возникает желание решить проблему менеджерскими методами, мотивировать сотрудников работать с системой — «премия наиболее активным пользователям портала»(1). Это опасно, ибо подменяет истинную мотивацию, и если «перестать платить за любовь» — все будет кончено. Тут очень уместна притча о пенсионере и хулиганах.
Хулиганы каждый день беспокоили одного старика, играли в футбол в его дворе, шумели и т. п. Рычагов воздействия у пенсионера никаких не было. Тогда он сказал, что эта игра ему нравится, и стал давать каждому гопнику по доллару «за работу» — то есть за каждую игру в его дворе. После такой недели он с видимым сожалением (кризис!) урезал оплату до 50 центов. Еще через неделю — до 25. В следующий раз шпана уже не пришла — «нашел дураков вкалывать за копейки».
Демократизм электронных пространств
А как сделать, чтобы все это заработало без материального подогрева и смазки?
Оказалось, надо всего лишь присмотреться к процессам, происходящим в Большом Интернете, где различные тематические сообщества уже десятилетиями решали все эти задачи, где эволюционно сложился набор систем, интерфейсов и практик, массово удобных и эффективных.
Например, там появились такие вещи.
Закладки. Самая первая парадигма, сбор находок в безбрежном Интернете. Затем они эволюционировали в сетевые закладки и даже в «закладки-цитаты» — Google Notebook, Evernote.
Блоги. Простейшая фиксация «ответов на незаданные вопросы». Минимальные «налоги» на регистрацию — не нужно классифицировать и актуализировать. Каждая запись — это только мнение автора на момент публикации.
Форумы. Место, где вопросы встречаются с ответами. Здесь уже есть попытка найти объективную истину или хотя бы собрать спектр мнений. Опять‑таки, актуализировать ничего не требуется, представлен весь спектр мнений вокруг одного вопроса, а вычленение сухого остатка — обычно работа читателя.
Вики‑системы. То место, где выжимаются актуальные и объективные знания, после чего они классифицируются и обрастают семантическими связями.
Определились и основные средства доступа.
Полнотекстовый поиск. Все научились «гуглить», и даже если есть отличная документация, пользователям быстрее найти ответы на свои конкретные вопросы через поисковики.
Концепция RSS/Atom‑каналов. Все изменения распространяются через ленты‑каналы в формате RSS или Atom, пользователи подписываются на них и просматривают агрегированные потоки в специальных программах и сервисах. Колесико мыши оказалось не менее ценным изобретением, чем обычное колесо: с ним очень удобно читать-просматривать длинные информационные полосы-ленты. Почему бы не присмотреться к этим инструментам и шаблонам их использования, а потом инсталлировать лучшие экземпляры у себя в компании и дать привычные для образованного человека третьего тысячелетия интерфейсы и практики — вместо того чтобы размещать очередную «библиотеку» или «систему документооборота», где все основано на бумажных метафорах доинтернетной эры.
Инженерный подход требует: «есть задача — разработать конструкцию для ее решения», после чего конструкция пустует, как заброшенное промздание. Новое решение будет его антиподом. Это скорее «агротехника» — высаживается правильная, жизнеспособная рассада, обеспечивается поливка и прочая инфраструктура, а дальше нужно наблюдать за внутренними тенденциями, внося коррективы лишь по необходимости. И такое садоводство, по крайней мере в ИТ-компаниях, встречается все чаще, ударяясь в одну из двух следующих крайностей.
Установить только какую‑нибудь вики‑систему и ждать, когда она сама наполнится знаниями. Получилось в мировом масштабе «Википедии», значит, и у нас все будет ОК. Но «Википедия» работает на мощности огромного числа авторов и редакторов, и упор там сделан не на полноту, а на целостность и актуальность — удаление недостаточно важного, недостаточно объективного, не имеющего твердых доказательств и т. п. В масштабе компании так делать нельзя — надо «допустить» информацию разной степени актуальности и обновляющие «дельты». Именно это и обеспечивает «поток» информации в противовес модели склада(2). Как раз такова модель блогов и форумов. Тогда нужно дать персональное пространство для хранения личного опыта.
«Дать людям все!» — как предлагается в кинофильме «Фонтан». Установить и вики‑систему, и блоги, и форумы, и закладки! Увы, в этом случае возникает конфликт использования — разные интерфейсы систем, невозможность переноса содержимого из‑за несовместимых форматов разметки, концепций ссылок и т. п.
Что же делать? Хорошие новости! На самом деле все стандартные системы блогов/форумов/закладок созданы для агрессивной внешней интернет‑среды, где нужно учитывать противодействию спаму, вандалам и идиотам. Даже вики‑системы если и справляются с этим, то только благодаря активному сообществу — заброшенная вики очень быстро превращается в ферму ссылок для SEO‑спамеров.
Но внутри компании, в интранете — доверенная среда. Если там обнаруживается спаммер/вандал/идиот — это радость для HR‑службы. Ему можно вправить мозги или уволить, пока он не наломал серьезных дров. А это явно прибавляет уверенности в том, что в компании можно создать не просто «сад знаний», а настоящую оранжерею на базе мощной вики‑системы, невозможную в Большом Интернете — ведь там мало кто согласится вести блог, который может испортить любой прохожий. В компании становятся осмысленными даже микроблоги. Ведь твит в Интернете о том, что какой‑то «sdk756f разобрался с технологией XXX», несет практически нулевую информацию. Ну разве что эта технология настолько редка и важна для вас, что вы попробуете с ним связаться. Совсем другое дело, если это заметка от «Васи из соседнего отдела», — теперь, когда вы нашли этот микропост-маркер, вы знаете, с кем эту тему можно обсудить, а сделать запись «Васе» ничего не стоило!
Так вот, можно реализовать все концепции: закладки, блоги, форумы и вики — на базе одной системы, наиболее мощной из всех. А именно — качественной вики, такой как MediaWiki! То есть получить все плюс бонусы вики‑систем: совместное редактирование, управление версиями, удобную разметку, поддержку шаблонов и разнородного мультимедиаконтента!
Внимательно присмотревшись, можно даже убрать концептуальный раздел между блогами и форумами — это на самом деле одно и то же, вопрос только в представлении и классификации. В обоих случаях это список блоков «тема, сообщение, обсуждение». Но блоги — это в первую очередь хронологическая лента сообщений от отдельного автора, а форум — «самое свежее от всех», то есть либо только что опубликованные темы, либо те, где кипит обсуждение. Технически это может быть единая система, просто между двумя представлениями «блоги» и «форумы» нет никакого ментальной разницы, куда писать сотруднику, когда у него возникает мысль или вопрос.
Да, информация в блогах и форумах может стать:
неактуальной — но поскольку она привязана к датам публикации, степень доверия и актуальности вполне можно вычислять из этого. Мешать может только устаревшая информация, которая в поиске находится раньше актуальной. Тогда ее можно удалить, обновить или быстро пометить как «архивную», понизив релевантность для поиска;
дублированной — например, если в длинном обсуждении «перемывается» одна и та же тема. Но полнота у нас уже есть, а если затраты оправданны, и мы легко можем добиваться и целостности, делая выжимки и резюме обсуждений в соответствии с обычным вики-подходом.
И все это не теоретические соображения, а реальный опыт: именно такое расширение «ВикиЛоги» MediaWiki мы реализовали в нашей компании. Широк спектр обсуждаемых в компании тем — от политических и организационных новостей в блоге генерального директора до жарких технологических споров с сотнями комментариев, в которых если и не рождается истина, то, по крайней мере, составляется резюме возможных проблем и решений, а участники определяются с позицией. Выросла и вовлеченность сотрудников в наполнение базы знаний.
Иногда еще встречается мнение, что вики‑системы — это какие‑то унылые поделки для программистов и прочих гиков, у которых нет денег на «что‑то серьезное от солидного вендора». Это не так. Добротные вики‑системы являются отличным компромиссом между эффективностью фиксации и актуализации знаний и их простотой и доступностью для всех категорий сотрудников. Важно запомнить: правильная вики‑система — это не когда «все плоским текстом», а когда «быстро-быстро»(3). Значит, можно грузить сколь угодно «богатый» контент — фото, видео, скринкасты, звук, диаграммы, майндмапы, статьи и книги в PDF/DjVu и, на худой конец, просто документы в офисных форматах.
А мощность самой концепции позволяет использовать вики практически для всего, хоть как‑то попадающего в категории «база знаний» и «публикация материалов», где единственная уязвимость — это все менее ценная постраничная верстка для бумажной печати. Более подробно все это разобрано в статье «MediaWiki — серебряная пуля или швейцарский нож?»(4).
Осталось поговорить о «закладках», или, вернее, о «вырезках», — ведь нечто схожее аналитики доинтернетной эры, пользуясь ножницами и кнопками, вытворяли с газетами. Они очень важны при Knowledge Miningе во внешнем Интернете — ведь сейчас пользователь компьютера совсем не похож на «оператора ЭВМ», сидящего перед клавиатурой с 10:00 до 18:00. Мы постоянно «серфим» в Интернете — ноутбуки и прочие девайсы сделали возможным чтение/просмотр информационных потоков в любом месте и положении, на улице и в туалете, стоя, лежа и сидя. Чисто физически приходится разделять режимы «читателя» и «аналитика-реализатора»: заметив интересное, выделить важное, чтобы позже, сидя за столом, проанализировать и применить. Или обратить на это важное внимание экспертов или ответственных товарищей. Например, можно собрать ключевые цитаты из книги или статьи, чтобы потом написать рецензию. Или добавить ссылки-заметки на плюсы и минусы технологии, а затем заняться их реальной проверкой. Или отметить активность конкурентов, чтобы отдел маркетинга сделал правильные выводы.
Проблемы стандартных сервисов закладок в том, что «личный склад» очень быстро замусоривается, в нем сложно искать. Набор закладок не может быть персональной базой знаний, его очень трудно рефакторить — быстро удалять, переносить куда‑то содержимое. К тому же большинство сервисов не хранят цитаты. Велики и накладные расходы на добавление ссылки: «заполните поля», «выберите категорию»… Нет групповой работы.
Как вы уже, наверное, догадались, мы сделали свой сервис «ВикиЗакладки» на базе MediaWiki. Там можно завести неограниченное число «каналов закладок» — статей, где будут размещаться ссылки и вырезки. Для добавления закладки и вырезки нужно всего лишь выделить интересное в броузере и нажать кнопку букмарклета. Сервис работает во всех броузерах без инсталляции. Закладки можно вести в одиночку и коллективно («Сводки аналитического отдела по рыночному сектору X»), разделять по темам («Книга YYY») или перемешивать. Закладки автоматически сортируются в хронологическом порядке по разделам статьи, но хранить их вечно не обязательно. Лучше время от времени разбирать их: на основе каких‑то писать новые или дополнять существующие статьи базы знаний, какие‑то превращать в реализованные проекты. А многое вскоре потеряет важность, и закладки можно будет стереть. Все это делается быстро, ибо интерфейс самый эффективный — редактирование теста: copy-paste, перенос и удаление блоков.
А чтобы сделать pull-интерфейс, нужно уметь превращать в RSS-поток любое изменение, будь то свежий пост в блоге, новая статья, закладка, редактирование и другие гибко задаваемые события. И сделать удобной подписку на эти каналы, с централизованной агрегацией и Web-интерфейсом, чтобы можно было их просматривать откуда угодно, быстро и удобно, — короче, сделать внутрикорпоративный «Google Reader». Мы сделали и его — это система «FeedOnFeeds»!
Реализован отличный полнотекстовый поиск с русской морфологией по всей вики‑системе, включая блоги-форумы-закладки, с настраиваемым выбором пространства поиска: например, можно искать в «блогах» или, наоборот, везде, кроме них. Впрочем, есть и push-интерфейс, реализованный через электронную почту, когда важна именно оперативность реакции: например, письмами приходят ответы к авторским постам и комментариям. Это привычный интерфейс для любого интернет-пользователя.
«Ненавязчивое» образование
Иногда знания нужно передавать не просто «обычной почтой без гарантии доставки», а «заказным письмом, с уведомлением о вручении», проверив, что авторские мысли поняты правильно. Такое полезно, например, для обучающих курсов или каких‑то важных регламентов.
Общеизвестен софизм греческого оратора Горгия: «Ничто не существует; если и существует, то оно непознаваемо; если оно и познаваемо, то непередаваемо». И трудно с ним не согласиться: просто диву даешься, насколько люди склонны пропускать или неверно трактовать элементарные регламенты!
Но выход есть! Как прочность программного обеспечения увеличивается при покрытии кода проверочными тестами, так и надежность передачи знаний увеличится, если сопроводить ее «автоматическими проверочными тестами на понимание».
Речь идет о классическом подходе формирования системы тестов с выбором вариантов. При всей критике, это очень дешево и эффективно. Ведь критикуют именно систему оценивания, с линейной зависимостью от числа баллов. А достаточно просто отсекать «тяжелые случаи», тугодумов или лентяев, и дополнять оценку по другим критериям. И очень эффективно использовать систему тестов в роли тренажера‑симулятора.
Но неужели нужна специальная система для редактирования тестов и выполнения проверок? Нет! Мы и это реализовали как расширение MediaWiki «MediaWikiQuizzer». То есть тесты — это те же вики‑статьи, все функции быстрой и эффективной публикации под рукой. Можно делать сколь угодно сложные композиции новых тестов из уже существующих, использовать вариации одной и той же тестовой базы — выдавать случайные блоки по N вопросов, перетасовывать варианты, включать режим экзамена или обучения и т. п.
Тесты могут работать как в проверочном режиме, так и в обучающем: «Вы выбрали не тот вариант, правильно так‑то и потому‑то». Если использовать MediaWiki для публикации курсов и MediaWikiQuizzer-тесты, то никакие «профессиональные системы e-learningа» скорее всего не потребуются. Ведь остальной бюрократический (учет студентов, оценок) функционал, предлагаемый этими системами, в организации разумного размера и с нормальными отношениями попросту не нужен.
И еще об обучении: Mediawiki можно использовать не только в режиме «человек-компьютер», но и для передачи знаний «человек-человек» — а именно, для семинаров и курсов со слайдами.
Широко известны проблемы правильных слайдов:
автор пытается угнаться за двумя зайцами: подготовить слайд-презентацию, которую можно одновременно использовать и во время доклада, и раздать для самостоятельного чтения. Из-за этого получаются страшные «слайдоменты» — гибриды «слайдов и документов»(5), совершенно бессмысленные для выступления;
авторы не могут работать совместно, быстро и параллельно редактировать слайды;
нет богатых возможностей семантической подготовки материала, таких как автоматическое построение графов и диаграмм, раскраски исходных кодов и прочего, все это приходится делать вручную и повторять при изменении материала;
хочется включать мультимедиаконтент на современном уровне — видеоролики, майднмапы, анимацию и т. п.;
сложно делать целостный reusable-контент — например, составлять презентации для разных аудиторий из одних и тех же блоков слайдов.
Мы решили и эту задачу, реализовав MediaWiki-расширение «S5SlideShow», позволяющее выпускать «гибридные» статьи, пригодные и чтения, и для показа в виде слайдов.
К сожалению, объем бумажной статьи ограничен, и «за бортом» осталось много наших MediaWiki-изобретений: календарь с системой регистрации, совместное редактирование изображений и много другое.
Но для читателя важны два главных момента.
MediaWiki «расцветает» в «оранжерее» корпоративного интранета, огражденная от вандалов и спаммеров, и на ней можно удобно реализовать все привычное для обмена знаниями: блоги, форумы, закладки, слайды, проверочные тесты.
Мы не просто «делимся опытом», а выложили все наши доработки в open-source и предлагаем всем заинтересовавшимся совершенно бесплатно установить все это у себя: просто зайдите по адресу http://wiki.4intra.net/Mediawiki4Intranet.
Dpznj c iemag.ru
Управление знаниями — область довольно молодая, с неясно очерченными границами, включающая как программную, так и социальную инженерию. Упоминания knowledge management в Интернете и публикациях часто склоняются к крайним взглядам.
Взгляд «Библиотекарский». Знания — это то, что хранится целостно в некоторой библиотеке, куда нужно все занести, каждый элемент детально описать и каталогизировать, «составить карточки», далее выдавать по атрибутным запросам. Управление заключается в контроле над этим процессом. Это основа разного рода систем документооборота и прочих библиотек, выдаваемых за «базы знаний».
Взгляд «Менеджерский». «Библиотека» — это утопия, основной объем знаний всегда остается в головах сотрудников, поэтому надо занимать «проактивную» позицию, шевелить людей, сбивать их в сообщества, проводить собрания‑семинары-конференции. Для этого нужны специально обученные люди, сводящие ищущих со знающими, занимающиеся «фасилитацией» общения и оргвопросами, — и все это представляет разновидность обычного организационного менеджмента. Типичный пример популярной книги Learning to Fly.
К сожалению, русский перевод‑калька «управление знаниями» не совсем соответствует исходному понятию. «Управление» ближе к «контролю», а management тут — скорее «забота и обеспечение». А ожидаемая цель Knowledge Management — не бесконечный затратный процесс с «ручным приводом, бурлаками и аниматорами», а обеспеченное инфраструктурой состояние организации, когда с минимальными накладными расходами знания фиксируются и распространяются по всем доступным каналам, где спрашивающие эффективно получают ответы и знакомятся с экспертами по своим темам.
При этом важно нащупать работающий компромисс между крайними точками разных граней.
Грань «ПЗУ vs. ОЗУ» — все ли должно быть на 100% формально зафиксировано, разложено по полочкам, прошито семантическими связями? К этому стремятся тяжелые системы управления требованиями. Или пусть все будет в головах, просто нужно больше общаться? Это Agile- подход.
Грань «полнота или актуальность?» Надо ли стремиться к широте в ущерб актуальности, или бороться за целостность? «Обо всем, с ошибками» или «точно, но о малом»?
Субъективность «авторского взгляда» или выстраданные компромиссы?
Передача знаний — «PUSH vs. PULL»: «толкать в людей» или дать им свободу «тянуть то, что им нужно»?
Синхронные или асинхронные процессы?
А получившаяся инфраструктура должна быть достаточно удобна для массового использования без существенной мотивации, ведь премиями или угрозой штрафов и увольнения пользователя можно заставить работать со сколь угодно неудобной системой, а тут ожидается: «счастья всем, даром, и пусть никто не уйдет обиженным».
Откуда же ждать таких систем и инструментов? Ведь полно примеров неработающих дорогих систем, установленных и внедренных, но которыми сотрудники так и не стали пользоваться. И возникает желание решить проблему менеджерскими методами, мотивировать сотрудников работать с системой — «премия наиболее активным пользователям портала»(1). Это опасно, ибо подменяет истинную мотивацию, и если «перестать платить за любовь» — все будет кончено. Тут очень уместна притча о пенсионере и хулиганах.
Хулиганы каждый день беспокоили одного старика, играли в футбол в его дворе, шумели и т. п. Рычагов воздействия у пенсионера никаких не было. Тогда он сказал, что эта игра ему нравится, и стал давать каждому гопнику по доллару «за работу» — то есть за каждую игру в его дворе. После такой недели он с видимым сожалением (кризис!) урезал оплату до 50 центов. Еще через неделю — до 25. В следующий раз шпана уже не пришла — «нашел дураков вкалывать за копейки».
Демократизм электронных пространств
А как сделать, чтобы все это заработало без материального подогрева и смазки?
Оказалось, надо всего лишь присмотреться к процессам, происходящим в Большом Интернете, где различные тематические сообщества уже десятилетиями решали все эти задачи, где эволюционно сложился набор систем, интерфейсов и практик, массово удобных и эффективных.
Например, там появились такие вещи.
Закладки. Самая первая парадигма, сбор находок в безбрежном Интернете. Затем они эволюционировали в сетевые закладки и даже в «закладки-цитаты» — Google Notebook, Evernote.
Блоги. Простейшая фиксация «ответов на незаданные вопросы». Минимальные «налоги» на регистрацию — не нужно классифицировать и актуализировать. Каждая запись — это только мнение автора на момент публикации.
Форумы. Место, где вопросы встречаются с ответами. Здесь уже есть попытка найти объективную истину или хотя бы собрать спектр мнений. Опять‑таки, актуализировать ничего не требуется, представлен весь спектр мнений вокруг одного вопроса, а вычленение сухого остатка — обычно работа читателя.
Вики‑системы. То место, где выжимаются актуальные и объективные знания, после чего они классифицируются и обрастают семантическими связями.
Определились и основные средства доступа.
Полнотекстовый поиск. Все научились «гуглить», и даже если есть отличная документация, пользователям быстрее найти ответы на свои конкретные вопросы через поисковики.
Концепция RSS/Atom‑каналов. Все изменения распространяются через ленты‑каналы в формате RSS или Atom, пользователи подписываются на них и просматривают агрегированные потоки в специальных программах и сервисах. Колесико мыши оказалось не менее ценным изобретением, чем обычное колесо: с ним очень удобно читать-просматривать длинные информационные полосы-ленты. Почему бы не присмотреться к этим инструментам и шаблонам их использования, а потом инсталлировать лучшие экземпляры у себя в компании и дать привычные для образованного человека третьего тысячелетия интерфейсы и практики — вместо того чтобы размещать очередную «библиотеку» или «систему документооборота», где все основано на бумажных метафорах доинтернетной эры.
Инженерный подход требует: «есть задача — разработать конструкцию для ее решения», после чего конструкция пустует, как заброшенное промздание. Новое решение будет его антиподом. Это скорее «агротехника» — высаживается правильная, жизнеспособная рассада, обеспечивается поливка и прочая инфраструктура, а дальше нужно наблюдать за внутренними тенденциями, внося коррективы лишь по необходимости. И такое садоводство, по крайней мере в ИТ-компаниях, встречается все чаще, ударяясь в одну из двух следующих крайностей.
Установить только какую‑нибудь вики‑систему и ждать, когда она сама наполнится знаниями. Получилось в мировом масштабе «Википедии», значит, и у нас все будет ОК. Но «Википедия» работает на мощности огромного числа авторов и редакторов, и упор там сделан не на полноту, а на целостность и актуальность — удаление недостаточно важного, недостаточно объективного, не имеющего твердых доказательств и т. п. В масштабе компании так делать нельзя — надо «допустить» информацию разной степени актуальности и обновляющие «дельты». Именно это и обеспечивает «поток» информации в противовес модели склада(2). Как раз такова модель блогов и форумов. Тогда нужно дать персональное пространство для хранения личного опыта.
«Дать людям все!» — как предлагается в кинофильме «Фонтан». Установить и вики‑систему, и блоги, и форумы, и закладки! Увы, в этом случае возникает конфликт использования — разные интерфейсы систем, невозможность переноса содержимого из‑за несовместимых форматов разметки, концепций ссылок и т. п.
Что же делать? Хорошие новости! На самом деле все стандартные системы блогов/форумов/закладок созданы для агрессивной внешней интернет‑среды, где нужно учитывать противодействию спаму, вандалам и идиотам. Даже вики‑системы если и справляются с этим, то только благодаря активному сообществу — заброшенная вики очень быстро превращается в ферму ссылок для SEO‑спамеров.
Но внутри компании, в интранете — доверенная среда. Если там обнаруживается спаммер/вандал/идиот — это радость для HR‑службы. Ему можно вправить мозги или уволить, пока он не наломал серьезных дров. А это явно прибавляет уверенности в том, что в компании можно создать не просто «сад знаний», а настоящую оранжерею на базе мощной вики‑системы, невозможную в Большом Интернете — ведь там мало кто согласится вести блог, который может испортить любой прохожий. В компании становятся осмысленными даже микроблоги. Ведь твит в Интернете о том, что какой‑то «sdk756f разобрался с технологией XXX», несет практически нулевую информацию. Ну разве что эта технология настолько редка и важна для вас, что вы попробуете с ним связаться. Совсем другое дело, если это заметка от «Васи из соседнего отдела», — теперь, когда вы нашли этот микропост-маркер, вы знаете, с кем эту тему можно обсудить, а сделать запись «Васе» ничего не стоило!
Так вот, можно реализовать все концепции: закладки, блоги, форумы и вики — на базе одной системы, наиболее мощной из всех. А именно — качественной вики, такой как MediaWiki! То есть получить все плюс бонусы вики‑систем: совместное редактирование, управление версиями, удобную разметку, поддержку шаблонов и разнородного мультимедиаконтента!
Внимательно присмотревшись, можно даже убрать концептуальный раздел между блогами и форумами — это на самом деле одно и то же, вопрос только в представлении и классификации. В обоих случаях это список блоков «тема, сообщение, обсуждение». Но блоги — это в первую очередь хронологическая лента сообщений от отдельного автора, а форум — «самое свежее от всех», то есть либо только что опубликованные темы, либо те, где кипит обсуждение. Технически это может быть единая система, просто между двумя представлениями «блоги» и «форумы» нет никакого ментальной разницы, куда писать сотруднику, когда у него возникает мысль или вопрос.
Да, информация в блогах и форумах может стать:
неактуальной — но поскольку она привязана к датам публикации, степень доверия и актуальности вполне можно вычислять из этого. Мешать может только устаревшая информация, которая в поиске находится раньше актуальной. Тогда ее можно удалить, обновить или быстро пометить как «архивную», понизив релевантность для поиска;
дублированной — например, если в длинном обсуждении «перемывается» одна и та же тема. Но полнота у нас уже есть, а если затраты оправданны, и мы легко можем добиваться и целостности, делая выжимки и резюме обсуждений в соответствии с обычным вики-подходом.
И все это не теоретические соображения, а реальный опыт: именно такое расширение «ВикиЛоги» MediaWiki мы реализовали в нашей компании. Широк спектр обсуждаемых в компании тем — от политических и организационных новостей в блоге генерального директора до жарких технологических споров с сотнями комментариев, в которых если и не рождается истина, то, по крайней мере, составляется резюме возможных проблем и решений, а участники определяются с позицией. Выросла и вовлеченность сотрудников в наполнение базы знаний.
Иногда еще встречается мнение, что вики‑системы — это какие‑то унылые поделки для программистов и прочих гиков, у которых нет денег на «что‑то серьезное от солидного вендора». Это не так. Добротные вики‑системы являются отличным компромиссом между эффективностью фиксации и актуализации знаний и их простотой и доступностью для всех категорий сотрудников. Важно запомнить: правильная вики‑система — это не когда «все плоским текстом», а когда «быстро-быстро»(3). Значит, можно грузить сколь угодно «богатый» контент — фото, видео, скринкасты, звук, диаграммы, майндмапы, статьи и книги в PDF/DjVu и, на худой конец, просто документы в офисных форматах.
А мощность самой концепции позволяет использовать вики практически для всего, хоть как‑то попадающего в категории «база знаний» и «публикация материалов», где единственная уязвимость — это все менее ценная постраничная верстка для бумажной печати. Более подробно все это разобрано в статье «MediaWiki — серебряная пуля или швейцарский нож?»(4).
Осталось поговорить о «закладках», или, вернее, о «вырезках», — ведь нечто схожее аналитики доинтернетной эры, пользуясь ножницами и кнопками, вытворяли с газетами. Они очень важны при Knowledge Miningе во внешнем Интернете — ведь сейчас пользователь компьютера совсем не похож на «оператора ЭВМ», сидящего перед клавиатурой с 10:00 до 18:00. Мы постоянно «серфим» в Интернете — ноутбуки и прочие девайсы сделали возможным чтение/просмотр информационных потоков в любом месте и положении, на улице и в туалете, стоя, лежа и сидя. Чисто физически приходится разделять режимы «читателя» и «аналитика-реализатора»: заметив интересное, выделить важное, чтобы позже, сидя за столом, проанализировать и применить. Или обратить на это важное внимание экспертов или ответственных товарищей. Например, можно собрать ключевые цитаты из книги или статьи, чтобы потом написать рецензию. Или добавить ссылки-заметки на плюсы и минусы технологии, а затем заняться их реальной проверкой. Или отметить активность конкурентов, чтобы отдел маркетинга сделал правильные выводы.
Проблемы стандартных сервисов закладок в том, что «личный склад» очень быстро замусоривается, в нем сложно искать. Набор закладок не может быть персональной базой знаний, его очень трудно рефакторить — быстро удалять, переносить куда‑то содержимое. К тому же большинство сервисов не хранят цитаты. Велики и накладные расходы на добавление ссылки: «заполните поля», «выберите категорию»… Нет групповой работы.
Как вы уже, наверное, догадались, мы сделали свой сервис «ВикиЗакладки» на базе MediaWiki. Там можно завести неограниченное число «каналов закладок» — статей, где будут размещаться ссылки и вырезки. Для добавления закладки и вырезки нужно всего лишь выделить интересное в броузере и нажать кнопку букмарклета. Сервис работает во всех броузерах без инсталляции. Закладки можно вести в одиночку и коллективно («Сводки аналитического отдела по рыночному сектору X»), разделять по темам («Книга YYY») или перемешивать. Закладки автоматически сортируются в хронологическом порядке по разделам статьи, но хранить их вечно не обязательно. Лучше время от времени разбирать их: на основе каких‑то писать новые или дополнять существующие статьи базы знаний, какие‑то превращать в реализованные проекты. А многое вскоре потеряет важность, и закладки можно будет стереть. Все это делается быстро, ибо интерфейс самый эффективный — редактирование теста: copy-paste, перенос и удаление блоков.
А чтобы сделать pull-интерфейс, нужно уметь превращать в RSS-поток любое изменение, будь то свежий пост в блоге, новая статья, закладка, редактирование и другие гибко задаваемые события. И сделать удобной подписку на эти каналы, с централизованной агрегацией и Web-интерфейсом, чтобы можно было их просматривать откуда угодно, быстро и удобно, — короче, сделать внутрикорпоративный «Google Reader». Мы сделали и его — это система «FeedOnFeeds»!
Реализован отличный полнотекстовый поиск с русской морфологией по всей вики‑системе, включая блоги-форумы-закладки, с настраиваемым выбором пространства поиска: например, можно искать в «блогах» или, наоборот, везде, кроме них. Впрочем, есть и push-интерфейс, реализованный через электронную почту, когда важна именно оперативность реакции: например, письмами приходят ответы к авторским постам и комментариям. Это привычный интерфейс для любого интернет-пользователя.
«Ненавязчивое» образование
Иногда знания нужно передавать не просто «обычной почтой без гарантии доставки», а «заказным письмом, с уведомлением о вручении», проверив, что авторские мысли поняты правильно. Такое полезно, например, для обучающих курсов или каких‑то важных регламентов.
Общеизвестен софизм греческого оратора Горгия: «Ничто не существует; если и существует, то оно непознаваемо; если оно и познаваемо, то непередаваемо». И трудно с ним не согласиться: просто диву даешься, насколько люди склонны пропускать или неверно трактовать элементарные регламенты!
Но выход есть! Как прочность программного обеспечения увеличивается при покрытии кода проверочными тестами, так и надежность передачи знаний увеличится, если сопроводить ее «автоматическими проверочными тестами на понимание».
Речь идет о классическом подходе формирования системы тестов с выбором вариантов. При всей критике, это очень дешево и эффективно. Ведь критикуют именно систему оценивания, с линейной зависимостью от числа баллов. А достаточно просто отсекать «тяжелые случаи», тугодумов или лентяев, и дополнять оценку по другим критериям. И очень эффективно использовать систему тестов в роли тренажера‑симулятора.
Но неужели нужна специальная система для редактирования тестов и выполнения проверок? Нет! Мы и это реализовали как расширение MediaWiki «MediaWikiQuizzer». То есть тесты — это те же вики‑статьи, все функции быстрой и эффективной публикации под рукой. Можно делать сколь угодно сложные композиции новых тестов из уже существующих, использовать вариации одной и той же тестовой базы — выдавать случайные блоки по N вопросов, перетасовывать варианты, включать режим экзамена или обучения и т. п.
Тесты могут работать как в проверочном режиме, так и в обучающем: «Вы выбрали не тот вариант, правильно так‑то и потому‑то». Если использовать MediaWiki для публикации курсов и MediaWikiQuizzer-тесты, то никакие «профессиональные системы e-learningа» скорее всего не потребуются. Ведь остальной бюрократический (учет студентов, оценок) функционал, предлагаемый этими системами, в организации разумного размера и с нормальными отношениями попросту не нужен.
И еще об обучении: Mediawiki можно использовать не только в режиме «человек-компьютер», но и для передачи знаний «человек-человек» — а именно, для семинаров и курсов со слайдами.
Широко известны проблемы правильных слайдов:
автор пытается угнаться за двумя зайцами: подготовить слайд-презентацию, которую можно одновременно использовать и во время доклада, и раздать для самостоятельного чтения. Из-за этого получаются страшные «слайдоменты» — гибриды «слайдов и документов»(5), совершенно бессмысленные для выступления;
авторы не могут работать совместно, быстро и параллельно редактировать слайды;
нет богатых возможностей семантической подготовки материала, таких как автоматическое построение графов и диаграмм, раскраски исходных кодов и прочего, все это приходится делать вручную и повторять при изменении материала;
хочется включать мультимедиаконтент на современном уровне — видеоролики, майднмапы, анимацию и т. п.;
сложно делать целостный reusable-контент — например, составлять презентации для разных аудиторий из одних и тех же блоков слайдов.
Мы решили и эту задачу, реализовав MediaWiki-расширение «S5SlideShow», позволяющее выпускать «гибридные» статьи, пригодные и чтения, и для показа в виде слайдов.
К сожалению, объем бумажной статьи ограничен, и «за бортом» осталось много наших MediaWiki-изобретений: календарь с системой регистрации, совместное редактирование изображений и много другое.
Но для читателя важны два главных момента.
MediaWiki «расцветает» в «оранжерее» корпоративного интранета, огражденная от вандалов и спаммеров, и на ней можно удобно реализовать все привычное для обмена знаниями: блоги, форумы, закладки, слайды, проверочные тесты.
Мы не просто «делимся опытом», а выложили все наши доработки в open-source и предлагаем всем заинтересовавшимся совершенно бесплатно установить все это у себя: просто зайдите по адресу http://wiki.4intra.net/Mediawiki4Intranet.
Dpznj c iemag.ru
Гугл видит ВсЕ. В прямом смысле видит
Взято у ne-onn
Доказательства
Функция Instant Preview – вот почему мы видим скриншоты-аннотации в SERP. Эти превью обладают впечатляющей возможностью: они не только отображают скриншот страницы, но также визуально выделяют и подчеркивают текст, подходящий под ваш запрос. Этого просто невозможно достигнуть простым текстовым пауком. Cкриншоты флеш-страниц – вы, возможно, уже заметили в Инструментах вебмастера Google скриншоты флеш-сайтов.
Постойте... я думал, Google не видит флеш... Подтверждение запросов AJAX POST – Мэтт Каттс подтвердил, что GoogleBot умеет обращаться с запросами AJAX POST, и, по случайному совпадению, это произошло через несколько часов после того как Рэнд запостил статью «GoogleBot – это Chrome». Согласно определению, AJAX – это контент, загружаемый JavaScript, когда происходит действие после загрузки страницы. Следовательно, его невозможно отследить с помощью текстового паука, потому что текстовый паук не выполняет JavaScript, а только получает существующий код, каким он предоставлен при первоначальной загрузке. Google отслеживает Flash – Мэтт Клэйтон также показал мне некоторые журналы сервера, в которых GoogleBot получал доступ к URL, которые доступны только через встроенные Flash-модули на Mixcloud.com: 66.249.71.130 "13/Nov/2011:11:55:41 +0000" "GET /config/?w=300&h=300&js=1&embed_type=widget_standard&feed= http%3A//www.mixcloud.com/chrisreadsubstance/bbe-mixtape-competition-2010.json&tk=TlVMTA HTTP/1.1" 200 695 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 66.249.71.116 "13/Nov/2011:11:51:14 +0000" "GET /config/?w=300&h=300&js=1&feed=http%3A//www.mixcloud.com/ZiMoN/electro-house-mix-16.json&embed_type=widget_standard&tk=TlVMTA HTTP/1.1" 200 694 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Допустим, это не новость, но другой пост от 2008 года объясняет, что Google «рассматривает Flash-файлы таким же образом, как это делал бы человек, вводя данные, и так далее». А, вы имеете в виду, как человек работает с браузером? Скорость сайта – Хотя Google мог бы получать время загрузки сайтов с панели инструментов и данные об использовании от Chrome, для него гораздо надежнее получать эту информацию, индексируя саму сеть. Не выполняя всего кода страницы, практически невозможно точно вычислить время загрузки этой страницы. До сих пор все это могло звучать так, как будто Google находится всего в нескольких шагах от SkyNet. А оптимизаторы и Google уже много лет уверяют нас, что поисковый робот (паук) имеет текстовую основу, поэтому это может показаться вам фантастикой. Уверяю вас, это не так, и многие из тех вещей, о которых я говорю, доступны программистам даже с намного менее сильной командой инженеров, чем у Google. Знакомьтесь – PhantomJS PhantomJS – это headless Webkit browser, которым можно управлять через JavaScript API. С помощью небольшой автоматизации скрипта браузер легко можно превратить в паука. Забавно, что его логотипом является призрак, похожий на призраки в Pacman, а концепт довольно прост: PhantomJS используется для загрузки страницы так, как пользователь видит ее в Firefox, Chrome или Safari, извлечения материалов и прослеживания ссылок. PhantomJS имеет бесчисленное количество приложений для парсинга информации и других видов анализа сайтов, и я советую SEO-общественности осознать это прежде чем мы двинемся дальше. Джош воспользовался PhantomJS, чтобы подготовить некоторые доказательства сведений, которые я выложил на SearchLove. Ранее, когда я выпустил GoFish, я уже упоминал, что столкнулся с трудностями при сборе информации о росте количества запросов с Google Insights с помощью текстового паука из-за того, что список этих вопросов предоставляется через AJAX. Ричард Бакстер предположил, что эти данные легко можно собрать с помощью строки XPath (XPath string), и это убеждает меня в том, что поисковая архитектура ImportXML в Google Docs основана тоже на headless browser. На схеме написано красным: «Обычным путем эти данные получить невозможно, потому что это AJAX». Во всяком случае, здесь Джош снимает эти данные со страницы при помощи PhantomJS. Делать скриншоты текстовым пауком невозможно, но с помощью headless webkit browser это проще простого. На этом примере Джош показывает, как делаются скриншоты при помощи PhantomJS. Chromium – это общедоступная ветвь браузера Webkit, а я сильно сомневаюсь, что Google создал браузер из чисто альтруистических побуждений. Вышеупомянутое исследование предполагает, что GoogleBot – это многопоточный headless browser на основе того же самого кода. Почему нам ничего не говорят? Ну, вообще-то, говорят, но утверждают, что «робот-индексатор для создания превью» – это совершенно отдельный объект. Представьте этого робота как «миссис Pacman». Участник главного форума вебмастеров пожаловался, что в качестве пользовательского агента у них в журналах отображается "Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.14 (KHTML, like Gecko) Chrome/9.0.597 Safari/534.14", а не "Mozilla/5.0 (en-us) AppleWebKit/525.13 (KHTML, like Gecko; Google Web Preview) Version/3.1 Safari/525.13". Джон Му рассказал: «В качестве инструмента для тестирования мгновенных превью мы используем пользовательский агент по образцу Chrome, чтобы можно было сравнить то, что будет видеть браузер (при помощи этого пользовательского агента), с тем, что видим мы с помощью доступа Googlebot к кэшированному превью». В то время как headless browser и Googlebot, как мы знаем, отличаются, мне кажется, что они всегда параллельно просматривают страницы и собирают информацию для индексации и ранжирования. Другими словами, это как одновременная двухпользовательская версия Pacman с миссис Pacman в 3D и обычным Pacman, которые играют на одном уровне в одно время. В конце концов, паукам не было бы смысла просматривать всю сеть дважды по отдельности. Так почему же относительно этих возможностей не все так ясно, ведь они имеют отношение к ранжированию? В двух словах: качество поиска. Прикрываясь недостатками текстовых пауков, поисковики могут продолжать использовать их в качестве козла отпущения, объясняющего их неидеальные результаты. Они могут продолжать двигаться в направлении таких вещей как предполагаемый AuthorRank и полагаться на SEO, чтобы в буквальном смысле оптимизировать свои поисковые машины. Они могут продолжать говорить неопределенные вещи, вроде «не гонитесь на алгоритмом», «улучшайте пользовательское восприятие» и «мы учитываем то, что видно без прокрутки», что заставляет специалистов SEO облегчать работу Google. Основной продукцией Google (и единственной их продукцией, если спросить у Эрика Шмидта в суде), является поиск, и если обнародовать информацию о том, что их возможности намного превосходят заявленные, то им придется повысить качество поиска. Они не говорят нам об этом, потому что с ростом возможностей растет и ответственность.
Что это означает для нас?
Когда мы с Джошем представили свое исследование, многие люди спрашивали меня: «Как это должно поменять мои действия в плане SEO?». По моему мнению, есть три момента:
1. Javascript не поможет вам ничего скрыть. Если вам казалось, что с помощью постзагрузки JavaScript вы можете спрятать какой-либо контент – прекратите это делать. Заманивание и переключение теперь на 100% неэффективный метод. Pacman видит все.
2. Пользовательское впечатление чрезвычайно важно. Google сейчас может в буквальном смысле видеть ваш сайт! Как сказал Мэтт Катс, они смотрят на то, что выше границы прокрутки, а следовательно, могут учитывать при ранжировании то, сколько рекламы представлено на странице. Google может применять данные о поведенческих факторах вместе с дизайном сайта чтобы определить, насколько сайт полезен для людей. Это одновременно радует и пугает, но также это означает, что каждый специалист SEO должен приобрести книгу Круга «Не заставляй меня думать».
3. Инструменты SEO должны стать умнее. Большинство средств SEO основано на текстовых сборщиках (text scrapers), и хотя многие из них довольно сложны (в данный момент лидирует SEOmoz), они все еще сильно напоминают Pacman 80-х годов. Если мы хотим понять, что на самом деле принимает во внимание Google при ранжировании страниц, надо учитывать больше аспектов. - При обсуждении таких вещей как Page Authority и вероятность спама необходимо визуально проверять страницы с точки зрения программы, а не ограничиваться простыми показателями, такими как плотность распределения ключевиков и граф ссылок.
Другими словами, нам нужен показатель качества пользовательского восприятия (UX Quality Score), на который влиял бы визуальный анализ и возможные видоизменения спама. - Следует сравнивать, насколько отображаемая страница отличается от того, что можно предполагать по коду. Это можно назвать коэффициентом дельта (Delta Score). - При оценке распределения доли ссылок на странице нужно также учитывать динамическое преобразование (dinamic transformations), поскольку поисковые машины способны понять, сколько в действительности ссылок на странице. Этот фактор тоже можно включить в коэффициент дельта (Delta Score). - Также следует включить в наш анализ обработку естественного языка, так как это, по-видимому, тоже учитывается алгоритмом Google. Этот фактор не оказывает значительного влияния на общий результат, но помогает определить ключевые понятия, с которыми машина ассоциирует контент, а также полностью понять, чего стоит ссылка с учетом желаемого результата. Другими словами, необходим контекстуальный анализ графа ссылок. В двух вещах я согласен с Мэттом Катсом. Единственный постоянный параметр – это перемены. Однако мы должны также понимать, что Google будет продолжать дезинформировать нас относительно своих возможностей или подталкивать к определенным выводам, которых мы потом будем придерживаться. Поэтому нам следует понимать, что Google в ответе за свои технологии. Проще говоря, если они могут точно доказать, что они ничего такого не делают, то с этого момента им следует начать; в конце концов, там работают одни из самых талантливых инженеров на планете. Google продолжает усложнять поисковый маркетинг и отменять данные, позволяющие нам улучшать восприятие пользователем, но факт в том, что у нас симбиоз. Поисковики нуждаются в SEO-специалистах и вебмастерах, чтобы сделать сеть быстрее, проще и понятнее, а мы нуждаемся в поисковиках, чтобы качественный контент поощрялся, занимая более заметные места. Проблема в том, что у Google в руках все карты, и я рад, что приложил свои усилия к тому, чтобы вырвать одну из них. Твой ход, Мэтт.
Взято у ne-onn
Доказательства
Функция Instant Preview – вот почему мы видим скриншоты-аннотации в SERP. Эти превью обладают впечатляющей возможностью: они не только отображают скриншот страницы, но также визуально выделяют и подчеркивают текст, подходящий под ваш запрос. Этого просто невозможно достигнуть простым текстовым пауком. Cкриншоты флеш-страниц – вы, возможно, уже заметили в Инструментах вебмастера Google скриншоты флеш-сайтов.
Постойте... я думал, Google не видит флеш... Подтверждение запросов AJAX POST – Мэтт Каттс подтвердил, что GoogleBot умеет обращаться с запросами AJAX POST, и, по случайному совпадению, это произошло через несколько часов после того как Рэнд запостил статью «GoogleBot – это Chrome». Согласно определению, AJAX – это контент, загружаемый JavaScript, когда происходит действие после загрузки страницы. Следовательно, его невозможно отследить с помощью текстового паука, потому что текстовый паук не выполняет JavaScript, а только получает существующий код, каким он предоставлен при первоначальной загрузке. Google отслеживает Flash – Мэтт Клэйтон также показал мне некоторые журналы сервера, в которых GoogleBot получал доступ к URL, которые доступны только через встроенные Flash-модули на Mixcloud.com: 66.249.71.130 "13/Nov/2011:11:55:41 +0000" "GET /config/?w=300&h=300&js=1&embed_type=widget_standard&feed= http%3A//www.mixcloud.com/chrisreadsubstance/bbe-mixtape-competition-2010.json&tk=TlVMTA HTTP/1.1" 200 695 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 66.249.71.116 "13/Nov/2011:11:51:14 +0000" "GET /config/?w=300&h=300&js=1&feed=http%3A//www.mixcloud.com/ZiMoN/electro-house-mix-16.json&embed_type=widget_standard&tk=TlVMTA HTTP/1.1" 200 694 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Допустим, это не новость, но другой пост от 2008 года объясняет, что Google «рассматривает Flash-файлы таким же образом, как это делал бы человек, вводя данные, и так далее». А, вы имеете в виду, как человек работает с браузером? Скорость сайта – Хотя Google мог бы получать время загрузки сайтов с панели инструментов и данные об использовании от Chrome, для него гораздо надежнее получать эту информацию, индексируя саму сеть. Не выполняя всего кода страницы, практически невозможно точно вычислить время загрузки этой страницы. До сих пор все это могло звучать так, как будто Google находится всего в нескольких шагах от SkyNet. А оптимизаторы и Google уже много лет уверяют нас, что поисковый робот (паук) имеет текстовую основу, поэтому это может показаться вам фантастикой. Уверяю вас, это не так, и многие из тех вещей, о которых я говорю, доступны программистам даже с намного менее сильной командой инженеров, чем у Google. Знакомьтесь – PhantomJS PhantomJS – это headless Webkit browser, которым можно управлять через JavaScript API. С помощью небольшой автоматизации скрипта браузер легко можно превратить в паука. Забавно, что его логотипом является призрак, похожий на призраки в Pacman, а концепт довольно прост: PhantomJS используется для загрузки страницы так, как пользователь видит ее в Firefox, Chrome или Safari, извлечения материалов и прослеживания ссылок. PhantomJS имеет бесчисленное количество приложений для парсинга информации и других видов анализа сайтов, и я советую SEO-общественности осознать это прежде чем мы двинемся дальше. Джош воспользовался PhantomJS, чтобы подготовить некоторые доказательства сведений, которые я выложил на SearchLove. Ранее, когда я выпустил GoFish, я уже упоминал, что столкнулся с трудностями при сборе информации о росте количества запросов с Google Insights с помощью текстового паука из-за того, что список этих вопросов предоставляется через AJAX. Ричард Бакстер предположил, что эти данные легко можно собрать с помощью строки XPath (XPath string), и это убеждает меня в том, что поисковая архитектура ImportXML в Google Docs основана тоже на headless browser. На схеме написано красным: «Обычным путем эти данные получить невозможно, потому что это AJAX». Во всяком случае, здесь Джош снимает эти данные со страницы при помощи PhantomJS. Делать скриншоты текстовым пауком невозможно, но с помощью headless webkit browser это проще простого. На этом примере Джош показывает, как делаются скриншоты при помощи PhantomJS. Chromium – это общедоступная ветвь браузера Webkit, а я сильно сомневаюсь, что Google создал браузер из чисто альтруистических побуждений. Вышеупомянутое исследование предполагает, что GoogleBot – это многопоточный headless browser на основе того же самого кода. Почему нам ничего не говорят? Ну, вообще-то, говорят, но утверждают, что «робот-индексатор для создания превью» – это совершенно отдельный объект. Представьте этого робота как «миссис Pacman». Участник главного форума вебмастеров пожаловался, что в качестве пользовательского агента у них в журналах отображается "Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.14 (KHTML, like Gecko) Chrome/9.0.597 Safari/534.14", а не "Mozilla/5.0 (en-us) AppleWebKit/525.13 (KHTML, like Gecko; Google Web Preview) Version/3.1 Safari/525.13". Джон Му рассказал: «В качестве инструмента для тестирования мгновенных превью мы используем пользовательский агент по образцу Chrome, чтобы можно было сравнить то, что будет видеть браузер (при помощи этого пользовательского агента), с тем, что видим мы с помощью доступа Googlebot к кэшированному превью». В то время как headless browser и Googlebot, как мы знаем, отличаются, мне кажется, что они всегда параллельно просматривают страницы и собирают информацию для индексации и ранжирования. Другими словами, это как одновременная двухпользовательская версия Pacman с миссис Pacman в 3D и обычным Pacman, которые играют на одном уровне в одно время. В конце концов, паукам не было бы смысла просматривать всю сеть дважды по отдельности. Так почему же относительно этих возможностей не все так ясно, ведь они имеют отношение к ранжированию? В двух словах: качество поиска. Прикрываясь недостатками текстовых пауков, поисковики могут продолжать использовать их в качестве козла отпущения, объясняющего их неидеальные результаты. Они могут продолжать двигаться в направлении таких вещей как предполагаемый AuthorRank и полагаться на SEO, чтобы в буквальном смысле оптимизировать свои поисковые машины. Они могут продолжать говорить неопределенные вещи, вроде «не гонитесь на алгоритмом», «улучшайте пользовательское восприятие» и «мы учитываем то, что видно без прокрутки», что заставляет специалистов SEO облегчать работу Google. Основной продукцией Google (и единственной их продукцией, если спросить у Эрика Шмидта в суде), является поиск, и если обнародовать информацию о том, что их возможности намного превосходят заявленные, то им придется повысить качество поиска. Они не говорят нам об этом, потому что с ростом возможностей растет и ответственность.
Что это означает для нас?
Когда мы с Джошем представили свое исследование, многие люди спрашивали меня: «Как это должно поменять мои действия в плане SEO?». По моему мнению, есть три момента:
1. Javascript не поможет вам ничего скрыть. Если вам казалось, что с помощью постзагрузки JavaScript вы можете спрятать какой-либо контент – прекратите это делать. Заманивание и переключение теперь на 100% неэффективный метод. Pacman видит все.
2. Пользовательское впечатление чрезвычайно важно. Google сейчас может в буквальном смысле видеть ваш сайт! Как сказал Мэтт Катс, они смотрят на то, что выше границы прокрутки, а следовательно, могут учитывать при ранжировании то, сколько рекламы представлено на странице. Google может применять данные о поведенческих факторах вместе с дизайном сайта чтобы определить, насколько сайт полезен для людей. Это одновременно радует и пугает, но также это означает, что каждый специалист SEO должен приобрести книгу Круга «Не заставляй меня думать».
3. Инструменты SEO должны стать умнее. Большинство средств SEO основано на текстовых сборщиках (text scrapers), и хотя многие из них довольно сложны (в данный момент лидирует SEOmoz), они все еще сильно напоминают Pacman 80-х годов. Если мы хотим понять, что на самом деле принимает во внимание Google при ранжировании страниц, надо учитывать больше аспектов. - При обсуждении таких вещей как Page Authority и вероятность спама необходимо визуально проверять страницы с точки зрения программы, а не ограничиваться простыми показателями, такими как плотность распределения ключевиков и граф ссылок.
Другими словами, нам нужен показатель качества пользовательского восприятия (UX Quality Score), на который влиял бы визуальный анализ и возможные видоизменения спама. - Следует сравнивать, насколько отображаемая страница отличается от того, что можно предполагать по коду. Это можно назвать коэффициентом дельта (Delta Score). - При оценке распределения доли ссылок на странице нужно также учитывать динамическое преобразование (dinamic transformations), поскольку поисковые машины способны понять, сколько в действительности ссылок на странице. Этот фактор тоже можно включить в коэффициент дельта (Delta Score). - Также следует включить в наш анализ обработку естественного языка, так как это, по-видимому, тоже учитывается алгоритмом Google. Этот фактор не оказывает значительного влияния на общий результат, но помогает определить ключевые понятия, с которыми машина ассоциирует контент, а также полностью понять, чего стоит ссылка с учетом желаемого результата. Другими словами, необходим контекстуальный анализ графа ссылок. В двух вещах я согласен с Мэттом Катсом. Единственный постоянный параметр – это перемены. Однако мы должны также понимать, что Google будет продолжать дезинформировать нас относительно своих возможностей или подталкивать к определенным выводам, которых мы потом будем придерживаться. Поэтому нам следует понимать, что Google в ответе за свои технологии. Проще говоря, если они могут точно доказать, что они ничего такого не делают, то с этого момента им следует начать; в конце концов, там работают одни из самых талантливых инженеров на планете. Google продолжает усложнять поисковый маркетинг и отменять данные, позволяющие нам улучшать восприятие пользователем, но факт в том, что у нас симбиоз. Поисковики нуждаются в SEO-специалистах и вебмастерах, чтобы сделать сеть быстрее, проще и понятнее, а мы нуждаемся в поисковиках, чтобы качественный контент поощрялся, занимая более заметные места. Проблема в том, что у Google в руках все карты, и я рад, что приложил свои усилия к тому, чтобы вырвать одну из них. Твой ход, Мэтт.
Взято у ne-onn
20 дек. 2011 г.
Facebook может влиять на кредитный рейтинг участников
Взято с ИнФокс
Банки и иные финансовые учреждения намерены использовать социальную сеть Facebook для получения дополнительной информации о клиентах, желающих получить кредит на те или иные нужды.
Личная страничка человека в Facebook может рассказать специалистам о многом и существенно отразиться на его кредитном рейтинге. Основываясь на анализе данных, банк может принять решение о выплате кредита или отказе в кредитовании. Принцип работы этой схемы готов пока еще не полностью, но некоторые его аспекты уже озвучены. Работники банка будут смотреть, в первую очередь, на список друзей клиента и искать среди них злостных неплательщиков. Наличие таковых, само собой, не будет способствовать успеху в получении суммы. Обратная ситуация — когда в списке друзей у клиента есть весьма обеспеченные люди, — тоже имеет место быть, и тут уж шансы на получение кредита заметно возрастают.
По некоторым данным, одной только сетью Facebook банки не ограничатся. Для анализа им подойдет даже Twitter, столь популярный на западе. Здесь, как и в случае с социальной сеть, оценивается список друзей, но также и самого клиента в микроблоге.
Банки и иные финансовые учреждения намерены использовать социальную сеть Facebook для получения дополнительной информации о клиентах, желающих получить кредит на те или иные нужды.
Личная страничка человека в Facebook может рассказать специалистам о многом и существенно отразиться на его кредитном рейтинге. Основываясь на анализе данных, банк может принять решение о выплате кредита или отказе в кредитовании. Принцип работы этой схемы готов пока еще не полностью, но некоторые его аспекты уже озвучены. Работники банка будут смотреть, в первую очередь, на список друзей клиента и искать среди них злостных неплательщиков. Наличие таковых, само собой, не будет способствовать успеху в получении суммы. Обратная ситуация — когда в списке друзей у клиента есть весьма обеспеченные люди, — тоже имеет место быть, и тут уж шансы на получение кредита заметно возрастают.
По некоторым данным, одной только сетью Facebook банки не ограничатся. Для анализа им подойдет даже Twitter, столь популярный на западе. Здесь, как и в случае с социальной сеть, оценивается список друзей, но также и самого клиента в микроблоге.
Подписаться на:
Сообщения (Atom)