Три наших персонажа: программист, дизайнер и клиент.

По просьбам пользователей после прочтения статьи Визуализация данных на CSS

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

Большинство дизайнов ориентировано на использование фиксированных значений при верстке: ширина и высота блоков, размер шрифта. Это позволяет сверстанному шаблону «не разваливаться» при изменении масштабов просмотра и сохранять свойство кроссбраузерности. Однако в этом есть один большой минус – при большом разрешении экрана маленькие фиксированные блоки теряются на большой площади и остаются незамеченными. Тут даже не спасет «резиновая» верстка, т.к. сайт будет выглядеть еще более нечитабельным, например на 19'' мониторах при разрешении большем 1280 по ширине. Для меня это актуально, т.к. на ноутбуке 17'' с разрешением 1400х800 просматривать «резиновый» сайт очень неудобно. И желание оставаться на таком сайте отпадает быстро. Существует ли способ, позволяющий управлять масштабами не только текста, но и всего сайта?

Не знаю как у вас, а у меня давно исчезла мысль о том, что в работе может не быть авралов. Причин множество: неправильная оценка сложности и задач и сроков для их реализации, задержки утверждения документов или предоставления информации по проекту со стороны заказчика, человеческий фактор. А в итоге получаем неподъемное количество работы на пару со стрессом. Причем, не всегда проблемы могут быть внутренние. Сколько раз мне приходилось наблюдать и участвовать в проектах, в которых все идет по плану. Спокойно и размеренно. Функциональность проработана, все необходимые тесты имеются и пройдены, документация написана. И вот остается день – два до сдачи, и… От заказчика приходит гневное письмо, что он изучил последнюю версию продукта и понял, что все не так и надо изменить то-то и то-то, причем сделать это необходимо в кратчайшие сроки.

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

Видеозапись встречи (500 Мб AVI), альтернатива
Презентация от Мио

Начало проекта

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

Хабрареволюция

Первичная концепция сайта была такова, что посты редакции публиковались в разделе «тексты», а посты остальных участников — в разделе «блоги» (?). Однако с течением времени начало нарастать недовольство пользователей неравенство в правах и была совершена «хабрареволюция», при которой каждый пользователь получил право быть полноценным автором.

Сейчас уже много где написано и упомянуто про технику CSS sprites (aka CSS Image Maps). Я не буду открывать Америку и рассказывать о ней дотошно еще раз, а просто хочу привести несколько примеров и полезных ссылок. И пару советов из собственной практики.

Сама техника заключается в том, что мы создаем комбинированное изображение, из которого затем «вырезаем» с помощью свойств background-position нужный нам в данном случае кусок. На текущем уровне поддержки браузерами (я полагаю, что 99,9%) оно является просто must-have для любого уважающего себя интернет-ресурса (ибо позволяет сократить число запросов к серверу, отделить поведение от представления, возложить труд по анимации на CSS-движок браузера, а не на JS-движок, т.е. это будет работать даже с выключенными скриптами, и много-много прочих «вкусностей»). Но обо всем по порядку. Поехали.

читать дальше на webo.in →

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

Я сумел найти для себя оптимальный вариант.

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

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

Проект инициирован и идет полным ходом.
Некая проектная документация для него уже составлена и подходит время для отрисовки дизайна. Менеджер ставит дизайнеру задачу, а через неделю забирает 10 прекрасно нарисованных макетов страниц. Дизайнер старался как мог и потому каждый пиксель в данном дизайне продуман и поставлен на нужное место.
Дизайн передается к верстальщику, который погружаясь в код старается заверстать великолепный дизайн дизайнера с точностью до пикселя. На выходе он по документации выдает 20 заверстанных страниц.
После чего дизайн поступает программистам. Которые собирают проект и теперь это уже не просто статичный дизайн — это работающий интернет-сайт.

Казалось бы просто, но.
Когда через несколько недель после начала сборки проекта до проекта добираются тестировщики, они хватаются за голову. В верстке обнаруживается десятки несоответствий дизайну. Баги сыплются на головы программистов и верстальщика. Следя за сборкой, дизайнер погружается в грусть все глубже и глубже, его состояние на границе отчаяния, а дизайн в забвении (как можно положить “это” в портфолио?!). Верстальщик не прекращает попыток фиксить баги, но они появляются быстрее, чем он успевает их читать.