За много лет работы в области web-разработки мне приходилось сталкиваться с самыми разными проблемами на этапе создания и отладки сайтов. Многие технические и идеологические проблемы многократно упоминались в различных статьях, но одна очень часто встречающаяся проблема кажется мне незаслуженно обойденной вниманием. Это учет длины строковых данных, которые будут присутствовать в элементах сайта. Речь о названиях рубрик, пунктах меню, данных во всевозможных списках, описаниях, всплывающих подсказках и так далее. Учесть все эти вещи — сложно. Но если не учесть, сложностей может оказаться еще больше. Статья предназначена, скорее, для фрилансеров или небольших групп разработчиков, где процесс разработки менее формализован, а каждый (в том числе — сомнительный) клиент более ценен, чем для более крупных web-студий. Пригодится она и тем, кто занимается web-разработкой, сидя в IT-службах крупных компаний, не желающих отдавать создание своих сайтов на сторону.
Бывает, конечно, что разработка идет по совершенно ясному плану, заказчик четко выражает свои требования, а все исполнители (дизайнеры, верстальщики, программисты, аналитики) работают сообща, имея точное представление о работе друг друга. Но бывает так не всегда, и именно об этом «не всегда» и пойдет далее речь.
Ситуация неполного понимания между участниками проекта часто ведет к тому, что заказчик сначала плотно работает с дизайнером, а потом, имея на руках нравящийся ему дизайн, идет к верстальщикам и программистам. Это происходит обычно по двум основным причинам: во-первых, заказчику проще выражать свои мысли, опираясь на визуальный ряд (дизайн), а во-вторых, большинство людей представляют себе сайт, как «интерактивные картинки и текст», за которыми где-то в глубине прячется код, движок, база данных и прочее. При том небольшие группы разработчиков, боясь спугнуть клиента, могут не слишком противиться такой сложившейся практике.
Вот в этот момент ответственность за то, чтобы все данные поместились в отведенные им места, и возлагается неявным образом на несчастного дизайнера.
Заказчик говорит: «Мне нужен макет красивого магазина стройматериалов». Дизайнер осведомляется, сколько там будет корневых категорий, и получив число от пяти до семи, рисует горизонтальное меню с выпадающими подпунктами. А дальше все это обрастает украшениями, тенями и прочим. Заказчик ведь уже имеет опыт торговли на ближайшем рынке стройматериалов и знает, что если не сделать аппликацию из оранжевых самоклеящихся ценников «Стеклоблоки дёшево», на его контейнер внимания никто не обратит.
А уже потом, на этапе заполнения каталога, выясняется, что корневых разделов у него будет двадцать…
На самом деле, разбираться с этой проблемой может начать и сам дизайнер. В случае, если в его интересах не заниматься переделкой и подгонкой макета (если он — фрилансер, которого ждет следующий проект), ему самому стоит более тщательно опросить заказчика о будущем содержимом сайта и сделать из этого соответствующие выводы.
Если же разработкой занимается группа, то им заранее стоит определить, кто из них должен брать на себя аналитическую работу такого рода. При том, это может зависеть еще и от того, что есть у заказчика на данный момент. Если он уже занимается «оффлайновой» торговлей, то у него, возможно, уже имеется своя система складского учета (пусть даже это будет файлик в Excel) и проанализировать ее будет проще человеку с навыками программирования. Если все начинается с нуля — тут для роли аналитика может быть критичной возможность уделить на это максимальное время или понимание предметной области, к которой будет относиться сайт.
Главное сырье для аналитической работы в этом направлении — текст. Соответственно, главное, что нужно сделать сначала — это получить искомый текст. Будь то база существующего сайта (если задача — создание новой версии), выгрузка из складской программы, либо просто набитые в электронном виде примеры строк из блокнотных записей во время беседы с заказчиком. Если есть другие сайты аналогичной направленности — примеры данных оттуда.
Все это стоит разложить по отдельным таблицам, соответствующим разным видам данных: все те же названия разделов, текстовые описания товаров и тому подобное.
Следующей составляющей задачи является определение минимальной и максимальной возможной длины внутри каждого типа. Программистам я советов давать не стану — каждый и так, наверняка, знает десяток способов это сделать любимыми средствами. А для тех, чья область деятельности — графический редактор или редактор HTML, даю простой рецепт:
В итоге мы получаем таблицу, в которой строки отсортированы по длине. Все, что в середине, скорее всего, не представляет интереса. Важны самые короткие и самые длинные строки, вот их-то и стоит иметь под рукой дизайнеру, а потом и верстальщику, чтобы заполнять именно ими кнопки, пункты меню, блоки описаний и так далее.
Если сайт представляет собой магазин — обязательно нужно уделить внимание и тому, что сложно проанализировать способом, который описан выше — размерам полей для вывода количества товаров и цен.
Компактный блок корзины может выглядеть в макете красиво, но если средний чек в магазине ожидается семизначным (покупатель ведь может выбрать, например, не целое число погонных метров линолеума, от чего цена будет заканчиваться на ",50"), а место есть только под пять цифр, это будет очевидной ошибкой.
Еще одним немаловажным моментом может быть внесение ограничений на длину в приложение к техническому заданию и документацию к сайту. Это может избавить от необоснованных претензий, если заказчик все же умудрится потом вбить нечто такое, из-за чего все будет выглядеть недостойным образом.
Представить себе эффект от отсутствия такого анализа очень просто. Вообразите себе последствия того, что в макете нарисованы кнопки с графическим фоном (какие-нибудь сложные завитушки), на которых написано: «Жалюзи», «Обои». А при загрузке реальной базы туда попадает надпись: «Сверла для перф. SDS-MAX пр-во Bosch», при том таких строк будет много.
Или наоборот — дизайнер забил в текст описания пару страниц традиционного «Lorem ipsum...», а у заказчика больше одного предложения там не было и не предвидится, а потому на странице будет зиять дыра пустого пространства.
Объяснить заказчику, что все эти проблемы вызваны его данными — можно. Но он ведь все равно хочет, чтобы его сайт был не менее красив, чем продемонстрированный ему в начале графический макет, и что-то делать с этим все равно придется.
Заказчик, конечно, может отказаться идти навстречу с предоставлением данных для предварительного анализа, ссылаясь на самые разные причины. И уж тут дело исполнителей — отказаться от сотрудничества (неадекватный заказчик может создать проблем на сумму, которая сильно превышает сумму в договоре), или пытаться обойти «мины», закладывая в дизайн и верстку решения на случай необходимого масштабирования, перенос строк, обрезку блоков. Стоит только иметь в виду, что если требования к сайту все же не включают минималистический дизайн, но включают еще и совместимость со всяким старьем, такие попытки предусмотреть всё могут вылиться в немалые затраты труда.
Пусть дизайнер решает...
Бывает, конечно, что разработка идет по совершенно ясному плану, заказчик четко выражает свои требования, а все исполнители (дизайнеры, верстальщики, программисты, аналитики) работают сообща, имея точное представление о работе друг друга. Но бывает так не всегда, и именно об этом «не всегда» и пойдет далее речь.
Ситуация неполного понимания между участниками проекта часто ведет к тому, что заказчик сначала плотно работает с дизайнером, а потом, имея на руках нравящийся ему дизайн, идет к верстальщикам и программистам. Это происходит обычно по двум основным причинам: во-первых, заказчику проще выражать свои мысли, опираясь на визуальный ряд (дизайн), а во-вторых, большинство людей представляют себе сайт, как «интерактивные картинки и текст», за которыми где-то в глубине прячется код, движок, база данных и прочее. При том небольшие группы разработчиков, боясь спугнуть клиента, могут не слишком противиться такой сложившейся практике.
Вот в этот момент ответственность за то, чтобы все данные поместились в отведенные им места, и возлагается неявным образом на несчастного дизайнера.
Заказчик говорит: «Мне нужен макет красивого магазина стройматериалов». Дизайнер осведомляется, сколько там будет корневых категорий, и получив число от пяти до семи, рисует горизонтальное меню с выпадающими подпунктами. А дальше все это обрастает украшениями, тенями и прочим. Заказчик ведь уже имеет опыт торговли на ближайшем рынке стройматериалов и знает, что если не сделать аппликацию из оранжевых самоклеящихся ценников «Стеклоблоки дёшево», на его контейнер внимания никто не обратит.
А уже потом, на этапе заполнения каталога, выясняется, что корневых разделов у него будет двадцать…
Если не дизайнер, то кто?
На самом деле, разбираться с этой проблемой может начать и сам дизайнер. В случае, если в его интересах не заниматься переделкой и подгонкой макета (если он — фрилансер, которого ждет следующий проект), ему самому стоит более тщательно опросить заказчика о будущем содержимом сайта и сделать из этого соответствующие выводы.
Если же разработкой занимается группа, то им заранее стоит определить, кто из них должен брать на себя аналитическую работу такого рода. При том, это может зависеть еще и от того, что есть у заказчика на данный момент. Если он уже занимается «оффлайновой» торговлей, то у него, возможно, уже имеется своя система складского учета (пусть даже это будет файлик в Excel) и проанализировать ее будет проще человеку с навыками программирования. Если все начинается с нуля — тут для роли аналитика может быть критичной возможность уделить на это максимальное время или понимание предметной области, к которой будет относиться сайт.
И что же делать?
Главное сырье для аналитической работы в этом направлении — текст. Соответственно, главное, что нужно сделать сначала — это получить искомый текст. Будь то база существующего сайта (если задача — создание новой версии), выгрузка из складской программы, либо просто набитые в электронном виде примеры строк из блокнотных записей во время беседы с заказчиком. Если есть другие сайты аналогичной направленности — примеры данных оттуда.
Все это стоит разложить по отдельным таблицам, соответствующим разным видам данных: все те же названия разделов, текстовые описания товаров и тому подобное.
Следующей составляющей задачи является определение минимальной и максимальной возможной длины внутри каждого типа. Программистам я советов давать не стану — каждый и так, наверняка, знает десяток способов это сделать любимыми средствами. А для тех, чья область деятельности — графический редактор или редактор HTML, даю простой рецепт:
- таблицу со строками загружаем в OpenOffice Calc
- выбираем ячейку справа от первой ячейки со строкой
- в input line вводим =LEN(номер ячейки слева, например — A1) и жмем на зеленую галку, после чего в самой ячейке вместо формулы появляется число — длина строки в символах
- «растягиваем» эту ячейку вниз за ее нижний правый угол по всей длине таблицы со строками и получаем значения длины для всех ячеек
- выделяем столбец со значениями длины и жмем «сортировать», после чего Calc спросит, расширить ли ему диапазон сортировки, на что нужно ответить положительно
В итоге мы получаем таблицу, в которой строки отсортированы по длине. Все, что в середине, скорее всего, не представляет интереса. Важны самые короткие и самые длинные строки, вот их-то и стоит иметь под рукой дизайнеру, а потом и верстальщику, чтобы заполнять именно ими кнопки, пункты меню, блоки описаний и так далее.
Если сайт представляет собой магазин — обязательно нужно уделить внимание и тому, что сложно проанализировать способом, который описан выше — размерам полей для вывода количества товаров и цен.
Компактный блок корзины может выглядеть в макете красиво, но если средний чек в магазине ожидается семизначным (покупатель ведь может выбрать, например, не целое число погонных метров линолеума, от чего цена будет заканчиваться на ",50"), а место есть только под пять цифр, это будет очевидной ошибкой.
Еще одним немаловажным моментом может быть внесение ограничений на длину в приложение к техническому заданию и документацию к сайту. Это может избавить от необоснованных претензий, если заказчик все же умудрится потом вбить нечто такое, из-за чего все будет выглядеть недостойным образом.
Что это дает?
Представить себе эффект от отсутствия такого анализа очень просто. Вообразите себе последствия того, что в макете нарисованы кнопки с графическим фоном (какие-нибудь сложные завитушки), на которых написано: «Жалюзи», «Обои». А при загрузке реальной базы туда попадает надпись: «Сверла для перф. SDS-MAX пр-во Bosch», при том таких строк будет много.
Или наоборот — дизайнер забил в текст описания пару страниц традиционного «Lorem ipsum...», а у заказчика больше одного предложения там не было и не предвидится, а потому на странице будет зиять дыра пустого пространства.
Объяснить заказчику, что все эти проблемы вызваны его данными — можно. Но он ведь все равно хочет, чтобы его сайт был не менее красив, чем продемонстрированный ему в начале графический макет, и что-то делать с этим все равно придется.
А что, если не выйдет?
Заказчик, конечно, может отказаться идти навстречу с предоставлением данных для предварительного анализа, ссылаясь на самые разные причины. И уж тут дело исполнителей — отказаться от сотрудничества (неадекватный заказчик может создать проблем на сумму, которая сильно превышает сумму в договоре), или пытаться обойти «мины», закладывая в дизайн и верстку решения на случай необходимого масштабирования, перенос строк, обрезку блоков. Стоит только иметь в виду, что если требования к сайту все же не включают минималистический дизайн, но включают еще и совместимость со всяким старьем, такие попытки предусмотреть всё могут вылиться в немалые затраты труда.
