Выбери любимый жанр

Выбрать книгу по жанру

Фантастика и фэнтези

Детективы и триллеры

Проза

Любовные романы

Приключения

Детские

Поэзия и драматургия

Старинная литература

Научно-образовательная

Компьютеры и интернет

Справочная литература

Документальная литература

Религия и духовность

Юмор

Дом и семья

Деловая литература

Жанр не определен

Техника

Прочее

Драматургия

Фольклор

Военное дело

Последние комментарии
оксана2018-11-27
Вообще, я больше люблю новинки литератур
К книге
Professor2018-11-27
Очень понравилась книга. Рекомендую!
К книге
Vera.Li2016-02-21
Миленько и простенько, без всяких интриг
К книге
ст.ст.2018-05-15
 И что это было?
К книге
Наталья222018-11-27
Сюжет захватывающий. Все-таки читать кни
К книге

Журнал «Компьютерра» №32 от 06 сентября 2005 года - Журнал Компьютерра - Страница 7


7
Изменить размер шрифта:

В поиске средств единения с Linux компания Microsoft могла бы взять пример с Sun Microsystems, учредившей в августе должность омбудсмена. В британском парламенте омбудсмен занимается расследованием жалоб граждан, а в Sun назначенный на эту должность Саймон Фиппс будет выслушивать недовольных политикой фирмы в области открытого ПО и по возможности урегулировать недоразумения. В качестве примера таких недоразумений Фиппс приводит недавний казус с аннулированием лицензии на Java для FreeBSD. Верная своим корням, Sun выдала для FreeBSD бесплатную бессрочную лицензию на Java, продлевавшуюся каждый год (до тех пор, пока не была аннулирована в связи с выпуском новой лицензии, которую FreeBSD должна была получить у Sun на тех же условиях). Но в Беркли дочитали только до слова «аннулирована» и поспешили обидеться - совершенно напрасно, как считает Фиппс. Случай, однако, наглядно показывает причину, из-за которой Ричард Столлмен призывает Sun отпустить Java в свободное плавание под лицензией GPL. Ситуация «моя Java, что хочу, то с ней и делаю» хороша с точки зрения стандартизации. Но если Sun хочет сделать Java воздухом для отрасли, кому нужна монополия на воздух?

ТЕМА НОМЕРА: Главное - Порядок

Клиент, обращающийся в студию веб-дизайна, зачастую плохо представляет, какой объем работы нужно проделать, чтобы в конце концов по милому ему адресу www.название_фирмы.ru появился хороший веб-сайт.

Именно поэтому, чтобы муки творчества не затянулись на долгие годы, начинать нужно с четкой формулировки задачи и целей. Когда совместными усилиями клиента и представителей студии этот этап пройден, клиенту могут быть названы примерные расценки, способы оплаты и ориентировочные сроки. Кстати, потенциальные заказчики часто спрашивают о наличии прайс-листа. Это неверный подход: прайс-лист может быть в магазине, в кафе, в музее, в прачечной - потому что все наименования этого «листа» (меню или прейскуранта) созданы по определенным правилам и нормам. Дизайн же - «вещь», не поддающаяся стандартизации и нормоконтролю, поэтому наличие у некоторых студий прайс-листа с, например, таким пунктом: «Веб-сайт: до 10 страниц - 100 у. е.» - может вызывать лишь мысли о некомпетентности и неграмотности работников такой студии. Реально возможно назвать лишь ценовой интервал, в который может вписаться проект. Точная стоимость утверждается только после детального обсуждения заказа и объема работ[Если студию и заказчика разделяют сотни километров, то, как правило, речь идет о поиске способа перевода денег с наименьшей комиссией за перевод]. После получения аванса менеджеры могут попросить заказчика составить техническое задание, в котором должно быть подробно описано, что и как делать (структура, система навигации, предпочтения по стилю и цветовой гамме будущего сайта, уже имеющиеся наработки и пр.). Возможно, что эту работу заказчик оставит на усмотрение студии. Кроме того, всегда полезно узнать у клиентов о необходимости создания или редизайна существующей графики - логотипа компании, иконок к программе и сопутствующей графики для сайта, ведь многие привыкли к своему нередко аляповатому, но милому сердцу дизайну. Необходимость в дополнительной графике обсуждается отдельно. Только после всего этого задание уходит к дизайнеру, и в дальнейшем уже он контактирует напрямую[Для устранения эффекта испорченного телефона] с клиентом.

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

Если у вас возник вопрос, связанный с веб-программированием (PHP, Perl, JavaScript), обращайтесь на форумы WebMastak.com или на форум WebScript.Ru (forums.webscript.ru), - кто-нибудь, разбирающийся в той теме, которая вас интересует, обязательно откликнется и поможет решить вашу проблему. Проверял на себе не раз.

Неплохой форум по Perl располагается на сайте Perl.dp.ua. На сайте много интересных материалов в разделе «PERLеводы» - переводы англоязычных статей.

Главное - спокойствие

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

На следующем этапе за дело берется специалист по проектированию пользовательских интерфейсов. Его задача - спроектировать максимально прозрачную, доступную и понятную структуру проекта для конечного потребителя продукта - не для заказчика, а именно для посетителей ресурса, которые будут пользоваться им для решения своих задач. Под системой взаимодействия нужно понимать не только удобство пользования (часто по ошибке называемое «юзабилити»[На самом деле, этот термин более общий: «usability» (англ. «удобство пользования») - это не только удобство пользования сайтом, но и степень соответствия содержимого сайта потребностям целевой аудитории, организация системы обратной связи с посетителями и др.]), но и общую ясность, легкость восприятия. Сюда в первую очередь нужно отнести максимально четкую группировку контента по разделам, рубрикам, блокам и т. п. Кроме того, нужно ясно представлять технические аспекты реализации системы навигации проекта - лишь тогда можно переходить к следующему этапу (поэтому дизайнеры всегда должны быть в курсе последних технологий для реализации своих красивых задумок).

На RealCodingсобрана информация о HTML, CSS, JavaScript, PHP, Perl, WAP, а также учебники по этим темам. На форумах forums.realcoding.net много интересных сообщений, присланных посетителями сайта.На Codenet веб-разработкам посвящен довольно большой раздел , касающийся PHP, ASP, Perl, Apache, Microsoft IIS, SSI, Java, JavaScript, VBScript - и это далеко не полный перечень. На форуме forum.codenet.ru вы можете задать вопрос, который, возможно, войдет в перечень вопросов и ответов (FAQ), публикуемых на www.codenet.ru/webmast/faq. А еще на сайте имеется довольно интересная рассылка. Советую подписаться.

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

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

вернуться
вернуться
вернуться