“Масштабируемый” дизайн
Незаметно изменились требования к макетам современных сайтов - вместе со всеми социальными аспектами, с модой на web2.0, с отношением к рекламе, с развитием технологий и каналов, для которых уже совсем не страшны как раньше большие объёмы тяжёлой графики. Изменились требования к дизайнерам, к уровню знания технологий и к их готовности работать так сказать в ногу с веяниями. “Обратить” же дизайнера-консерватора, рисующего по-старинке фиксированный макет (может, и красивая картинка, но не функциона-альная) - это тяжко и грустно. Вроде и умные люди, и грамотные. А объяснить надо новый мифический дизайнерский термин - “масштабируемый” дизайн. Хочу обсудить два аспекта масштабируемости.
1. Масштабируемость на уровне прототипов или дизайн для бета.
Суть этой проблемы в том, что большая часть сервисов, на которые приходится делать дизайн - они в мир выходят в состоянии беты. Эта ситуация вполне обычна для современного веба, ещё не прошла мода вешать лейблу “beta” возле лого сайта или даже в имени-ссылке (beta.ya.ru) указывать на то, что выпущенная версия - это (неполная? тестовая?) не конечный вариант сервирса. Для дизайнера же в большинстве случаев это означает, что тот эскиз, который он рисует, ->верстает и внедряет на публичный сервис, должен быть, с одной стороны, очень даже модный, эффектный, запоминающийся, лёгкий etc., а с другой стороны - любое расширение функциональности, добавление новых фич, создание глобальных рубрик-информационных блоков, внедрение чего бы то ни было проходило максимально безболезненно для дизайна в целом. Чтобы не пришлось для каждой новой версии беты рисовать новый дизайн, который базируется на перехлёстывающихся блочечках с тенюшечками, скруглёнными уголками, градиентами, которые можно порезать без злостного нарушения композиции в масштабе 1:1 и только, а стоит только перепрорезать очередной блок под большее количество элементов - оп-па, и композиция нарушена, и дизайнер злобно смотрит на верстальщиков и программеров - испохабили шедевр!
Как приноровиться к дизайну для публичных бета-сервисов? Возможно, столь обсасываемый пресловутый стиль web2.0 - это как раз он и есть - квадратно-гнездовой дизайн информационными блоками с акцентом на крупных формах (заголовках, иконках), с как бы оформлением блоков информационных (панели-уголочки-тени), дизайн, с которым добавление на сайт целого раздел, или рекламных блоков, или новых фич - дело техники. При этом примеров подобных решений, довольно приятно визуально оформленных - полно, казалось бы. И вот стопор. Поставить задание дизайнеру с формулировкой “масштабируемый дизайн” и попытаться объяснить, что я имею ввиду. И почему здесь сейчас три раздела и что делать (куда летит его “композиция”), когда добавиться четвёртый, а когда доделается до полноценной беты наш очередной тулз - где и как будет размещаться его реклама и что там будет размещаться сейчас. А может, кстати говоря, и не будет - если тулз купят раньше, чем мы его начнём рекламировать. Все прототипы, на бумаге или с помощью других подручных средств, дают только очень базовую модель будущеё страницы.
А дизайнер рисует ассимитричные формы, где в одной ассиметрии - гармонично так располагаются два доменных раздела, в другой - так же немасштабируемо - пяток главных разделов… Послушай, говорю. Вот у тебя языки - русский/английский, почему? А если придётся (и скорее всего таки придётся) делать fr версию - куда, извиняюсь, и как? Переделывать весь эскиз, весь макет? Но ведь на этот макет завязан не один человек (рисующий дизайнер) - туда же и верстальщик, и программер, т.е. глобальное переделывание эскиза сайта прибавит работы части команды. А если придумать для выбора языков другой… “дизайн”? расположить, реализовать, как-то так, что бы добавить третий язык или даже 50 (каким нибудь псевдокомбобоксом реализованный) - что бы это не нарушало твою “композицию”? И так по каждому объекту макета. Жёсткая привязка к сложному графическому макету использовалась часто на сайтах-визитках начала века, реже - на корпоративных сайтах, но никак не подходит для бета-сервисов нынешнего поколения. Такой вот web2.0
2. Модульные сетки.
Вот раньше было просто - находим сайт по теме, чтобы было максимальное пересечение аудитории, в статистике снимаем показатели по процентам - какие разрешения экрана наиболее популярны. Читаем руководства великих гуру. И изучаем два глобальных типа модульных сеток: фиксированные на размер800х600 (width=770) и резиновые колоночные (width=”100%”). Так можно было угодить и пользователям со (на сегодняшний день) старенькими слабенькими мониторами, и богатеям-буржуям с глобальными диагоналями, сильными видеокартами, и даже аудитория разделялась на “наши товары покупают только очень богатые клиенты, у них давно не используются такие разрешения” и “наши клиенты сидят на 14′ и старых картах, пусть не будет у них горизонтальной полосы прокрутки!”
Сейчас-то всё меняется. Богатые клиенты как раз всё чаще заходят на сайты с устройств с мелкими разрешениями, с всяческих КПК, к примеру. С лёгких, тончайших, воздушных и очень не дешёвых ноутов. И они же (всмысле такие же не бедные) - смотрят с гигантских устройств, с диагональю побольше несущей стены моей квартиры. Каким должен быть дизайн современного сайта, удовлетворяющего изысканные вкусы богатых клиентов? Какой должна быть модульная сетка? Фиксированной? С каким минимальным width? Резиновой? И куда она должна тянуться на разрешения, хотя бы, 1600х1200 (а ведь есть и значительно больше)? А на больших разрешениях - кто нибудь видел, как убого смотрятся эти тоненькие полосочки контента, сделанные с учётом пользователей с малыми разрешениями экрана (и ещё хорошо, когда разработчики дизайна не поленились эту тоненькую тощенькую колоночку центрировать, а если поленились и она выровнена по левому краю - то этого сайта на больших мониторах-разрешениях и не видно)? Как ещё более убого смотрятся резиновые длинные строки - два абзаца в одну строку, прочитать текст - шею свернёшь? Я - видела. Кшмар.
Конечно, можно придумывать сложные решения, когда контент генерируется с учётом разрешения экрана пользователя, и выводить те же две или три-четые колонки в зависимости от значения размера экрана.
Конечно, можно задавать как бы традиционные (2 или 3) колонки, а так же поля и отступы в сплошной динамике - свести этим к максимальной читаемости сетку как для маленьких, так и для высоких разрешений.
Что ещё можно придумать-то? Как научить эту талантливую творческую личность рисовать модный, коммерческий, масштабируемый и функциональный дизайн? Есть ли где-нибудь пособие по обращению художника-дизайнера (со своим видением мира, понятием о композиции и красоте) в успешно практикующего (т.е. настоящего, не придуманного) дизайнера, работы которого продают? Делать-то что? Искать другого, менее талантливого, но более гибкого и динамичного, таксказать, ловящего на лету? слов нет.
Кстати насчёт масштабируемости… было бы неплохо, если бы данный конкретный блог был масштабируемым хоть бы с точки зрения растягивания по ширине. Уж больно много места теряется при больших разрешениях. Остается только маленькая полоска текста… а-ля 1-на колонка газеты за весь лист. Это не есть юзабильно и вообще не гуд…
Точнее рабочая область (белый лист) нормальной (в принципе) ширины, а вот права кусок отъедается меню - а в итоге… итог собственно я и наблюдаю
кстати про масштабируемость. я вот для своего блога решил переверстать шаблон. так вот до конца пока нельзя решить вопрос 100% масштабируемости. обращался к коллегам верстальщикам, решения пока не нашли. вот что я наваял, поисзменяте размер шрифта и поймете, о чем я.
http://makets.lovata.com/webdev.lovata.com/
>Остается только маленькая полоска текста
Так о том и речь - это такой компромисс - чтобы не очень ущербно было для юзеров с очень большими разрешениями (как я понимаю типа как у вас - 1600х1200 и выше), очень малыми (КПК) и средними, обычненькими такими.
Какая альтернатива?
Резина - когда на огромных разрешениях получаем длинные строки? - это зло, и узкая колонка - зло меньшее.
>поисзменяте размер шрифта и поймете, о чем я.
Да, Паш, уже неплохо масштабируется, ровненько так. Но и дефолтовый размер шрифта обхаживать надо - не у всех рука на “Ctrl+” набита.
Т.е. находить решение именно на уровне более гибкой модульной сетки.
Но первая проблема масштабируемости дизайна меня волнует сильнее - в приоритетах выше. Модульные сетки - это уже техника. А вот на уровне идеи, эскиза - здесь мыслить нужно по-другому, другим стилем. И главная печаль в том, что - да, блоги причёсывать надо, но в заметке речь шла о коммерческом дизайне
о дизайне для коммерческого сайта.
да, проблема конечно в идее, мой дизайнер тоже, очень любит всякие коллажи в шапке сайта делать, соответственно, это сразу убивает возможность масштабируемости по ширине.
по поводу компромиссов. я всегда свои макет, если они предусматривают масштабируемость, по ширине в таком диапазоне разрешений 1024-1280. т.к. пользователи с разрешением близким к 1600, часто работаю не разворачивая окно браузера.
Очень меня интерсует вопрос масштабирования по ширине. Вроде бы красиво и удобно, когда есть поля слева и справа. Но и фиксированный размер по центру (крайний случай - по левому краю) имеет свои недостатки на разрешениях отличных от проектируемого. Следовательно остаётся 2 варианта:
1. Проценты - типа давайте оттяпаем с краев по 10, 15, 20% и вроде как хорошо, так ведь нет… не проходит на малых разрешениях.
2. Использование фиксированной ширины, но с привязкой к размеру шрифта… видимо те самые em. Типа чтобы всегда влезало не менее… ну зкажем… 80 символов.
так что же Правильно?! нет ли какого другого варианта?
Zigzag:
Кстати коллажик ведь можно ж как-то наверное масштабировать, если заранее сделать его большого размера. Никто не знает как сделать фоновую картинку (тот самый коллажик) автомасштабируемым с сохранением пропорций под размер блока?
>как сделать фоновую картинку (тот самый коллажик) автомасштабируемым
но моя техника, мягко говоря, в реальной жизни не применима. Суть техники в чём:
Я знаю
делаете дивный блок. В котором слоями бросаете изображения. Которые:
1. В формате png
2. И с градиентной прозрачностью
Но до тех пор, пока не искоренили навсегда IE5-6 такое решение будет нерационально громоздким, потому что придётся использовать кучу хаков, а если js у клиента отключен? Или ещё что-то?
Простая имитация масштабирования коллажика - когда основной рисунок вы ставите картинкой, к примеру, с выравниванием по одному краю, а в блок под эту картинку кладёте подходящий из коллажа градиентный или паттерновый фончик, и тогда ему по обстоятельствам стилями background-image: и этому фоновуму имиджу - position/repeate.
оффтоп. уже дважды такая лажа. писал большой ответ, потом жму кнопку, но в виду автоподстановки логина в поле OpenID, открывается страница авторизации, при нажатии назад, возвращается пустое текстовое поле!
>в виду автоподстановки логина в поле OpenID, открывается страница авторизации
Не красивый глюк. Как поправить - не знаю. Я подумаю, поспрашиваю у знакомых.
пробовал как-то интересный момент - коллажик выводил в виде не фона дивного блока, а обычного img у которого width=100% и heigth не указано вовсе. Чудесно работает, ну в рамках разумного… с учётом искажений при масштабировании, но если изначальна картинка достаточно большая, то это не слишком критично… тут конечно всё зависит от картинки. Вобщем писать поверх можно если сделать абсолютно позиционируемый блок так сказать выше, но вот как учесть его размер по высоте… опять всё упирается в JS видимо.
Зато если нужно просто коллажик - то всё получается тянущимся при любом разрешении/размере окна.
По поводу глюка с OpenID. Первое, что проверила - это версию плагина (к примеру, на SourceForge.net) - вроде последняя. Опции, доступные в настройках плагина, никак не подсказывают, что бы такое поправить, дабы избежать глюка. Ну можно не пользоваться OpenID вообще, а просто по-старинке заполнять поля, или не забывать копировать в буфер обмена предварительно набранный текст чтобы в случае чего. Или подсказать мне что и где я должна поправить в коде движка
>img у которого width=100% - это так же решение нереальное - особенно в частном примере с моим дизайнером. Да и в любом другом дизайне - смысл в коллаже, если он тянется? Качество где? особенно если для коллажа нужен .gif
Меньшие потери при масштабировании размеров картинки в богатых .png -картинках, но всё равно это решение не решение, можно даже не рассматривать серьёзно (во всяком случае в сегменте наших заказчиков).
господа, вы сошли с ума, какое нафиг масштабирование растровой графики?
>какое нафиг масштабирование растровой графики - вот именно, и я о том же.
Ну всё, всё, запинали
Умолкаю
растр… масштабирование… flash! вектор!!!
Belt, очень осторожно надо обращаться с флэшем
Дело не в графике. Можно как-нибудь обсудить особенности графики под порезку.
Проблема, которая важная действительно - новые концепции модульных сеток и связанное с ними новое виденье дизайнером своего будущего макета. Другое.
“Вот у тебя языки - русский/английский, почему? А если придётся (и скорее всего таки придётся) делать fr версию - куда, извиняюсь, и как? Переделывать весь эскиз, весь макет?” -
- чушь пишете, прекращайте работать без ТЗ (!!!), неужели никто не слышал о системном подходе? Если Заказчик меняет ТЗ - то он и должен оплачивать работу по доделке/переделке, да хоть заново всю работу оплачивать и, между прочим, существует ГОСТ для разработки информационной системы (правда 1990, но доля правды в нем есть) - а сайт является информационной системой, и пока не определен полностью функционал, или пока не прописаны все возможности расширения системы - работа идет с риском оказаться у проекта, который выйдет втридорого…
С чего вы такой злой, господин Vlasoff?
Где у меня написано, что заказчик не оплачивает работу по доделке/переделке? Как раз оплачивает. Просто проект(-ы, их несколько) запущен в доступное пользователям состояние в первой бете - самый-самый основной каркас, базовый механизм. По ходу дела конечно и функциональность дорабатывается, и глюки ловятся, кстати говоря частично силами самих пользователей. У нас всё нормально. У нас просто есть определённые требования к дизайну и дизайнеру.
А вы всё веб-дизайн, смотрю, гостами 1990-го года меряете :):) Достойно, браво.
я не вовсе злой, извините, если так показалось)))
я не меряю веб-дизайн гостами 1990 - не надо передергивать и переходить на личности
я говорю о необходимости системного подхода при разработке и эффективности разработки
я говорю о грамотном составлении ТЗ и правильной организации работы дизайнера
а все оправдания неумения это сделать - смешны
Да, всё правильно - я тоже об этом всё время говорю. Этот блог ещё молодой - и двух месяцев нет, читатели nundesign.livejournal.com и подписчики рассылки в курсе - только об этом и пишу.
И дело даже не в том, что заказчик оплачивает хронический редизайн.
И разумеется, мне не смешно.
ну значит мы нашли общие точки)