Это моя первая статья на хабре, если я её разместил не в тот блог, извините, более подходящего я не нашёл.

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

Тем кто считает, что в его компании Интернет как “канал продаж” используется на все 100%, читать эту статью необязательно.

На сегодняшний день, основная проблема коммерческих организаций в использование Интернета для бизнеса – низкий приоритет важности этого направления внутри компаний. Отсюда не понимание в чем эффективность, как её оценивать, что нужно делать. Следствием этого не продуктивная работа с сайтом, с заявками, запросами и обращениями посетителей с сайта компании.

Почему так происходит?

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

Например, нельзя блокировать кнопку (делать ее disabled), чтобы предотвратить отправку неправильно заполненной формы. Даже если вы совсем недавно научились отключать кнопочки. Даже если так делает ваш кумир. Это — порочная практика, подлежащая искоренению. И вот почему.

Задача:
Дизайнер нарисовал макет страницы, на заднем фоне которой была картинка. Я сначала было решил, что это фон который увеличивается по ширине в зависимости о разрешения монитора.
Но не тут то было. Дизайнер настаивал на то, что это масштабируемая картинка, которая сужается / растягивается при изменение окна приложения и по ширине и по высоте.
Заранее предупредив заказчика – что картинка будет грузиться 1 и в максимальном разрешении – его определили как 1600, приступил к работе.

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

Год подходит к концу — время подводить итоги. Вот и ChannelWeb подоспела со своим Топ-10 самых лучших открытых продуктов.

Открытое программное обеспечение это больше, чем просто операционная система Linux, и 2008 год отмечен громкими релизами таких продуктов, как OpenOffice.org, IBM Lotus Symphony, Firefox and Android. Но ОС Linux является сердцем FOSS движения, и в этом году она была популярна как никогда прежде. Вот список самых лучших продуктов с открытым исходным кодом.

«Совершенный Ajax» — новый подход к построению web-приложений, при котором web-сервер не генерирует ни строчки HTML-кода и взаимодействует с внешним миром только посредством web-служб; а клиентский интерфейс реализуется только на основе клиентских HTML, CSS, JavaScript.

Статья состоит из двух частей. В первой части — более живой и провокационной я постараюсь заинтересовать проблемой, рассказать о технологии «Совершенный Ajax» и показать ее применение на примере нашего проекта «Система Интерактивного Тестирования Знаний “Синтез”» (который имеет ряд интересных особенностей, таких, как использование серверного JavaScript на платформе Mozilla Rhino, прототипно-ориентированная ORM и поддержка SPARQL — языка запросов к Semantic Web).

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

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


Попробуйте угадать: к какой архитектуре относятся web-приложения?

К клиент-серверной говорите? Я ожидал, что Вы так ответите :-)

Что ж, давайте разберемся. В клиент-серверной архитектуре выделяют:

• Сервер — отвечает за хранение данных и реализацию бизнес-логики приложения.
  
  
• Клиент — отвечает за взаимодействие с пользователем ^[1].
  
  

Реализация бизнес-логики на сервере и взаимодействие с пользователем на клиенте четко разделены.

Преимущества клиент-серверной архитектуры очевидны; мы их все знаем:

1. Бизнес-логика не смешивается с пользовательским интерфейсом.
2. Можно реализовать несколько клиентов с разными пользовательскими интерфейсами: интерфейс командной строки, оконный Windows-интерфейс, Flash, web-интерфейс, мобильный интерфейс и т.д.
3. Клиентский компьютер не требователен к ресурсам;
4. И т.д.

Но, относятся ли web-приложения к клиент-серверной архитектуре?

Действительно, в web-приложениях есть сервер, отвечающий за бизнес логику приложения.

Но! За реализацию интерфейса отвечает не клиент, а тоже сервер. На сервере происходит обработка клиентской формы. Сервер генерирует HTML-код пользовательского интерфейса.

Клиент, т.е. браузер лишь визуализирует уже готовый HTML-код интерфейса. Это, фактически, то же самое, что прицепить к серверу монитор и объявить этот монитор клиентом…

Приветствую Хабр.
По мотивам cайта, сделанного сами знаете кем :)
В свое время увидел, такой эффект – слева сайта находятся ссылки, при клике на которые контентная область сайта плавно перемещается к указанному идентификатору. Эффект запомнился — решил повторить.
Для реализации плавного перемещения взял JQuery.

В мире ежедневно появляются несколько (десятков?) идей IT-проектов, авторы которых всерьез решают приняться за их реализацию. Кто-то берется за проект в одиночку, кто-то — собирает приятелей-энтузиастов, кто-то нанимает разработчиков на свои деньги, кто-то находит инвесторов. У кого-то проект получается таким, каким он себе его задумывал, у кого-то он сильно отличается от первоначального видения. Но большинство проектов, как показывает практика, перестают поддерживаться и/или закрываются.

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

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

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

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

3. Функциональность форм

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

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

Это происходит потому, что все «специалисты» знают: дизайн — это красивая картинка.

Дизайн лишь на 20% искусство, на 80% — это точная наука. И вы будете удивлены, когда узнаете, из чего на самом деле состоит каждая картинка.

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

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

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

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

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

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

Однако, автономные блоги обладают несколькими недостатками, как-то: отсутствие «друзей», неудобное представление информации о блоге, зачастую невозможность оставить мнение о ресурсе и прочее.

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

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

Итак, получили письмо от клиента

обычно есть следующие варианты

1. клиент явно перспективный и обратился «выборочно» именно к нам — есть большая вероятность, что переговоры будут удачными — тогда лучше сразу набивать стрелку и устанавливать личный контакт и все выяснять на месте. Хотя, границы бюджета лучше выяснить в любом случае.
2. клиент интересный, но многое неясно из его письма ( нет ТЗ, нет бюджета, он написал в несколько студий, сайт потенциально сложный, сайт неинтересный и тд. ). Тут важно прислать ему БРИФ на заполнение, выяснить сроки и бюджет. Согласовать бюджет сроки — уже потом встречаться в случае, если все устраивает.
3. Письмо подозрительно короткое и не «пахнет интересом». Например, «нужен обувной интернет-магазин, сколько стоит? Как быстро сделаете? Виталий» — тут вряд-ли чтото выгорит + вероятно это пробивон по ценам от конкурентов.
   В этом случае — цену говорим в полтора раза дето дороже, интересуемся «укладываемся ли мы в их бюджет» в положительном случае — можно встречаться. Иначе — скорее всего трата времени.

Предыстория

Как известно, перед тем, как выложить сайт в нет, мы его разрабатываем. И делаем мы это, как ни странно, на машине разработчика. И давно замечено, что javascript, а в некоторых случаях и css удобнее при разработке держать в нескольких файлах.Проблема в том, что, согласно принципам, описанным в статье Best Practices for Speeding Up Your Web Site (перевод доступен на сайте webo.in), для ускорения загрузки сайта нам нужно произвести следующие манипуляции над javascript и css файлами:

1. Слить весь javascript в один файл, причем, желательно так, чтобы сохранился нужный порядок — т.е., скажем, библиотека jQuery — была ближе к началу, а функции и объекты, которые ее используют — после нее.
2. Слить весь css в один файл
3. Сжать эти большие файлы с помощью какой-нибудь утилиты вроде yui-compressor (за исключением css-файлов, название которых начинается, скажем, с префикса ie_, которые содержат data:URL, и поэтому критично относятся к переходам со строки на строку, так что их для собственного спокойствия лучше не сжимать)
4. Расположить их в таком порядке — css-файл как можно ближе к открывающему тэгу head, а js-файл — как можно ближе к закрывающему тэгу body.
5. Выставить HTTP-заголовок expires на подольше, чтобы браузер пользователя их закешировал. Ну а для того, чтобы при следующем билде у пользователя обновился js и css надо этим файлам дать какое-нибудь уникальное имя.
6. Перед отдачей файлов клиенту сжимать их с помощью gzip

К чему это я?

Пункты 5 и 6 уже подробно расписаны в других местах.
Я же хочу рассмотреть в этой статье вопрос автоматизации пунктов 1,2,3,4. А точнее, я хочу предложить инструмент, с помощью которого одним (ну, максимум — двумя-тремя :) нажатием кнопки можно выполнить пункты 1, 2, 3, 4 настоящего списка и получить готовые к заливке на сервер javascript и css файлы.

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

Довольно часто коллеги жалуются на заказчиков. Мол, совсем от рук отбились, подонки! Ничего делать не хотят.

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

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

ВЕБОРУБ – это звание, присваиваемое ведущим веб-разработчикам, либо людям, заслужившим признание других веб-разработчиков.

ВЕБОРУБ – это неконференция, проводимая для того, чтобы ВЕБОРУБы имели возможность в непринужденной обстановке обсудить волнующие их темы.

Везде кризис — а у вас пир горой?
— Это уже не первый проводимый Веборуб и мы реально отрубим на нем те корни кризиса, которые крепко засели у многих в головах ;-)

Поделимся секретами как выжить и процветать в текущей ситуации.

Формат ВЕБОРУБА нам представляется таким:

• отсекаем (отрубаем) все лишнее;
• ни одного спонсора;
• не рассказывать очевидное, то, что можно найти в открытых источниках, т.е. рассказываем свое видение, мысли, идеи, опыт;
• нет традиционных докладов — выступления длятся итерационно, до 10 минут (до 5 слайдов, если они нужны).

Основная идея в том — чтоб отдать время на то, что нужно, интересно каждому (что мы пытаемся выведать в кулуарах).

Подробней на http://www.weborub.ru/

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

UPD: Опубликована вторая часть статьи habrahabr.ru/blogs/ui_design_and_usability/45680

Когда вы хотите увеличить доход вашего сервиса вы должны увеличить количество заполнений ваших веб-форм. Даже, если, на первый взгляд, у вас есть какие-то революционные идеи для того чтобы удивить посетителей, недостаточно просто добавить возможность регистрации на вашем сайте. Для того, чтобы сервис достиг максимальных посещений мы, дизайнеры, должны предоставить пользователю хорошие решения (good user experience). Мы должны завлечь их, описать им, как работает сервис, объяснить им, почему стоит заполнить форму и описать выгоду, которую они от этого получат. И, конечно, мы должны сделать их участие максимально простым.

Тем не менее, разработка дизайна веб-форм — это не простое дело. И здесь есть одна простая причина: никто не любит заполнять формы — ни в оффлайне ни в онлайне. Следовательно, как дизайнеры, мы обязаны найти дизайнерские решения, чтобы сделать заполнение форм делом простым, интуитивным и безболезненным.

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

Ниже мы представляем результаты обзора по текущим паттернам дизайна веб-форм — результат анализа ста популярных веб-сайтов, в которых веб-формы (должны бы) многое значат. Мы решили начать с форм регистрации. Ниже мы представляем первую часть наших исследований, вторая часть результатов обозрения будет опубликована на следующей неделе [прим. перев. — перевод второй части будет позже].

13 ноября, вот уже третий раз в подряд, в рамках «Всемирного дня юзабилити» в Москве прошла открытая конференция WUD 2008. Мероприятие посетило около 200 специалистов. От лица организаторов конференции — сообщества юзабилити-специалистов RusCHI — мы благодарим всех за интерес к вопросам юзабилити и человеко-компьютерного взаимодействия. Конференция традиционно была бесплатной и прошла в помещении компании 1С.

Посмотреть фотографии c WUD 2008 (Flickr)

Сайты авиакомпаний и агентств путешествий: текущее состояние и тенденции (Иван Бурмистров)

Презентация на Slideshare

Юзабилити и транспорт: вести с полей (Екатерина Умнова, Анна Тихонина, Иван Дегтяренко)

Презентация на Slideshare