Линкотека №5. Дизайн веб-интерфейсов. 6
Сегодня подборка интересных ссылок по теме дизайна пользовтельских интерфейсов, или как говорят на «буржуйском» User Experience Design.
UI-patterns — коллекция типовых решений (примеров) и скриншотов для создания веб-интерфейсов. Хорошо отсортирована. Будет полезна для вдохновения или поиска готового решения.
Quince UX Design Patterns Listing — еще одна подборка подобная предыдущей, но тут более детальное описание каждого примера и дополнительные иллюстрации.
UX Booth — блог о юзабилити и вообщем интерфейсах. Проводят периодически публичное юзабилити–тестирование разных сервисов и пишут критику.
Product Planner — онлайн–сервис, позволяющий группе разработчиков описывать движение (навигацию) по страницам сайта (user flow на буржуйском). Сервис этот не сложный, функционал довольно ограниченный, но со своей узкой задачей справляется отлично.
I ♥ wireframes — блог сербской девушки веб-дизайнера, собирающей фотографии и скриншоты wireframes (не знаю как перевести) и процесса их создания, которые используются для прототипирования интерфейсов. Хороший ресурс для вдохновения, особенно если вы еще толком не пробовали проектировать интерфейсы.
Пятерки считаю вполне хватит для первого поста на тему интерфейсов. Дальше будет меньше ссылок и больше личной писанины.
Буду рад, если напишите в комментариях какие ссылки оказались наиболее полезными. Это поможет мне определиться о чем написать следующий пост.
Твиттер или каждый день по пять копеек
Ну кого я удивлю такой темой? Удивлять не буду. Все знают про твиттер! Нет? загляните тогда в гугл.
А написать я хочу про несколько правил, которым следую публикуя информацию в твиттере и общаясь в этой среде. Оговорюсь про терминологию. Хорошее английское слово follow трудно перевести удачно в контексте твиттера, поэтому я буду употреблять слово «френдить», такой себе ЖЖ-шный слэнг :-)
По каким критериям я оцениваю френдить человека или нет:
- на сколько часто он пишет (для меня оптимально читать не больше 10 твитов в день от каждого френда);
- тематика само-собой, но важнее интересная подача и оригинальный контент;
- если у него число читателей меньше хоть в половину, чем число людей кого он читает, настораживает;
- больше хочется читать человека, пишущего свое, с меньшим кол-вом ответов на чужие твиты (reply);
- интересный профайл и ссылка на персональный веб-сайт — самый главный критерий, пожалуй.
Про что пишу сам:
- веб-разработка (еще бы!);
- фотография;
- mac/unix;
- немного личного.
Так что если мы еще не френды в твиттере, напишите мне :-)
Веб-стандарты и компромиссы
Всю жизнь человека преследуют компромиссы. Даже самые принципиальные люди, желающие жить в обществе, понимают, что есть моменты в которых компромисс просто необходим.
В мире веб-разработки да и вообще программирования компромиссы встречаются не менее часто. Хоть это и виртуальный мир окон, диалогов и кнопок, стоят за ним вполне реальные люди.
Об одном из таких компромиссов я хотел бы сегодня рассказать. Любой веб-разработчик знает про существование веб-стандартов, придуманных, как и любой стандарт, для облегчения работы и координации множества людей при выполнении схожих или одинаковых задач. Весь веб построен на стандарте HTML, и я думаю, что 99% веба работает с использованием CSS. HTML и CSS — две главные технические составляющие дизайна любого веб-сайта. Но как известно, мало кто из дизайнеров пользуется веб-стандартами (HTML/CSS) для создания дизайна, у них есть свои инструменты (графические редакторы) для решения этой задачи.
Процессом превращения картинок дизайна в HTML/CSS представление занимаются как раз выше упомянутые веб-разработчики, процесс этот называется версткой.
Вот в момент этого магического «превращения» картинок в сайт возникает проблема или правильнее сказать дилема.
HTML сам по себе не служит для создания стиля или дизайна, это в первую очередь документ,
его цель донести до пользователя содержимое (контент). Я уже писал про семантику, не буду повторяться в рамках этой статьи.
Перехожу к сути. Для настройки стиля (читай дизайна) HTML-документа в веб-стандартах предусмотрено использование CSS. Часто возникает ситуация, при которой в HTML документ попадает избыточное кол-во элементов, которые не несут никакого содержимого для пользователя, а используются только в CSS для придания стиля/дизайна документу. Это некорректно с точки зрения семантики HTML. Но это не так страшно. Более серьезная проблема в том, что частенько приходится нарушать сам стандарт разметки документа (HTML) ради придания ему определенных стилей (через CSS). Профессионалы называют это на сленге «невалидный код», от английского «valid — верный, корректный».
Нельзя сказать что валидный HTML очень важен для работы пользователя. На самом деле браузеры вполне хорошо обрабатывают документы с ошибками. На сегодня это вопрос скорее всего принципиальный и технологический. Является ли корректность кода обязательной — тема для отдельной статьи. Я просто кратко выражу личное мнение. Для больших, посещаемых сайтов корректность HTML-кода важна, т.к. ими пользуются не только люди, но и роботы, т.е. компьютерные программы, которые автоматизируют какие-то действия. Например, делают экспорт новостей с крупного новостного сайта для автоматической рассылки по смс. В этом случае ваш HTML код будет выступать в роли своеобразного API. Но это лишь один из примеров важности корректного HTML-кода.
Так вот теперь о компромиссах. Есть еще не упомянутая сегодня веб-технология JavaScript. С помощью JavaScript и DOM можно в момент загрузки страницы браузером корректировать ваш код. В нашем случае интересует именно HTML. Так вот это и есть простой и эффективный компромисс, модифицировать готовый корректный HTML с целью добавления элементов, которые используются чисто для дизайна. При относительно небольшом кол-ве таких элементов, скорость загрузки/отображения страницы для пользователя останется незаметной.
В ближайшем будущем попробую написать заметку почему важна валидность кода. В ней попробую привести примеры «компромиссного» кода и замерить скорость его работы.
PS: статья получилась довольно общая и возможно не совсем интересная для «бывалых», но это только первая статья из серии посвященной веб-стандартам. To be continued...
