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

Поэтому очень многие люди переводят содержимое визиток в электронную форму, решая таким образом проблемы доступа (электронная версия может быть скопирована в записную книжку телефона или лежать в месте, доступном через интернет) и поиска.  »Забить» в компьютер данные одной визитки не проблема, однако, когда их несколько десятков, как в примере с конференцией на это может уйти пара часов. Можно пробовать сканировать карточки, есть даже специальные программы, предназначенные для этого, однако их работа несовершенна в силу того, что помимо утилитарного назначения носителя контактной информации, визитка является элементом корпоративного стиля и в силу этого часто создана с использованием сложных шрифтов, нестандартным размещением информации и разными прочими фенечками, которые ставят в тупик сканирующие программы. Поэтому работу таких программ придется проверять и перевводить часть данных, что тоже требует времени. Что же делать? Решение есть, и называется оно QR код.

Картинка выше – QR код моей визитки, сгенерирована с помощью http://zxing.appspot.com/generator/ Этот код мы ставим на обратную сторону нашей креативной и нестандартной визитки и таким образом убиваем 2-х зайцев:

• визитка продолжает являться носителем стиля компании, нет необходимости упрощать ее;
• данные с визитки очень быстро могут быть переведены в электронную форму, я пользовался ридером для iPhone, в силу особенностей баркода количество ошибок сканирования стремится к нулю и данные не требуют проверки и правки

Любители хранить данные в электронной форме скажут вам спасибо!

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

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

Ассоциации дизайнеров Британии справедливо считают такую конкуренции не совсем честной и пытаются воздействовать на университеты через надзорные органы. Чем это закончится пока неизвестно.

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

Вариантов решения проблемы несколько.

1. Оставить все как есть, пусть разработчики сами решают как им быть дальше. Вариант самый простой, но про последствия писать, думаю, излишне.
2. Напрячь разработчиков – пусть пишут «самую лучшую в мире BTS в отдельно взятой конторе». Если клиенты могут подождать, и денег/времени не жалко – отличный вариант.
3. Использовать готовое решение и при необходимости доработать его под свои нужды. Вот на этом, пожалуй и остновимся.

Итак, перед нами стоит задача выбора системы отслеживания ошибок (bug tracking system, BTS) удовлетворяющую следующим базовым требованиям

• Поддержка большого количества проектов
• Удобный и функциональный web-интерфейс
• Наличие интеграции с системами контроля версий
• Поддержка многоязычности
• Учет и планирование рабочего времени
• Организация внутрикомандного взаимодействия разработчиков
• Работа с базами знаний (к примеру, wiki)
• Легкость доработки под нужды компании.
• Легкость установки и сопровождения.

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

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

Open Source разработки представлены добрым десятком проектов. Рассмотрим самые популярные из них.

Итак, список кандидатов:

• Bugzilla
• Mantis Bug Tracker
• Trac
• Redmine

Начнем с Bugzilla. (http://www.bugzilla.org)

Проект достаточно взрослый, первый релиз вышел в 2001 году. Написан на perl. В дистрибутиве debian lenny присутствует, что довольно таки упрощает его установку.

Ставим, смотрим.

Картина, прямо скажем, не очень. Поддержки разных языков из коробки нет (хотя можно загрузить и поставить ручками). Интеграции хотябы с SVN – нет. Wiki отсутствует, как прикрутить – сходу не ясно. Управление правами пользователей довольно неочевидно. Пробуем создать новый проект, пару-тройку багов и понимаем, что до вменяемого вида его еще пилить и пилить.
Смотрим на полсотни перловых скриптов, открываем process_bug.cgi с 2200+ строк перлового кода и молча сносим bugzilla до лучших времен.

Следующий кандидат – Mantis Bug Tracker. (http://www.mantisbt.org)
Написан на php, в установке простой донельзя.

Первое что бросается в глаза – весьма унылый внешний вид. Понятно разработчики настолько суровы, что им в общем-то все равно, как интерфейс сверстан, но ведь есть еще и клиенты, которым иногда тоже нужно открывать баги, принимать участие в обсуждениях.. Идем дальше. Wiki нет, хотя судя по документации некая Docu Wiki к нему прикручивается, интеграциию с svn видимо тоже придется реализовывать кувалдой и сварочным аппаратом. Таймтрекинг присутствует в зачаточном состоянии в виде какого-то плугина. Особенно настораживают многочисленные отзывы о проблемах с unicode. Взглянув на исходники, мысль о переделке или дописыванию рассасывается как по волшебству – около мегабайта слабо струкурированного php кода без малейшего намека на mvc и на стройный api мало кого вдохновит на подобные подвиги. Вывод: лучше не надо.

Trac (http://trac.edgewall.org)

Написан на питоне. Поставился на первый взгляд без особых проблем, но дальшейшие разборки с отдельными модулями и apache преватились в довольно увлекательный квест. Вдоволь наматерившись я его таки поборол, но пожелать подобного развлечения могу разве что конкурентам (и то не всяким). Как впоследствии оказалось, я не один такой счастливчик – 161000 результатов в выдаче гугла по запросу ‘trac install problem’ мягко говоря настораживают.
В целом система довольно приятная, но есть ряд довольно серьезных «но».
Работа с несколькими проектами требует довольно нетривиальных телодвижений, в частности создания отдельного окружения для каждого нового проекта. Когда их 3-5 это еще терпимо, но если 30-50? а 150? Да и python как-то оптимизма не добавляет…
Вывод: проект интересный, перспективный, но не для нас. увы.

Redmine. (http://www.redmine.org)

Написан на Ruby on Rails. Установился влёт – читая документацию, на установку я затратил около 15 минут. Сразу порадовала поддержка целой кучи баз данных – начиная от sqlite и заканчивая postgres. Интерфейс – весьма приятный, кое-где используется ajax, формы читабельные и понятные. В общем – клиенту показать не стыдно. Кстати, из коробки присутствует поддержка около 30 языков (в том числе русский и украинский). Пристуствует встроенный движок wiki, форум, совместногое хранилище файлов. Интеграция из коробки с svn, cvs, git, mercurial и рядом других систем хранения версий. Гибкая и, главное, понятная система разграничения прав доступа пользователей, дополнительных полей в сообщениях об ошибках и проектах. Не найдя сходу к чему придраться, решил заглянуть в код чтобы забраковать по причине сложности доработки, и… Не получилось. Фреймворк RoR вполне оправдал ожидания – MVC во всей своей красе. Представление отделено от логини обработки, логика отделена от данных. Красота.

Погоняв систему в тестовом режиме месяц глюков замечено не было, за исключением проблем с падением mongrel (решено уходом на fastcgi за 10 минут)

Вывод: redmine – наш выбор несмотря на «всего лишь» 3 летний срок существования проекта. Система идеально подходит как и для текущей работы, так и в качестве «трамплина» для разработки своей системы отслеживания ошибок.

1. Рисованный дизайн
Дизайн, что называется «от руки» останется популярным стилем, но только первые пару месяцев 2009 года. Затем такой дизайн постепенно будет перевоплощаться во что-то новое, более свежее, потому как дизайнеры склонны думать, что этот стиль понемногу изживает себя и веет ностальгией 2008 года.

2. Мобильный веб-дизайн
Заход на сайты через мобильные устройства всё ещё занимает малое процентное отношение. Тем не менее, оно будет расти, а сайты с большим трафиком вскоре станут переходить на «облегчённую» версию, например как «iPhone version».
Веб-дизайнерам, которые всегда хотят оставаться на гребне волны следует задуматься о создании мобильной версии сайтов. Ведь каждый пятый пользователь обладает полноценным смартфоном с полнофункциональным веб-браузером.

3. Социальные медиа
Прежде чем начать говорить о социальных медиа, скромно отмечу, что это словосочетание настолько часто повторяется людьми, что стало почти нарицательным. Социальные медиа основываются на идее о том, что каждый отдельный человек может взаимодействовать с другими людьми так, что вместе они чувствуют себя частью некоего сообщества.
По тенденциям 2009 года создать обыкновенный сайт будет недостаточно для клиента. Веб-дизайнеру понадобится определённая стратегия, подразумевающая взаимодействие с какими-либо социальными сетями. Самый простой пример: сделать страницу на MySpace (www.myspace.com) – наибольшая и самая известная из сетей.

4. JavaScript библиотеки
Благодаря популярности и простоте использования JavaScript, всё больше и больше сайтов используют jQuery, которая загружается достаточно быстро относительно других библиотек (200–400мс — существенный выигрыш в скорости).

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

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

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

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

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

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

Автор топика увидел, что сайт его компании, заказанный у каких-то самоделкиных (типа племянника директора) сверстан не по стандартам w3c и указал на это. На что самоделкины сказали: «А зачем нам стандартами заморачиваться? Посмотрите на Гугл и провалидируйте его, он тоже сделан не по стандартам, чем мы/вы хуже Гугла?»

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