Примечание: ниже расположен перевод заметки Image Optimization, Part 3: Four Steps to File Size Reduction от Stoyan Stefanov. В ней рассматриваются наиболее популярные консольные утилиты для минимизации изображений. Мои комментарии далее курсивом.
Об авторе: Stoyan Stefanov работает веб-разработчиком в команде Yahoo! по исключительной производительности и руководит разработкой инструмента для анализа производительности — YSlow. Он также внес значительный вклад в программы, разрабатываемые с открытым исходным кодом, выступает на конференциях и является техническим писателем: его последняя книга озаглавлена Объектно-ориентированный JavaScript.

Эта третья часть серии статей, посвященных оптимизации изображений (в первых двух была сплошная вода, но на досуге почитать интересно). С предыдущими частями можно ознакомиться по ссылкам:

• Оптимизация изображений, часть 1: важность картинок
• Оптимизация изображений, часть 2: выбираем нужный формат файлов

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

Проблема

На многих сайтах я наблюдаю следующий процесс:

1. Пользователь заходит на сайт
2. Пользователь находит что-то, что он хочет купить/скачать/сохранить
3. Пользователь переходит на страницу регистрации
4. Пользователь вводит свою информацию и ждёт письма с ссылкой активации
5. Пользователь получает письмо и переходит по ссылке
6. Пользователь попадает либо на страницу активации, либо на страницу логина, либо на страницу, откуда он начал регистрацию
7. Пользователь снова находит то что он хотел купить/скачать/сохранить
8. Пользователь покупает/скачивает/сохраняет

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

Решение

Сегодня я смотрела видео с презентации одного из мемберов команды 37 signals о том, как они, оставаясь маленькой компанией (из 12 человек), не привлекая венчурные инвестиции, умудряются успешно продавать свой продукт и быть чертовски прибыльными.

Обобщая идею презентации могу сказать следующее:

1. Создайте хороший продукт
2. Установите разумную цену
3. Попросите ваших пользователей заплатить за него

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

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

Несмотря на то, что некоторыми это может рассматриваться как инсайдерская информация – нам нечего скрывать:

//2500 пользователей пользуются нашими платными услугами

2500 пользователей платной услуги получаются при допущениях:
V нашего рынка = 1000 000 пользователей (согласно проведенному нами
исследованию)
Мы занимаем 5% рынка = 50 000 пользователей
5% из них пользуется нашими услугами = 2500 пользователей. (это 25% от 1% ;))

#1 вариант#
базовый: от 5 у.е. — 50% пользователей
средний: от 10 у.е. 40% пользователей
продвинутый: от 15 у.е. — 10% пользователей
1250 * 5 + 1000 * 10 + 250 * 15=
6250 + 10 000 + 3750 = 20 000 у.е. месяц
***дальше по тексту без расшифровки

#2 вариант#
базовый: от 5 60%
средний: от 10 30%
продвинутый: от 15 — 10%
7500 + 7500 + 3750 = 18 750 месяц

#3 вариант#
базовый: от 5 70%
средний: от 10 20%
продвинутый: от 15 — 10%
8750 + 5000 + 3750 = 17 750 месяц

#4 вариант#
базовый: от 5 75%
средний: от 10 20%
продвинутый: от 15 — 5%
9375 + 5000 + 1875 = 16 250

Как видите, при любом раскладе получается весьма неплохо. Это не сотни миллионов, которыми воротят ключевые игроки рынка, но это неплохие деньги для начала.

Возвращаясь к идее 37 signals: у вас есть оооочень маленькие шансы стать еще одним facebook’ом, myspace или google. Они есть, но совсем небольшие. Кроме того, даже эти компании не стали «звездами за 1 ночь», а развивали свою базу пользователей постепенно, пусть и очень большими шагами.

А теперь спросите себя: готовы ли вы переработать свою стратегию таким образом, чтобы ваш бизнес действительно приносил деньги, а не имел виртуальную стоимость (как происходит со многими стартапами, которые потом покупают)? Если да, то вперед!
Я думаю, что мы свой выбор уже сделали.

Готовим макет для клиента. Часть I: Гладить или нет?

Часть I: Гладить или нет?
Часть II: Если гладить, то как?

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

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

Важно другое. Верхняя половина с шапкой из нереально синего неба, чрезмерно зелёной травки, блестящих хромированных небоскрёбов и пластмассовых людей с приклеенными улыбками — всё это очень нравится клиентам, и сами дизайнеры пузырятся от гордости, показывая подобные коллажики своим коллегам. А вот нижняя половина… Тут, в большинстве случаев, как раз всё очень и очень уныло.

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

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

Всем уже давно понятно, что от мобильников никуда не деться, и как следствие, никуда не деться от того, что ваш блог будут читать с экрана мобильного телефона. И пусть мой блог с мобильника посещают не более 10 человек в месяц, я таки решился на то, что бы сделать мобильную версию. Но так-как я ленивый до невозможности, я нашёл способ сделать приемлемую мобильную версию за очень короткое время. Причём не только блога, но и любого сайта, который отдаёт RSS поток.

Site Helper(SH) – тулза для помощи верстальщикам, а также хороший инструмент для общения верстальщик-программер-руководитель, а так же руководитель-клиент «не отходя от сайта» незаметно для обычных пользователей и в реальном режиме времени.

Наверное, каждый, кто хотя бы разверстал пиксель в пиксель под каждый браузер, сталкивался с ситуацией, когда что-то едет, не совпадают высоты ширины блоков… ситуация знакомая.
Тут может спасти PixelPerfect или сетка разметки на js или SH ;)

Ещё очень распространенная ситуация, когда заказчик или тестер нашел баг и не может понятно объяснить, где он находится. Ну, или заказчик решил добавить блок баннеров и также не может внятно объяснить, что и куда.

После того, как я опубликовал давече тему о создании макета страницы, нам с тов. CurlyBrace пришла в голову одна интересная мысль: а не сделать ли того, что мы умеем делать лучше всего?

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

Внимание: топик не содержит WYSIWYG!

Вы не поверите, но в 85-м году компания Apple в своем руководстве для разработчиков прямо призывала всегда, когда это возможно, стараться заменять надписи пиктограммами. Якобы пиктограммы понятнее начинающему пользователю, чем слова. Конечно, это полная чепуха. Словами намного проще высказать почти любую идею.

Если только вы не проектируете интерфейс графического редактора В этом случае, как говорится, лучше один раз увидеть, чем сто раз прочитать:

Нижние 6 иконок прямо изображают результат применения соответствующих инструментов.

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

Очень часто приходится видеть варианты элемента управления «аккордеон» на различных сайтах. В этой заметке я хотел бы предложить свой вариант, который кроме того, что обладает некоторыми оригинальными свойствами, еще и весит в minified-виде всего 618 байт. Заодно, я покажу как быстро написать простейший плагин для jQuery.

Забегая в перед скажу, что плагин тестировался в Firefox 3.0.3, Internet Explorer 7 и 8b2, Opera 9.52 и Chrome 0.3.154.9. Во всех других браузерах работоспособность гарантируется настолько насколько в них работает jQuery.

Для любопытных приведу пример того, что будет в итоге (ссылки и кнопки в примере не работают).

Приветствую тебя, Хабрачеловек.

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

Итак.

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

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

Исследовательское подразделение Microsoft Research в Кембридже провело апгрейд фирменного интерфейса Surface. Новый прототип называется SecondLight. Как можно наблюдать в демонстрационном видео (WMV), если над столом держать какой-то непрозрачный материал, то на нём будет уже другая картинка.



Таким образом, мы получаем два экрана. Например, на столе можно демонстрировать спутниковую карту местности, а на лист вверху проецировать названия улиц. Или на столе — изображение автомобиля, а если проводить над ним лист — то там будут показываться его конструкция изнутри.

На днях мне потребовалось установить движок для англоязычного блога. Проблема в том, что хостинг (VPS с объемом памяти 256 Мб) не тянет WordPress версии 2.6, а в 2.0.11 (которая, возможно, и заработала бы) работают не все нужные мне плагины. В общем, я решил посмотреть, какие сейчас существуют легкие CMS, причем на основе CodeIgniter, как наиболее быстрого и потребляющего мало памяти фреймворка PHP. Требования по функционалу у меня достаточно простые: возможность ведения блога, желательно с SEO-примочками (прописывание заголовков, мета-тегов, генерация Google Sitemap).

Занимательные поделки от Джонатана Снука. Данная статья будет интересна скорее новичкам, нежели более умудренным разработчикам, хотя мистер Снук достаточно авторитетен и его методики могут быть полезны всем.

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

Выкладываю фреймворк, написанный для себя.
Причина создания: надоело каждый раз при верстке нового сайта заниматься одним и тем же — переделывать мой любимый Tripoli (исправляя его баги, добавлять свойства разметки); добавлять JS-фреймворк jQuery, создавать типичную HTML-структуру. Решил объединить часто используемые мной элементы в единое универсальное целое.
Делал для себя, то есть — аккуратно и хорошо.

Отсебятина

А вот и перевод третьего урока по Google Maps API. Этот урок — как видно из названия — посвящен созданию карт при помощи данных, хранящихся в БД. Как и предыдущие — кросс-пост из моего блога.

jQuery — это замечательный JavaScript Framework, который подкупает своей простотой в понимании и удобством в использовании. Но изучение надо с чего-то начинать, и лично моё мнение — лучше всего начинать с наглядных примеров, и они далее…

Dompdf — класс написанный на PHP 5 для преобразования HTML в PDF.
Проблема конвертации html в pdf встречается не так часто, но все же возникает у некоторых веб-мастеров.