Системы представления цвета

Самая распро­страненная и понятная компьютеру без перевода система RGB (от англ. «Red, Green, Blue», т. е. «красный, зеленый, синий») — не единственная. Если цвет компьютерного экрана изменяется от черного (отсутствие цвета) до бе­лого (максимальная яркость всех трех составляющих), то на бумаге, наоборот, отсутствию цвета соответствует бе­лый, а смешению максимального количества красок — черный (точнее, темно-бурый). Поэтому вместо системы RGB, называемой аддитивной («складывающей»), при под­готовке к печати изображение должно быть переведено в субтрактивную («вычитающую») систему, использующую противоположные исходным цвета — противоположный красному голубой, противоположный зеленому пурпурный и противоположный синему желтый. Чтобы расширить диапазон цветовоспроизведения, к этим трем компонентам добавляется четвертый — черный, и вся система получает наименование CMYK («Cyan, Magenta, Yellow, blacK»; чер­ный обозначается в этой аббревиатуре буквой К, чтобы не путать его с синим). Таким образом, для подготовленного к печати изображения в системе CMYK нужно 4 байта на пиксел, и далеко не все растровые форматы способны хра­нить такое изображение (чаще всего для этого используется формат TIFF).

В компьютерных графических программах применяется еще одна система представления цвета — система HSV (от англ. Hue-Saturation-Value, тон-насыщенность-яркость; эту же систему называют иногда HSB, Hue-Saturation-Brightness, или HLS, Hue-Lightness-Saturation). Эта система представляет собой абстракцию, моделирующую не физические свойства цвета, а его восприятие человеком. Растровые форматы не используют систему НSVдля хранения изображений, но с ее помощью очень удобно подбирать цвет при практической работе (стр. 103).

Важно помнить, что цветовой охват системы CMYK существенно уже, чем у RGB или HSV, так как на бумаге в принципе невозможно воспроиз­вести некоторые особо яркие и насыщенные экранные цвета. Поэтому изображения, готовящиеся для печати на бумаге, с самого начала должны рассчитывать на узкий цветовой спектр CMYK.

Программирование

За всем, что

мы видим не только в окне своего броузера, но и во­обще на экране компьютера, стоят программы — множество

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

Существуют, однако, исключения из этого правила. Ин­тересно отметить, что если до сих пор всегда программы порождали данные и оперировали ими, то в Интернете, наоборот, данные (веб-страницы) могут включать в се­бя и подчинять своим целям программные вставки. Эти «островки интерактивности» — JavaScript-сценарии, Java-апплеты и даже элементы HTML-форм — до сих пор не стали и, очевидно, никогда уже не станут несущим карка­сом для информации Интернета. Однако во многих случаях программирование способно с выгодой «оживить» статиче­ские веб-страницы и реализовать те функции, без которых невозможно полноценное общение с компьютером, в какой бы среде оно ни происходило.

JavaScript

Разработанный в 1995 г. фирмой Netscape для версии 2.0 своего броузера язык JavaScript до сих пор остается вспо­могательным, но в то же время абсолютно незаменимым инструментом, позволяющим загруженной в броузер стра­нице динамически управлять своим содержимым, а заодно и собственно броузером. По своему набору функций этот язык близок к макроязыкам, которые с давних пор встра­иваются в любую достаточно сложную программу или систему программ. В отличие от Java, JavaScript-сценарии не замыкается в изолированном апплете (стр. 69), а сво­бодно переплетается и взаимодействует с HTML-разметкой страницы. Будучи тесно связан с HTML, язык этот име­ет сходные недостатки и очень похожий по извилистости жизненный путь.

JavaScript из Netscape 2.0 не умел почти ничего, кроме как открывать и закрывать окна броузера (стр. 198), загружать в них документы, управлять фреймами и взаимодействовать с полями форм (например, проверяя правильность введен­ных в них значений). Сценарий, встроенный в документ с помощью тега SCRIPT, мог вставлять кусочки HTML-кода в то место документа, в котором расположен сам, но не мог ни считывать содержимое других частей документа, ни,

самое главное, изменять текст или графику документа после его загрузки на компьютер пользователя.

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

Динамический HTML

Недоделанность JavaScript пришлась как нельзя более на руку компании Microsoft, как раз в это время бросившей все усилия на завоевание рынка броузеров. Еще в третьей версии Microsoft Internet Explorer язык сценариев (который фирме пришлось назвать JScript, так как марка JavaScript принадлежала Netscape) отличался от своего конкурента разве что тем, что многочисленные ошибки и упущения в его реализации были расположены в непривычных местах. В четвертой версии, однако, фирма Microsoft решила уйти в отрыв.

Как известно маркетологам, одно из главных условий успеха любой новинки — запоминающееся название. Чтобы не раз­дражать пользователей путаницей между JScript и JavaScript, фирма Microsoft окрестила комбинацию, включающую рас­ширенный язык сценариев, частичную поддержку CSS2 и несколько мелких усовершенствований, словосочетанием «динамический HTML», — развернув, по своему обыкнове­нию, массированную рекламную кампанию, подающую его как средство от всех без исключения болезней «обычного» HTML. Netscape волей-неволей должна была ответить на вызов и, скрепя сердце, объявила о поддержке динамиче­ского HTML в четвертой версии своего броузера, — хотя его возможности имели довольно мало общего с набором технологий Microsoft.

Основную идею динамического HTML можно сформулиро­вать очень просто: полный контроль языка сценариев над всеми без исключения элементами документа, параметра­ми их оформления и размещения (как подразумеваемыми в HTML, так и задаваемыми с помощью CSS) и даже

над самим текстом страницы. Благодаря этому любой элемент HTML-документа сможет двигаться в произволь­ном направлении, как угодно изменять свое формати­рование и буквально переписываться — как в ответ на действия пользователя, так и по собственной инициативе. В сочетании с абсолютным позиционированием элемен­тов средствами CSS (стр. 241) это позволяет реализовать на веб-странице почти полноценный программный интер­фейс с выпадающими многоуровневыми меню (стр. 214), перетаскиванием объектов мышью и т. п.

До сих пор, впрочем, динамический HTML особого рас­пространения в Интернете не получил, и для этого есть объективные причины. Главную роль играет, конечно, не­совместимость броузеров-конкурентов, из-за которой очень трудно, а в некоторых случаях и невозможно создать од­ну версию динамической страницы, которая сохраняла бы работоспособность в обоих броузерах. Сказывается также конкуренция со стороны формата Shockwave Flash, в кото­ром можно реализовать не менее интерактивные эффекты, чем в динамическом HTML, который притом полностью застрахован от несовместимостей (существует только один, разработанный самой фирмой Macromedia подключаемый модуль для просмотра Flash-вставок) и имеет стандартную специализированную среду разработки. Конечно, с доступ­ностью информации в неграфических средах (стр. 34) у Flash дела обстоят куда хуже, чем у динамического HTML, но графические дизайнеры, к сожалению, редко задумываются о таких вещах.

Как всегда с опозданием, свое слово сказал и W3C. Разработанный им стандарт «объектной модели докумен­та» (Document Object Model, DOM) подробно описывает взаимодействие встроенного в веб-страницу сценария с эле­ментами документа, перечисляя все возможные действия, свойства и взаимозависимости для объектов, на которые распадается содержимое документа с точки зрения сцена­рия. Пока достаточно близко к этим предписаниям подошел только броузер Microsoft.

Спецификация DOM оперирует достаточно общими прин­ципами и потому не зависит ни от конкретного языка разметки документа, ни от языка сценариев. В то же время стандартизации не избежал и сам JavaScript; его «официальная», в общественном пользовании находящаяся версия называется ECMAScript (стандарт этот был создан не

W3C, а европейской промышленной ассоциацией ЕСМА). Интересно следить за тем, как компании, всегда стре­мившиеся любыми средствами добиться преимущества над конкурентами и по возможности монополизировать свой сектор рынка, начинают уступать инициативу независимым организациям-стандартизаторам (состоящим, впрочем, из представителей тех же самых фирм-конкурентов), посте­пенно осознавая важность единых и обязательных для всех «правил игры».

Модульные технологии

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

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

К сожалению, существует сразу несколько препятствий к реализации этой простой схемы.

• Исполняемый файл программы, скомпилированной для одной компьютерной платформы (например, для Windows 95), не будет работать на другом типе ком­пьютеров (например, на Макинтоше) или в другой операционной системе (например, в DOS). Веб-страницащ

не имеет возможности выяснить, в какую операционную систему она попала на компьютере пользователя, так что выбор нужной версии программы из нескольких имеющихся отпадает. Это ограничение можно обойти, пересылая с сервера не готовый к исполнению двоичный код, а исходный текст программы на языке програм­мирования, с тем чтобы компьютер пользователя само­стоятельно превращал его в понятный ему код. Такое решение, однако, имеет свои недостатки: потерю зна­чительной части быстродействия, незастрахованность от ошибок при компиляции и необходимость устанавливать на компьютер наряду с броузером еще и интерпретатор языка программирования (который будет тем объеми­стее, чем больше возможностей предоставляет данный язык).

• Давать любому желающему возможность выполнять на вашем компьютере свои программы — более чем риско­ванная затея. В отличие от JavaScript-сценария, в котором соответствующих средств нет и не может быть в прин­ципе, программа на обычном языке программирования способна заразить вас вирусом, попортить данные на вашем диске или уворовать конфиденциальную инфор­мацию.

• Наконец, довольно трудно обеспечить небольшой объем файла с программой, приемлемый для перекачивания по сети. Если графику всегда можно попытаться опти­мизировать, уменьшив ее размер за счет некоторой потери качества, то объем файла программы почти не поддается изменению без существенного усечения ее функций.

На данный момент существуют три технологии встраивания программных объектов в документ. Все они так или иначе пытаются справиться с перечисленными ограничениями.

• Технология подключаемых модулей (plug-in modules) под­разумевает наличие двух компонентов: общего для всех объектов данного типа модуля, который достаточно пе­рекачать из сети один раз и установить на компьютере пользователя как обычную программу, и подключаемых к HTML-странице объектов. Последние интерпретиру­ются и выводятся на отведенное им место в пределах страницы соответствующим модулем, запуск которого (как правило, в фоновом режиме, т. е. без создания соб­ственного окна) берет на себя броузер.

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

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

• Апплеты на языке Java, при всех своих особенностях, имеют немало пунктов сходства с подключаемыми мо­дулями. Основную часть выполняемой апплетом работы берет на себя не передаваемый по сети объект ми­нимального объема, а большая программная система, называемая «виртуальной машиной Java» и устанавлива­емая на компьютер пользователя только раз (в отличие от подключаемого модуля, пользователю не приходится перекачивать ее из сети, так как оба визуальных броузера поставляются уже со встроенными виртуальными маши­нами). Подключаемый к веб-странице объект содержит так называемые «байтовые коды» — нечто среднее между исходным текстом и скомпилированным двоич­ным файлом программы, компромисс между идеалами быстродействия и переносимости.

Набор функций у апплетов ограничен даже сильнее, чем у подключаемых модулей. Хотя Java и относит­ся к полнофункциональным языкам программирования,

в апплетах этот язык имеет дело не с реальным ком­пьютером, а с внутренностями виртуальной машины, надежно ограждающей компьютер от любых продуктов жизнедеятельности апплета. Конечно, везде, где есть защита, можно постараться ее обойти, и поиск «дыр» в виртуальных машинах доставляет и долго еще будет до­ставлять приятные минуты компьютерным взломщикам. И все же в целом Java-апплеты можно считать достаточно безопасной технологией.

К сожалению, виртуальная машина у каждого из броузе­ров своя, и, несмотря на декларируемую совместимость между ними, апплет, который работает на одной из этих машин, иногда может отказаться работать на другой. Кроме того, как и любая многоуровневая система, Java-апплеты в сравнении с обычными программами сильно проигрывают в быстродействии. Наконец, необходи­мость «настоящего» программирования для изготовления апплетов обуславливает трудоемкость этого процесса. С другой стороны, наличие готовой виртуальной маши­ны почти на каждом компьютере и, опять-таки, богатые возможности полнофункционального языка программи­рования открывают перед этой технологией определен­ные перспективы. Так, уже упоминавшаяся технология Macromedia Flash (стр. 58) позволяет сохранять Flash-«мультики» в виде Java-апплетов, для работы которых не нужен установленный на компьютере Flash-модуль.

• Одно время Java-апплетам пытались составить кон­куренцию так называемые «компоненты ActiveX» — технология фирмы Microsoft, ограниченная только бро­узером Internet Explorer и только платформой Windows. Это наделавшее поначалу много шума, но быстро за­бытое нововведение интересно отсутствием какой бы то ни было «прокладки» между программным модулем (по сути, обычным исполняемым файлом в форма­те Windows) и операционной системой. Для решения проблемы безопасности была разработана система «элек­тронных подписей» с регистрацией законопослушных авторов ActiveX-апплетов у спонсируемых Microsoft «ци­фровых нотариусов». Неудивительно, что эта громоздкая система оказалась нежизнеспособной. В настоящее вре­мя изредка используются лишь ActiveX-объекты самой фирмы Microsoft, поставляемые вместе с ее броузе­рами.

В Windows-версии броузера Internet Explorer (начиная с версии 4) тех­нология ActiveX является не одним из усовершенствований, а букваль­но фундаментом всей программы. При запуске броузера управление получает контейнер, сразу же вызывающий ActiveX-модуль, в котором, собственно, и заключены все функции броузера. Любой программист может, таким образом, без труда встроить в свою программу самый настоящий броузер, написав всего лишь небольшую функцию для вы­зова этого модуля и обмена данными с ним. Отдельные функциональ­ные блоки броузера — виртуальная машина Java, интерпретатор HTML и даже сам блок взаимодействия с органами управления ActiveX — ре­ализованы в виде ActiveX-модулей.

Динамические страницы

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

По некоторым оценкам, больше половины всех страниц в современном Интернете генерируются и обновляются ди­намически — на основе информации из баз данных, в ответ на действия пользователя или в зависимости от каких-то внешних обстоятельств (например, текущей даты или курса доллара). Простейшая технология такого рода, поддержива­емая почти всеми веб-серверами, называется SSI (Server Side Include, «Вставки на уровне сервера»). Возможности ее огра­ничены вставкой внутрь одного HTML-файла содержимого другого, автоматической установкой даты, подсчетом числа загрузок страницы и т. п. Из более сложных технологий создания динамических сайтов особенно популярны две: CGI и ASP.

Стандарт CGI (Common Gateway Interface, «Общий интер­фейс шлюзов»), поддерживаемый большинством программ-серверов, не накладывает каких-либо ограничений на ис­пользуемый язык программирования, а лишь перечисляет правила, которые должна выполнять программа, генериру­ющая веб-страницу, чтобы сервер мог запускать ее в ответ на запрос документа с определенным URL. Однако по­скольку большинство таких программ пишутся на специ­ализированном языке Perl, термины «CGI» и «Perl» часто употребляются как синонимы. Стандарт CGI достаточно

прост и, в частности, ничего не говорит о взаимодействии с какими бы то ни было базами данных, оставляя этот аспект целиком на совести самой CGI-программы и того языка, на котором она написана. Язык Perl не является собственностью какой-либо фирмы, и существуют бесплат­но распространяемые интерпретаторы этого языка для всех операционных систем.

Альтернатива CGI, появившаяся в последнее время, — язык ASP (Active Server Pages, «Активные страницы на сервере») фирмы Microsoft (вполне естественно, что поддержка ASP существует пока только в веб-сервере US этой же фирмы). ASP-код хранится не в отдельных объектах, а встраива­ется прямо в HTML «активной» страницы, но в отличие от JavaScript никогда не выходит за пределы веб-сервера. Инструкции языка ASP позволяют генерировать фрагменты HTML-кода, выбирать один из вариантов кода в зависи­мости от каких-то условий, циклически повторять куски HTML с изменениями и т. п. ASP-файл может состоять це­ликом из ASP-инструкций, а может и быть чистым HTML без единой ASP-вставки; так или иначе, сервер отсылает броузеру только «сухой остаток» HTML после выполнения всех команд ASP. С практической точки зрения главным достоинством ASP являются развитые средства доступа к ба­зам данных, многие из которых, как и веб-сервер Microsoft, работают на платформе Windows NT.

Глава II. Основы дизай­на

Я не очень-то погрешу против истины, сказав, что вся эта книга была написана ради единственной главы — той, которую вы начинаете читать. Уверенное владение современными технологиями веб-дизайнеру не­обходимо, однако в основе его мастерства лежат все-таки куда более фундаментальные и медленнее устаревающие знания.

От читателей моих статей по веб-дизайну, публикуемых по адресу www.webreference.com/dlab/ , я получаю немало писем с одобрением их скорее теоретической, чем практи­ческой направленности (особенно выделяющейся на фоне бесчисленных сайтов с «How To» и «Top Ten Dont's», на разные лады повторяющих небольшой набор разрозненных практических советов). Многие читатели спрашивают, где начинающий веб-дизайнер — иногда поневоле, иногда по зову сердца окунувшийся в эту область творчества, но ни­когда не учившийся в художественном училище и даже не

очень хорошо представляющий, чему там учат, — мог бы найти достаточно полный и в то же время по возможности популярный курс основ дизайна.

Хорошие книги по теории дизайна, конечно, есть. Но вместо того, чтобы опираться на авторитет классиков, я решил сам написать небольшое введение в предмет.

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

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

Подыскивая аналог теории дизайна среди наук традици­онных, нельзя не заметить, что она стоит гораздо ближе к таким гуманитарным дисциплинам, как философия или филология, а не к точным наукам вроде математики. Как и в дизайне, в философии есть свои общепризнанные фак­ты, принципы и подходы, истинность которых никто не подвергает сомнению. Однако ценность нового философ­ского сочинения определяется все же свойствами скорее субъективными: новизной идей, убедительностью аргумен­тации, иногда даже достоинствами литературного стиля. Философскую систему невозможно опровергнуть в принци­пе — она живет по своим собственным законам, и Витген­штейн не «опровергает» Платона, хотя и противоречит ему на каждом шагу.

Почти то же самое, с некоторыми оговорками, можно сказать и о любом дискурсе в области теоретического

дизайна. Даже опираясь на примеры из практики, автор волен трактовать их сколь угодно субъективно (собственно говоря, многие категории дизайна и невозможно оценивать объективно) — так, как того требует выстраиваемая им система понятий. Вот почему я взял на себя смелость представить на суд читателя свою собственную, если так можно выразиться, философию дизайна.

Как учиться дизайну

Философия эта, как и любая философия, родилась из наблюдений, размышлений и со­поставлений. Я совсем не хочу, чтобы вы всегда и во всем разделяли мою точку зрения; моя цель — не вербовать сто­ронников, а сделать так, чтобы после прочтения этой книги вы глубже понимали свое ремесло и свободнее чувствовали себя с палитрой дизайнера в руках. Поэтому я призываю вас сразу же проверять все почерпнутые здесь знания своей практикой и анализом чужих работ и не пугаться, если ваши выводы не совпадут с моими. (И разумеется, я всегда буду рад услышать от вас любые комментарии или возражения как по теоретическим, так и по самым что ни на есть прак­тическим вопросам веб-дизайна. Пишите мне по адресу: dmitry@klrsanov.com.)

Самостоятельный теоретический анализ, критика и разбор чужих творений — один из лучших способов обучения практическому дизайну. Резонерствуйте, абстрагируйте, со­чиняйте теории на ходу, спрашивайте себя «а что, если»; загрузите копию нравящейся вам страницы в графический редактор и посмотрите, можете ли вы ее улучшить или хотя бы изменить, не ухудшив. Немедленно обобщайте все, чему вы научились на практике и старайтесь сразу же делать практические выводы из своих теорий. Не огорчай­тесь, если наткнетесь на противоречие, — ведь осознанное противоречие есть лучший двигатель мысли. Очевидно, совет этот подходит не всем — вы можете быть одаренным дизайнером и притом не иметь никакой склонности к теоретизированию. Но и в этом случае для развития художественных способностей нет ничего лучше, чем свободное экспериментирование как с чужими работами, так и на чистом листе бумаги. В упражнениях этих нужно найти оптимальное соотношение бесцельности и целенаправленности; вы не должны при этом зависеть от вкусов и потребностей какого бы то ни было заказчика (хотя стоит прислушиваться к мнению собратьев-дизайнеров), но в то же время вы сами должны каждый раз ставить

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

Поиск по сайту: