← Февраль 2006 → | ||||||
1
|
2
|
3
|
5
|
|||
---|---|---|---|---|---|---|
6
|
7
|
8
|
9
|
10
|
12
|
|
13
|
14
|
15
|
16
|
17
|
19
|
|
20
|
21
|
22
|
23
|
24
|
25
|
26
|
27
|
28
|
За последние 60 дней ни разу не выходила
Сайт рассылки:
http://design.i2r.ru
Открыта:
24-10-2001
Адрес
автора: inet.webbuild.libraryi2r-owner@subscribe.ru
Статистика
0 за неделю
Библиотека Вебстроительства - новости, статьи, обзоры
БИБЛИОТЕКА CАЙТОСТРОИТЕЛЬСТВАновости, статьи, обзоры | ||
| ||
| ||
Adobe, как и обещали, стабильно сообщают о доработках и разработках, из последних сообщений - бета-версия Flex и адаптация пакетов программ для старых и новых Mac`ов. Компания IT-Online объявляет об интересном однодневном семинаре - "Проектирование пользовательских интерфейсов", автор и ведущий семинара - Дмитрий Сатин, расскажет о принципах дизайна для программ и веб-сайтов, о юзабилити интерфейсов и решении типовых программ. Лично мне было бы очень любопытно посетить семинар, но до Москвы от меня не близко, а вопросов хотелось бы задать много, поскольку действительно приходится заниматься разработкой как веб-сайтов, так программных интерфейсов. И я точно знаю, что мнение разработчиков и пользователей о том, как должен выглядеть интерфейс приложения, веб или клиентского, очень сильно отличаются. Имеют свое авторитетное мнение по сему вопросу и рекламодатели. Так, в частности, в AdSense.blogspot.com опубликована заметка для блогеров, советуют, как оптимально разместить рекламу на сайте. Помимо адсенсовских частностей можно наблюдать упрощенные схемы "золотого треугольника", которые работают не только для AdSence, но и для любых рекламных блоков. Интересная новость, которая всю неделю обсуждается сетевым сообществом - в российском законодательстве о СМИ планируется ряд изменений, в частности, это касается онлайновых СМИ, информагентств. Как это коснется всех информационных сайтов и чем обернется в конечном итоге, пока не ясно, правки в закон на стадии обсуждения, подождем. А об информационных сайтах мы поговорим сегодня, но не о законодательной составляющей, а о разработке. Многочисленные советы по оптимизации и продвижению веб-сайтов в сети в конечном счете сводятся к одному: содержание, уникальный и востребованный контент рулит. Визуальный дизайн, стерильная верстка, бэклинки - это вторично. Как следствие - более ясное понимание и заказчиками, и самими разработчиками того факта, что любой проект, будет это новостийный, корпоративный или личный сайт - он должен быть прежде всего *информационный*, т.е. должна быть система, которая позволяет быстро и легко вносить изменения и добавления на сайт. По-видимому именно поэтому такой популярностью пользуются блоги - в любой момент, в любом объеме вы получаете возможность изменить или добавить контент, а любая информация, текст, фотографии, иллюстрации, аналитические заметки или мысли в слух - это потенциальная возможность привлечь потенциальных же читателей, а для коммерческих сайтов - и покупателей, заказчиков Сервисы дневников-блогов известны на сегодняшний день самые разные, от заслужено популярного ЖЖ до малоизвестных экспериментальных, платных или бесплатных, буржуйских или региональных, однако те из вас, мои дорогие читатели, которые уже ведут свои блоги (а многие, я знаю, не один и экспериментировали с разными сервисами и разными движками) знаю, что в любом готовом решении всегда чего-то не хватает, всегда хочется добавить какую-то полезную фичу, что-то изменить, доработать. Так же многих в готовых решениях более чем устраивает тот факт, что большая часть известных на сегодняшний день блог-сервисов является еще и хостингом для блогов - тот же livejournal успешно решает за своих пользователей проблему с выбором - где, у кого и как , на каких условиях арендовать площадку для своих дневников. Это понятно. Уже частично отличается ситуация, когда владельцы сайта осознают необходимость в хостинге, в аренде своего пространства для проекта - тогда есть три варианта:
Я, к примеру, не знаю ни одного бесплатного или условно бесплатного движка, который бы устраивал меня полностью, если знаете вы - пожалуйста, поделитесь информацией. Большинство же разработок - достаточно глючные, дырявые и негибкие, т.е. переводя на русский язык - соглашаясь на использование халявы, вы должны быть готовы к тому, что в любой момент в любом месте может произойти сбой, или же обнаружится уязвимость в безопасности, или - самая распространенная проблема - вы просто не можете оптимизировать готовое решение под свои нужны. Впрочем, если вы не слишком придирчивы, почему нет? Поликарпов Роман на cвоем сайте опубликовал хороший обзор бесплатны cms, можете ознакомиться. Что касается коммерческих решений - есть много интересных разработок, довольно гибких, многофункциональных, разработчики которых постоянно совершенствуют свое детище, саппорт уведомляет своих клиентов о новых апдейтах - некоторые из известных мне CMS действительно хороши, их можно было бы успешно использовать для ваших (моих) информационных проектов, но... цена. Как правило хорошая CMS, как вы и сами знаете, изрядно стоит. Настолько дорого, что первая мысль, которая приходит в голову - разработать СВОЮ систему
управления содержанием, СВОЙ движок, при этом он будет заточен именно под конкретные задачи проекта (правда конкретные задачи у большинства информационных проектов чаще всего одинаковые), разработать самому (или в соавторстве с соседом-программистом) или же заказать. И тут... Прежде всего вам придется поставить задачу. Себе ли, или вашим разработчикам, но вы попытаетесь составить некую схему, систему требований к движку, да так, чтобы учесть все возможные полезные или желательные функции. Кто сталкивался с заказчиками подобных систем, знают, что на первом этапе запросы у них довольно скромные. Нужно что-то простенькое, ну, вы знаете - чтобы секретарша легко могла добавить новость в соответствующий раздел. Однако дальше запросы растут, и это еще хорошо, если растут они в процессе планирования, до утверждения ТЗ, так же не плохо, если необходимость в новых функциях обнаруживается после сдачи проекта - главное - отследить, где заканчивается обещанная "поддержка" движка (в случае мелких непринципиальных глючков), и где начинается разработка новой версии системы (которая чаще всего бывает совсем новой, в корне измененной, грубо говоря не модифицированной, а разработанной заново) - с новым ТЗ, новым бизнеспланом и другими деньгами. Значительно печальнее, когда новые требования вдруг озвучиваются в процессе, когда заказчик "внезапно" вспоминает, что ему совершенно необходим еще какой-то важный сервис, без которого его будущий проект просто-таки теряет смысл : и здесь требуется тот самый опорный документ, на базе которого разработчик озвучил стоимость проекта, к примеру, опираясь на предполагаемое время разработки. Техническое задание формируется на основании требований, озвученных заказчиком. Даже если вы собираетесь создавать такой движок для своих нужд - в садитесь в кресле с листочком в руках, или проще - перед компьютером, открываете текстовый документ, и конспектируете - что хочется, что будет нужно, явные требования, потенциальные возможности, чтобы не упустить что-то важное. Вы можете обратиться к аналитику, вы можете сами себе быть аналитиком, но в любом случае ваш этап проектирования начнется с перечисления требований. Интересное наблюдение: начинающие программисты зачастую смело берутся за работу, считая, что ясно видят, что и как нужно делать. А вот те, кто создавал или участвовал в создании таких систем не один и не два раза, значительно чаще задумываются о том, насколько все же сложно сделать универсальный проект, продуманную, гибкую структуру, которая сможет удовлетворить самого что ни на есть придирчивого заказчика, систему, которую легко можно модифицировать под разные задачи, под разных клиентов. Задумываются о том, что такое *оптимальная CMS*. Хотя по моему мнению, оптимальная система - это такой же миф, как и философский камень или вечный двигатель. Оценка "оптимальности" всегда будет субъективной. Зависимость от платформ и технологий, непропорциональный рост сложности в настройке и адаптации при росте функциональности, избыточность используемых техник при попытке эмулировать простоту - это только немногое "зло", которое будет накапливаться в процессе "совершенствования" системы. Проблемы скорее философского и психологического характера: для того, чтобы средний типичный, "непродвинутый" пользователь системы должен легко подключить к работе любой интересный ему сервис и легко им воспользоваться, разработчику системы придется на порядки усложнить функциональность движка, следствие - бесконечный рост возможностей приводит к бесконечному усложнению и утяжелению готового движка. Среди известных мне развитых систем управления наблюдается два подхода:
Теперь по поводу собственно требований. Собрать, перечислить их тоже не так просто, здесь тоже нужен опыт, и, желательно, не по одному движку и не по одному заказчику.
Вот так, казалось бы, все просто. Все сложности начинаются, когда есть разные типы контента, когда информационная архитектура становится сложноупорядоченной, а количество желаемых сервисов растет. Проще говоря, все сложности начинаются, когда вы начинаете работу над реальным проектом. Попробуем о реальном: Кто управляет сайтомМы сейчас не говорим о директорах или владельцах проекта. Мы будем считать, что управляет сайтом любой человек, который может внести какие-бы то ни было изменения на сайте - от оптимизации движка и совершенствования дизайна до работы с контентом. В контексте темы разработки CMS это определяется для того, чтобы заранее сформировать группы доступа к сайту, определить права доступа, создать систему авторизации. В типичном требовании типичного заказчика как правило это звучит так: "чтобы секретарша, которая не имеет представления о верстке, могла добавить выданную ей в текстовом документе новость, а некий администратор (свой или кто-то из саппорта) поправить глюки или ошибки, этой секретаршей допущенные". Действительно, так тоже бывает. Попробуем рассмотреть более сложный проект и более сложную систему доступа. Возьмем типичный информационный новостийный сайт, хорошо посещаемый, на котором не только можно почитать интересные новости или посмотреть хорошую графику, но и оставить комментарий к просмотренному, обсудить что-то в форуме и т.д.
Кстати в качестве небольшого отступления - по поводу примера прав доступа для простого зарегестрированного пользователя каталога сайтов, который может редактировать информацию о своем сайте. Здесь получается палка о двух концах. С одной стороны - да, хороший современный движок для каталога сайтов уже трудно представить без такой функции. Однако большинство владельцев каталогов сайтов искренне заинтересованы в том, чтобы каталог был чистенький и не заспамленный. Именно для этого каталог тщательно модерируется, осуждаются описания сайтов, избыточно содержащие *ключевые слова* вместо внятного и лаконичного (и честного) текста. Не проходят модерацию сайты, не соответствующие указанной рубрике, или по другим причинам, как правило указанным в т.наз. privacy policy, в правилах, определяющих политику каталога. Однако если уж пользователь получает права на редактирование (в последствии) информации, то что ему мешает указать при регистрации аккуратные валидные данные, а после зайти под своим аккаунтом и поменять описание на перечень ключевых слов, то же самое сделать с названием сайта, а для некоторых каталогов - даже изменить адрес ссылки на сайт, указав в качестве исходного - очередной раскручиваемый дорвей? Это же на сколько порядков усложняется работа модератора каталога, которому, дабы соблюсти красоту в своем проекте, придется ежедневно пролистывать все рубрики, все страницы в поисках таких нарушителей? Куда проще по-старинке, когда права на запись были только у модератора, и пользователь не мог ничего изменить, только написать в саппорт слезную просьбу о внесении изменений, кои тоже сначала должны пройти проверку. И это только начало. Теперь в краткой форме следует собрать все требования к информационному сайту, к наличию всех возможных сервисов, к формированию интерфейса - для посетителей, для зарегестрированных пользователей, модераторов и администраторов. Повторюсь, собрать ВСЕ требования, которые и реализовать в некоей абстрактной оптимальной системе практически не возможно, хотя бы потому, что часть из них все равно будет противоречить друг другу. И все же я обращаюсь к читателям, к начинающим и опытным разработчикам - пишите в блог или на почту design@i2r.ru - хотелось бы выделить группу традиционных требований, а так же обсудить заказываемые нестандартные функции и сервисы. А к тем, кто все же выберется на семинар Сатина - великая просьба, вы задайте вопрос по поводу оптимального интерфейса для "админской части" информационного сайта, для модераторов. Очень хочется услышать по этому поводу мнение авторитета, профессионала, да.
:: ПО Adobe будет работать и на старых, и на новых "маках"
:: Техника креативного мышления: голая абстракция [дизайн] У Л Ы Б Н И Т Е С Ь !
Упадок нравов. Предложение авторам: Если вы хотите публиковаться, если вы хотите, чтобы ваше имя стало более известным, а ваш сайт - более посещаемым - присылайте ваши статьи о веб-дизайне, компьютерной графике, методах раскрутки сайтов, технологии флеш и на другие темы, имеющие отношение к Сайтостроительству, редактору раздела. ::: рассылку ведет: Татьяна Вукс http://www.i2r.ru 2006 ::: |
Subscribe.Ru
Поддержка подписчиков Другие рассылки этой тематики Другие рассылки этого автора |
Подписан адрес:
Код этой рассылки: inet.webbuild.libraryi2r Архив рассылки |
Отписаться
Вебом
Почтой
Вспомнить пароль |
В избранное | ||