https://wiki.cusu.edu.ua/api.php?action=feedcontributions&feedformat=atom&user=I+Shevchenko 2026-04-09T15:57:42Z Внесок користувача MediaWiki 1.23.2 https://wiki.cusu.edu.ua/index.php/%D0%9F%D0%B0%D1%80%D0%B0%D0%B3%D1%80%D0%B0%D1%84%D0%B8_%D0%90%D1%80%D1%82%D1%94%D0%BC%D1%96%D1%8F_%D0%9B%D1%94%D0%B1%D1%94%D0%B4%D1%94%D0%B2%D0%B0 2012-03-15T17:11:00Z

<p>I Shevchenko: /* § 95. Заявка на дизайн */</p> <hr /> <div>==§ 50. О статусной строке==<br /> <br /> Не можна втручатися в звичний стандартний інтерфейс і не можна ховати його елементи в ситуаціях, коли людина їх очікує.<br /> <br /> &lt;&lt;— Каков ваш статус, Лена? Проще говоря, каков ваш социум эр актум? С. Довлатов.&gt;&gt;<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/50/ Переглянути повністю]<br /> <br /> ==§ 55. Как писать слово «интернет»?==<br /> <br /> Освітченість &quot;світлин&quot; філологічних наук бажає бути кращою.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/55/ Оригінал станні]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:56, 20 грудня 2011 (EET)<br /> <br /> ==§ 60. Э... коммерция==<br /> <br /> Електронна комерція існує, чи це лише маркетинговий хід?<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/60/ Оригінал статті]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:59, 20 грудня 2011 (EET)<br /> <br /> ==§ 119. Буква Ё==<br /> <br /> Про значення букви &quot;Ё&quot; її правила вживання, труднощі які вона викликає при вживанні, її переваги та недоліки.<br /> <br /> Ё — недобуква. Використання &quot;Ё&quot; скрізь - насильство над читачем.<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/119/ Переглянути повністю]<br /> <br /> ==§ 161. Ідея на мінус мільйон==<br /> <br /> Про ціну винаходу. Для реалізації більшості ідей потрібно затратити більше коштів ніж ти від цього отримаеш прибутку)<br /> <br /> &quot;Кожен винахідник, або дизайнер, який розповідає про свою ідею, повинен чесно говорити: «У мене є ідея на мінус мільйон». &quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/161/ Прочитати повністю]<br /> <br /> <br /> == § 162. Творча криза==<br /> <br /> Творча криза - це глухий кут шляху без сенсу.<br /> <br /> Оригінальне і незвичайне неможливо придумати, воно з'являється тільки в результаті роботи над поставленою задачею.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/162/ Прочитати повністю]<br /> <br /> --[[Користувач:Gorduarabey|Gorduarabey]] 09:47, 23 листопада 2010 (EET)<br /> <br /> <br /> == § 145. Безглузда презентація==<br /> <br /> &quot;Краща презентація та, яку не показали.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/145/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> <br /> == § 147. Простота ≠ примітивність==<br /> <br /> &quot;Дизайн повинен бути простим, але не примітивним.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/147/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> ==Артемий Лебедев соц проэкт==<br /> &quot;Улучшение дорожных знаков в Киеве&quot; <br /> http://www.artlebedev.ru/kovodstvo/business-lynch/2009/06/15/commented/<br /> --[[Користувач:Alex46|Alex46]] 13:58, 21 грудня 2010 (EET)<br /> ==Организация пешеходных переходов с подсветкой в Тюмени==<br /> http://habrahabr.ru/blogs/design/44390/<br /> --[[Користувач:Alex46|Alex46]] 13:59, 21 грудня 2010 (EET)<br /> <br /> == § 166. Повітря спільне ==<br /> <br /> &quot;У кожної реклами повинно бути чітко окреслене місце&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/166/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> == § 150. От обратного ==<br /> <br /> &quot;Один з найефективніших дизайнерських прийомів - придумування незручних, незрозумілих і заплутаних рішень.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/150/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> ==§ 163 Правила написання поштових адрес ==<br /> <br /> Раніше реквізити адреси прийнято було писати від більшого до меншого: країна, індекс, місто, вулиця, будинок, квартира, ПІБ. У світі прийнята інша система складання адреси, тому що в світі відправляють багато пошти і дбають про те, щоб вона швидше доходила до місця призначення<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/163/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:08, 4 січня 2011 (EET)<br /> <br /> ==§ 112 Амперсанд ==<br /> <br /> Амперсанд - це назва знака &amp;. Про нього треба знати три речі: звідки він узявся, чому так називається і чи потрібен він нам для чого-небудь.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/112/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:11, 4 січня 2011 (EET)<br /> <br /> ==§ 138. Кофе — оно ==<br /> <br /> Ознакою псевдоінтеллігентності є зауваження «кави - він». Зазвичай так говорять люди, які не помічають цих помилок у мовленні.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/138/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:48, 5 січня 2011 (EET)<br /> <br /> ==§ 103. Хочу как у них ==<br /> <br /> Знаки принадлежщие компаниям с превосходными, узнаваемыми, образцовыми товарами и услугами и подрожание им.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/103/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:55, 5 січня 2011 (EET)<br /> <br /> ==§ 165. Три правила про ви==<br /> <br /> У російській мові існує займенник ви, до якого додаються досить прості правила вживання і невживання.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/165/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 164. Три крапки==<br /> <br /> Всім відомі три крапки ...<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/164/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 149. Решение задач==<br /> <br /> Автор уверен, что дизайн является решением задач, а не творчеством. Дизайнер, который считает, что дизайн — это когда надо сделать красиво, просто не понимает смысла профессии.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/149/ Прочитати повністю]<br /> <br /> --[[Користувач:Kat|Kat]] 11:30, 19 січня 2011 (EET)<br /> <br /> ==§ 152. Патент краток, язык — вечен==<br /> <br /> [[§ 152. Патент краток, язык — вечен]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:53, 01 грудня 2011 (EET)<br /> <br /> <br /> ==§ 148. Единица смысла==<br /> <br /> [[§ 148. Единица смысла]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:57, 01 грудня 2011 (EET)<br /> <br /> ==§ 158. Коротке тире ==<br /> <br /> В даному параграфі А. Лєбєдєв стверджує, що в текстах діапазони як і раніше будуть позначатися з допомогою довгого тире а в номерах телефонів залишиться коротке. При позначенні діапазонів в числах планується ввести коротке тире, а не те що є на даний час, яке довжиною дорівнює &quot;N&quot;.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/158/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:26, 6 грудня 2011 (EET)<br /> <br /> ==§ 167. Метод прогресивного джіпєга ==<br /> <br /> В цій статті автор пропонує інший метод завантаження зображень.<br /> <br /> &quot;Час витрачається тільки на нужну степінь прожарювання, а загальний вигляд стейка завжди є.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/167/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:30, 6 грудня 2011 (EET)<br /> <br /> ==§ 171. Правила оформлення посилань==<br /> <br /> В статті автор розповідає про основні правила, яких слід дотримуватись при оформленні посилань.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/171/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 156. Дизайн - це війна==<br /> <br /> В статті на прикладі боротьби виробників тютюну з противниками тютюнопаління розповідається про те, як за допомогою знання психології сприйняття, за допомогою дизайнерських прийомів противники придумують нові способи боротьби один з одним.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/156/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 169. Підписи на фотографіях==<br /> <br /> Стаття про те, як не перетворитися з чудового фотографа у жахливого дизайнера. Оскільки неправельний підпис фотографії може погубити будь-який шедевр. <br /> &lt;br&gt;'''Правило:''' не потрібно перетворювати підпис фотографії у рекламу. <br /> [http://www.artlebedev.ru/kovodstvo/sections/169/ Читати оригінал]<br /> <br /> --[[Користувач:I_Shevchenko|Шевченко Ігор]] 18:13, 15 березня 2012 (EET)<br /> <br /> ==§ 95. Заявка на дизайн==<br /> <br /> Як з'являється хороший дизайн? Або випадково, або усвідомлено. Випадково вдалий дизайн мало кого цікавить, тому розглянемо, як робити хороший дизайн усвідомлено. Одним з кращих та плідних способів зробити хороший дизайн - є аналіз власних та чужих помилок, які були зроблені при рішенні даної задачі. Так, саме аналіз помилок, оскільки аналіз вдалих рішень не призвиде ні до чого окрім подальшого шаблонного копіювання існуючого рішення, яке згодом може стати неправельним. А аналіз помилок, як мінімум, дає нам змогу уникнути їх в майбутньому. А щоб бачити помилки, треба просто дивитися. <br /> [http://www.artlebedev.ru/kovodstvo/sections/95/ Читати оригінал]<br /> <br /> --[[Користувач:I_Shevchenko|Шевченко Ігор]] 18:44, 15 березня 2012 (EET)</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D0%B0%D1%80%D0%B0%D0%B3%D1%80%D0%B0%D1%84%D0%B8_%D0%90%D1%80%D1%82%D1%94%D0%BC%D1%96%D1%8F_%D0%9B%D1%94%D0%B1%D1%94%D0%B4%D1%94%D0%B2%D0%B0 2012-03-15T17:09:49Z

<p>I Shevchenko: /* § 95. Заявка на дизайн */</p> <hr /> <div>==§ 50. О статусной строке==<br /> <br /> Не можна втручатися в звичний стандартний інтерфейс і не можна ховати його елементи в ситуаціях, коли людина їх очікує.<br /> <br /> &lt;&lt;— Каков ваш статус, Лена? Проще говоря, каков ваш социум эр актум? С. Довлатов.&gt;&gt;<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/50/ Переглянути повністю]<br /> <br /> ==§ 55. Как писать слово «интернет»?==<br /> <br /> Освітченість &quot;світлин&quot; філологічних наук бажає бути кращою.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/55/ Оригінал станні]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:56, 20 грудня 2011 (EET)<br /> <br /> ==§ 60. Э... коммерция==<br /> <br /> Електронна комерція існує, чи це лише маркетинговий хід?<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/60/ Оригінал статті]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:59, 20 грудня 2011 (EET)<br /> <br /> ==§ 119. Буква Ё==<br /> <br /> Про значення букви &quot;Ё&quot; її правила вживання, труднощі які вона викликає при вживанні, її переваги та недоліки.<br /> <br /> Ё — недобуква. Використання &quot;Ё&quot; скрізь - насильство над читачем.<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/119/ Переглянути повністю]<br /> <br /> ==§ 161. Ідея на мінус мільйон==<br /> <br /> Про ціну винаходу. Для реалізації більшості ідей потрібно затратити більше коштів ніж ти від цього отримаеш прибутку)<br /> <br /> &quot;Кожен винахідник, або дизайнер, який розповідає про свою ідею, повинен чесно говорити: «У мене є ідея на мінус мільйон». &quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/161/ Прочитати повністю]<br /> <br /> <br /> == § 162. Творча криза==<br /> <br /> Творча криза - це глухий кут шляху без сенсу.<br /> <br /> Оригінальне і незвичайне неможливо придумати, воно з'являється тільки в результаті роботи над поставленою задачею.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/162/ Прочитати повністю]<br /> <br /> --[[Користувач:Gorduarabey|Gorduarabey]] 09:47, 23 листопада 2010 (EET)<br /> <br /> <br /> == § 145. Безглузда презентація==<br /> <br /> &quot;Краща презентація та, яку не показали.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/145/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> <br /> == § 147. Простота ≠ примітивність==<br /> <br /> &quot;Дизайн повинен бути простим, але не примітивним.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/147/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> ==Артемий Лебедев соц проэкт==<br /> &quot;Улучшение дорожных знаков в Киеве&quot; <br /> http://www.artlebedev.ru/kovodstvo/business-lynch/2009/06/15/commented/<br /> --[[Користувач:Alex46|Alex46]] 13:58, 21 грудня 2010 (EET)<br /> ==Организация пешеходных переходов с подсветкой в Тюмени==<br /> http://habrahabr.ru/blogs/design/44390/<br /> --[[Користувач:Alex46|Alex46]] 13:59, 21 грудня 2010 (EET)<br /> <br /> == § 166. Повітря спільне ==<br /> <br /> &quot;У кожної реклами повинно бути чітко окреслене місце&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/166/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> == § 150. От обратного ==<br /> <br /> &quot;Один з найефективніших дизайнерських прийомів - придумування незручних, незрозумілих і заплутаних рішень.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/150/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> ==§ 163 Правила написання поштових адрес ==<br /> <br /> Раніше реквізити адреси прийнято було писати від більшого до меншого: країна, індекс, місто, вулиця, будинок, квартира, ПІБ. У світі прийнята інша система складання адреси, тому що в світі відправляють багато пошти і дбають про те, щоб вона швидше доходила до місця призначення<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/163/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:08, 4 січня 2011 (EET)<br /> <br /> ==§ 112 Амперсанд ==<br /> <br /> Амперсанд - це назва знака &amp;. Про нього треба знати три речі: звідки він узявся, чому так називається і чи потрібен він нам для чого-небудь.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/112/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:11, 4 січня 2011 (EET)<br /> <br /> ==§ 138. Кофе — оно ==<br /> <br /> Ознакою псевдоінтеллігентності є зауваження «кави - він». Зазвичай так говорять люди, які не помічають цих помилок у мовленні.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/138/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:48, 5 січня 2011 (EET)<br /> <br /> ==§ 103. Хочу как у них ==<br /> <br /> Знаки принадлежщие компаниям с превосходными, узнаваемыми, образцовыми товарами и услугами и подрожание им.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/103/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:55, 5 січня 2011 (EET)<br /> <br /> ==§ 165. Три правила про ви==<br /> <br /> У російській мові існує займенник ви, до якого додаються досить прості правила вживання і невживання.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/165/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 164. Три крапки==<br /> <br /> Всім відомі три крапки ...<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/164/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 149. Решение задач==<br /> <br /> Автор уверен, что дизайн является решением задач, а не творчеством. Дизайнер, который считает, что дизайн — это когда надо сделать красиво, просто не понимает смысла профессии.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/149/ Прочитати повністю]<br /> <br /> --[[Користувач:Kat|Kat]] 11:30, 19 січня 2011 (EET)<br /> <br /> ==§ 152. Патент краток, язык — вечен==<br /> <br /> [[§ 152. Патент краток, язык — вечен]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:53, 01 грудня 2011 (EET)<br /> <br /> <br /> ==§ 148. Единица смысла==<br /> <br /> [[§ 148. Единица смысла]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:57, 01 грудня 2011 (EET)<br /> <br /> ==§ 158. Коротке тире ==<br /> <br /> В даному параграфі А. Лєбєдєв стверджує, що в текстах діапазони як і раніше будуть позначатися з допомогою довгого тире а в номерах телефонів залишиться коротке. При позначенні діапазонів в числах планується ввести коротке тире, а не те що є на даний час, яке довжиною дорівнює &quot;N&quot;.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/158/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:26, 6 грудня 2011 (EET)<br /> <br /> ==§ 167. Метод прогресивного джіпєга ==<br /> <br /> В цій статті автор пропонує інший метод завантаження зображень.<br /> <br /> &quot;Час витрачається тільки на нужну степінь прожарювання, а загальний вигляд стейка завжди є.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/167/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:30, 6 грудня 2011 (EET)<br /> <br /> ==§ 171. Правила оформлення посилань==<br /> <br /> В статті автор розповідає про основні правила, яких слід дотримуватись при оформленні посилань.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/171/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 156. Дизайн - це війна==<br /> <br /> В статті на прикладі боротьби виробників тютюну з противниками тютюнопаління розповідається про те, як за допомогою знання психології сприйняття, за допомогою дизайнерських прийомів противники придумують нові способи боротьби один з одним.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/156/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 169. Підписи на фотографіях==<br /> <br /> Стаття про те, як не перетворитися з чудового фотографа у жахливого дизайнера. Оскільки неправельний підпис фотографії може погубити будь-який шедевр. <br /> &lt;br&gt;'''Правило:''' не потрібно перетворювати підпис фотографії у рекламу. <br /> [http://www.artlebedev.ru/kovodstvo/sections/169/ Читати оригінал]<br /> <br /> --[[Користувач:I_Shevchenko|Шевченко Ігор]] 18:13, 15 березня 2012 (EET)<br /> <br /> ==§ 95. Заявка на дизайн==<br /> <br /> Як з'являється хороший дизайн? Або випадково, або усвідомлено. Випадково вдалий дизайн мало кого цікавить, тому розглянемо, як робити хороший дизайн усвідомлено. Одним з кращих та плідних способів зробити хороший дизайн - є аналіз власних та чужих помилок, які були зроблені при рішенні даної задачі. Так, саме аналіз помилок, оскільки аналіз вдалих рішень не призвиде ні до чого окрім подальшого шаблонного копіювання існуючого рішення, яке згодом може стати неправельним. А аналіз помилок, як мінімум, дасть нам змогу уникнути їх в майбутньому. А щоб бачити помилки, треба просто дивитися. <br /> [http://www.artlebedev.ru/kovodstvo/sections/95/ Читати оригінал]<br /> <br /> --[[Користувач:I_Shevchenko|Шевченко Ігор]] 18:44, 15 березня 2012 (EET)</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D0%B0%D1%80%D0%B0%D0%B3%D1%80%D0%B0%D1%84%D0%B8_%D0%90%D1%80%D1%82%D1%94%D0%BC%D1%96%D1%8F_%D0%9B%D1%94%D0%B1%D1%94%D0%B4%D1%94%D0%B2%D0%B0 2012-03-15T16:47:30Z

<p>I Shevchenko: </p> <hr /> <div>==§ 50. О статусной строке==<br /> <br /> Не можна втручатися в звичний стандартний інтерфейс і не можна ховати його елементи в ситуаціях, коли людина їх очікує.<br /> <br /> &lt;&lt;— Каков ваш статус, Лена? Проще говоря, каков ваш социум эр актум? С. Довлатов.&gt;&gt;<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/50/ Переглянути повністю]<br /> <br /> ==§ 55. Как писать слово «интернет»?==<br /> <br /> Освітченість &quot;світлин&quot; філологічних наук бажає бути кращою.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/55/ Оригінал станні]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:56, 20 грудня 2011 (EET)<br /> <br /> ==§ 60. Э... коммерция==<br /> <br /> Електронна комерція існує, чи це лише маркетинговий хід?<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/60/ Оригінал статті]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:59, 20 грудня 2011 (EET)<br /> <br /> ==§ 119. Буква Ё==<br /> <br /> Про значення букви &quot;Ё&quot; її правила вживання, труднощі які вона викликає при вживанні, її переваги та недоліки.<br /> <br /> Ё — недобуква. Використання &quot;Ё&quot; скрізь - насильство над читачем.<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/119/ Переглянути повністю]<br /> <br /> ==§ 161. Ідея на мінус мільйон==<br /> <br /> Про ціну винаходу. Для реалізації більшості ідей потрібно затратити більше коштів ніж ти від цього отримаеш прибутку)<br /> <br /> &quot;Кожен винахідник, або дизайнер, який розповідає про свою ідею, повинен чесно говорити: «У мене є ідея на мінус мільйон». &quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/161/ Прочитати повністю]<br /> <br /> <br /> == § 162. Творча криза==<br /> <br /> Творча криза - це глухий кут шляху без сенсу.<br /> <br /> Оригінальне і незвичайне неможливо придумати, воно з'являється тільки в результаті роботи над поставленою задачею.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/162/ Прочитати повністю]<br /> <br /> --[[Користувач:Gorduarabey|Gorduarabey]] 09:47, 23 листопада 2010 (EET)<br /> <br /> <br /> == § 145. Безглузда презентація==<br /> <br /> &quot;Краща презентація та, яку не показали.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/145/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> <br /> == § 147. Простота ≠ примітивність==<br /> <br /> &quot;Дизайн повинен бути простим, але не примітивним.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/147/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> ==Артемий Лебедев соц проэкт==<br /> &quot;Улучшение дорожных знаков в Киеве&quot; <br /> http://www.artlebedev.ru/kovodstvo/business-lynch/2009/06/15/commented/<br /> --[[Користувач:Alex46|Alex46]] 13:58, 21 грудня 2010 (EET)<br /> ==Организация пешеходных переходов с подсветкой в Тюмени==<br /> http://habrahabr.ru/blogs/design/44390/<br /> --[[Користувач:Alex46|Alex46]] 13:59, 21 грудня 2010 (EET)<br /> <br /> == § 166. Повітря спільне ==<br /> <br /> &quot;У кожної реклами повинно бути чітко окреслене місце&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/166/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> == § 150. От обратного ==<br /> <br /> &quot;Один з найефективніших дизайнерських прийомів - придумування незручних, незрозумілих і заплутаних рішень.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/150/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> ==§ 163 Правила написання поштових адрес ==<br /> <br /> Раніше реквізити адреси прийнято було писати від більшого до меншого: країна, індекс, місто, вулиця, будинок, квартира, ПІБ. У світі прийнята інша система складання адреси, тому що в світі відправляють багато пошти і дбають про те, щоб вона швидше доходила до місця призначення<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/163/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:08, 4 січня 2011 (EET)<br /> <br /> ==§ 112 Амперсанд ==<br /> <br /> Амперсанд - це назва знака &amp;. Про нього треба знати три речі: звідки він узявся, чому так називається і чи потрібен він нам для чого-небудь.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/112/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:11, 4 січня 2011 (EET)<br /> <br /> ==§ 138. Кофе — оно ==<br /> <br /> Ознакою псевдоінтеллігентності є зауваження «кави - він». Зазвичай так говорять люди, які не помічають цих помилок у мовленні.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/138/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:48, 5 січня 2011 (EET)<br /> <br /> ==§ 103. Хочу как у них ==<br /> <br /> Знаки принадлежщие компаниям с превосходными, узнаваемыми, образцовыми товарами и услугами и подрожание им.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/103/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:55, 5 січня 2011 (EET)<br /> <br /> ==§ 165. Три правила про ви==<br /> <br /> У російській мові існує займенник ви, до якого додаються досить прості правила вживання і невживання.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/165/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 164. Три крапки==<br /> <br /> Всім відомі три крапки ...<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/164/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 149. Решение задач==<br /> <br /> Автор уверен, что дизайн является решением задач, а не творчеством. Дизайнер, который считает, что дизайн — это когда надо сделать красиво, просто не понимает смысла профессии.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/149/ Прочитати повністю]<br /> <br /> --[[Користувач:Kat|Kat]] 11:30, 19 січня 2011 (EET)<br /> <br /> ==§ 152. Патент краток, язык — вечен==<br /> <br /> [[§ 152. Патент краток, язык — вечен]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:53, 01 грудня 2011 (EET)<br /> <br /> <br /> ==§ 148. Единица смысла==<br /> <br /> [[§ 148. Единица смысла]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:57, 01 грудня 2011 (EET)<br /> <br /> ==§ 158. Коротке тире ==<br /> <br /> В даному параграфі А. Лєбєдєв стверджує, що в текстах діапазони як і раніше будуть позначатися з допомогою довгого тире а в номерах телефонів залишиться коротке. При позначенні діапазонів в числах планується ввести коротке тире, а не те що є на даний час, яке довжиною дорівнює &quot;N&quot;.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/158/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:26, 6 грудня 2011 (EET)<br /> <br /> ==§ 167. Метод прогресивного джіпєга ==<br /> <br /> В цій статті автор пропонує інший метод завантаження зображень.<br /> <br /> &quot;Час витрачається тільки на нужну степінь прожарювання, а загальний вигляд стейка завжди є.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/167/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:30, 6 грудня 2011 (EET)<br /> <br /> ==§ 171. Правила оформлення посилань==<br /> <br /> В статті автор розповідає про основні правила, яких слід дотримуватись при оформленні посилань.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/171/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 156. Дизайн - це війна==<br /> <br /> В статті на прикладі боротьби виробників тютюну з противниками тютюнопаління розповідається про те, як за допомогою знання психології сприйняття, за допомогою дизайнерських прийомів противники придумують нові способи боротьби один з одним.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/156/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 169. Підписи на фотографіях==<br /> <br /> Стаття про те, як не перетворитися з чудового фотографа у жахливого дизайнера. Оскільки неправельний підпис фотографії може погубити будь-який шедевр. <br /> &lt;br&gt;'''Правило:''' не потрібно перетворювати підпис фотографії у рекламу. <br /> [http://www.artlebedev.ru/kovodstvo/sections/169/ Читати оригінал]<br /> <br /> --[[Користувач:I_Shevchenko|Шевченко Ігор]] 18:13, 15 березня 2012 (EET)<br /> <br /> ==§ 95. Заявка на дизайн==<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/95/ Читати оригінал]<br /> <br /> --[[Користувач:I_Shevchenko|Шевченко Ігор]] 18:44, 15 березня 2012 (EET)</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D0%B0%D1%80%D0%B0%D0%B3%D1%80%D0%B0%D1%84%D0%B8_%D0%90%D1%80%D1%82%D1%94%D0%BC%D1%96%D1%8F_%D0%9B%D1%94%D0%B1%D1%94%D0%B4%D1%94%D0%B2%D0%B0 2012-03-15T16:17:57Z

<p>I Shevchenko: /* § 169. Підписи на фотографіях */</p> <hr /> <div>==§ 50. О статусной строке==<br /> <br /> Не можна втручатися в звичний стандартний інтерфейс і не можна ховати його елементи в ситуаціях, коли людина їх очікує.<br /> <br /> &lt;&lt;— Каков ваш статус, Лена? Проще говоря, каков ваш социум эр актум? С. Довлатов.&gt;&gt;<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/50/ Переглянути повністю]<br /> <br /> ==§ 55. Как писать слово «интернет»?==<br /> <br /> Освітченість &quot;світлин&quot; філологічних наук бажає бути кращою.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/55/ Оригінал станні]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:56, 20 грудня 2011 (EET)<br /> <br /> ==§ 60. Э... коммерция==<br /> <br /> Електронна комерція існує, чи це лише маркетинговий хід?<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/60/ Оригінал статті]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:59, 20 грудня 2011 (EET)<br /> <br /> ==§ 119. Буква Ё==<br /> <br /> Про значення букви &quot;Ё&quot; її правила вживання, труднощі які вона викликає при вживанні, її переваги та недоліки.<br /> <br /> Ё — недобуква. Використання &quot;Ё&quot; скрізь - насильство над читачем.<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/119/ Переглянути повністю]<br /> <br /> ==§ 161. Ідея на мінус мільйон==<br /> <br /> Про ціну винаходу. Для реалізації більшості ідей потрібно затратити більше коштів ніж ти від цього отримаеш прибутку)<br /> <br /> &quot;Кожен винахідник, або дизайнер, який розповідає про свою ідею, повинен чесно говорити: «У мене є ідея на мінус мільйон». &quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/161/ Прочитати повністю]<br /> <br /> <br /> == § 162. Творча криза==<br /> <br /> Творча криза - це глухий кут шляху без сенсу.<br /> <br /> Оригінальне і незвичайне неможливо придумати, воно з'являється тільки в результаті роботи над поставленою задачею.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/162/ Прочитати повністю]<br /> <br /> --[[Користувач:Gorduarabey|Gorduarabey]] 09:47, 23 листопада 2010 (EET)<br /> <br /> <br /> == § 145. Безглузда презентація==<br /> <br /> &quot;Краща презентація та, яку не показали.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/145/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> <br /> == § 147. Простота ≠ примітивність==<br /> <br /> &quot;Дизайн повинен бути простим, але не примітивним.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/147/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> ==Артемий Лебедев соц проэкт==<br /> &quot;Улучшение дорожных знаков в Киеве&quot; <br /> http://www.artlebedev.ru/kovodstvo/business-lynch/2009/06/15/commented/<br /> --[[Користувач:Alex46|Alex46]] 13:58, 21 грудня 2010 (EET)<br /> ==Организация пешеходных переходов с подсветкой в Тюмени==<br /> http://habrahabr.ru/blogs/design/44390/<br /> --[[Користувач:Alex46|Alex46]] 13:59, 21 грудня 2010 (EET)<br /> <br /> == § 166. Повітря спільне ==<br /> <br /> &quot;У кожної реклами повинно бути чітко окреслене місце&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/166/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> == § 150. От обратного ==<br /> <br /> &quot;Один з найефективніших дизайнерських прийомів - придумування незручних, незрозумілих і заплутаних рішень.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/150/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> ==§ 163 Правила написання поштових адрес ==<br /> <br /> Раніше реквізити адреси прийнято було писати від більшого до меншого: країна, індекс, місто, вулиця, будинок, квартира, ПІБ. У світі прийнята інша система складання адреси, тому що в світі відправляють багато пошти і дбають про те, щоб вона швидше доходила до місця призначення<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/163/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:08, 4 січня 2011 (EET)<br /> <br /> ==§ 112 Амперсанд ==<br /> <br /> Амперсанд - це назва знака &amp;. Про нього треба знати три речі: звідки він узявся, чому так називається і чи потрібен він нам для чого-небудь.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/112/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:11, 4 січня 2011 (EET)<br /> <br /> ==§ 138. Кофе — оно ==<br /> <br /> Ознакою псевдоінтеллігентності є зауваження «кави - він». Зазвичай так говорять люди, які не помічають цих помилок у мовленні.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/138/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:48, 5 січня 2011 (EET)<br /> <br /> ==§ 103. Хочу как у них ==<br /> <br /> Знаки принадлежщие компаниям с превосходными, узнаваемыми, образцовыми товарами и услугами и подрожание им.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/103/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:55, 5 січня 2011 (EET)<br /> <br /> ==§ 165. Три правила про ви==<br /> <br /> У російській мові існує займенник ви, до якого додаються досить прості правила вживання і невживання.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/165/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 164. Три крапки==<br /> <br /> Всім відомі три крапки ...<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/164/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 149. Решение задач==<br /> <br /> Автор уверен, что дизайн является решением задач, а не творчеством. Дизайнер, который считает, что дизайн — это когда надо сделать красиво, просто не понимает смысла профессии.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/149/ Прочитати повністю]<br /> <br /> --[[Користувач:Kat|Kat]] 11:30, 19 січня 2011 (EET)<br /> <br /> ==§ 152. Патент краток, язык — вечен==<br /> <br /> [[§ 152. Патент краток, язык — вечен]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:53, 01 грудня 2011 (EET)<br /> <br /> <br /> ==§ 148. Единица смысла==<br /> <br /> [[§ 148. Единица смысла]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:57, 01 грудня 2011 (EET)<br /> <br /> ==§ 158. Коротке тире ==<br /> <br /> В даному параграфі А. Лєбєдєв стверджує, що в текстах діапазони як і раніше будуть позначатися з допомогою довгого тире а в номерах телефонів залишиться коротке. При позначенні діапазонів в числах планується ввести коротке тире, а не те що є на даний час, яке довжиною дорівнює &quot;N&quot;.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/158/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:26, 6 грудня 2011 (EET)<br /> <br /> ==§ 167. Метод прогресивного джіпєга ==<br /> <br /> В цій статті автор пропонує інший метод завантаження зображень.<br /> <br /> &quot;Час витрачається тільки на нужну степінь прожарювання, а загальний вигляд стейка завжди є.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/167/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:30, 6 грудня 2011 (EET)<br /> <br /> ==§ 171. Правила оформлення посилань==<br /> <br /> В статті автор розповідає про основні правила, яких слід дотримуватись при оформленні посилань.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/171/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 156. Дизайн - це війна==<br /> <br /> В статті на прикладі боротьби виробників тютюну з противниками тютюнопаління розповідається про те, як за допомогою знання психології сприйняття, за допомогою дизайнерських прийомів противники придумують нові способи боротьби один з одним.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/156/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 169. Підписи на фотографіях==<br /> <br /> Стаття про те, як не перетворитися з чудового фотографа у жахливого дизайнера. Оскільки неправельний підпис фотографії може погубити будь-який шедевр. <br /> &lt;br&gt;'''Правило:''' не потрібно перетворювати підпис фотографії у рекламу. <br /> [http://www.artlebedev.ru/kovodstvo/sections/169/ Читати оригінал]<br /> <br /> --[[Користувач:I_Shevchenko|Шевченко Ігор]] 18:13, 15 березня 2012 (EET)</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D0%B0%D1%80%D0%B0%D0%B3%D1%80%D0%B0%D1%84%D0%B8_%D0%90%D1%80%D1%82%D1%94%D0%BC%D1%96%D1%8F_%D0%9B%D1%94%D0%B1%D1%94%D0%B4%D1%94%D0%B2%D0%B0 2012-03-15T16:17:44Z

<p>I Shevchenko: /* § 169. Підписи на фотографіях */</p> <hr /> <div>==§ 50. О статусной строке==<br /> <br /> Не можна втручатися в звичний стандартний інтерфейс і не можна ховати його елементи в ситуаціях, коли людина їх очікує.<br /> <br /> &lt;&lt;— Каков ваш статус, Лена? Проще говоря, каков ваш социум эр актум? С. Довлатов.&gt;&gt;<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/50/ Переглянути повністю]<br /> <br /> ==§ 55. Как писать слово «интернет»?==<br /> <br /> Освітченість &quot;світлин&quot; філологічних наук бажає бути кращою.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/55/ Оригінал станні]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:56, 20 грудня 2011 (EET)<br /> <br /> ==§ 60. Э... коммерция==<br /> <br /> Електронна комерція існує, чи це лише маркетинговий хід?<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/60/ Оригінал статті]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:59, 20 грудня 2011 (EET)<br /> <br /> ==§ 119. Буква Ё==<br /> <br /> Про значення букви &quot;Ё&quot; її правила вживання, труднощі які вона викликає при вживанні, її переваги та недоліки.<br /> <br /> Ё — недобуква. Використання &quot;Ё&quot; скрізь - насильство над читачем.<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/119/ Переглянути повністю]<br /> <br /> ==§ 161. Ідея на мінус мільйон==<br /> <br /> Про ціну винаходу. Для реалізації більшості ідей потрібно затратити більше коштів ніж ти від цього отримаеш прибутку)<br /> <br /> &quot;Кожен винахідник, або дизайнер, який розповідає про свою ідею, повинен чесно говорити: «У мене є ідея на мінус мільйон». &quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/161/ Прочитати повністю]<br /> <br /> <br /> == § 162. Творча криза==<br /> <br /> Творча криза - це глухий кут шляху без сенсу.<br /> <br /> Оригінальне і незвичайне неможливо придумати, воно з'являється тільки в результаті роботи над поставленою задачею.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/162/ Прочитати повністю]<br /> <br /> --[[Користувач:Gorduarabey|Gorduarabey]] 09:47, 23 листопада 2010 (EET)<br /> <br /> <br /> == § 145. Безглузда презентація==<br /> <br /> &quot;Краща презентація та, яку не показали.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/145/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> <br /> == § 147. Простота ≠ примітивність==<br /> <br /> &quot;Дизайн повинен бути простим, але не примітивним.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/147/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> ==Артемий Лебедев соц проэкт==<br /> &quot;Улучшение дорожных знаков в Киеве&quot; <br /> http://www.artlebedev.ru/kovodstvo/business-lynch/2009/06/15/commented/<br /> --[[Користувач:Alex46|Alex46]] 13:58, 21 грудня 2010 (EET)<br /> ==Организация пешеходных переходов с подсветкой в Тюмени==<br /> http://habrahabr.ru/blogs/design/44390/<br /> --[[Користувач:Alex46|Alex46]] 13:59, 21 грудня 2010 (EET)<br /> <br /> == § 166. Повітря спільне ==<br /> <br /> &quot;У кожної реклами повинно бути чітко окреслене місце&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/166/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> == § 150. От обратного ==<br /> <br /> &quot;Один з найефективніших дизайнерських прийомів - придумування незручних, незрозумілих і заплутаних рішень.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/150/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> ==§ 163 Правила написання поштових адрес ==<br /> <br /> Раніше реквізити адреси прийнято було писати від більшого до меншого: країна, індекс, місто, вулиця, будинок, квартира, ПІБ. У світі прийнята інша система складання адреси, тому що в світі відправляють багато пошти і дбають про те, щоб вона швидше доходила до місця призначення<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/163/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:08, 4 січня 2011 (EET)<br /> <br /> ==§ 112 Амперсанд ==<br /> <br /> Амперсанд - це назва знака &amp;. Про нього треба знати три речі: звідки він узявся, чому так називається і чи потрібен він нам для чого-небудь.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/112/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:11, 4 січня 2011 (EET)<br /> <br /> ==§ 138. Кофе — оно ==<br /> <br /> Ознакою псевдоінтеллігентності є зауваження «кави - він». Зазвичай так говорять люди, які не помічають цих помилок у мовленні.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/138/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:48, 5 січня 2011 (EET)<br /> <br /> ==§ 103. Хочу как у них ==<br /> <br /> Знаки принадлежщие компаниям с превосходными, узнаваемыми, образцовыми товарами и услугами и подрожание им.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/103/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:55, 5 січня 2011 (EET)<br /> <br /> ==§ 165. Три правила про ви==<br /> <br /> У російській мові існує займенник ви, до якого додаються досить прості правила вживання і невживання.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/165/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 164. Три крапки==<br /> <br /> Всім відомі три крапки ...<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/164/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 149. Решение задач==<br /> <br /> Автор уверен, что дизайн является решением задач, а не творчеством. Дизайнер, который считает, что дизайн — это когда надо сделать красиво, просто не понимает смысла профессии.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/149/ Прочитати повністю]<br /> <br /> --[[Користувач:Kat|Kat]] 11:30, 19 січня 2011 (EET)<br /> <br /> ==§ 152. Патент краток, язык — вечен==<br /> <br /> [[§ 152. Патент краток, язык — вечен]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:53, 01 грудня 2011 (EET)<br /> <br /> <br /> ==§ 148. Единица смысла==<br /> <br /> [[§ 148. Единица смысла]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:57, 01 грудня 2011 (EET)<br /> <br /> ==§ 158. Коротке тире ==<br /> <br /> В даному параграфі А. Лєбєдєв стверджує, що в текстах діапазони як і раніше будуть позначатися з допомогою довгого тире а в номерах телефонів залишиться коротке. При позначенні діапазонів в числах планується ввести коротке тире, а не те що є на даний час, яке довжиною дорівнює &quot;N&quot;.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/158/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:26, 6 грудня 2011 (EET)<br /> <br /> ==§ 167. Метод прогресивного джіпєга ==<br /> <br /> В цій статті автор пропонує інший метод завантаження зображень.<br /> <br /> &quot;Час витрачається тільки на нужну степінь прожарювання, а загальний вигляд стейка завжди є.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/167/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:30, 6 грудня 2011 (EET)<br /> <br /> ==§ 171. Правила оформлення посилань==<br /> <br /> В статті автор розповідає про основні правила, яких слід дотримуватись при оформленні посилань.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/171/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 156. Дизайн - це війна==<br /> <br /> В статті на прикладі боротьби виробників тютюну з противниками тютюнопаління розповідається про те, як за допомогою знання психології сприйняття, за допомогою дизайнерських прийомів противники придумують нові способи боротьби один з одним.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/156/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 169. Підписи на фотографіях==<br /> <br /> Стаття про те, як не перетворитися з чудового фотографа у жахливого дизайнера. Оскільки неправельний підпис фотографії може погубити будь-який шедевр. <br /> &lt;br&gt;'''Правило:''' не потрібно перетворювати підпис фотографії у рекламу. <br /> [http://www.artlebedev.ru/kovodstvo/sections/169/ Читати оригінал]<br /> <br /> &lt;br&gt;--[[Користувач:I_Shevchenko|Шевченко Ігор]] 18:13, 15 березня 2012 (EET)</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D0%B0%D1%80%D0%B0%D0%B3%D1%80%D0%B0%D1%84%D0%B8_%D0%90%D1%80%D1%82%D1%94%D0%BC%D1%96%D1%8F_%D0%9B%D1%94%D0%B1%D1%94%D0%B4%D1%94%D0%B2%D0%B0 2012-03-15T16:17:19Z

<p>I Shevchenko: /* § 169. Підписи на фотографіях */</p> <hr /> <div>==§ 50. О статусной строке==<br /> <br /> Не можна втручатися в звичний стандартний інтерфейс і не можна ховати його елементи в ситуаціях, коли людина їх очікує.<br /> <br /> &lt;&lt;— Каков ваш статус, Лена? Проще говоря, каков ваш социум эр актум? С. Довлатов.&gt;&gt;<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/50/ Переглянути повністю]<br /> <br /> ==§ 55. Как писать слово «интернет»?==<br /> <br /> Освітченість &quot;світлин&quot; філологічних наук бажає бути кращою.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/55/ Оригінал станні]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:56, 20 грудня 2011 (EET)<br /> <br /> ==§ 60. Э... коммерция==<br /> <br /> Електронна комерція існує, чи це лише маркетинговий хід?<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/60/ Оригінал статті]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:59, 20 грудня 2011 (EET)<br /> <br /> ==§ 119. Буква Ё==<br /> <br /> Про значення букви &quot;Ё&quot; її правила вживання, труднощі які вона викликає при вживанні, її переваги та недоліки.<br /> <br /> Ё — недобуква. Використання &quot;Ё&quot; скрізь - насильство над читачем.<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/119/ Переглянути повністю]<br /> <br /> ==§ 161. Ідея на мінус мільйон==<br /> <br /> Про ціну винаходу. Для реалізації більшості ідей потрібно затратити більше коштів ніж ти від цього отримаеш прибутку)<br /> <br /> &quot;Кожен винахідник, або дизайнер, який розповідає про свою ідею, повинен чесно говорити: «У мене є ідея на мінус мільйон». &quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/161/ Прочитати повністю]<br /> <br /> <br /> == § 162. Творча криза==<br /> <br /> Творча криза - це глухий кут шляху без сенсу.<br /> <br /> Оригінальне і незвичайне неможливо придумати, воно з'являється тільки в результаті роботи над поставленою задачею.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/162/ Прочитати повністю]<br /> <br /> --[[Користувач:Gorduarabey|Gorduarabey]] 09:47, 23 листопада 2010 (EET)<br /> <br /> <br /> == § 145. Безглузда презентація==<br /> <br /> &quot;Краща презентація та, яку не показали.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/145/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> <br /> == § 147. Простота ≠ примітивність==<br /> <br /> &quot;Дизайн повинен бути простим, але не примітивним.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/147/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> ==Артемий Лебедев соц проэкт==<br /> &quot;Улучшение дорожных знаков в Киеве&quot; <br /> http://www.artlebedev.ru/kovodstvo/business-lynch/2009/06/15/commented/<br /> --[[Користувач:Alex46|Alex46]] 13:58, 21 грудня 2010 (EET)<br /> ==Организация пешеходных переходов с подсветкой в Тюмени==<br /> http://habrahabr.ru/blogs/design/44390/<br /> --[[Користувач:Alex46|Alex46]] 13:59, 21 грудня 2010 (EET)<br /> <br /> == § 166. Повітря спільне ==<br /> <br /> &quot;У кожної реклами повинно бути чітко окреслене місце&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/166/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> == § 150. От обратного ==<br /> <br /> &quot;Один з найефективніших дизайнерських прийомів - придумування незручних, незрозумілих і заплутаних рішень.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/150/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> ==§ 163 Правила написання поштових адрес ==<br /> <br /> Раніше реквізити адреси прийнято було писати від більшого до меншого: країна, індекс, місто, вулиця, будинок, квартира, ПІБ. У світі прийнята інша система складання адреси, тому що в світі відправляють багато пошти і дбають про те, щоб вона швидше доходила до місця призначення<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/163/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:08, 4 січня 2011 (EET)<br /> <br /> ==§ 112 Амперсанд ==<br /> <br /> Амперсанд - це назва знака &amp;. Про нього треба знати три речі: звідки він узявся, чому так називається і чи потрібен він нам для чого-небудь.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/112/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:11, 4 січня 2011 (EET)<br /> <br /> ==§ 138. Кофе — оно ==<br /> <br /> Ознакою псевдоінтеллігентності є зауваження «кави - він». Зазвичай так говорять люди, які не помічають цих помилок у мовленні.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/138/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:48, 5 січня 2011 (EET)<br /> <br /> ==§ 103. Хочу как у них ==<br /> <br /> Знаки принадлежщие компаниям с превосходными, узнаваемыми, образцовыми товарами и услугами и подрожание им.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/103/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:55, 5 січня 2011 (EET)<br /> <br /> ==§ 165. Три правила про ви==<br /> <br /> У російській мові існує займенник ви, до якого додаються досить прості правила вживання і невживання.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/165/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 164. Три крапки==<br /> <br /> Всім відомі три крапки ...<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/164/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 149. Решение задач==<br /> <br /> Автор уверен, что дизайн является решением задач, а не творчеством. Дизайнер, который считает, что дизайн — это когда надо сделать красиво, просто не понимает смысла профессии.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/149/ Прочитати повністю]<br /> <br /> --[[Користувач:Kat|Kat]] 11:30, 19 січня 2011 (EET)<br /> <br /> ==§ 152. Патент краток, язык — вечен==<br /> <br /> [[§ 152. Патент краток, язык — вечен]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:53, 01 грудня 2011 (EET)<br /> <br /> <br /> ==§ 148. Единица смысла==<br /> <br /> [[§ 148. Единица смысла]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:57, 01 грудня 2011 (EET)<br /> <br /> ==§ 158. Коротке тире ==<br /> <br /> В даному параграфі А. Лєбєдєв стверджує, що в текстах діапазони як і раніше будуть позначатися з допомогою довгого тире а в номерах телефонів залишиться коротке. При позначенні діапазонів в числах планується ввести коротке тире, а не те що є на даний час, яке довжиною дорівнює &quot;N&quot;.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/158/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:26, 6 грудня 2011 (EET)<br /> <br /> ==§ 167. Метод прогресивного джіпєга ==<br /> <br /> В цій статті автор пропонує інший метод завантаження зображень.<br /> <br /> &quot;Час витрачається тільки на нужну степінь прожарювання, а загальний вигляд стейка завжди є.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/167/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:30, 6 грудня 2011 (EET)<br /> <br /> ==§ 171. Правила оформлення посилань==<br /> <br /> В статті автор розповідає про основні правила, яких слід дотримуватись при оформленні посилань.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/171/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 156. Дизайн - це війна==<br /> <br /> В статті на прикладі боротьби виробників тютюну з противниками тютюнопаління розповідається про те, як за допомогою знання психології сприйняття, за допомогою дизайнерських прийомів противники придумують нові способи боротьби один з одним.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/156/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 169. Підписи на фотографіях==<br /> <br /> Стаття про те, як не перетворитися з чудового фотографа у жахливого дизайнера. Оскільки неправельний підпис фотографії може погубити будь-який шедевр. <br /> <br /> &lt;br&gt;'''Правило:''' не потрібно перетворювати підпис фотографії у рекламу. <br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/169/ Читати оригінал]<br /> <br /> &lt;br&gt;--[[Користувач:I_Shevchenko|Шевченко Ігор]] 18:13, 15 березня 2012 (EET)</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D0%B0%D1%80%D0%B0%D0%B3%D1%80%D0%B0%D1%84%D0%B8_%D0%90%D1%80%D1%82%D1%94%D0%BC%D1%96%D1%8F_%D0%9B%D1%94%D0%B1%D1%94%D0%B4%D1%94%D0%B2%D0%B0 2012-03-15T16:16:43Z

<p>I Shevchenko: /* § 169. Підписи на фотографіях */</p> <hr /> <div>==§ 50. О статусной строке==<br /> <br /> Не можна втручатися в звичний стандартний інтерфейс і не можна ховати його елементи в ситуаціях, коли людина їх очікує.<br /> <br /> &lt;&lt;— Каков ваш статус, Лена? Проще говоря, каков ваш социум эр актум? С. Довлатов.&gt;&gt;<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/50/ Переглянути повністю]<br /> <br /> ==§ 55. Как писать слово «интернет»?==<br /> <br /> Освітченість &quot;світлин&quot; філологічних наук бажає бути кращою.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/55/ Оригінал станні]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:56, 20 грудня 2011 (EET)<br /> <br /> ==§ 60. Э... коммерция==<br /> <br /> Електронна комерція існує, чи це лише маркетинговий хід?<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/60/ Оригінал статті]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:59, 20 грудня 2011 (EET)<br /> <br /> ==§ 119. Буква Ё==<br /> <br /> Про значення букви &quot;Ё&quot; її правила вживання, труднощі які вона викликає при вживанні, її переваги та недоліки.<br /> <br /> Ё — недобуква. Використання &quot;Ё&quot; скрізь - насильство над читачем.<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/119/ Переглянути повністю]<br /> <br /> ==§ 161. Ідея на мінус мільйон==<br /> <br /> Про ціну винаходу. Для реалізації більшості ідей потрібно затратити більше коштів ніж ти від цього отримаеш прибутку)<br /> <br /> &quot;Кожен винахідник, або дизайнер, який розповідає про свою ідею, повинен чесно говорити: «У мене є ідея на мінус мільйон». &quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/161/ Прочитати повністю]<br /> <br /> <br /> == § 162. Творча криза==<br /> <br /> Творча криза - це глухий кут шляху без сенсу.<br /> <br /> Оригінальне і незвичайне неможливо придумати, воно з'являється тільки в результаті роботи над поставленою задачею.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/162/ Прочитати повністю]<br /> <br /> --[[Користувач:Gorduarabey|Gorduarabey]] 09:47, 23 листопада 2010 (EET)<br /> <br /> <br /> == § 145. Безглузда презентація==<br /> <br /> &quot;Краща презентація та, яку не показали.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/145/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> <br /> == § 147. Простота ≠ примітивність==<br /> <br /> &quot;Дизайн повинен бути простим, але не примітивним.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/147/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> ==Артемий Лебедев соц проэкт==<br /> &quot;Улучшение дорожных знаков в Киеве&quot; <br /> http://www.artlebedev.ru/kovodstvo/business-lynch/2009/06/15/commented/<br /> --[[Користувач:Alex46|Alex46]] 13:58, 21 грудня 2010 (EET)<br /> ==Организация пешеходных переходов с подсветкой в Тюмени==<br /> http://habrahabr.ru/blogs/design/44390/<br /> --[[Користувач:Alex46|Alex46]] 13:59, 21 грудня 2010 (EET)<br /> <br /> == § 166. Повітря спільне ==<br /> <br /> &quot;У кожної реклами повинно бути чітко окреслене місце&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/166/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> == § 150. От обратного ==<br /> <br /> &quot;Один з найефективніших дизайнерських прийомів - придумування незручних, незрозумілих і заплутаних рішень.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/150/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> ==§ 163 Правила написання поштових адрес ==<br /> <br /> Раніше реквізити адреси прийнято було писати від більшого до меншого: країна, індекс, місто, вулиця, будинок, квартира, ПІБ. У світі прийнята інша система складання адреси, тому що в світі відправляють багато пошти і дбають про те, щоб вона швидше доходила до місця призначення<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/163/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:08, 4 січня 2011 (EET)<br /> <br /> ==§ 112 Амперсанд ==<br /> <br /> Амперсанд - це назва знака &amp;. Про нього треба знати три речі: звідки він узявся, чому так називається і чи потрібен він нам для чого-небудь.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/112/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:11, 4 січня 2011 (EET)<br /> <br /> ==§ 138. Кофе — оно ==<br /> <br /> Ознакою псевдоінтеллігентності є зауваження «кави - він». Зазвичай так говорять люди, які не помічають цих помилок у мовленні.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/138/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:48, 5 січня 2011 (EET)<br /> <br /> ==§ 103. Хочу как у них ==<br /> <br /> Знаки принадлежщие компаниям с превосходными, узнаваемыми, образцовыми товарами и услугами и подрожание им.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/103/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:55, 5 січня 2011 (EET)<br /> <br /> ==§ 165. Три правила про ви==<br /> <br /> У російській мові існує займенник ви, до якого додаються досить прості правила вживання і невживання.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/165/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 164. Три крапки==<br /> <br /> Всім відомі три крапки ...<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/164/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 149. Решение задач==<br /> <br /> Автор уверен, что дизайн является решением задач, а не творчеством. Дизайнер, который считает, что дизайн — это когда надо сделать красиво, просто не понимает смысла профессии.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/149/ Прочитати повністю]<br /> <br /> --[[Користувач:Kat|Kat]] 11:30, 19 січня 2011 (EET)<br /> <br /> ==§ 152. Патент краток, язык — вечен==<br /> <br /> [[§ 152. Патент краток, язык — вечен]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:53, 01 грудня 2011 (EET)<br /> <br /> <br /> ==§ 148. Единица смысла==<br /> <br /> [[§ 148. Единица смысла]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:57, 01 грудня 2011 (EET)<br /> <br /> ==§ 158. Коротке тире ==<br /> <br /> В даному параграфі А. Лєбєдєв стверджує, що в текстах діапазони як і раніше будуть позначатися з допомогою довгого тире а в номерах телефонів залишиться коротке. При позначенні діапазонів в числах планується ввести коротке тире, а не те що є на даний час, яке довжиною дорівнює &quot;N&quot;.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/158/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:26, 6 грудня 2011 (EET)<br /> <br /> ==§ 167. Метод прогресивного джіпєга ==<br /> <br /> В цій статті автор пропонує інший метод завантаження зображень.<br /> <br /> &quot;Час витрачається тільки на нужну степінь прожарювання, а загальний вигляд стейка завжди є.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/167/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:30, 6 грудня 2011 (EET)<br /> <br /> ==§ 171. Правила оформлення посилань==<br /> <br /> В статті автор розповідає про основні правила, яких слід дотримуватись при оформленні посилань.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/171/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 156. Дизайн - це війна==<br /> <br /> В статті на прикладі боротьби виробників тютюну з противниками тютюнопаління розповідається про те, як за допомогою знання психології сприйняття, за допомогою дизайнерських прийомів противники придумують нові способи боротьби один з одним.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/156/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 169. Підписи на фотографіях==<br /> Стаття про те, як не перетворитися з чудового фотографа у жахливого дизайнера. Оскільки неправельний підпис фотографії може погубити будь-який шедевр. <br /> &lt;br&gt;'''Правило:''' не потрібно перетворювати підпис фотографії у рекламу. <br /> [http://www.artlebedev.ru/kovodstvo/sections/169/ Читати оригінал]<br /> &lt;br&gt;--[[Користувач:I_Shevchenko|Шевченко Ігор]] 18:13, 15 березня 2012 (EET)</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D0%B0%D1%80%D0%B0%D0%B3%D1%80%D0%B0%D1%84%D0%B8_%D0%90%D1%80%D1%82%D1%94%D0%BC%D1%96%D1%8F_%D0%9B%D1%94%D0%B1%D1%94%D0%B4%D1%94%D0%B2%D0%B0 2012-03-15T16:16:14Z

<p>I Shevchenko: /* § 169. Підписи на фотографіях */</p> <hr /> <div>==§ 50. О статусной строке==<br /> <br /> Не можна втручатися в звичний стандартний інтерфейс і не можна ховати його елементи в ситуаціях, коли людина їх очікує.<br /> <br /> &lt;&lt;— Каков ваш статус, Лена? Проще говоря, каков ваш социум эр актум? С. Довлатов.&gt;&gt;<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/50/ Переглянути повністю]<br /> <br /> ==§ 55. Как писать слово «интернет»?==<br /> <br /> Освітченість &quot;світлин&quot; філологічних наук бажає бути кращою.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/55/ Оригінал станні]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:56, 20 грудня 2011 (EET)<br /> <br /> ==§ 60. Э... коммерция==<br /> <br /> Електронна комерція існує, чи це лише маркетинговий хід?<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/60/ Оригінал статті]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:59, 20 грудня 2011 (EET)<br /> <br /> ==§ 119. Буква Ё==<br /> <br /> Про значення букви &quot;Ё&quot; її правила вживання, труднощі які вона викликає при вживанні, її переваги та недоліки.<br /> <br /> Ё — недобуква. Використання &quot;Ё&quot; скрізь - насильство над читачем.<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/119/ Переглянути повністю]<br /> <br /> ==§ 161. Ідея на мінус мільйон==<br /> <br /> Про ціну винаходу. Для реалізації більшості ідей потрібно затратити більше коштів ніж ти від цього отримаеш прибутку)<br /> <br /> &quot;Кожен винахідник, або дизайнер, який розповідає про свою ідею, повинен чесно говорити: «У мене є ідея на мінус мільйон». &quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/161/ Прочитати повністю]<br /> <br /> <br /> == § 162. Творча криза==<br /> <br /> Творча криза - це глухий кут шляху без сенсу.<br /> <br /> Оригінальне і незвичайне неможливо придумати, воно з'являється тільки в результаті роботи над поставленою задачею.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/162/ Прочитати повністю]<br /> <br /> --[[Користувач:Gorduarabey|Gorduarabey]] 09:47, 23 листопада 2010 (EET)<br /> <br /> <br /> == § 145. Безглузда презентація==<br /> <br /> &quot;Краща презентація та, яку не показали.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/145/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> <br /> == § 147. Простота ≠ примітивність==<br /> <br /> &quot;Дизайн повинен бути простим, але не примітивним.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/147/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> ==Артемий Лебедев соц проэкт==<br /> &quot;Улучшение дорожных знаков в Киеве&quot; <br /> http://www.artlebedev.ru/kovodstvo/business-lynch/2009/06/15/commented/<br /> --[[Користувач:Alex46|Alex46]] 13:58, 21 грудня 2010 (EET)<br /> ==Организация пешеходных переходов с подсветкой в Тюмени==<br /> http://habrahabr.ru/blogs/design/44390/<br /> --[[Користувач:Alex46|Alex46]] 13:59, 21 грудня 2010 (EET)<br /> <br /> == § 166. Повітря спільне ==<br /> <br /> &quot;У кожної реклами повинно бути чітко окреслене місце&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/166/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> == § 150. От обратного ==<br /> <br /> &quot;Один з найефективніших дизайнерських прийомів - придумування незручних, незрозумілих і заплутаних рішень.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/150/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> ==§ 163 Правила написання поштових адрес ==<br /> <br /> Раніше реквізити адреси прийнято було писати від більшого до меншого: країна, індекс, місто, вулиця, будинок, квартира, ПІБ. У світі прийнята інша система складання адреси, тому що в світі відправляють багато пошти і дбають про те, щоб вона швидше доходила до місця призначення<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/163/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:08, 4 січня 2011 (EET)<br /> <br /> ==§ 112 Амперсанд ==<br /> <br /> Амперсанд - це назва знака &amp;. Про нього треба знати три речі: звідки він узявся, чому так називається і чи потрібен він нам для чого-небудь.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/112/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:11, 4 січня 2011 (EET)<br /> <br /> ==§ 138. Кофе — оно ==<br /> <br /> Ознакою псевдоінтеллігентності є зауваження «кави - він». Зазвичай так говорять люди, які не помічають цих помилок у мовленні.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/138/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:48, 5 січня 2011 (EET)<br /> <br /> ==§ 103. Хочу как у них ==<br /> <br /> Знаки принадлежщие компаниям с превосходными, узнаваемыми, образцовыми товарами и услугами и подрожание им.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/103/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:55, 5 січня 2011 (EET)<br /> <br /> ==§ 165. Три правила про ви==<br /> <br /> У російській мові існує займенник ви, до якого додаються досить прості правила вживання і невживання.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/165/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 164. Три крапки==<br /> <br /> Всім відомі три крапки ...<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/164/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 149. Решение задач==<br /> <br /> Автор уверен, что дизайн является решением задач, а не творчеством. Дизайнер, который считает, что дизайн — это когда надо сделать красиво, просто не понимает смысла профессии.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/149/ Прочитати повністю]<br /> <br /> --[[Користувач:Kat|Kat]] 11:30, 19 січня 2011 (EET)<br /> <br /> ==§ 152. Патент краток, язык — вечен==<br /> <br /> [[§ 152. Патент краток, язык — вечен]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:53, 01 грудня 2011 (EET)<br /> <br /> <br /> ==§ 148. Единица смысла==<br /> <br /> [[§ 148. Единица смысла]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:57, 01 грудня 2011 (EET)<br /> <br /> ==§ 158. Коротке тире ==<br /> <br /> В даному параграфі А. Лєбєдєв стверджує, що в текстах діапазони як і раніше будуть позначатися з допомогою довгого тире а в номерах телефонів залишиться коротке. При позначенні діапазонів в числах планується ввести коротке тире, а не те що є на даний час, яке довжиною дорівнює &quot;N&quot;.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/158/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:26, 6 грудня 2011 (EET)<br /> <br /> ==§ 167. Метод прогресивного джіпєга ==<br /> <br /> В цій статті автор пропонує інший метод завантаження зображень.<br /> <br /> &quot;Час витрачається тільки на нужну степінь прожарювання, а загальний вигляд стейка завжди є.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/167/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:30, 6 грудня 2011 (EET)<br /> <br /> ==§ 171. Правила оформлення посилань==<br /> <br /> В статті автор розповідає про основні правила, яких слід дотримуватись при оформленні посилань.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/171/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 156. Дизайн - це війна==<br /> <br /> В статті на прикладі боротьби виробників тютюну з противниками тютюнопаління розповідається про те, як за допомогою знання психології сприйняття, за допомогою дизайнерських прийомів противники придумують нові способи боротьби один з одним.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/156/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 169. Підписи на фотографіях==<br /> Стаття про те, як не перетворитися з чудового фотографа у жахливого дизайнера. Оскільки неправельний підпис фотографії може погубити будь-який шедевр. <br /> &lt;br&gt;'''Правило:''' не потрібно перетворювати підпис фотографії у рекламу. <br /> [http://www.artlebedev.ru/kovodstvo/sections/169/ Читати оригінал]<br /> --[[Користувач:I_Shevchenko|Шевченко Ігор]] 18:13, 15 березня 2012 (EET)</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D0%B0%D1%80%D0%B0%D0%B3%D1%80%D0%B0%D1%84%D0%B8_%D0%90%D1%80%D1%82%D1%94%D0%BC%D1%96%D1%8F_%D0%9B%D1%94%D0%B1%D1%94%D0%B4%D1%94%D0%B2%D0%B0 2012-03-15T16:15:26Z

<p>I Shevchenko: /* § 169. Підписи на фотографіях */</p> <hr /> <div>==§ 50. О статусной строке==<br /> <br /> Не можна втручатися в звичний стандартний інтерфейс і не можна ховати його елементи в ситуаціях, коли людина їх очікує.<br /> <br /> &lt;&lt;— Каков ваш статус, Лена? Проще говоря, каков ваш социум эр актум? С. Довлатов.&gt;&gt;<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/50/ Переглянути повністю]<br /> <br /> ==§ 55. Как писать слово «интернет»?==<br /> <br /> Освітченість &quot;світлин&quot; філологічних наук бажає бути кращою.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/55/ Оригінал станні]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:56, 20 грудня 2011 (EET)<br /> <br /> ==§ 60. Э... коммерция==<br /> <br /> Електронна комерція існує, чи це лише маркетинговий хід?<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/60/ Оригінал статті]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:59, 20 грудня 2011 (EET)<br /> <br /> ==§ 119. Буква Ё==<br /> <br /> Про значення букви &quot;Ё&quot; її правила вживання, труднощі які вона викликає при вживанні, її переваги та недоліки.<br /> <br /> Ё — недобуква. Використання &quot;Ё&quot; скрізь - насильство над читачем.<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/119/ Переглянути повністю]<br /> <br /> ==§ 161. Ідея на мінус мільйон==<br /> <br /> Про ціну винаходу. Для реалізації більшості ідей потрібно затратити більше коштів ніж ти від цього отримаеш прибутку)<br /> <br /> &quot;Кожен винахідник, або дизайнер, який розповідає про свою ідею, повинен чесно говорити: «У мене є ідея на мінус мільйон». &quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/161/ Прочитати повністю]<br /> <br /> <br /> == § 162. Творча криза==<br /> <br /> Творча криза - це глухий кут шляху без сенсу.<br /> <br /> Оригінальне і незвичайне неможливо придумати, воно з'являється тільки в результаті роботи над поставленою задачею.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/162/ Прочитати повністю]<br /> <br /> --[[Користувач:Gorduarabey|Gorduarabey]] 09:47, 23 листопада 2010 (EET)<br /> <br /> <br /> == § 145. Безглузда презентація==<br /> <br /> &quot;Краща презентація та, яку не показали.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/145/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> <br /> == § 147. Простота ≠ примітивність==<br /> <br /> &quot;Дизайн повинен бути простим, але не примітивним.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/147/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> ==Артемий Лебедев соц проэкт==<br /> &quot;Улучшение дорожных знаков в Киеве&quot; <br /> http://www.artlebedev.ru/kovodstvo/business-lynch/2009/06/15/commented/<br /> --[[Користувач:Alex46|Alex46]] 13:58, 21 грудня 2010 (EET)<br /> ==Организация пешеходных переходов с подсветкой в Тюмени==<br /> http://habrahabr.ru/blogs/design/44390/<br /> --[[Користувач:Alex46|Alex46]] 13:59, 21 грудня 2010 (EET)<br /> <br /> == § 166. Повітря спільне ==<br /> <br /> &quot;У кожної реклами повинно бути чітко окреслене місце&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/166/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> == § 150. От обратного ==<br /> <br /> &quot;Один з найефективніших дизайнерських прийомів - придумування незручних, незрозумілих і заплутаних рішень.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/150/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> ==§ 163 Правила написання поштових адрес ==<br /> <br /> Раніше реквізити адреси прийнято було писати від більшого до меншого: країна, індекс, місто, вулиця, будинок, квартира, ПІБ. У світі прийнята інша система складання адреси, тому що в світі відправляють багато пошти і дбають про те, щоб вона швидше доходила до місця призначення<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/163/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:08, 4 січня 2011 (EET)<br /> <br /> ==§ 112 Амперсанд ==<br /> <br /> Амперсанд - це назва знака &amp;. Про нього треба знати три речі: звідки він узявся, чому так називається і чи потрібен він нам для чого-небудь.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/112/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:11, 4 січня 2011 (EET)<br /> <br /> ==§ 138. Кофе — оно ==<br /> <br /> Ознакою псевдоінтеллігентності є зауваження «кави - він». Зазвичай так говорять люди, які не помічають цих помилок у мовленні.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/138/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:48, 5 січня 2011 (EET)<br /> <br /> ==§ 103. Хочу как у них ==<br /> <br /> Знаки принадлежщие компаниям с превосходными, узнаваемыми, образцовыми товарами и услугами и подрожание им.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/103/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:55, 5 січня 2011 (EET)<br /> <br /> ==§ 165. Три правила про ви==<br /> <br /> У російській мові існує займенник ви, до якого додаються досить прості правила вживання і невживання.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/165/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 164. Три крапки==<br /> <br /> Всім відомі три крапки ...<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/164/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 149. Решение задач==<br /> <br /> Автор уверен, что дизайн является решением задач, а не творчеством. Дизайнер, который считает, что дизайн — это когда надо сделать красиво, просто не понимает смысла профессии.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/149/ Прочитати повністю]<br /> <br /> --[[Користувач:Kat|Kat]] 11:30, 19 січня 2011 (EET)<br /> <br /> ==§ 152. Патент краток, язык — вечен==<br /> <br /> [[§ 152. Патент краток, язык — вечен]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:53, 01 грудня 2011 (EET)<br /> <br /> <br /> ==§ 148. Единица смысла==<br /> <br /> [[§ 148. Единица смысла]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:57, 01 грудня 2011 (EET)<br /> <br /> ==§ 158. Коротке тире ==<br /> <br /> В даному параграфі А. Лєбєдєв стверджує, що в текстах діапазони як і раніше будуть позначатися з допомогою довгого тире а в номерах телефонів залишиться коротке. При позначенні діапазонів в числах планується ввести коротке тире, а не те що є на даний час, яке довжиною дорівнює &quot;N&quot;.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/158/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:26, 6 грудня 2011 (EET)<br /> <br /> ==§ 167. Метод прогресивного джіпєга ==<br /> <br /> В цій статті автор пропонує інший метод завантаження зображень.<br /> <br /> &quot;Час витрачається тільки на нужну степінь прожарювання, а загальний вигляд стейка завжди є.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/167/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:30, 6 грудня 2011 (EET)<br /> <br /> ==§ 171. Правила оформлення посилань==<br /> <br /> В статті автор розповідає про основні правила, яких слід дотримуватись при оформленні посилань.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/171/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 156. Дизайн - це війна==<br /> <br /> В статті на прикладі боротьби виробників тютюну з противниками тютюнопаління розповідається про те, як за допомогою знання психології сприйняття, за допомогою дизайнерських прийомів противники придумують нові способи боротьби один з одним.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/156/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 169. Підписи на фотографіях==<br /> Стаття про те, як не перетворитися з чудового фотографа у жахливого дизайнера. Оскільки неправельний підпис фотографії може погубити будь-який шедевр. <br /> &lt;br&gt;'''Правило:''' не потрібно перетворювати підпис фотографії у рекламу. <br /> [http://www.artlebedev.ru/kovodstvo/sections/169/ Читати оригінал]<br /> --[[Користувач:I_Shevchenko|Шевченко Ігор] 18:13, 15 березня 2012 (EET)</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D0%B0%D1%80%D0%B0%D0%B3%D1%80%D0%B0%D1%84%D0%B8_%D0%90%D1%80%D1%82%D1%94%D0%BC%D1%96%D1%8F_%D0%9B%D1%94%D0%B1%D1%94%D0%B4%D1%94%D0%B2%D0%B0 2012-03-15T16:13:26Z

<p>I Shevchenko: /* § 169. Підписи на фотографіях */</p> <hr /> <div>==§ 50. О статусной строке==<br /> <br /> Не можна втручатися в звичний стандартний інтерфейс і не можна ховати його елементи в ситуаціях, коли людина їх очікує.<br /> <br /> &lt;&lt;— Каков ваш статус, Лена? Проще говоря, каков ваш социум эр актум? С. Довлатов.&gt;&gt;<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/50/ Переглянути повністю]<br /> <br /> ==§ 55. Как писать слово «интернет»?==<br /> <br /> Освітченість &quot;світлин&quot; філологічних наук бажає бути кращою.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/55/ Оригінал станні]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:56, 20 грудня 2011 (EET)<br /> <br /> ==§ 60. Э... коммерция==<br /> <br /> Електронна комерція існує, чи це лише маркетинговий хід?<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/60/ Оригінал статті]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:59, 20 грудня 2011 (EET)<br /> <br /> ==§ 119. Буква Ё==<br /> <br /> Про значення букви &quot;Ё&quot; її правила вживання, труднощі які вона викликає при вживанні, її переваги та недоліки.<br /> <br /> Ё — недобуква. Використання &quot;Ё&quot; скрізь - насильство над читачем.<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/119/ Переглянути повністю]<br /> <br /> ==§ 161. Ідея на мінус мільйон==<br /> <br /> Про ціну винаходу. Для реалізації більшості ідей потрібно затратити більше коштів ніж ти від цього отримаеш прибутку)<br /> <br /> &quot;Кожен винахідник, або дизайнер, який розповідає про свою ідею, повинен чесно говорити: «У мене є ідея на мінус мільйон». &quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/161/ Прочитати повністю]<br /> <br /> <br /> == § 162. Творча криза==<br /> <br /> Творча криза - це глухий кут шляху без сенсу.<br /> <br /> Оригінальне і незвичайне неможливо придумати, воно з'являється тільки в результаті роботи над поставленою задачею.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/162/ Прочитати повністю]<br /> <br /> --[[Користувач:Gorduarabey|Gorduarabey]] 09:47, 23 листопада 2010 (EET)<br /> <br /> <br /> == § 145. Безглузда презентація==<br /> <br /> &quot;Краща презентація та, яку не показали.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/145/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> <br /> == § 147. Простота ≠ примітивність==<br /> <br /> &quot;Дизайн повинен бути простим, але не примітивним.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/147/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> ==Артемий Лебедев соц проэкт==<br /> &quot;Улучшение дорожных знаков в Киеве&quot; <br /> http://www.artlebedev.ru/kovodstvo/business-lynch/2009/06/15/commented/<br /> --[[Користувач:Alex46|Alex46]] 13:58, 21 грудня 2010 (EET)<br /> ==Организация пешеходных переходов с подсветкой в Тюмени==<br /> http://habrahabr.ru/blogs/design/44390/<br /> --[[Користувач:Alex46|Alex46]] 13:59, 21 грудня 2010 (EET)<br /> <br /> == § 166. Повітря спільне ==<br /> <br /> &quot;У кожної реклами повинно бути чітко окреслене місце&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/166/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> == § 150. От обратного ==<br /> <br /> &quot;Один з найефективніших дизайнерських прийомів - придумування незручних, незрозумілих і заплутаних рішень.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/150/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> ==§ 163 Правила написання поштових адрес ==<br /> <br /> Раніше реквізити адреси прийнято було писати від більшого до меншого: країна, індекс, місто, вулиця, будинок, квартира, ПІБ. У світі прийнята інша система складання адреси, тому що в світі відправляють багато пошти і дбають про те, щоб вона швидше доходила до місця призначення<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/163/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:08, 4 січня 2011 (EET)<br /> <br /> ==§ 112 Амперсанд ==<br /> <br /> Амперсанд - це назва знака &amp;. Про нього треба знати три речі: звідки він узявся, чому так називається і чи потрібен він нам для чого-небудь.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/112/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:11, 4 січня 2011 (EET)<br /> <br /> ==§ 138. Кофе — оно ==<br /> <br /> Ознакою псевдоінтеллігентності є зауваження «кави - він». Зазвичай так говорять люди, які не помічають цих помилок у мовленні.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/138/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:48, 5 січня 2011 (EET)<br /> <br /> ==§ 103. Хочу как у них ==<br /> <br /> Знаки принадлежщие компаниям с превосходными, узнаваемыми, образцовыми товарами и услугами и подрожание им.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/103/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:55, 5 січня 2011 (EET)<br /> <br /> ==§ 165. Три правила про ви==<br /> <br /> У російській мові існує займенник ви, до якого додаються досить прості правила вживання і невживання.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/165/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 164. Три крапки==<br /> <br /> Всім відомі три крапки ...<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/164/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 149. Решение задач==<br /> <br /> Автор уверен, что дизайн является решением задач, а не творчеством. Дизайнер, который считает, что дизайн — это когда надо сделать красиво, просто не понимает смысла профессии.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/149/ Прочитати повністю]<br /> <br /> --[[Користувач:Kat|Kat]] 11:30, 19 січня 2011 (EET)<br /> <br /> ==§ 152. Патент краток, язык — вечен==<br /> <br /> [[§ 152. Патент краток, язык — вечен]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:53, 01 грудня 2011 (EET)<br /> <br /> <br /> ==§ 148. Единица смысла==<br /> <br /> [[§ 148. Единица смысла]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:57, 01 грудня 2011 (EET)<br /> <br /> ==§ 158. Коротке тире ==<br /> <br /> В даному параграфі А. Лєбєдєв стверджує, що в текстах діапазони як і раніше будуть позначатися з допомогою довгого тире а в номерах телефонів залишиться коротке. При позначенні діапазонів в числах планується ввести коротке тире, а не те що є на даний час, яке довжиною дорівнює &quot;N&quot;.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/158/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:26, 6 грудня 2011 (EET)<br /> <br /> ==§ 167. Метод прогресивного джіпєга ==<br /> <br /> В цій статті автор пропонує інший метод завантаження зображень.<br /> <br /> &quot;Час витрачається тільки на нужну степінь прожарювання, а загальний вигляд стейка завжди є.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/167/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:30, 6 грудня 2011 (EET)<br /> <br /> ==§ 171. Правила оформлення посилань==<br /> <br /> В статті автор розповідає про основні правила, яких слід дотримуватись при оформленні посилань.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/171/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 156. Дизайн - це війна==<br /> <br /> В статті на прикладі боротьби виробників тютюну з противниками тютюнопаління розповідається про те, як за допомогою знання психології сприйняття, за допомогою дизайнерських прийомів противники придумують нові способи боротьби один з одним.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/156/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 169. Підписи на фотографіях==<br /> Стаття про те, як не перетворитися з чудового фотографа у жахливого дизайнера. Оскільки неправельний підпис фотографії може погубити будь-який шедевр. <br /> &lt;br&gt;'''Правило:''' не потрібно перетворювати підпис фотографії у рекламу. <br /> [http://www.artlebedev.ru/kovodstvo/sections/169/ Читати оригінал]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D0%B0%D1%80%D0%B0%D0%B3%D1%80%D0%B0%D1%84%D0%B8_%D0%90%D1%80%D1%82%D1%94%D0%BC%D1%96%D1%8F_%D0%9B%D1%94%D0%B1%D1%94%D0%B4%D1%94%D0%B2%D0%B0 2012-03-15T16:11:57Z

<p>I Shevchenko: /* § 169. Подписи на фотографиях */</p> <hr /> <div>==§ 50. О статусной строке==<br /> <br /> Не можна втручатися в звичний стандартний інтерфейс і не можна ховати його елементи в ситуаціях, коли людина їх очікує.<br /> <br /> &lt;&lt;— Каков ваш статус, Лена? Проще говоря, каков ваш социум эр актум? С. Довлатов.&gt;&gt;<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/50/ Переглянути повністю]<br /> <br /> ==§ 55. Как писать слово «интернет»?==<br /> <br /> Освітченість &quot;світлин&quot; філологічних наук бажає бути кращою.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/55/ Оригінал станні]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:56, 20 грудня 2011 (EET)<br /> <br /> ==§ 60. Э... коммерция==<br /> <br /> Електронна комерція існує, чи це лише маркетинговий хід?<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/60/ Оригінал статті]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:59, 20 грудня 2011 (EET)<br /> <br /> ==§ 119. Буква Ё==<br /> <br /> Про значення букви &quot;Ё&quot; її правила вживання, труднощі які вона викликає при вживанні, її переваги та недоліки.<br /> <br /> Ё — недобуква. Використання &quot;Ё&quot; скрізь - насильство над читачем.<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/119/ Переглянути повністю]<br /> <br /> ==§ 161. Ідея на мінус мільйон==<br /> <br /> Про ціну винаходу. Для реалізації більшості ідей потрібно затратити більше коштів ніж ти від цього отримаеш прибутку)<br /> <br /> &quot;Кожен винахідник, або дизайнер, який розповідає про свою ідею, повинен чесно говорити: «У мене є ідея на мінус мільйон». &quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/161/ Прочитати повністю]<br /> <br /> <br /> == § 162. Творча криза==<br /> <br /> Творча криза - це глухий кут шляху без сенсу.<br /> <br /> Оригінальне і незвичайне неможливо придумати, воно з'являється тільки в результаті роботи над поставленою задачею.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/162/ Прочитати повністю]<br /> <br /> --[[Користувач:Gorduarabey|Gorduarabey]] 09:47, 23 листопада 2010 (EET)<br /> <br /> <br /> == § 145. Безглузда презентація==<br /> <br /> &quot;Краща презентація та, яку не показали.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/145/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> <br /> == § 147. Простота ≠ примітивність==<br /> <br /> &quot;Дизайн повинен бути простим, але не примітивним.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/147/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> ==Артемий Лебедев соц проэкт==<br /> &quot;Улучшение дорожных знаков в Киеве&quot; <br /> http://www.artlebedev.ru/kovodstvo/business-lynch/2009/06/15/commented/<br /> --[[Користувач:Alex46|Alex46]] 13:58, 21 грудня 2010 (EET)<br /> ==Организация пешеходных переходов с подсветкой в Тюмени==<br /> http://habrahabr.ru/blogs/design/44390/<br /> --[[Користувач:Alex46|Alex46]] 13:59, 21 грудня 2010 (EET)<br /> <br /> == § 166. Повітря спільне ==<br /> <br /> &quot;У кожної реклами повинно бути чітко окреслене місце&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/166/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> == § 150. От обратного ==<br /> <br /> &quot;Один з найефективніших дизайнерських прийомів - придумування незручних, незрозумілих і заплутаних рішень.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/150/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> ==§ 163 Правила написання поштових адрес ==<br /> <br /> Раніше реквізити адреси прийнято було писати від більшого до меншого: країна, індекс, місто, вулиця, будинок, квартира, ПІБ. У світі прийнята інша система складання адреси, тому що в світі відправляють багато пошти і дбають про те, щоб вона швидше доходила до місця призначення<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/163/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:08, 4 січня 2011 (EET)<br /> <br /> ==§ 112 Амперсанд ==<br /> <br /> Амперсанд - це назва знака &amp;. Про нього треба знати три речі: звідки він узявся, чому так називається і чи потрібен він нам для чого-небудь.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/112/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:11, 4 січня 2011 (EET)<br /> <br /> ==§ 138. Кофе — оно ==<br /> <br /> Ознакою псевдоінтеллігентності є зауваження «кави - він». Зазвичай так говорять люди, які не помічають цих помилок у мовленні.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/138/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:48, 5 січня 2011 (EET)<br /> <br /> ==§ 103. Хочу как у них ==<br /> <br /> Знаки принадлежщие компаниям с превосходными, узнаваемыми, образцовыми товарами и услугами и подрожание им.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/103/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:55, 5 січня 2011 (EET)<br /> <br /> ==§ 165. Три правила про ви==<br /> <br /> У російській мові існує займенник ви, до якого додаються досить прості правила вживання і невживання.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/165/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 164. Три крапки==<br /> <br /> Всім відомі три крапки ...<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/164/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 149. Решение задач==<br /> <br /> Автор уверен, что дизайн является решением задач, а не творчеством. Дизайнер, который считает, что дизайн — это когда надо сделать красиво, просто не понимает смысла профессии.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/149/ Прочитати повністю]<br /> <br /> --[[Користувач:Kat|Kat]] 11:30, 19 січня 2011 (EET)<br /> <br /> ==§ 152. Патент краток, язык — вечен==<br /> <br /> [[§ 152. Патент краток, язык — вечен]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:53, 01 грудня 2011 (EET)<br /> <br /> <br /> ==§ 148. Единица смысла==<br /> <br /> [[§ 148. Единица смысла]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:57, 01 грудня 2011 (EET)<br /> <br /> ==§ 158. Коротке тире ==<br /> <br /> В даному параграфі А. Лєбєдєв стверджує, що в текстах діапазони як і раніше будуть позначатися з допомогою довгого тире а в номерах телефонів залишиться коротке. При позначенні діапазонів в числах планується ввести коротке тире, а не те що є на даний час, яке довжиною дорівнює &quot;N&quot;.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/158/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:26, 6 грудня 2011 (EET)<br /> <br /> ==§ 167. Метод прогресивного джіпєга ==<br /> <br /> В цій статті автор пропонує інший метод завантаження зображень.<br /> <br /> &quot;Час витрачається тільки на нужну степінь прожарювання, а загальний вигляд стейка завжди є.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/167/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:30, 6 грудня 2011 (EET)<br /> <br /> ==§ 171. Правила оформлення посилань==<br /> <br /> В статті автор розповідає про основні правила, яких слід дотримуватись при оформленні посилань.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/171/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 156. Дизайн - це війна==<br /> <br /> В статті на прикладі боротьби виробників тютюну з противниками тютюнопаління розповідається про те, як за допомогою знання психології сприйняття, за допомогою дизайнерських прийомів противники придумують нові способи боротьби один з одним.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/156/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 169. Підписи на фотографіях==<br /> Стаття про те, як не перетворитися з чудового фотографа у жахливого дизайнера. Оскільки неправельний підпис фотографії може погубити будь-який шедевр. <br /> '''Правило:''' не потрібно перетворювати підпис фотографії у рекламу. <br /> [http://www.artlebedev.ru/kovodstvo/sections/169/ Читати оригінал]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D0%B0%D1%80%D0%B0%D0%B3%D1%80%D0%B0%D1%84%D0%B8_%D0%90%D1%80%D1%82%D1%94%D0%BC%D1%96%D1%8F_%D0%9B%D1%94%D0%B1%D1%94%D0%B4%D1%94%D0%B2%D0%B0 2012-03-15T16:10:45Z

<p>I Shevchenko: </p> <hr /> <div>==§ 50. О статусной строке==<br /> <br /> Не можна втручатися в звичний стандартний інтерфейс і не можна ховати його елементи в ситуаціях, коли людина їх очікує.<br /> <br /> &lt;&lt;— Каков ваш статус, Лена? Проще говоря, каков ваш социум эр актум? С. Довлатов.&gt;&gt;<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/50/ Переглянути повністю]<br /> <br /> ==§ 55. Как писать слово «интернет»?==<br /> <br /> Освітченість &quot;світлин&quot; філологічних наук бажає бути кращою.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/55/ Оригінал станні]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:56, 20 грудня 2011 (EET)<br /> <br /> ==§ 60. Э... коммерция==<br /> <br /> Електронна комерція існує, чи це лише маркетинговий хід?<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/60/ Оригінал статті]<br /> <br /> --[[Користувач:Demo1420|Demo1420]] 02:59, 20 грудня 2011 (EET)<br /> <br /> ==§ 119. Буква Ё==<br /> <br /> Про значення букви &quot;Ё&quot; її правила вживання, труднощі які вона викликає при вживанні, її переваги та недоліки.<br /> <br /> Ё — недобуква. Використання &quot;Ё&quot; скрізь - насильство над читачем.<br /> <br /> [[Користувач:NICOLE|Паршенков Віталій]]<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/119/ Переглянути повністю]<br /> <br /> ==§ 161. Ідея на мінус мільйон==<br /> <br /> Про ціну винаходу. Для реалізації більшості ідей потрібно затратити більше коштів ніж ти від цього отримаеш прибутку)<br /> <br /> &quot;Кожен винахідник, або дизайнер, який розповідає про свою ідею, повинен чесно говорити: «У мене є ідея на мінус мільйон». &quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/161/ Прочитати повністю]<br /> <br /> <br /> == § 162. Творча криза==<br /> <br /> Творча криза - це глухий кут шляху без сенсу.<br /> <br /> Оригінальне і незвичайне неможливо придумати, воно з'являється тільки в результаті роботи над поставленою задачею.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/162/ Прочитати повністю]<br /> <br /> --[[Користувач:Gorduarabey|Gorduarabey]] 09:47, 23 листопада 2010 (EET)<br /> <br /> <br /> == § 145. Безглузда презентація==<br /> <br /> &quot;Краща презентація та, яку не показали.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/145/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> <br /> == § 147. Простота ≠ примітивність==<br /> <br /> &quot;Дизайн повинен бути простим, але не примітивним.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/147/ Прочитати повністю]<br /> <br /> --[[Користувач:Aleksey|Новіков Олексій]] 20:30, 28 листопада 2010 (EET)<br /> ==Артемий Лебедев соц проэкт==<br /> &quot;Улучшение дорожных знаков в Киеве&quot; <br /> http://www.artlebedev.ru/kovodstvo/business-lynch/2009/06/15/commented/<br /> --[[Користувач:Alex46|Alex46]] 13:58, 21 грудня 2010 (EET)<br /> ==Организация пешеходных переходов с подсветкой в Тюмени==<br /> http://habrahabr.ru/blogs/design/44390/<br /> --[[Користувач:Alex46|Alex46]] 13:59, 21 грудня 2010 (EET)<br /> <br /> == § 166. Повітря спільне ==<br /> <br /> &quot;У кожної реклами повинно бути чітко окреслене місце&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/166/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> == § 150. От обратного ==<br /> <br /> &quot;Один з найефективніших дизайнерських прийомів - придумування незручних, незрозумілих і заплутаних рішень.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/150/ Прочитати повністю]<br /> <br /> --[[Користувач:ZHSergey|Жаботін Сергій]] 04:14, 28 грудня 2010 (EET)<br /> <br /> ==§ 163 Правила написання поштових адрес ==<br /> <br /> Раніше реквізити адреси прийнято було писати від більшого до меншого: країна, індекс, місто, вулиця, будинок, квартира, ПІБ. У світі прийнята інша система складання адреси, тому що в світі відправляють багато пошти і дбають про те, щоб вона швидше доходила до місця призначення<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/163/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:08, 4 січня 2011 (EET)<br /> <br /> ==§ 112 Амперсанд ==<br /> <br /> Амперсанд - це назва знака &amp;. Про нього треба знати три речі: звідки він узявся, чому так називається і чи потрібен він нам для чого-небудь.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/112/ Прочитати повністю]<br /> <br /> --[[Користувач:Thrashington|Ярмак Вячеслав]] 14:11, 4 січня 2011 (EET)<br /> <br /> ==§ 138. Кофе — оно ==<br /> <br /> Ознакою псевдоінтеллігентності є зауваження «кави - він». Зазвичай так говорять люди, які не помічають цих помилок у мовленні.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/138/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:48, 5 січня 2011 (EET)<br /> <br /> ==§ 103. Хочу как у них ==<br /> <br /> Знаки принадлежщие компаниям с превосходными, узнаваемыми, образцовыми товарами и услугами и подрожание им.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/103/ Прочитати повністю]<br /> <br /> --[[Користувач:Slasher|Українцев Влад]] 10:55, 5 січня 2011 (EET)<br /> <br /> ==§ 165. Три правила про ви==<br /> <br /> У російській мові існує займенник ви, до якого додаються досить прості правила вживання і невживання.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/165/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 164. Три крапки==<br /> <br /> Всім відомі три крапки ...<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/164/ Прочитати повністю]<br /> <br /> --[[Користувач:VLavr|Лавріненко Віталій]] 23:33, 17 січня 2011 (EET)<br /> <br /> ==§ 149. Решение задач==<br /> <br /> Автор уверен, что дизайн является решением задач, а не творчеством. Дизайнер, который считает, что дизайн — это когда надо сделать красиво, просто не понимает смысла профессии.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/149/ Прочитати повністю]<br /> <br /> --[[Користувач:Kat|Kat]] 11:30, 19 січня 2011 (EET)<br /> <br /> ==§ 152. Патент краток, язык — вечен==<br /> <br /> [[§ 152. Патент краток, язык — вечен]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:53, 01 грудня 2011 (EET)<br /> <br /> <br /> ==§ 148. Единица смысла==<br /> <br /> [[§ 148. Единица смысла]]<br /> <br /> --[[Користувач:Нагорний|Нагорний Сергій]]-- 21:57, 01 грудня 2011 (EET)<br /> <br /> ==§ 158. Коротке тире ==<br /> <br /> В даному параграфі А. Лєбєдєв стверджує, що в текстах діапазони як і раніше будуть позначатися з допомогою довгого тире а в номерах телефонів залишиться коротке. При позначенні діапазонів в числах планується ввести коротке тире, а не те що є на даний час, яке довжиною дорівнює &quot;N&quot;.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/158/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:26, 6 грудня 2011 (EET)<br /> <br /> ==§ 167. Метод прогресивного джіпєга ==<br /> <br /> В цій статті автор пропонує інший метод завантаження зображень.<br /> <br /> &quot;Час витрачається тільки на нужну степінь прожарювання, а загальний вигляд стейка завжди є.&quot;<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/167/ Прочитати повністю]<br /> <br /> --[[Користувач:Viper|Григоржевський Василь]] 14:30, 6 грудня 2011 (EET)<br /> <br /> ==§ 171. Правила оформлення посилань==<br /> <br /> В статті автор розповідає про основні правила, яких слід дотримуватись при оформленні посилань.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/171/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 156. Дизайн - це війна==<br /> <br /> В статті на прикладі боротьби виробників тютюну з противниками тютюнопаління розповідається про те, як за допомогою знання психології сприйняття, за допомогою дизайнерських прийомів противники придумують нові способи боротьби один з одним.<br /> <br /> [http://www.artlebedev.ru/kovodstvo/sections/156/ Прочитати повністю]<br /> <br /> --[[Користувач:Vad zel|Зеленський Вадим]] 23:05, 19 грудня 2011 (EET)<br /> <br /> ==§ 169. Подписи на фотографиях==<br /> Стаття про те, як не перетворитися з чудового фотографа у жахливого дизайнера. Оскільки неправельний підпис фотографії може погубити будь-який шедевр. <br /> '''Правило:''' не потрібно перетворювати підпис фотографії у рекламу. <br /> [http://www.artlebedev.ru/kovodstvo/sections/169/ Прочитати повністю]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%A0%D0%BE%D0%B7%D1%80%D0%BE%D0%B1%D0%BA%D0%B0_%D1%96%D0%BD%D1%82%D0%B5%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D0%B8%D1%85_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC 2011-12-13T13:34:41Z

<p>I Shevchenko: </p> <hr /> <div>Основна аксіома дизайну інтерфейсів свідчить:<br /> <br /> '''Гарний дизайн призначеного для користувача інтерфейсу вважається, якщо програма відповідає очікуванням користувачів про те, як вона повинна поводитися.'''<br /> <br /> Все інше – наслідки.<br /> <br /> [[Ресурси мережі Інтернет стосовно курсу РІС]]<br /> <br /> == Загальні принципи проектування інтерактивних систем ==<br /> <br /> [[Поняття призначеного для користувача інтерфейсу]]<br /> <br /> [[Інтерфейс командного рядка]]<br /> <br /> [[Стандартизація та універсалізація інтерфейсу користувача прикладних програмних засобів]]<br /> <br /> === Вимоги до інтерфейсу ===<br /> <br /> [[Природність інтерфейсу]]<br /> <br /> [[Узгодженість інтерфейсу]]<br /> <br /> [[Дружність інтерфейсу]]<br /> <br /> [[Принцип «зворотного зв'язку»]]<br /> <br /> [[Простота інтерфейсу]]<br /> <br /> [[Гнучкість інтерфейсу]]<br /> <br /> [[Естетична привабливість інтерфейсу]]<br /> <br /> === Основні етапи розробки призначеного для користувача інтерфейсу ===<br /> <br /> [[Вибір структури діалогу]]<br /> <br /> [[Розробка сценарію діалогу]]<br /> <br /> [[Визначення складу і візуальних атрибутів інформації, що відображається]]<br /> <br /> [[Темп ведення діалогу]]<br /> <br /> [[Візуальні атрибути інформації, що відображається]]<br /> <br /> [[Категорії користувачів]]<br /> <br /> === Системний підхід до розробки інтерфейсів ===<br /> <br /> [[Інтерфейс користувача]]<br /> <br /> [[Меню інтерфейса]]<br /> <br /> [[Вікно діалогу]]<br /> <br /> == Принципи побудови інтерфейсів ==<br /> <br /> [[Золотий перетин]]<br /> <br /> [[Гаманець Міллера]]<br /> <br /> [[Бритва Оккама або KISS]]<br /> <br /> [[Принцип групування]]<br /> <br /> [[Видимість відображає користь]]<br /> <br /> [[Розумне запозичення]]<br /> <br /> == Еврістичні правила Якоба Нільсена ==<br /> <br /> [[Видимість стану системи (зворотній зв'язок)]]<br /> <br /> [[Поінформованість користувача]]<br /> <br /> [[Засоби забезпечення зворотнього зв'язку]]<br /> <br /> [[Час сповіщення]]<br /> <br /> [[Рівність між системою та реальним світом]]<br /> <br /> [[Свобода дій користувача]]<br /> <br /> [[Послідовність та стандартизація]]<br /> <br /> [[Попередження помилок]]<br /> <br /> [[Ніж запоминати, краще розуміти]]<br /> <br /> [[Гнучкість та ефективність використання]]<br /> <br /> [[Естетичність та мінімальність дизайну]]<br /> <br /> [[Розпізнавання та виправлення помилок]]<br /> <br /> [[Опис помилок]]<br /> <br /> [[Опис вирішення проблеми]]<br /> <br /> [[Довідка та документація]]<br /> <br /> == Контрольний список інтерфейсу ==<br /> <br /> [[Контрольний список|Контрольний список інтерфейсу]]<br /> <br /> <br /> ==Публіцистика==<br /> <br /> [[Статті Якоба Нільсена]]<br /> <br /> [[Параграфи Артємія Лєбєдєва]]<br /> <br /> [[Закон дірявих абстракцій]]<br /> <br /> [[Usability. Семен Куликов]]<br /> <br /> [[Експертна оцінка|Юзабилити-тестирование по дешевке. Экспертная оценка]]<br /> <br /> [[Головні функції дизайнера інтерфейсів| І жнець, і швець, та на дудці гравець]]<br /> <br /> [[Інтерфейси для майстрів]]<br /> <br /> [[Керівництво користувача для користувача| Керівництво користувача для користувача]]<br /> <br /> [[Проектування інтерфейсу як частина розробки ТЗ| Проектування інтерфейсу як частина розробки ТЗ]]<br /> <br /> [[category:РІС|*]]<br /> <br /> [[category:Навчальні проекти]]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F_%D1%96%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D1%83_%D1%8F%D0%BA_%D1%87%D0%B0%D1%81%D1%82%D0%B8%D0%BD%D0%B0_%D1%80%D0%BE%D0%B7%D1%80%D0%BE%D0%B1%D0%BA%D0%B8_%D0%A2%D0%97 2011-12-13T13:32:25Z

<p>I Shevchenko: </p> <hr /> <div>Впровадження систем автоматизації бізнесу, як знає будь-який в цій області фахівець, аж ніяк не є легкою справою. Якщо саме створення системи технічно є не дуже складним (наприклад, не можна сказати, що середньостатистична система наповнена складними алгоритмами), то впровадження такої системи вимагає від автоматизатора рідкісного завзяття та спритності. При цьому корінь багатьох проблем знаходиться у технічному завданні. Як кажуть, «що задумали, те й зробили», але потім виявляється, що задумали-то і неправильно. Для вирішення проблем, що виникають при створенні ТЗ, а виявлених при впровадженні, придумано безліч технологій і методів проте сама їх кількість свідчить про те, що жоден метод до повного успіху не приводить. Крім того, багато методів мають принциповий недолік - вони збільшують об'єм роботи наодному етапі, хай і заради економії на іншому, а також вимагають серйозних інвестицій у навчанні працівників (характерний приклад - RUP). Існує, однак, підхід, який не вимагає особливої ​​кваліфікації співробітників, значно полегшує впровадження, не збільшуючи обсяг робіт по розробки ТЗ.<br /> <br /> Сутність підходу може бути описана однією фразою - проектування інтерфейсу не є частиною процесу розробки, а є частиною процесу створення специфікацій на систему.<br /> <br /> Тут необхідно зробити два важливих уточнення. По-перше, інтерфейс все одно буде розроблений (практика показує, що замовники чомусь неохоче оплачують функціональність без інтерфейсу). По-друге, від проектування інтерфейсу нічого особливого не потрібно - на нього можуть бути виділені ті ж ресурси, що і у випадку звичайної розробки, так само як і вийти він може таким же. Авторам, які заробляють собі на життя розробкою ергономічних інтерфейсів, неприємно це говорити, але інтерфейс може бути навіть не ергономічним, все одно впровадження буде полегшено; зрозуміло, у випадку ергономічного інтерфейсу впровадження буде ще більш простим, але такий інтерфейс дорожче і довше робиться.<br /> <br /> ==Пропонований підхід дозволяє вирішити наступні проблеми:==<br /> <br /> *Усунути розбіжності в поглядах на постановку задачі замовника і виконавця. Специфікації на скільки-небудь складні системи занадто абстрактні. Їх насилу утримують в голові навіть автори, а до кінця не розуміє ніхто, особливо ключова особа - замовник. Для нього ця специфікація нічим не відрізняється від сакральних письмен (багато хто навіть припускають, що незрозумілі ТЗ призначені для того, щоб справити на них враження і здерти побільше грошей). Немає різниці, що підсунуть йому розробники, реальне ТЗ або інструкцію до газонокосарці на фарсі - всі однаково незрозуміло. Наївно припускати, що замовник, легко підписав таке ТЗ, також легко прийме розроблену систему. Прототипи інтерфейсу є тим єдиним документом, який замовник може зрозуміти і оцінити. А зрозумівши і оцінивши - свідомо підписати.<br /> <br /> *Полегшити процес впровадження системи. Вагома частина проблем впровадження в якісно виконаному проекті припадає на інтерфейс, створений формально правильно, але неадекватно уявленням замовника. Не існує виду ТЗ, крім власне прототипу інтерфейсу, який би міг інтегрувати такого роду вимоги. Наочний приклад: у будь-якому ТЗ можна прописати, що «в системі є адресна книга, яка складається з таких-то даних і таких-то функцій». Але неможливо формалізувати вже в ТЗ, як ця адресна книга повинна реально працювати (якісь функції потрібно «витягнути» наверх, якісь можна «засунути»), як, врешті-решт, ця адресна книга повинна виглядати. При цьому апеляції виконавця до підписаного технічним завданням - мовляв, ось же перераховані функції ... ось вони всі в наявності - як правило, не спрацьовують, оскільки при відомій спритності у контексті користувальницького інтерфейсу проінтерпретувати ТЗ завжди можна дуже по-різному. Тільки заздалегідь спроектований інтерфейс дозволяє застрахуватися від такого роду претензій.<br /> <br /> *Скоротити число доробок системи, викликаних невідповідністю її функціональності очікуванням клієнта. Тільки побачивши саму систему, замовник може реально зрозуміти її можливості, так само як і оцінити власні потреби. Для замовника програмний продукт і його інтерфейс цілком тотожні. Отже, показавши замовнику інтерфейс на стадії підготовки ТЗ, можна знизити кількість і обсяг переробок, потреба в яких виникає через розбіжності очікувань замовника із запланованою в ТЗ функціональністю системи. (Потрібно, втім, відзначити, що такі переробки частіше за все не проблематичні для розробників, які зазвичай наполягають на додатковій оплаті цих послуг.)<br /> <br /> *Зняти ризик необхідності доопрацювання функціональності системи, з-за незадоволеності замовника запропонованим інтерфейсом. При розробці інтерфейсу немає рішуче ніякої гарантії того, що він буде прийнятий замовником. Опис функцій системи бінарно, функція може бути, може не бути. Доказ її наявності рідко вимагає аргументації. Інтерфейс ж може бути або досить хорошим, або недостатньо хорошим. Коли в справу вступають відносні терміни, все ускладнюється, що може приводити в виникненню конфліктних ситуацій. Годі й говорити, що при переробці недостатньо хорошого інтерфейсу функціональність системи, яка вже є, змінюється теж, причому без оплати праці розробника.<br /> <br /> Таким чином, є об'єктивна користь в тому, щоб розглядати проектування інтерфейсу не як стадію розробки, а як стадію створення ТЗ. Але як це зробити? На перший погляд, завдання здається важкою, частково з організаційної, частково з технічної сторін.<br /> <br /> Спочатку про організаційну стороні. На перший погляд замовника важко переконати відмовитися від думки, що робити що-то «реальне» треба відразу після підписання договору. Однак практика показує, що проміжні наочні результати роботи над системою, а саме прототипи інтерфейсу, продемонстровані вже на другий день роботи, а не через кілька тижнів, призводять клієнта в себе захищеними. На відміну від звичайного ТЗ, робота над яким замовнику реально не видно («ну що там, пара пунктів додалася») прототипи інтерфейсу легко зрозумілі і прогрес у роботі явно помітний. Друга організаційна проблема пов'язана з необхідністю підписувати два договори: на створення ТЗ (читай - інтерфейсу) і на розробку функціональності системи. Причому підписання другого договору відкладається на певний строк, необхідний для розробки інтерфейсу, що розтягує проект у часі. У принципі, ця проблема нерозв'язна, але, з іншого боку, тут багато що залежить від її сприйняття: так, договору два, але зате другий договір виходить значно більш точним (вже маючи інтерфейс, легше оцінити трудовитрати).<br /> <br /> Технічна проблема пов'язана з труднощами прототипування. У звичайному режимі роботи інтерфейс створюється вже в засобі розробки, створювати ж прототип таким чином нерентабельно. Інтерфейс створюється через безліч ітерацій, а переробляти вже зроблене вже дорого. Порівняно недавно з'явилися спеціальні засоби для прототипування інтерфейсу (наприклад, Norpath Studio), але поки вони досить сирі. Вихід - використання неспеціалізованих графічних редакторів. Ще кілька років тому основним таким редактором був MS PowerPoint, зараз же найбільш зручним слід визнати MS Visio. Складні екранні форми, втім, до цих пір зручніше просто малювати на папері.<br /> <br /> І, нарешті, головна проблема. Подовження процесу розробки ТЗ часто сприймається самими розробниками як безумовне зло - звичка спочатку робити, а вже потім думати, традиційно сильна в російському IT-бізнесі. На жаль, змінити цей звичай може тільки «досвід, син помилок важких». Поки, в усякому разі ...<br /> <br /> Звичайно, проектування інтерфесу на етапі розробки специфікацій системи не є панацеєю. Такий підхід не дозволяє поліпшити якість розробки в принципі, наприклад, він зовсім не зменшує кількість помилок програмування. Більш того, він не завжди застосуємо. Інтерфейс складної системи неможливо з самого початку спроектувати повністю: доведеться спочатку робити працюючу бета-версію і остаточно ред інтерфейс вже на її основі. Крім того, у багатьох проектах з-за не залежать ні від кого причин не виходить розтягувати процес створення ТЗ (замовник хоче побачити які-небудь результати вже завтра). Однак, враховуючи низькі «вхідні» вимоги до застосування запропонованого методу (незрівнянні, наприклад, з тяганиною і бюрократією, зумовленої використанням UML), проектування інтерфейсів на стадії підготовки специфікацій майже завжди є вкрай успішним методом вирішення проблем впровадження.</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F_%D1%96%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D1%83_%D1%8F%D0%BA_%D1%87%D0%B0%D1%81%D1%82%D0%B8%D0%BD%D0%B0_%D1%80%D0%BE%D0%B7%D1%80%D0%BE%D0%B1%D0%BA%D0%B8_%D0%A2%D0%97 2011-12-13T13:31:37Z

<p>I Shevchenko: </p> <hr /> <div>Впровадження систем автоматизації бізнесу, як знає будь-який в цій області фахівець, аж ніяк не є легкою справою. Якщо саме створення системи технічно є не дуже складним (наприклад, не можна сказати, що середньостатистична система наповнена складними алгоритмами), то впровадження такої системи вимагає від автоматизатора рідкісного завзяття та спритності. При цьому корінь багатьох проблем знаходиться у технічному завданні. Як кажуть, «що задумали, те й зробили», але потім виявляється, що задумали-то і неправильно. Для вирішення проблем, що виникають при створенні ТЗ, а виявлених при впровадженні, придумано безліч технологій і методів проте сама їх кількість свідчить про те, що жоден метод до повного успіху не приводить. Крім того, багато методів мають принциповий недолік - вони збільшують об'єм роботи наодному етапі, хай і заради економії на іншому, а також вимагають серйозних інвестицій у навчанні працівників (характерний приклад - RUP). Існує, однак, підхід, який не вимагає особливої ​​кваліфікації співробітників, значно полегшує впровадження, не збільшуючи обсяг робіт по розробки ТЗ.<br /> <br /> Сутність підходу може бути описана однією фразою - проектування інтерфейсу не є частиною процесу розробки, а є частиною процесу створення специфікацій на систему.<br /> <br /> Тут необхідно зробити два важливих уточнення. По-перше, інтерфейс все одно буде розроблений (практика показує, що замовники чомусь неохоче оплачують функціональність без інтерфейсу). По-друге, від проектування інтерфейсу нічого особливого не потрібно - на нього можуть бути виділені ті ж ресурси, що і у випадку звичайної розробки, так само як і вийти він може таким же. Авторам, які заробляють собі на життя розробкою ергономічних інтерфейсів, неприємно це говорити, але інтерфейс може бути навіть не ергономічним, все одно впровадження буде полегшено; зрозуміло, у випадку ергономічного інтерфейсу впровадження буде ще більш простим, але такий інтерфейс дорожче і довше робиться.<br /> <br /> =Пропонований підхід дозволяє вирішити наступні проблеми:=<br /> <br /> *Усунути розбіжності в поглядах на постановку задачі замовника і виконавця. Специфікації на скільки-небудь складні системи занадто абстрактні. Їх насилу утримують в голові навіть автори, а до кінця не розуміє ніхто, особливо ключова особа - замовник. Для нього ця специфікація нічим не відрізняється від сакральних письмен (багато хто навіть припускають, що незрозумілі ТЗ призначені для того, щоб справити на них враження і здерти побільше грошей). Немає різниці, що підсунуть йому розробники, реальне ТЗ або інструкцію до газонокосарці на фарсі - всі однаково незрозуміло. Наївно припускати, що замовник, легко підписав таке ТЗ, також легко прийме розроблену систему. Прототипи інтерфейсу є тим єдиним документом, який замовник може зрозуміти і оцінити. А зрозумівши і оцінивши - свідомо підписати.<br /> <br /> *Полегшити процес впровадження системи. Вагома частина проблем впровадження в якісно виконаному проекті припадає на інтерфейс, створений формально правильно, але неадекватно уявленням замовника. Не існує виду ТЗ, крім власне прототипу інтерфейсу, який би міг інтегрувати такого роду вимоги. Наочний приклад: у будь-якому ТЗ можна прописати, що «в системі є адресна книга, яка складається з таких-то даних і таких-то функцій». Але неможливо формалізувати вже в ТЗ, як ця адресна книга повинна реально працювати (якісь функції потрібно «витягнути» наверх, якісь можна «засунути»), як, врешті-решт, ця адресна книга повинна виглядати. При цьому апеляції виконавця до підписаного технічним завданням - мовляв, ось же перераховані функції ... ось вони всі в наявності - як правило, не спрацьовують, оскільки при відомій спритності у контексті користувальницького інтерфейсу проінтерпретувати ТЗ завжди можна дуже по-різному. Тільки заздалегідь спроектований інтерфейс дозволяє застрахуватися від такого роду претензій.<br /> <br /> *Скоротити число доробок системи, викликаних невідповідністю її функціональності очікуванням клієнта. Тільки побачивши саму систему, замовник може реально зрозуміти її можливості, так само як і оцінити власні потреби. Для замовника програмний продукт і його інтерфейс цілком тотожні. Отже, показавши замовнику інтерфейс на стадії підготовки ТЗ, можна знизити кількість і обсяг переробок, потреба в яких виникає через розбіжності очікувань замовника із запланованою в ТЗ функціональністю системи. (Потрібно, втім, відзначити, що такі переробки частіше за все не проблематичні для розробників, які зазвичай наполягають на додатковій оплаті цих послуг.)<br /> <br /> *Зняти ризик необхідності доопрацювання функціональності системи, з-за незадоволеності замовника запропонованим інтерфейсом. При розробці інтерфейсу немає рішуче ніякої гарантії того, що він буде прийнятий замовником. Опис функцій системи бінарно, функція може бути, може не бути. Доказ її наявності рідко вимагає аргументації. Інтерфейс ж може бути або досить хорошим, або недостатньо хорошим. Коли в справу вступають відносні терміни, все ускладнюється, що може приводити в виникненню конфліктних ситуацій. Годі й говорити, що при переробці недостатньо хорошого інтерфейсу функціональність системи, яка вже є, змінюється теж, причому без оплати праці розробника.<br /> <br /> Таким чином, є об'єктивна користь в тому, щоб розглядати проектування інтерфейсу не як стадію розробки, а як стадію створення ТЗ. Але як це зробити? На перший погляд, завдання здається важкою, частково з організаційної, частково з технічної сторін.<br /> <br /> Спочатку про організаційну стороні. На перший погляд замовника важко переконати відмовитися від думки, що робити що-то «реальне» треба відразу після підписання договору. Однак практика показує, що проміжні наочні результати роботи над системою, а саме прототипи інтерфейсу, продемонстровані вже на другий день роботи, а не через кілька тижнів, призводять клієнта в себе захищеними. На відміну від звичайного ТЗ, робота над яким замовнику реально не видно («ну що там, пара пунктів додалася») прототипи інтерфейсу легко зрозумілі і прогрес у роботі явно помітний. Друга організаційна проблема пов'язана з необхідністю підписувати два договори: на створення ТЗ (читай - інтерфейсу) і на розробку функціональності системи. Причому підписання другого договору відкладається на певний строк, необхідний для розробки інтерфейсу, що розтягує проект у часі. У принципі, ця проблема нерозв'язна, але, з іншого боку, тут багато що залежить від її сприйняття: так, договору два, але зате другий договір виходить значно більш точним (вже маючи інтерфейс, легше оцінити трудовитрати).<br /> <br /> Технічна проблема пов'язана з труднощами прототипування. У звичайному режимі роботи інтерфейс створюється вже в засобі розробки, створювати ж прототип таким чином нерентабельно. Інтерфейс створюється через безліч ітерацій, а переробляти вже зроблене вже дорого. Порівняно недавно з'явилися спеціальні засоби для прототипування інтерфейсу (наприклад, Norpath Studio), але поки вони досить сирі. Вихід - використання неспеціалізованих графічних редакторів. Ще кілька років тому основним таким редактором був MS PowerPoint, зараз же найбільш зручним слід визнати MS Visio. Складні екранні форми, втім, до цих пір зручніше просто малювати на папері.<br /> <br /> І, нарешті, головна проблема. Подовження процесу розробки ТЗ часто сприймається самими розробниками як безумовне зло - звичка спочатку робити, а вже потім думати, традиційно сильна в російському IT-бізнесі. На жаль, змінити цей звичай може тільки «досвід, син помилок важких». Поки, в усякому разі ...<br /> <br /> Звичайно, проектування інтерфесу на етапі розробки специфікацій системи не є панацеєю. Такий підхід не дозволяє поліпшити якість розробки в принципі, наприклад, він зовсім не зменшує кількість помилок програмування. Більш того, він не завжди застосуємо. Інтерфейс складної системи неможливо з самого початку спроектувати повністю: доведеться спочатку робити працюючу бета-версію і остаточно ред інтерфейс вже на її основі. Крім того, у багатьох проектах з-за не залежать ні від кого причин не виходить розтягувати процес створення ТЗ (замовник хоче побачити які-небудь результати вже завтра). Однак, враховуючи низькі «вхідні» вимоги до застосування запропонованого методу (незрівнянні, наприклад, з тяганиною і бюрократією, зумовленої використанням UML), проектування інтерфейсів на стадії підготовки специфікацій майже завжди є вкрай успішним методом вирішення проблем впровадження.</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F_%D1%96%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D1%83_%D1%8F%D0%BA_%D1%87%D0%B0%D1%81%D1%82%D0%B8%D0%BD%D0%B0_%D1%80%D0%BE%D0%B7%D1%80%D0%BE%D0%B1%D0%BA%D0%B8_%D0%A2%D0%97 2011-12-13T13:31:00Z

<p>I Shevchenko: </p> <hr /> <div>Впровадження систем автоматизації бізнесу, як знає будь-який в цій області фахівець, аж ніяк не є легкою справою. Якщо саме створення системи технічно є не дуже складним (наприклад, не можна сказати, що середньостатистична система наповнена складними алгоритмами), то впровадження такої системи вимагає від автоматизатора рідкісного завзяття та спритності. При цьому корінь багатьох проблем знаходиться у технічному завданні. Як кажуть, «що задумали, те й зробили», але потім виявляється, що задумали-то і неправильно. Для вирішення проблем, що виникають при створенні ТЗ, а виявлених при впровадженні, придумано безліч технологій і методів проте сама їх кількість свідчить про те, що жоден метод до повного успіху не приводить. Крім того, багато методів мають принциповий недолік - вони збільшують об'єм роботи наодному етапі, хай і заради економії на іншому, а також вимагають серйозних інвестицій у навчанні працівників (характерний приклад - RUP). Існує, однак, підхід, який не вимагає особливої ​​кваліфікації співробітників, значно полегшує впровадження, не збільшуючи обсяг робіт по розробки ТЗ.<br /> <br /> Сутність підходу може бути описана однією фразою - проектування інтерфейсу не є частиною процесу розробки, а є частиною процесу створення специфікацій на систему.<br /> <br /> Тут необхідно зробити два важливих уточнення. По-перше, інтерфейс все одно буде розроблений (практика показує, що замовники чомусь неохоче оплачують функціональність без інтерфейсу). По-друге, від проектування інтерфейсу нічого особливого не потрібно - на нього можуть бути виділені ті ж ресурси, що і у випадку звичайної розробки, так само як і вийти він може таким же. Авторам, які заробляють собі на життя розробкою ергономічних інтерфейсів, неприємно це говорити, але інтерфейс може бути навіть не ергономічним, все одно впровадження буде полегшено; зрозуміло, у випадку ергономічного інтерфейсу впровадження буде ще більш простим, але такий інтерфейс дорожче і довше робиться.<br /> <br /> **Пропонований підхід дозволяє вирішити наступні проблеми:**<br /> <br /> *Усунути розбіжності в поглядах на постановку задачі замовника і виконавця. Специфікації на скільки-небудь складні системи занадто абстрактні. Їх насилу утримують в голові навіть автори, а до кінця не розуміє ніхто, особливо ключова особа - замовник. Для нього ця специфікація нічим не відрізняється від сакральних письмен (багато хто навіть припускають, що незрозумілі ТЗ призначені для того, щоб справити на них враження і здерти побільше грошей). Немає різниці, що підсунуть йому розробники, реальне ТЗ або інструкцію до газонокосарці на фарсі - всі однаково незрозуміло. Наївно припускати, що замовник, легко підписав таке ТЗ, також легко прийме розроблену систему. Прототипи інтерфейсу є тим єдиним документом, який замовник може зрозуміти і оцінити. А зрозумівши і оцінивши - свідомо підписати.<br /> <br /> *Полегшити процес впровадження системи. Вагома частина проблем впровадження в якісно виконаному проекті припадає на інтерфейс, створений формально правильно, але неадекватно уявленням замовника. Не існує виду ТЗ, крім власне прототипу інтерфейсу, який би міг інтегрувати такого роду вимоги. Наочний приклад: у будь-якому ТЗ можна прописати, що «в системі є адресна книга, яка складається з таких-то даних і таких-то функцій». Але неможливо формалізувати вже в ТЗ, як ця адресна книга повинна реально працювати (якісь функції потрібно «витягнути» наверх, якісь можна «засунути»), як, врешті-решт, ця адресна книга повинна виглядати. При цьому апеляції виконавця до підписаного технічним завданням - мовляв, ось же перераховані функції ... ось вони всі в наявності - як правило, не спрацьовують, оскільки при відомій спритності у контексті користувальницького інтерфейсу проінтерпретувати ТЗ завжди можна дуже по-різному. Тільки заздалегідь спроектований інтерфейс дозволяє застрахуватися від такого роду претензій.<br /> <br /> *Скоротити число доробок системи, викликаних невідповідністю її функціональності очікуванням клієнта. Тільки побачивши саму систему, замовник може реально зрозуміти її можливості, так само як і оцінити власні потреби. Для замовника програмний продукт і його інтерфейс цілком тотожні. Отже, показавши замовнику інтерфейс на стадії підготовки ТЗ, можна знизити кількість і обсяг переробок, потреба в яких виникає через розбіжності очікувань замовника із запланованою в ТЗ функціональністю системи. (Потрібно, втім, відзначити, що такі переробки частіше за все не проблематичні для розробників, які зазвичай наполягають на додатковій оплаті цих послуг.)<br /> <br /> *Зняти ризик необхідності доопрацювання функціональності системи, з-за незадоволеності замовника запропонованим інтерфейсом. При розробці інтерфейсу немає рішуче ніякої гарантії того, що він буде прийнятий замовником. Опис функцій системи бінарно, функція може бути, може не бути. Доказ її наявності рідко вимагає аргументації. Інтерфейс ж може бути або досить хорошим, або недостатньо хорошим. Коли в справу вступають відносні терміни, все ускладнюється, що може приводити в виникненню конфліктних ситуацій. Годі й говорити, що при переробці недостатньо хорошого інтерфейсу функціональність системи, яка вже є, змінюється теж, причому без оплати праці розробника.<br /> <br /> Таким чином, є об'єктивна користь в тому, щоб розглядати проектування інтерфейсу не як стадію розробки, а як стадію створення ТЗ. Але як це зробити? На перший погляд, завдання здається важкою, частково з організаційної, частково з технічної сторін.<br /> <br /> Спочатку про організаційну стороні. На перший погляд замовника важко переконати відмовитися від думки, що робити що-то «реальне» треба відразу після підписання договору. Однак практика показує, що проміжні наочні результати роботи над системою, а саме прототипи інтерфейсу, продемонстровані вже на другий день роботи, а не через кілька тижнів, призводять клієнта в себе захищеними. На відміну від звичайного ТЗ, робота над яким замовнику реально не видно («ну що там, пара пунктів додалася») прототипи інтерфейсу легко зрозумілі і прогрес у роботі явно помітний. Друга організаційна проблема пов'язана з необхідністю підписувати два договори: на створення ТЗ (читай - інтерфейсу) і на розробку функціональності системи. Причому підписання другого договору відкладається на певний строк, необхідний для розробки інтерфейсу, що розтягує проект у часі. У принципі, ця проблема нерозв'язна, але, з іншого боку, тут багато що залежить від її сприйняття: так, договору два, але зате другий договір виходить значно більш точним (вже маючи інтерфейс, легше оцінити трудовитрати).<br /> <br /> Технічна проблема пов'язана з труднощами прототипування. У звичайному режимі роботи інтерфейс створюється вже в засобі розробки, створювати ж прототип таким чином нерентабельно. Інтерфейс створюється через безліч ітерацій, а переробляти вже зроблене вже дорого. Порівняно недавно з'явилися спеціальні засоби для прототипування інтерфейсу (наприклад, Norpath Studio), але поки вони досить сирі. Вихід - використання неспеціалізованих графічних редакторів. Ще кілька років тому основним таким редактором був MS PowerPoint, зараз же найбільш зручним слід визнати MS Visio. Складні екранні форми, втім, до цих пір зручніше просто малювати на папері.<br /> <br /> І, нарешті, головна проблема. Подовження процесу розробки ТЗ часто сприймається самими розробниками як безумовне зло - звичка спочатку робити, а вже потім думати, традиційно сильна в російському IT-бізнесі. На жаль, змінити цей звичай може тільки «досвід, син помилок важких». Поки, в усякому разі ...<br /> <br /> Звичайно, проектування інтерфесу на етапі розробки специфікацій системи не є панацеєю. Такий підхід не дозволяє поліпшити якість розробки в принципі, наприклад, він зовсім не зменшує кількість помилок програмування. Більш того, він не завжди застосуємо. Інтерфейс складної системи неможливо з самого початку спроектувати повністю: доведеться спочатку робити працюючу бета-версію і остаточно ред інтерфейс вже на її основі. Крім того, у багатьох проектах з-за не залежать ні від кого причин не виходить розтягувати процес створення ТЗ (замовник хоче побачити які-небудь результати вже завтра). Однак, враховуючи низькі «вхідні» вимоги до застосування запропонованого методу (незрівнянні, наприклад, з тяганиною і бюрократією, зумовленої використанням UML), проектування інтерфейсів на стадії підготовки специфікацій майже завжди є вкрай успішним методом вирішення проблем впровадження.</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F_%D1%96%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D1%83_%D1%8F%D0%BA_%D1%87%D0%B0%D1%81%D1%82%D0%B8%D0%BD%D0%B0_%D1%80%D0%BE%D0%B7%D1%80%D0%BE%D0%B1%D0%BA%D0%B8_%D0%A2%D0%97 2011-12-13T13:30:07Z

<p>I Shevchenko: </p> <hr /> <div>Впровадження систем автоматизації бізнесу, як знає будь-який в цій області фахівець, аж ніяк не є легкою справою. Якщо саме створення системи технічно є не дуже складним (наприклад, не можна сказати, що середньостатистична система наповнена складними алгоритмами), то впровадження такої системи вимагає від автоматизатора рідкісного завзяття та спритності. При цьому корінь багатьох проблем знаходиться у технічному завданні. Як кажуть, «що задумали, те й зробили», але потім виявляється, що задумали-то і неправильно. Для вирішення проблем, що виникають при створенні ТЗ, а виявлених при впровадженні, придумано безліч технологій і методів проте сама їх кількість свідчить про те, що жоден метод до повного успіху не приводить. Крім того, багато методів мають принциповий недолік - вони збільшують об'єм роботи наодному етапі, хай і заради економії на іншому, а також вимагають серйозних інвестицій у навчанні працівників (характерний приклад - RUP). Існує, однак, підхід, який не вимагає особливої ​​кваліфікації співробітників, значно полегшує впровадження, не збільшуючи обсяг робіт по розробки ТЗ.<br /> <br /> Сутність підходу може бути описана однією фразою - проектування інтерфейсу не є частиною процесу розробки, а є частиною процесу створення специфікацій на систему.<br /> <br /> Тут необхідно зробити два важливих уточнення. По-перше, інтерфейс все одно буде розроблений (практика показує, що замовники чомусь неохоче оплачують функціональність без інтерфейсу). По-друге, від проектування інтерфейсу нічого особливого не потрібно - на нього можуть бути виділені ті ж ресурси, що і у випадку звичайної розробки, так само як і вийти він може таким же. Авторам, які заробляють собі на життя розробкою ергономічних інтерфейсів, неприємно це говорити, але інтерфейс може бути навіть не ергономічним, все одно впровадження буде полегшено; зрозуміло, у випадку ергономічного інтерфейсу впровадження буде ще більш простим, але такий інтерфейс дорожче і довше робиться.<br /> <br /> Пропонований підхід дозволяє вирішити наступні проблеми:<br /> *Усунути розбіжності в поглядах на постановку задачі замовника і виконавця. Специфікації на скільки-небудь складні системи занадто абстрактні. Їх насилу утримують в голові навіть автори, а до кінця не розуміє ніхто, особливо ключова особа - замовник. Для нього ця специфікація нічим не відрізняється від сакральних письмен (багато хто навіть припускають, що незрозумілі ТЗ призначені для того, щоб справити на них враження і здерти побільше грошей). Немає різниці, що підсунуть йому розробники, реальне ТЗ або інструкцію до газонокосарці на фарсі - всі однаково незрозуміло. Наївно припускати, що замовник, легко підписав таке ТЗ, також легко прийме розроблену систему. Прототипи інтерфейсу є тим єдиним документом, який замовник може зрозуміти і оцінити. А зрозумівши і оцінивши - свідомо підписати.<br /> <br /> *Полегшити процес впровадження системи. Вагома частина проблем впровадження в якісно виконаному проекті припадає на інтерфейс, створений формально правильно, але неадекватно уявленням замовника. Не існує виду ТЗ, крім власне прототипу інтерфейсу, який би міг інтегрувати такого роду вимоги. Наочний приклад: у будь-якому ТЗ можна прописати, що «в системі є адресна книга, яка складається з таких-то даних і таких-то функцій». Але неможливо формалізувати вже в ТЗ, як ця адресна книга повинна реально працювати (якісь функції потрібно «витягнути» наверх, якісь можна «засунути»), як, врешті-решт, ця адресна книга повинна виглядати. При цьому апеляції виконавця до підписаного технічним завданням - мовляв, ось же перераховані функції ... ось вони всі в наявності - як правило, не спрацьовують, оскільки при відомій спритності у контексті користувальницького інтерфейсу проінтерпретувати ТЗ завжди можна дуже по-різному. Тільки заздалегідь спроектований інтерфейс дозволяє застрахуватися від такого роду претензій.<br /> <br /> *Скоротити число доробок системи, викликаних невідповідністю її функціональності очікуванням клієнта. Тільки побачивши саму систему, замовник може реально зрозуміти її можливості, так само як і оцінити власні потреби. Для замовника програмний продукт і його інтерфейс цілком тотожні. Отже, показавши замовнику інтерфейс на стадії підготовки ТЗ, можна знизити кількість і обсяг переробок, потреба в яких виникає через розбіжності очікувань замовника із запланованою в ТЗ функціональністю системи. (Потрібно, втім, відзначити, що такі переробки частіше за все не проблематичні для розробників, які зазвичай наполягають на додатковій оплаті цих послуг.)<br /> <br /> *Зняти ризик необхідності доопрацювання функціональності системи, з-за незадоволеності замовника запропонованим інтерфейсом. При розробці інтерфейсу немає рішуче ніякої гарантії того, що він буде прийнятий замовником. Опис функцій системи бінарно, функція може бути, може не бути. Доказ її наявності рідко вимагає аргументації. Інтерфейс ж може бути або досить хорошим, або недостатньо хорошим. Коли в справу вступають відносні терміни, все ускладнюється, що може приводити в виникненню конфліктних ситуацій. Годі й говорити, що при переробці недостатньо хорошого інтерфейсу функціональність системи, яка вже є, змінюється теж, причому без оплати праці розробника.<br /> <br /> Таким чином, є об'єктивна користь в тому, щоб розглядати проектування інтерфейсу не як стадію розробки, а як стадію створення ТЗ. Але як це зробити? На перший погляд, завдання здається важкою, частково з організаційної, частково з технічної сторін.<br /> <br /> Спочатку про організаційну стороні. На перший погляд замовника важко переконати відмовитися від думки, що робити що-то «реальне» треба відразу після підписання договору. Однак практика показує, що проміжні наочні результати роботи над системою, а саме прототипи інтерфейсу, продемонстровані вже на другий день роботи, а не через кілька тижнів, призводять клієнта в себе захищеними. На відміну від звичайного ТЗ, робота над яким замовнику реально не видно («ну що там, пара пунктів додалася») прототипи інтерфейсу легко зрозумілі і прогрес у роботі явно помітний. Друга організаційна проблема пов'язана з необхідністю підписувати два договори: на створення ТЗ (читай - інтерфейсу) і на розробку функціональності системи. Причому підписання другого договору відкладається на певний строк, необхідний для розробки інтерфейсу, що розтягує проект у часі. У принципі, ця проблема нерозв'язна, але, з іншого боку, тут багато що залежить від її сприйняття: так, договору два, але зате другий договір виходить значно більш точним (вже маючи інтерфейс, легше оцінити трудовитрати).<br /> <br /> Технічна проблема пов'язана з труднощами прототипування. У звичайному режимі роботи інтерфейс створюється вже в засобі розробки, створювати ж прототип таким чином нерентабельно. Інтерфейс створюється через безліч ітерацій, а переробляти вже зроблене вже дорого. Порівняно недавно з'явилися спеціальні засоби для прототипування інтерфейсу (наприклад, Norpath Studio), але поки вони досить сирі. Вихід - використання неспеціалізованих графічних редакторів. Ще кілька років тому основним таким редактором був MS PowerPoint, зараз же найбільш зручним слід визнати MS Visio. Складні екранні форми, втім, до цих пір зручніше просто малювати на папері.<br /> <br /> І, нарешті, головна проблема. Подовження процесу розробки ТЗ часто сприймається самими розробниками як безумовне зло - звичка спочатку робити, а вже потім думати, традиційно сильна в російському IT-бізнесі. На жаль, змінити цей звичай може тільки «досвід, син помилок важких». Поки, в усякому разі ...<br /> <br /> Звичайно, проектування інтерфесу на етапі розробки специфікацій системи не є панацеєю. Такий підхід не дозволяє поліпшити якість розробки в принципі, наприклад, він зовсім не зменшує кількість помилок програмування. Більш того, він не завжди застосуємо. Інтерфейс складної системи неможливо з самого початку спроектувати повністю: доведеться спочатку робити працюючу бета-версію і остаточно ред інтерфейс вже на її основі. Крім того, у багатьох проектах з-за не залежать ні від кого причин не виходить розтягувати процес створення ТЗ (замовник хоче побачити які-небудь результати вже завтра). Однак, враховуючи низькі «вхідні» вимоги до застосування запропонованого методу (незрівнянні, наприклад, з тяганиною і бюрократією, зумовленої використанням UML), проектування інтерфейсів на стадії підготовки специфікацій майже завжди є вкрай успішним методом вирішення проблем впровадження.</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F_%D1%96%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D1%83_%D1%8F%D0%BA_%D1%87%D0%B0%D1%81%D1%82%D0%B8%D0%BD%D0%B0_%D1%80%D0%BE%D0%B7%D1%80%D0%BE%D0%B1%D0%BA%D0%B8_%D0%A2%D0%97 2011-12-13T13:29:43Z

<p>I Shevchenko: </p> <hr /> <div>Впровадження систем автоматизації бізнесу, як знає будь-який в цій області фахівець, аж ніяк не є легкою справою. Якщо саме створення системи технічно є не дуже складним (наприклад, не можна сказати, що середньостатистична система наповнена складними алгоритмами), то впровадження такої системи вимагає від автоматизатора рідкісного завзяття та спритності. При цьому корінь багатьох проблем знаходиться у технічному завданні. Як кажуть, «що задумали, те й зробили», але потім виявляється, що задумали-то і неправильно. Для вирішення проблем, що виникають при створенні ТЗ, а виявлених при впровадженні, придумано безліч технологій і методів проте сама їх кількість свідчить про те, що жоден метод до повного успіху не приводить. Крім того, багато методів мають принциповий недолік - вони збільшують об'єм роботи наодному етапі, хай і заради економії на іншому, а також вимагають серйозних інвестицій у навчанні працівників (характерний приклад - RUP). Існує, однак, підхід, який не вимагає особливої ​​кваліфікації співробітників, значно полегшує впровадження, не збільшуючи обсяг робіт по розробки ТЗ.<br /> <br /> Сутність підходу може бути описана однією фразою - проектування інтерфейсу не є частиною процесу розробки, а є частиною процесу створення специфікацій на систему.<br /> <br /> Тут необхідно зробити два важливих уточнення. По-перше, інтерфейс все одно буде розроблений (практика показує, що замовники чомусь неохоче оплачують функціональність без інтерфейсу). По-друге, від проектування інтерфейсу нічого особливого не потрібно - на нього можуть бути виділені ті ж ресурси, що і у випадку звичайної розробки, так само як і вийти він може таким же. Авторам, які заробляють собі на життя розробкою ергономічних інтерфейсів, неприємно це говорити, але інтерфейс може бути навіть не ергономічним, все одно впровадження буде полегшено; зрозуміло, у випадку ергономічного інтерфейсу впровадження буде ще більш простим, але такий інтерфейс дорожче і довше робиться.<br /> <br /> Пропонований підхід дозволяє вирішити наступні проблеми:<br /> *Усунути розбіжності в поглядах на постановку задачі замовника і виконавця. Специфікації на скільки-небудь складні системи занадто абстрактні. Їх насилу утримують в голові навіть автори, а до кінця не розуміє ніхто, особливо ключова особа - замовник. Для нього ця специфікація нічим не відрізняється від сакральних письмен (багато хто навіть припускають, що незрозумілі ТЗ призначені для того, щоб справити на них враження і здерти побільше грошей). Немає різниці, що підсунуть йому розробники, реальне ТЗ або інструкцію до газонокосарці на фарсі - всі однаково незрозуміло. Наївно припускати, що замовник, легко підписав таке ТЗ, також легко прийме розроблену систему. Прототипи інтерфейсу є тим єдиним документом, який замовник може зрозуміти і оцінити. А зрозумівши і оцінивши - свідомо підписати.<br /> *Полегшити процес впровадження системи. Вагома частина проблем впровадження в якісно виконаному проекті припадає на інтерфейс, створений формально правильно, але неадекватно уявленням замовника. Не існує виду ТЗ, крім власне прототипу інтерфейсу, який би міг інтегрувати такого роду вимоги. Наочний приклад: у будь-якому ТЗ можна прописати, що «в системі є адресна книга, яка складається з таких-то даних і таких-то функцій». Але неможливо формалізувати вже в ТЗ, як ця адресна книга повинна реально працювати (якісь функції потрібно «витягнути» наверх, якісь можна «засунути»), як, врешті-решт, ця адресна книга повинна виглядати. При цьому апеляції виконавця до підписаного технічним завданням - мовляв, ось же перераховані функції ... ось вони всі в наявності - як правило, не спрацьовують, оскільки при відомій спритності у контексті користувальницького інтерфейсу проінтерпретувати ТЗ завжди можна дуже по-різному. Тільки заздалегідь спроектований інтерфейс дозволяє застрахуватися від такого роду претензій.<br /> *Скоротити число доробок системи, викликаних невідповідністю її функціональності очікуванням клієнта. Тільки побачивши саму систему, замовник може реально зрозуміти її можливості, так само як і оцінити власні потреби. Для замовника програмний продукт і його інтерфейс цілком тотожні. Отже, показавши замовнику інтерфейс на стадії підготовки ТЗ, можна знизити кількість і обсяг переробок, потреба в яких виникає через розбіжності очікувань замовника із запланованою в ТЗ функціональністю системи. (Потрібно, втім, відзначити, що такі переробки частіше за все не проблематичні для розробників, які зазвичай наполягають на додатковій оплаті цих послуг.)<br /> *Зняти ризик необхідності доопрацювання функціональності системи, з-за незадоволеності замовника запропонованим інтерфейсом. При розробці інтерфейсу немає рішуче ніякої гарантії того, що він буде прийнятий замовником. Опис функцій системи бінарно, функція може бути, може не бути. Доказ її наявності рідко вимагає аргументації. Інтерфейс ж може бути або досить хорошим, або недостатньо хорошим. Коли в справу вступають відносні терміни, все ускладнюється, що може приводити в виникненню конфліктних ситуацій. Годі й говорити, що при переробці недостатньо хорошого інтерфейсу функціональність системи, яка вже є, змінюється теж, причому без оплати праці розробника.<br /> <br /> Таким чином, є об'єктивна користь в тому, щоб розглядати проектування інтерфейсу не як стадію розробки, а як стадію створення ТЗ. Але як це зробити? На перший погляд, завдання здається важкою, частково з організаційної, частково з технічної сторін.<br /> <br /> Спочатку про організаційну стороні. На перший погляд замовника важко переконати відмовитися від думки, що робити що-то «реальне» треба відразу після підписання договору. Однак практика показує, що проміжні наочні результати роботи над системою, а саме прототипи інтерфейсу, продемонстровані вже на другий день роботи, а не через кілька тижнів, призводять клієнта в себе захищеними. На відміну від звичайного ТЗ, робота над яким замовнику реально не видно («ну що там, пара пунктів додалася») прототипи інтерфейсу легко зрозумілі і прогрес у роботі явно помітний. Друга організаційна проблема пов'язана з необхідністю підписувати два договори: на створення ТЗ (читай - інтерфейсу) і на розробку функціональності системи. Причому підписання другого договору відкладається на певний строк, необхідний для розробки інтерфейсу, що розтягує проект у часі. У принципі, ця проблема нерозв'язна, але, з іншого боку, тут багато що залежить від її сприйняття: так, договору два, але зате другий договір виходить значно більш точним (вже маючи інтерфейс, легше оцінити трудовитрати).<br /> <br /> Технічна проблема пов'язана з труднощами прототипування. У звичайному режимі роботи інтерфейс створюється вже в засобі розробки, створювати ж прототип таким чином нерентабельно. Інтерфейс створюється через безліч ітерацій, а переробляти вже зроблене вже дорого. Порівняно недавно з'явилися спеціальні засоби для прототипування інтерфейсу (наприклад, Norpath Studio), але поки вони досить сирі. Вихід - використання неспеціалізованих графічних редакторів. Ще кілька років тому основним таким редактором був MS PowerPoint, зараз же найбільш зручним слід визнати MS Visio. Складні екранні форми, втім, до цих пір зручніше просто малювати на папері.<br /> <br /> І, нарешті, головна проблема. Подовження процесу розробки ТЗ часто сприймається самими розробниками як безумовне зло - звичка спочатку робити, а вже потім думати, традиційно сильна в російському IT-бізнесі. На жаль, змінити цей звичай може тільки «досвід, син помилок важких». Поки, в усякому разі ...<br /> <br /> Звичайно, проектування інтерфесу на етапі розробки специфікацій системи не є панацеєю. Такий підхід не дозволяє поліпшити якість розробки в принципі, наприклад, він зовсім не зменшує кількість помилок програмування. Більш того, він не завжди застосуємо. Інтерфейс складної системи неможливо з самого початку спроектувати повністю: доведеться спочатку робити працюючу бета-версію і остаточно ред інтерфейс вже на її основі. Крім того, у багатьох проектах з-за не залежать ні від кого причин не виходить розтягувати процес створення ТЗ (замовник хоче побачити які-небудь результати вже завтра). Однак, враховуючи низькі «вхідні» вимоги до застосування запропонованого методу (незрівнянні, наприклад, з тяганиною і бюрократією, зумовленої використанням UML), проектування інтерфейсів на стадії підготовки специфікацій майже завжди є вкрай успішним методом вирішення проблем впровадження.</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F_%D1%96%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D1%83_%D1%8F%D0%BA_%D1%87%D0%B0%D1%81%D1%82%D0%B8%D0%BD%D0%B0_%D1%80%D0%BE%D0%B7%D1%80%D0%BE%D0%B1%D0%BA%D0%B8_%D0%A2%D0%97 2011-12-13T13:29:01Z

<p>I Shevchenko: </p> <hr /> <div>Впровадження систем автоматизації бізнесу, як знає будь-який в цій області фахівець, аж ніяк не є легкою справою. Якщо саме створення системи технічно є не дуже складним (наприклад, не можна сказати, що середньостатистична система наповнена складними алгоритмами), то впровадження такої системи вимагає від автоматизатора рідкісного завзяття та спритності. При цьому корінь багатьох проблем знаходиться у технічному завданні. Як кажуть, «що задумали, те й зробили», але потім виявляється, що задумали-то і неправильно. Для вирішення проблем, що виникають при створенні ТЗ, а виявлених при впровадженні, придумано безліч технологій і методів проте сама їх кількість свідчить про те, що жоден метод до повного успіху не приводить. Крім того, багато методів мають принциповий недолік - вони збільшують об'єм роботи наодному етапі, хай і заради економії на іншому, а також вимагають серйозних інвестицій у навчанні працівників (характерний приклад - RUP). Існує, однак, підхід, який не вимагає особливої ​​кваліфікації співробітників, значно полегшує впровадження, не збільшуючи обсяг робіт по розробки ТЗ.<br /> <br /> Сутність підходу може бути описана однією фразою - проектування інтерфейсу не є частиною процесу розробки, а є частиною процесу створення специфікацій на систему.<br /> <br /> Тут необхідно зробити два важливих уточнення. По-перше, інтерфейс все одно буде розроблений (практика показує, що замовники чомусь неохоче оплачують функціональність без інтерфейсу). По-друге, від проектування інтерфейсу нічого особливого не потрібно - на нього можуть бути виділені ті ж ресурси, що і у випадку звичайної розробки, так само як і вийти він може таким же. Авторам, які заробляють собі на життя розробкою ергономічних інтерфейсів, неприємно це говорити, але інтерфейс може бути навіть не ергономічним, все одно впровадження буде полегшено; зрозуміло, у випадку ергономічного інтерфейсу впровадження буде ще більш простим, але такий інтерфейс дорожче і довше робиться.<br /> <br /> Пропонований підхід дозволяє вирішити наступні проблеми:<br /> *Усунути розбіжності в поглядах на постановку задачі замовника і виконавця. Специфікації на скільки-небудь складні системи занадто абстрактні. Їх насилу утримують в голові навіть автори, а до кінця не розуміє ніхто, особливо ключова особа - замовник. Для нього ця специфікація нічим не відрізняється від сакральних письмен (багато хто навіть припускають, що незрозумілі ТЗ призначені для того, щоб справити на них враження і здерти побільше грошей). Немає різниці, що підсунуть йому розробники, реальне ТЗ або інструкцію до газонокосарці на фарсі - всі однаково незрозуміло. Наївно припускати, що замовник, легко підписав таке ТЗ, також легко прийме розроблену систему. Прототипи інтерфейсу є тим єдиним документом, який замовник може зрозуміти і оцінити. А зрозумівши і оцінивши - свідомо підписати.<br /> *Полегшити процес впровадження системи. Вагома частина проблем впровадження в якісно виконаному проекті припадає на інтерфейс, створений формально правильно, але неадекватно уявленням замовника. Не існує виду ТЗ, крім власне прототипу інтерфейсу, який би міг інтегрувати такого роду вимоги. Наочний приклад: у будь-якому ТЗ можна прописати, що «в системі є адресна книга, яка складається з таких-то даних і таких-то функцій». Але неможливо формалізувати вже в ТЗ, як ця адресна книга повинна реально працювати (якісь функції потрібно «витягнути» наверх, якісь можна «засунути»), як, врешті-решт, ця адресна книга повинна виглядати. При цьому апеляції виконавця до підписаного технічним завданням - мовляв, ось же перераховані функції ... ось вони всі в наявності - як правило, не спрацьовують, оскільки при відомій спритності у контексті користувальницького інтерфейсу проінтерпретувати ТЗ завжди можна дуже по-різному. Тільки заздалегідь спроектований інтерфейс дозволяє застрахуватися від такого роду претензій.<br /> *Скоротити число доробок системи, викликаних невідповідністю її функціональності очікуванням клієнта. Тільки побачивши саму систему, замовник може реально зрозуміти її можливості, так само як і оцінити власні потреби. Для замовника програмний продукт і його інтерфейс цілком тотожні. Отже, показавши замовнику інтерфейс на стадії підготовки ТЗ, можна знизити кількість і обсяг переробок, потреба в яких виникає через розбіжності очікувань замовника із запланованою в ТЗ функціональністю системи. (Потрібно, втім, відзначити, що такі переробки частіше за все не проблематичні для розробників, які зазвичай наполягають на додатковій оплаті цих послуг.)<br /> *Зняти ризик необхідності доопрацювання функціональності системи, з-за незадоволеності замовника запропонованим інтерфейсом. При розробці інтерфейсу немає рішуче ніякої гарантії того, що він буде прийнятий замовником. Опис функцій системи бінарно, функція може бути, може не бути. Доказ її наявності рідко вимагає аргументації. Інтерфейс ж може бути або досить хорошим, або недостатньо хорошим. Коли в справу вступають відносні терміни, все ускладнюється, що може приводити в виникненню конфліктних ситуацій. Годі й говорити, що при переробці недостатньо хорошого інтерфейсу функціональність системи, яка вже є, змінюється теж, причому без оплати праці розробника.<br /> <br /> Таким чином, є об'єктивна користь в тому, щоб розглядати проектування інтерфейсу не як стадію розробки, а як стадію створення ТЗ. Але як це зробити? На перший погляд, завдання здається важкою, частково з організаційної, частково з технічної сторін.<br /> <br /> Спочатку про організаційну стороні. На перший погляд замовника важко переконати відмовитися від думки, що робити що-то «реальне» треба відразу після підписання договору. Однак практика показує, що проміжні наочні результати роботи над системою, а саме прототипи інтерфейсу, продемонстровані вже на другий день роботи, а не через кілька тижнів, призводять клієнта в себе захищеними. На відміну від звичайного ТЗ, робота над яким замовнику реально не видно («ну що там, пара пунктів додалася») прототипи інтерфейсу легко зрозумілі і прогрес у роботі явно помітний. Друга організаційна проблема пов'язана з необхідністю підписувати два договори: на створення ТЗ (читай - інтерфейсу) і на розробку функціональності системи. Причому підписання другого договору відкладається на певний строк, необхідний для розробки інтерфейсу, що розтягує проект у часі. У принципі, ця проблема нерозв'язна, але, з іншого боку, тут багато що залежить від її сприйняття: так, договору два, але зате другий договір виходить значно більш точним (вже маючи інтерфейс, легше оцінити трудовитрати).<br /> <br /> Технічна проблема пов'язана з труднощами прототипування. У звичайному режимі роботи інтерфейс створюється вже в засобі розробки, створювати ж прототип таким чином нерентабельно. Інтерфейс створюється через безліч ітерацій, а переробляти вже зроблене вже дорого. Порівняно недавно з'явилися спеціальні засоби для прототипування інтерфейсу (наприклад, Norpath Studio), але поки вони досить сирі. Вихід - використання неспеціалізованих графічних редакторів. Ще кілька років тому основним таким редактором був MS PowerPoint, зараз же найбільш зручним слід визнати MS Visio. Складні екранні форми, втім, до цих пір зручніше просто малювати на папері.<br /> <br /> І, нарешті, головна проблема. Подовження процесу розробки ТЗ часто сприймається самими розробниками як безумовне зло - звичка спочатку робити, а вже потім думати, традиційно сильна в російському IT-бізнесі. На жаль, змінити цей звичай може тільки «досвід, син помилок важких». Поки, в усякому разі ...<br /> <br /> Звичайно, проектування інтерфесу на етапі розробки специфікацій системи не є панацеєю. Такий підхід не дозволяє поліпшити якість розробки в принципі, наприклад, він зовсім не зменшує кількість помилок програмування. Більш того, він не завжди застосуємо. Інтерфейс складної системи неможливо з самого початку спроектувати повністю: доведеться спочатку робити працюючу бета-версію і остаточно ред інтерфейс вже на її основі. Крім того, у багатьох проектах з-за не залежать ні від кого причин не виходить розтягувати процес створення ТЗ (замовник хоче побачити які-небудь результати вже завтра). Однак, враховуючи низькі «вхідні» вимоги до застосування запропонованого методу (незрівнянні, наприклад, з тяганиною і бюрократією, зумовленої використанням UML), проектування інтерфейсів на стадії підготовки специфікацій майже завжди є вкрай успішним методом вирішення проблем впровадження.</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F_%D1%96%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D1%83_%D1%8F%D0%BA_%D1%87%D0%B0%D1%81%D1%82%D0%B8%D0%BD%D0%B0_%D1%80%D0%BE%D0%B7%D1%80%D0%BE%D0%B1%D0%BA%D0%B8_%D0%A2%D0%97 2011-12-13T13:27:54Z

<p>I Shevchenko: </p> <hr /> <div>Впровадження систем автоматизації бізнесу, як знає будь-який в цій області фахівець, аж ніяк не є легкою справою. Якщо саме створення системи технічно є не дуже складним (наприклад, не можна сказати, що середньостатистична система наповнена складними алгоритмами), то впровадження такої системи вимагає від автоматизатора рідкісного завзяття та спритності. При цьому корінь багатьох проблем знаходиться у технічному завданні. Як кажуть, «що задумали, те й зробили», але потім виявляється, що задумали-то і неправильно. Для вирішення проблем, що виникають при створенні ТЗ, а виявлених при впровадженні, придумано безліч технологій і методів проте сама їх кількість свідчить про те, що жоден метод до повного успіху не приводить. Крім того, багато методів мають принциповий недолік - вони збільшують об'єм роботи наодному етапі, хай і заради економії на іншому, а також вимагають серйозних інвестицій у навчанні працівників (характерний приклад - RUP). Існує, однак, підхід, який не вимагає особливої ​​кваліфікації співробітників, значно полегшує впровадження, не збільшуючи обсяг робіт по розробки ТЗ.<br /> <br /> Сутність підходу може бути описана однією фразою - проектування інтерфейсу не є частиною процесу розробки, а є частиною процесу створення специфікацій на систему.<br /> <br /> Тут необхідно зробити два важливих уточнення. По-перше, інтерфейс все одно буде розроблений (практика показує, що замовники чомусь неохоче оплачують функціональність без інтерфейсу). По-друге, від проектування інтерфейсу нічого особливого не потрібно - на нього можуть бути виділені ті ж ресурси, що і у випадку звичайної розробки, так само як і вийти він може таким же. Авторам, які заробляють собі на життя розробкою ергономічних інтерфейсів, неприємно це говорити, але інтерфейс може бути навіть не ергономічним, все одно впровадження буде полегшено; зрозуміло, у випадку ергономічного інтерфейсу впровадження буде ще більш простим, але такий інтерфейс дорожче і довше робиться.<br /> <br /> Пропонований підхід дозволяє вирішити наступні проблеми:<br /> <br /> *Усунути розбіжності в поглядах на постановку задачі замовника і виконавця. Специфікації на скільки-небудь складні системи занадто абстрактні. Їх насилу утримують в голові навіть автори, а до кінця не розуміє ніхто, особливо ключова особа - замовник. Для нього ця специфікація нічим не відрізняється від сакральних письмен (багато хто навіть припускають, що незрозумілі ТЗ призначені для того, щоб справити на них враження і здерти побільше грошей). Немає різниці, що підсунуть йому розробники, реальне ТЗ або інструкцію до газонокосарці на фарсі - всі однаково незрозуміло. Наївно припускати, що замовник, легко підписав таке ТЗ, також легко прийме розроблену систему. Прототипи інтерфейсу є тим єдиним документом, який замовник може зрозуміти і оцінити. А зрозумівши і оцінивши - свідомо підписати.<br /> <br /> *Полегшити процес впровадження системи. Вагома частина проблем впровадження в якісно виконаному проекті припадає на інтерфейс, створений формально правильно, але неадекватно уявленням замовника. Не існує виду ТЗ, крім власне прототипу інтерфейсу, який би міг інтегрувати такого роду вимоги. Наочний приклад: у будь-якому ТЗ можна прописати, що «в системі є адресна книга, яка складається з таких-то даних і таких-то функцій». Але неможливо формалізувати вже в ТЗ, як ця адресна книга повинна реально працювати (якісь функції потрібно «витягнути» наверх, якісь можна «засунути»), як, врешті-решт, ця адресна книга повинна виглядати. При цьому апеляції виконавця до підписаного технічним завданням - мовляв, ось же перераховані функції ... ось вони всі в наявності - як правило, не спрацьовують, оскільки при відомій спритності у контексті користувальницького інтерфейсу проінтерпретувати ТЗ завжди можна дуже по-різному. Тільки заздалегідь спроектований інтерфейс дозволяє застрахуватися від такого роду претензій.<br /> <br /> *Скоротити число доробок системи, викликаних невідповідністю її функціональності очікуванням клієнта. Тільки побачивши саму систему, замовник може реально зрозуміти її можливості, так само як і оцінити власні потреби. Для замовника програмний продукт і його інтерфейс цілком тотожні. Отже, показавши замовнику інтерфейс на стадії підготовки ТЗ, можна знизити кількість і обсяг переробок, потреба в яких виникає через розбіжності очікувань замовника із запланованою в ТЗ функціональністю системи. (Потрібно, втім, відзначити, що такі переробки частіше за все не проблематичні для розробників, які зазвичай наполягають на додатковій оплаті цих послуг.)<br /> <br /> *Зняти ризик необхідності доопрацювання функціональності системи, з-за незадоволеності замовника запропонованим інтерфейсом. При розробці інтерфейсу немає рішуче ніякої гарантії того, що він буде прийнятий замовником. Опис функцій системи бінарно, функція може бути, може не бути. Доказ її наявності рідко вимагає аргументації. Інтерфейс ж може бути або досить хорошим, або недостатньо хорошим. Коли в справу вступають відносні терміни, все ускладнюється, що може приводити в виникненню конфліктних ситуацій. Годі й говорити, що при переробці недостатньо хорошого інтерфейсу функціональність системи, яка вже є, змінюється теж, причому без оплати праці розробника.<br /> <br /> Таким чином, є об'єктивна користь в тому, щоб розглядати проектування інтерфейсу не як стадію розробки, а як стадію створення ТЗ. Але як це зробити? На перший погляд, завдання здається важкою, частково з організаційної, частково з технічної сторін.<br /> <br /> Спочатку про організаційну стороні. На перший погляд замовника важко переконати відмовитися від думки, що робити що-то «реальне» треба відразу після підписання договору. Однак практика показує, що проміжні наочні результати роботи над системою, а саме прототипи інтерфейсу, продемонстровані вже на другий день роботи, а не через кілька тижнів, призводять клієнта в себе захищеними. На відміну від звичайного ТЗ, робота над яким замовнику реально не видно («ну що там, пара пунктів додалася») прототипи інтерфейсу легко зрозумілі і прогрес у роботі явно помітний. Друга організаційна проблема пов'язана з необхідністю підписувати два договори: на створення ТЗ (читай - інтерфейсу) і на розробку функціональності системи. Причому підписання другого договору відкладається на певний строк, необхідний для розробки інтерфейсу, що розтягує проект у часі. У принципі, ця проблема нерозв'язна, але, з іншого боку, тут багато що залежить від її сприйняття: так, договору два, але зате другий договір виходить значно більш точним (вже маючи інтерфейс, легше оцінити трудовитрати).<br /> <br /> Технічна проблема пов'язана з труднощами прототипування. У звичайному режимі роботи інтерфейс створюється вже в засобі розробки, створювати ж прототип таким чином нерентабельно. Інтерфейс створюється через безліч ітерацій, а переробляти вже зроблене вже дорого. Порівняно недавно з'явилися спеціальні засоби для прототипування інтерфейсу (наприклад, Norpath Studio), але поки вони досить сирі. Вихід - використання неспеціалізованих графічних редакторів. Ще кілька років тому основним таким редактором був MS PowerPoint, зараз же найбільш зручним слід визнати MS Visio. Складні екранні форми, втім, до цих пір зручніше просто малювати на папері.<br /> <br /> І, нарешті, головна проблема. Подовження процесу розробки ТЗ часто сприймається самими розробниками як безумовне зло - звичка спочатку робити, а вже потім думати, традиційно сильна в російському IT-бізнесі. На жаль, змінити цей звичай може тільки «досвід, син помилок важких». Поки, в усякому разі ...<br /> <br /> Звичайно, проектування інтерфесу на етапі розробки специфікацій системи не є панацеєю. Такий підхід не дозволяє поліпшити якість розробки в принципі, наприклад, він зовсім не зменшує кількість помилок програмування. Більш того, він не завжди застосуємо. Інтерфейс складної системи неможливо з самого початку спроектувати повністю: доведеться спочатку робити працюючу бета-версію і остаточно ред інтерфейс вже на її основі. Крім того, у багатьох проектах з-за не залежать ні від кого причин не виходить розтягувати процес створення ТЗ (замовник хоче побачити які-небудь результати вже завтра). Однак, враховуючи низькі «вхідні» вимоги до застосування запропонованого методу (незрівнянні, наприклад, з тяганиною і бюрократією, зумовленої використанням UML), проектування інтерфейсів на стадії підготовки специфікацій майже завжди є вкрай успішним методом вирішення проблем впровадження.</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F_%D1%96%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D1%83_%D1%8F%D0%BA_%D1%87%D0%B0%D1%81%D1%82%D0%B8%D0%BD%D0%B0_%D1%80%D0%BE%D0%B7%D1%80%D0%BE%D0%B1%D0%BA%D0%B8_%D0%A2%D0%97 2011-12-13T13:27:29Z

<p>I Shevchenko: </p> <hr /> <div>Впровадження систем автоматизації бізнесу, як знає будь-який в цій області фахівець, аж ніяк не є легкою справою. Якщо саме створення системи технічно є не дуже складним (наприклад, не можна сказати, що середньостатистична система наповнена складними алгоритмами), то впровадження такої системи вимагає від автоматизатора рідкісного завзяття та спритності. При цьому корінь багатьох проблем знаходиться у технічному завданні. Як кажуть, «що задумали, те й зробили», але потім виявляється, що задумали-то і неправильно. Для вирішення проблем, що виникають при створенні ТЗ, а виявлених при впровадженні, придумано безліч технологій і методів проте сама їх кількість свідчить про те, що жоден метод до повного успіху не приводить. Крім того, багато методів мають принциповий недолік - вони збільшують об'єм роботи наодному етапі, хай і заради економії на іншому, а також вимагають серйозних інвестицій у навчанні працівників (характерний приклад - RUP). Існує, однак, підхід, який не вимагає особливої ​​кваліфікації співробітників, значно полегшує впровадження, не збільшуючи обсяг робіт по розробки ТЗ.<br /> <br /> Сутність підходу може бути описана однією фразою - проектування інтерфейсу не є частиною процесу розробки, а є частиною процесу створення специфікацій на систему.<br /> <br /> Тут необхідно зробити два важливих уточнення. По-перше, інтерфейс все одно буде розроблений (практика показує, що замовники чомусь неохоче оплачують функціональність без інтерфейсу). По-друге, від проектування інтерфейсу нічого особливого не потрібно - на нього можуть бути виділені ті ж ресурси, що і у випадку звичайної розробки, так само як і вийти він може таким же. Авторам, які заробляють собі на життя розробкою ергономічних інтерфейсів, неприємно це говорити, але інтерфейс може бути навіть не ергономічним, все одно впровадження буде полегшено; зрозуміло, у випадку ергономічного інтерфейсу впровадження буде ще більш простим, але такий інтерфейс дорожче і довше робиться.<br /> <br /> Пропонований підхід дозволяє вирішити наступні проблеми:<br /> <br /> *Усунути розбіжності в поглядах на постановку задачі замовника і виконавця. Специфікації на скільки-небудь складні системи занадто абстрактні. Їх насилу утримують в голові навіть автори, а до кінця не розуміє ніхто, особливо ключова особа - замовник. Для нього ця специфікація нічим не відрізняється від сакральних письмен (багато хто навіть припускають, що незрозумілі ТЗ призначені для того, щоб справити на них враження і здерти побільше грошей). Немає різниці, що підсунуть йому розробники, реальне ТЗ або інструкцію до газонокосарці на фарсі - всі однаково незрозуміло. Наївно припускати, що замовник, легко підписав таке ТЗ, також легко прийме розроблену систему. Прототипи інтерфейсу є тим єдиним документом, який замовник може зрозуміти і оцінити. А зрозумівши і оцінивши - свідомо підписати.<br /> <br /> *Полегшити процес впровадження системи. Вагома частина проблем впровадження в якісно виконаному проекті припадає на інтерфейс, створений формально правильно, але неадекватно уявленням замовника. Не існує виду ТЗ, крім власне прототипу інтерфейсу, який би міг інтегрувати такого роду вимоги. Наочний приклад: у будь-якому ТЗ можна прописати, що «в системі є адресна книга, яка складається з таких-то даних і таких-то функцій». Але неможливо формалізувати вже в ТЗ, як ця адресна книга повинна реально працювати (якісь функції потрібно «витягнути» наверх, якісь можна «засунути»), як, врешті-решт, ця адресна книга повинна виглядати. При цьому апеляції виконавця до підписаного технічним завданням - мовляв, ось же перераховані функції ... ось вони всі в наявності - як правило, не спрацьовують, оскільки при відомій спритності у контексті користувальницького інтерфейсу проінтерпретувати ТЗ завжди можна дуже по-різному. Тільки заздалегідь спроектований інтерфейс дозволяє застрахуватися від такого роду претензій.<br /> <br /> *Скоротити число доробок системи, викликаних невідповідністю її функціональності очікуванням клієнта. Тільки побачивши саму систему, замовник може реально зрозуміти її можливості, так само як і оцінити власні потреби. Для замовника програмний продукт і його інтерфейс цілком тотожні. Отже, показавши замовнику інтерфейс на стадії підготовки ТЗ, можна знизити кількість і обсяг переробок, потреба в яких виникає через розбіжності очікувань замовника із запланованою в ТЗ функціональністю системи. (Потрібно, втім, відзначити, що такі переробки частіше за все не проблематичні для розробників, які зазвичай наполягають на додатковій оплаті цих послуг.)<br /> <br /> *Зняти ризик необхідності доопрацювання функціональності системи, з-за незадоволеності замовника запропонованим інтерфейсом. При розробці інтерфейсу немає рішуче ніякої гарантії того, що він буде прийнятий замовником. Опис функцій системи бінарно, функція може бути, може не бути. Доказ її наявності рідко вимагає аргументації. Інтерфейс ж може бути або досить хорошим, або недостатньо хорошим. Коли в справу вступають відносні терміни, все ускладнюється, що може приводити в виникненню конфліктних ситуацій. Годі й говорити, що при переробці недостатньо хорошого інтерфейсу функціональність системи, яка вже є, змінюється теж, причому без оплати праці розробника.<br /> <br /> Таким чином, є об'єктивна користь в тому, щоб розглядати проектування інтерфейсу не як стадію розробки, а як стадію створення ТЗ. Але як це зробити? На перший погляд, завдання здається важкою, частково з організаційної, частково з технічної сторін.<br /> <br /> Спочатку про організаційну стороні. На перший погляд замовника важко переконати відмовитися від думки, що робити що-то «реальне» треба відразу після підписання договору. Однак практика показує, що проміжні наочні результати роботи над системою, а саме прототипи інтерфейсу, продемонстровані вже на другий день роботи, а не через кілька тижнів, призводять клієнта в себе захищеними. На відміну від звичайного ТЗ, робота над яким замовнику реально не видно («ну що там, пара пунктів додалася») прототипи інтерфейсу легко зрозумілі і прогрес у роботі явно помітний. Друга організаційна проблема пов'язана з необхідністю підписувати два договори: на створення ТЗ (читай - інтерфейсу) і на розробку функціональності системи. Причому підписання другого договору відкладається на певний строк, необхідний для розробки інтерфейсу, що розтягує проект у часі. У принципі, ця проблема нерозв'язна, але, з іншого боку, тут багато що залежить від її сприйняття: так, договору два, але зате другий договір виходить значно більш точним (вже маючи інтерфейс, легше оцінити трудовитрати).<br /> <br /> Технічна проблема пов'язана з труднощами прототипування. У звичайному режимі роботи інтерфейс створюється вже в засобі розробки, створювати ж прототип таким чином нерентабельно. Інтерфейс створюється через безліч ітерацій, а переробляти вже зроблене вже дорого. Порівняно недавно з'явилися спеціальні засоби для прототипування інтерфейсу (наприклад, Norpath Studio), але поки вони досить сирі. Вихід - використання неспеціалізованих графічних редакторів. Ще кілька років тому основним таким редактором був MS PowerPoint, зараз же найбільш зручним слід визнати MS Visio. Складні екранні форми, втім, до цих пір зручніше просто малювати на папері.<br /> <br /> І, нарешті, головна проблема. Подовження процесу розробки ТЗ часто сприймається самими розробниками як безумовне зло - звичка спочатку робити, а вже потім думати, традиційно сильна в російському IT-бізнесі. На жаль, змінити цей звичай може тільки «досвід, син помилок важких». Поки, в усякому разі ...<br /> <br /> Звичайно, проектування інтерфесу на етапі розробки специфікацій системи не є панацеєю. Такий підхід не дозволяє поліпшити якість розробки в принципі, наприклад, він зовсім не зменшує кількість помилок програмування. Більш того, він не завжди застосуємо. Інтерфейс складної системи неможливо з самого початку спроектувати повністю: доведеться спочатку робити працюючу бета-версію і остаточно ред інтерфейс вже на її основі. Крім того, у багатьох проектах з-за не залежать ні від кого причин не виходить розтягувати процес створення ТЗ (замовник хоче побачити які-небудь результати вже завтра). Однак, враховуючи низькі «вхідні» вимоги до застосування запропонованого методу (незрівнянні, наприклад, з тяганиною і бюрократією, зумовленої використанням UML), проектування інтерфейсів на стадії підготовки специфікацій майже завжди є вкрай успішним методом вирішення проблем впровадження.</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F_%D1%96%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D1%83_%D1%8F%D0%BA_%D1%87%D0%B0%D1%81%D1%82%D0%B8%D0%BD%D0%B0_%D1%80%D0%BE%D0%B7%D1%80%D0%BE%D0%B1%D0%BA%D0%B8_%D0%A2%D0%97 2011-12-13T13:21:47Z

<p>I Shevchenko: </p> <hr /> <div>Впровадження систем автоматизації бізнесу, як знає будь-який в цій області фахівець, аж ніяк не є легкою справою. Якщо саме створення системи технічно є не дуже складним (наприклад, не можна сказати, що середньостатистична система наповнена складними алгоритмами), то впровадження такої системи вимагає від автоматизатора рідкісного завзяття та спритності. При цьому корінь багатьох проблем знаходиться у технічному завданні. Як кажуть, «що задумали, те й зробили», але потім виявляється, що задумали-то і неправильно. Для вирішення проблем, що виникають при створенні ТЗ, а виявлених при впровадженні, придумано безліч технологій і методів проте сама їх кількість свідчить про те, що жоден метод до повного успіху не приводить. Крім того, багато методів мають принциповий недолік - вони збільшують об'єм роботи наодному етапі, хай і заради економії на іншому, а також вимагають серйозних інвестицій у навчанні працівників (характерний приклад - RUP). Існує, однак, підхід, який не вимагає особливої ​​кваліфікації співробітників, значно полегшує впровадження, не збільшуючи обсяг робіт по розробки ТЗ.<br /> <br /> Сутність підходу може бути описана однією фразою - проектування інтерфейсу не є частина процесу розробки, а частина процесу створення специфікацій на систему.<br /> <br /> Тут необхідно зробити два важливих уточнення. По-перше, інтерфейс все одно буде розроблений (практика показує, що замовники чомусь неохоче оплачують функціональність без інтерфейсу). По-друге, від проектування інтерфейсу нічого особливого не потрібно - на нього можуть бути виділені ті ж ресурси, що і у випадку звичайної розробки, так само як і вийти він може таким же. Авторам, які заробляють собі на життя розробкою ергономічних інтерфейсів, неприємно це говорити, але інтерфейс може бути навіть не ергономічним, все одно впровадження буде полегшено; зрозуміло, у випадку ергономічного інтерфейсу впровадження буде ще більш простим, але такий інтерфейс дорожче і довше робиться.<br /> <br /> Пропонований підхід дозволяє вирішити наступні проблеми:<br /> <br /> Усунути розбіжності в поглядах на постановку задачі замовника і виконавця. Специфікації на скільки-небудь складні системи занадто абстрактні. Їх насилу утримують в голові навіть автори, а до кінця не розуміє ніхто, особливо ключова особа - замовник. Для нього ця специфікація нічим не відрізняється від сакральних письмен (багато хто навіть припускають, що незрозумілі ТЗ призначені для того, щоб справити на них враження і здерти побільше грошей). Немає різниці, що підсунуть йому розробники, реальне ТЗ або інструкцію до газонокосарці на фарсі - всі однаково незрозуміло. Наївно припускати, що замовник, легко підписав таке ТЗ, також легко прийме розроблену систему. Прототипи інтерфейсу є тим єдиним документом, який замовник може зрозуміти і оцінити. А зрозумівши і оцінивши - свідомо підписати.<br /> <br /> Полегшити процес впровадження системи. Вагома частина проблем впровадження в якісно виконаному проекті припадає на інтерфейс, створений формально правильно, але неадекватно уявленням замовника. Не існує виду ТЗ, крім власне прототипу інтерфейсу, який би міг інтегрувати такого роду вимоги. Наочний приклад: у будь-якому ТЗ можна прописати, що «в системі є адресна книга, яка складається з таких-то даних і таких-то функцій». Але неможливо формалізувати вже в ТЗ, як ця адресна книга повинна реально працювати (якісь функції потрібно «витягнути» наверх, якісь можна «засунути»), як, врешті-решт, ця адресна книга повинна виглядати. При цьому апеляції виконавця до підписаного технічним завданням - мовляв, ось же перераховані функції ... ось вони всі в наявності - як правило, не спрацьовують, оскільки при відомій спритності у контексті користувальницького інтерфейсу проінтерпретувати ТЗ завжди можна дуже по-різному. Тільки заздалегідь спроектований інтерфейс дозволяє застрахуватися від такого роду претензій.<br /> <br /> Скоротити число доробок системи, викликаних невідповідністю її функціональності очікуванням клієнта. Тільки побачивши саму систему, замовник може реально зрозуміти її можливості, так само як і оцінити власні потреби. Для замовника програмний продукт і його інтерфейс цілком тотожні. Отже, показавши замовнику інтерфейс на стадії підготовки ТЗ, можна знизити кількість і обсяг переробок, потреба в яких виникає через розбіжності очікувань замовника із запланованою в ТЗ функціональністю системи. (Потрібно, втім, відзначити, що такі переробки частіше за все не проблематичні для розробників, які зазвичай наполягають на додатковій оплаті цих послуг.)<br /> <br /> Зняти ризик необхідності доопрацювання функціональності системи, з-за незадоволеності замовника запропонованим інтерфейсом. При розробці інтерфейсу немає рішуче ніякої гарантії того, що він буде прийнятий замовником. Опис функцій системи бінарно, функція може бути, може не бути. Доказ її наявності рідко вимагає аргументації. Інтерфейс ж може бути або досить хорошим, або недостатньо хорошим. Коли в справу вступають відносні терміни, все ускладнюється, що може приводити в виникненню конфліктних ситуацій. Годі й говорити, що при переробці недостатньо хорошого інтерфейсу функціональність системи, яка вже є, змінюється теж, причому без оплати праці розробника.<br /> <br /> Таким чином, є об'єктивна користь в тому, щоб розглядати проектування інтерфейсу не як стадію розробки, а як стадію створення ТЗ. Але як це зробити? На перший погляд, завдання здається важкою, частково з організаційної, частково з технічної сторін.<br /> <br /> Спочатку про організаційну стороні. На перший погляд замовника важко переконати відмовитися від думки, що робити що-то «реальне» треба відразу після підписання договору. Однак практика показує, що проміжні наочні результати роботи над системою, а саме прототипи інтерфейсу, продемонстровані вже на другий день роботи, а не через кілька тижнів, призводять клієнта в себе захищеними. На відміну від звичайного ТЗ, робота над яким замовнику реально не видно («ну що там, пара пунктів додалася») прототипи інтерфейсу легко зрозумілі і прогрес у роботі явно помітний. Друга організаційна проблема пов'язана з необхідністю підписувати два договори: на створення ТЗ (читай - інтерфейсу) і на розробку функціональності системи. Причому підписання другого договору відкладається на певний строк, необхідний для розробки інтерфейсу, що розтягує проект у часі. У принципі, ця проблема нерозв'язна, але, з іншого боку, тут багато що залежить від її сприйняття: так, договору два, але зате другий договір виходить значно більш точним (вже маючи інтерфейс, легше оцінити трудовитрати).<br /> <br /> Технічна проблема пов'язана з труднощами прототипування. У звичайному режимі роботи інтерфейс створюється вже в засобі розробки, створювати ж прототип таким чином нерентабельно. Інтерфейс створюється через безліч ітерацій, а переробляти вже зроблене вже дорого. Порівняно недавно з'явилися спеціальні засоби для прототипування інтерфейсу (наприклад, Norpath Studio), але поки вони досить сирі. Вихід - використання неспеціалізованих графічних редакторів. Ще кілька років тому основним таким редактором був MS PowerPoint, зараз же найбільш зручним слід визнати MS Visio. Складні екранні форми, втім, до цих пір зручніше просто малювати на папері.<br /> <br /> І, нарешті, головна проблема. Подовження процесу розробки ТЗ часто сприймається самими розробниками як безумовне зло - звичка спочатку робити, а вже потім думати, традиційно сильна в російському IT-бізнесі. На жаль, змінити цей звичай може тільки «досвід, син помилок важких». Поки, в усякому разі ...<br /> <br /> Звичайно, проектування інтерфесу на етапі розробки специфікацій системи не є панацеєю. Такий підхід не дозволяє поліпшити якість розробки в принципі, наприклад, він зовсім не зменшує кількість помилок програмування. Більш того, він не завжди застосуємо. Інтерфейс складної системи неможливо з самого початку спроектувати повністю: доведеться спочатку робити працюючу бета-версію і остаточно ред інтерфейс вже на її основі. Крім того, у багатьох проектах з-за не залежать ні від кого причин не виходить розтягувати процес створення ТЗ (замовник хоче побачити які-небудь результати вже завтра). Однак, враховуючи низькі «вхідні» вимоги до застосування запропонованого методу (незрівнянні, наприклад, з тяганиною і бюрократією, зумовленої використанням UML), проектування інтерфейсів на стадії підготовки специфікацій майже завжди є вкрай успішним методом вирішення проблем впровадження.</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F_%D1%96%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D1%83_%D1%8F%D0%BA_%D1%87%D0%B0%D1%81%D1%82%D0%B8%D0%BD%D0%B0_%D1%80%D0%BE%D0%B7%D1%80%D0%BE%D0%B1%D0%BA%D0%B8_%D0%A2%D0%97 2011-12-13T13:11:45Z

<p>I Shevchenko: Створена сторінка: Впровадження систем автоматизації бізнесу, як знає будь-який залучений в цю область фахі...</p> <hr /> <div>Впровадження систем автоматизації бізнесу, як знає будь-який залучений в цю область фахівець, аж ніяк не є легкою справою. Якщо саме створення системи, взагалі кажучи, технічно не дуже складно (наприклад, не можна сказати, що середньостатистична система наповнена складними алгоритмами), то впровадження вимагає від автоматизатора незвичайною кваліфікації, рідкісного завзяття та спритності. При цьому коріння багатьох проблем знаходяться у технічному завданні. Як кажуть, «що задумали, то й зробили», але потім іноді виявляється, що задумали щось і неправильно. Для вирішення проблем, що виникають при створенні ТЗ, а виявляються при впровадженні, придумано безліч технологій і методів проте сама їх кількість свідчить про те, що жоден метод до повного успіху не приводить. Крім того, багато методи мають принциповий недолік - вони збільшують об'єм частини роботи, хай і заради економії на іншому етапі, і вимагають серйозних інвестицій у навчання працівників (характерний приклад - RUP). Існує, однак, підхід, який не вимагає особливої ​​кваліфікації співробітників, значно полегшує впровадження, не збільшуючи обсяг робіт з розробки ТЗ.<br /> <br /> Сутність підходу може бути описана однією фразою - проектування інтерфейсу не є частина процесу розробки, а частина процесу створення специфікацій на систему.<br /> <br /> Тут необхідно зробити два важливих уточнення. По-перше, інтерфейс все одно буде розроблений (практика показує, що замовники чомусь неохоче оплачують функціональність без інтерфейсу). По-друге, від проектування інтерфейсу нічого особливого не потрібно - на нього можуть бути виділені ті ж ресурси, що і у випадку звичайної розробки, так само як і вийти він може таким же. Авторам, які заробляють собі на життя розробкою ергономічних інтерфейсів, неприємно це говорити, але інтерфейс може бути навіть не ергономічним, все одно впровадження буде полегшено; зрозуміло, у випадку ергономічного інтерфейсу впровадження буде ще більш простим, але такий інтерфейс дорожче і довше робиться.<br /> <br /> Пропонований підхід дозволяє вирішити наступні проблеми:<br /> <br /> Усунути розбіжності в поглядах на постановку задачі замовника і виконавця. Специфікації на скільки-небудь складні системи занадто абстрактні. Їх насилу утримують в голові навіть автори, а до кінця не розуміє ніхто, особливо ключова особа - замовник. Для нього ця специфікація нічим не відрізняється від сакральних письмен (багато хто навіть припускають, що незрозумілі ТЗ призначені для того, щоб справити на них враження і здерти побільше грошей). Немає різниці, що підсунуть йому розробники, реальне ТЗ або інструкцію до газонокосарці на фарсі - всі однаково незрозуміло. Наївно припускати, що замовник, легко підписав таке ТЗ, також легко прийме розроблену систему. Прототипи інтерфейсу є тим єдиним документом, який замовник може зрозуміти і оцінити. А зрозумівши і оцінивши - свідомо підписати.<br /> <br /> Полегшити процес впровадження системи. Вагома частина проблем впровадження в якісно виконаному проекті припадає на інтерфейс, створений формально правильно, але неадекватно уявленням замовника. Не існує виду ТЗ, крім власне прототипу інтерфейсу, який би міг інтегрувати такого роду вимоги. Наочний приклад: у будь-якому ТЗ можна прописати, що «в системі є адресна книга, яка складається з таких-то даних і таких-то функцій». Але неможливо формалізувати вже в ТЗ, як ця адресна книга повинна реально працювати (якісь функції потрібно «витягнути» наверх, якісь можна «засунути»), як, врешті-решт, ця адресна книга повинна виглядати. При цьому апеляції виконавця до підписаного технічним завданням - мовляв, ось же перераховані функції ... ось вони всі в наявності - як правило, не спрацьовують, оскільки при відомій спритності у контексті користувальницького інтерфейсу проінтерпретувати ТЗ завжди можна дуже по-різному. Тільки заздалегідь спроектований інтерфейс дозволяє застрахуватися від такого роду претензій.<br /> <br /> Скоротити число доробок системи, викликаних невідповідністю її функціональності очікуванням клієнта. Тільки побачивши саму систему, замовник може реально зрозуміти її можливості, так само як і оцінити власні потреби. Для замовника програмний продукт і його інтерфейс цілком тотожні. Отже, показавши замовнику інтерфейс на стадії підготовки ТЗ, можна знизити кількість і обсяг переробок, потреба в яких виникає через розбіжності очікувань замовника із запланованою в ТЗ функціональністю системи. (Потрібно, втім, відзначити, що такі переробки частіше за все не проблематичні для розробників, які зазвичай наполягають на додатковій оплаті цих послуг.)<br /> <br /> Зняти ризик необхідності доопрацювання функціональності системи, з-за незадоволеності замовника запропонованим інтерфейсом. При розробці інтерфейсу немає рішуче ніякої гарантії того, що він буде прийнятий замовником. Опис функцій системи бінарно, функція може бути, може не бути. Доказ її наявності рідко вимагає аргументації. Інтерфейс ж може бути або досить хорошим, або недостатньо хорошим. Коли в справу вступають відносні терміни, все ускладнюється, що може приводити в виникненню конфліктних ситуацій. Годі й говорити, що при переробці недостатньо хорошого інтерфейсу функціональність системи, яка вже є, змінюється теж, причому без оплати праці розробника.<br /> <br /> Таким чином, є об'єктивна користь в тому, щоб розглядати проектування інтерфейсу не як стадію розробки, а як стадію створення ТЗ. Але як це зробити? На перший погляд, завдання здається важкою, частково з організаційної, частково з технічної сторін.<br /> <br /> Спочатку про організаційну стороні. На перший погляд замовника важко переконати відмовитися від думки, що робити що-то «реальне» треба відразу після підписання договору. Однак практика показує, що проміжні наочні результати роботи над системою, а саме прототипи інтерфейсу, продемонстровані вже на другий день роботи, а не через кілька тижнів, призводять клієнта в себе захищеними. На відміну від звичайного ТЗ, робота над яким замовнику реально не видно («ну що там, пара пунктів додалася») прототипи інтерфейсу легко зрозумілі і прогрес у роботі явно помітний. Друга організаційна проблема пов'язана з необхідністю підписувати два договори: на створення ТЗ (читай - інтерфейсу) і на розробку функціональності системи. Причому підписання другого договору відкладається на певний строк, необхідний для розробки інтерфейсу, що розтягує проект у часі. У принципі, ця проблема нерозв'язна, але, з іншого боку, тут багато що залежить від її сприйняття: так, договору два, але зате другий договір виходить значно більш точним (вже маючи інтерфейс, легше оцінити трудовитрати).<br /> <br /> Технічна проблема пов'язана з труднощами прототипування. У звичайному режимі роботи інтерфейс створюється вже в засобі розробки, створювати ж прототип таким чином нерентабельно. Інтерфейс створюється через безліч ітерацій, а переробляти вже зроблене вже дорого. Порівняно недавно з'явилися спеціальні засоби для прототипування інтерфейсу (наприклад, Norpath Studio), але поки вони досить сирі. Вихід - використання неспеціалізованих графічних редакторів. Ще кілька років тому основним таким редактором був MS PowerPoint, зараз же найбільш зручним слід визнати MS Visio. Складні екранні форми, втім, до цих пір зручніше просто малювати на папері.<br /> <br /> І, нарешті, головна проблема. Подовження процесу розробки ТЗ часто сприймається самими розробниками як безумовне зло - звичка спочатку робити, а вже потім думати, традиційно сильна в російському IT-бізнесі. На жаль, змінити цей звичай може тільки «досвід, син помилок важких». Поки, в усякому разі ...<br /> <br /> Звичайно, проектування інтерфесу на етапі розробки специфікацій системи не є панацеєю. Такий підхід не дозволяє поліпшити якість розробки в принципі, наприклад, він зовсім не зменшує кількість помилок програмування. Більш того, він не завжди застосуємо. Інтерфейс складної системи неможливо з самого початку спроектувати повністю: доведеться спочатку робити працюючу бета-версію і остаточно ред інтерфейс вже на її основі. Крім того, у багатьох проектах з-за не залежать ні від кого причин не виходить розтягувати процес створення ТЗ (замовник хоче побачити які-небудь результати вже завтра). Однак, враховуючи низькі «вхідні» вимоги до застосування запропонованого методу (незрівнянні, наприклад, з тяганиною і бюрократією, зумовленої використанням UML), проектування інтерфейсів на стадії підготовки специфікацій майже завжди є вкрай успішним методом вирішення проблем впровадження.</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%A1%D1%82%D1%83%D0%B4%D0%B5%D0%BD%D1%82%D1%81%D1%8C%D0%BA%D1%96_%D1%80%D0%BE%D0%B1%D0%BE%D1%82%D0%B8_%D0%B7_%D0%BC%D1%83%D0%BB%D1%8C%D1%82%D0%B8%D0%BC%D0%B5%D0%B4%D1%96%D0%B9%D0%BD%D0%B8%D1%85_%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D1%96%D0%B9 2010-12-22T12:39:23Z

<p>I Shevchenko: /* Шевченко Ігор */</p> <hr /> <div>Розміщуємо посилання на ваші сторінки й зовнішні ресурси<br /> <br /> == [[User:vad_zel|Зеленський Вадим Сергійович]]==<br /> <br /> [[Лабораторна робота №1-2 | Лабораторна робота №1]]<br /> <br /> [[Лабораторна робота №1-2 | Лабораторна робота №2]]<br /> <br /> [[Лабораторна робота №3 Зеленський | Лабораторна робота №3]]<br /> <br /> [[Лабораторна робота №4 Зеленський | Лабораторна робота №4]]<br /> <br /> [[лаба 5 | Лабораторна робота №5]]<br /> <br /> [[лаба 6 | Лабораторна робота №6]]<br /> <br /> [[Laba_7-8 | Лабораторна робота №7]]<br /> <br /> ==[[User:NICOLE| Паршенков Віталій Сергійович, 36 група ]]== <br /> <br /> [[Лаб_роб №1 | Лабораторна робота №1]]<br /> <br /> [[Лаб_роб №2 | Лабораторна робота №2]]<br /> <br /> [[Лаб_роб №3 | Лабораторна робота №3]]<br /> <br /> [[Лаб_роб №4 | Лабораторна робота №4]]<br /> <br /> [[Лаб_роб №5 | Лабораторна робота №5]]<br /> <br /> [[Лаб_роб №6 | Лабораторна робота №6]]<br /> <br /> [[Лаб_роб №7 | Лабораторна робота №7]]<br /> <br /> == Волошин Віталій Миколайович ==<br /> <br /> [[Лаб_Роб_№1-2 | Лабораторна робота № 1-2]]<br /> <br /> [[Лаб_Роб_№3 | Лабораторна робота №3]]<br /> <br /> [[Лаб_Роб_№4 | Лабораторна робота №4]]<br /> <br /> [[Лаб_Роб_№5 | Лабораторна робота №5]]<br /> <br /> [[Лаб_Роб_№6 | Лабораторна робота №6]]<br /> <br /> [[Лаб_Роб_№7 | Лабораторна робота №7]]<br /> <br /> == Бакуменко Володимир Олксандрович ==<br /> <br /> [[лаораторна робота №3 | Лабораторна робота №3]]<br /> <br /> [[лаораторна робота №4 | Лабораторна робота №4]]<br /> <br /> [[лаораторна робота №5 | Лабораторна робота №5]]<br /> <br /> [[лаораторна робота №6 | Лабораторна робота №6]]<br /> <br /> [[лаораторна робота №7 | Лабораторна робота №7]]<br /> <br /> == [[User:Бєлінський_Андрій|Бєлінський Андрій]] ==<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;[[Лабораторна робота 1: Мультимедійні технології (Beliand) | Лабораторна робота 1]]<br /> &lt;li&gt;[[Лабораторна робота 1: Мультимедійні технології (Beliand) | Лабораторна робота 2]]<br /> &lt;li&gt;[[Лабораторна робота 3: Мультимедійні технології (Beliand) | Лабораторна робота 3]]<br /> &lt;li&gt;[[Лабораторна робота 4: Мультимедійні технології (Beliand) | Лабораторна робота 4]]<br /> &lt;li&gt;[[Лабораторна робота 5: Мультимедійні технології (Beliand) | Лабораторна робота 5]]<br /> &lt;li&gt;[[Лабораторна робота 6: Мультимедійні технології (Beliand) | Лабораторна робота 6]]<br /> &lt;li&gt;[[Лабораторна робота 7: Мультимедійні технології (Beliand) | Лабораторна робота 7-8]]<br /> &lt;/ul&gt;<br /> <br /> ==[[User:demo1420 | Пшиник Ігор Олександрович ]]==<br /> <br /> [[лаб_роб_3|Лабораторна робота №3]]<br /> <br /> [http://www.slideshare.net/demo1420/wi-fi-windows-6270036#| Лабораторна робота №6 Пшиника Ігор]<br /> <br /> [[Лабораторна робота №7 Пшиника Ігора# | Лабораторна робота №7]]<br /> <br /> ==[[Користувач:I_Shevchenko| Шевченко Ігор]]==<br /> [[Lab_1,2| Лабораторна робота№1,2]]<br /> <br /> [[Lab_3| Лабораторна робота№3]]<br /> <br /> [[Lab_4| Лабораторна робота№4]]<br /> <br /> [[Lab_5| Лабораторна робота№5]]<br /> <br /> [[Lab_6| Лабораторна робота№6]]<br /> <br /> [[Lab_7| Лабораторна робота№7,8]]<br /> <br /> == [[User:Viper|Григоржевський Василь Аркадійович]], 36 група ==<br /> <br /> <br /> [[Лаб1,2| Лабораторна № 1]]<br /> <br /> [[Лаб1,2| Лабораторна № 2]]<br /> <br /> [[Лаб3| Лабораторна № 3]]<br /> <br /> [[Лаб4| Лабораторна № 4]]<br /> <br /> [[Лаб5| Лабораторна № 5]]<br /> <br /> [[лаб6| Лабораторна № 6]]<br /> <br /> [[lab_7_8| Лабораторна № 7]]<br /> <br /> [[lab_7_8| Лабораторна № 8]]<br /> <br /> == [[Користувач:BuMeRok91 |Антонов Олексій Сергійович]], 36 група ==<br /> <br /> [[Лабораторна робота №1 (з предмету мультимедіа)| Лабораторна № 1]]<br /> <br /> [[Лабораторна робота №2 (з предмету мультимедіа)| Лабораторна № 2]]<br /> <br /> [[Лабораторна робота №3 (З предмету мультимедіа)| Лабораторна № 3]]<br /> <br /> [[Лабораторна робота №4 (З предмету мультимедіа)| Лабораторна № 4]]<br /> <br /> [[Лабораторна робота №5 (З предмету мультимедіа)| Лабораторна № 5]]<br /> <br /> [[Лабораторна робота №6 (З предмету мультимедіа)| Лабораторна № 6]]<br /> <br /> [[Лабораторна робота №7 (З предмету мультимедіа)| Лабораторна № 7]]<br /> <br /> == [[Користувач:Nopasha |Суховещенко Павло Костянтинович]], 36 група ==<br /> <br /> [[ 1 | Лабораторна робота № 1]]<br /> <br /> [[ 1 | Лабораторна робота № 2]]<br /> <br /> [[ Labs_-3 | Лабораторна робота № 3]]<br /> <br /> [[ Labs_-4 | Лабораторна робота № 4]]<br /> <br /> [[ Labs_-5 | Лабораторна робота № 5]]<br /> <br /> [[ Labs_-6 | Лабораторна робота № 6]]<br /> <br /> [[ Labs_-7 | Лабораторна робота № 7]]<br /> <br /> [[ Labs_-7 | Лабораторна робота № 8]]<br /> <br /> ==[[User:Нагорний| Нагорний Сергій Сергійович, 36 група ]]== <br /> <br /> [[Лабораторна робота №1 Нагорного | Лабораторна робота №1]]<br /> <br /> [[Лабораторна робота №2 Нагорного | Лабораторна робота №2]]<br /> <br /> [[Лабораторна робота №3 Нагорного | Лабораторна робота №3]]<br /> <br /> [[Лабораторна робота №4 Нагорного | Лабораторна робота №4]]<br /> <br /> [[Лабораторна робота №5 Нагорного | Лабораторна робота №5]]<br /> <br /> [[Лабораторна робота №6 Нагорного | Лабораторна робота №6]]<br /> <br /> [[Лабораторна робота №7 Нагорного | Лабораторна робота №7]]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_5 2010-12-22T12:38:28Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із відео. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів відео файлів<br /> <br /> === Теоретичні питання: ===<br /> <br /> # [[Відео | Відео, як складова мультимедіа]]<br /> # [[Формати_відео_файлів | Формати відео файлів]]<br /> # Конвертація відео файлів в різні формати.<br /> # Представлення відео в проекті.<br /> # Особливості оцінювання відео файлів.<br /> <br /> === Практичні завдання ===<br /> Для організації перегляду власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]<br /> <br /> [[Файл:Win_V.JPG|thumb|350px|center|Моя відео бібліотека ]]<br /> Щоб створити бібліотеку достатьно зайти на вкладку Параметри програвача Winamp і вказати в розділі бібліотека ті каталоги за якими Winamp<br /> буде наблюдать і автоматично знаходити Video файли та заносити їх автоматично до бібліотеки<br /> [[Файл:Win b.JPG|thumb|350px|center|]]<br /> Для конвертації відеофайлу скористаємося програмою [http://www.any-video-converter.com/products/for_video_free/ Any video Converter ]. Для цього перетягуємо відеофайл у цетральну область програми. Етапи конвертування:<br /> &lt;ol&gt;<br /> &lt;li&gt;Вибираємо початкову та кінцеву позицію<br /> &lt;li&gt;Вибираємо кодек<br /> &lt;li&gt;Вибираємо розширення відео<br /> &lt;li&gt;Вибираємо бітрейт відео та частоту кадрів<br /> &lt;li&gt;Вибираємо налаштування аудіокодека<br /> &lt;/ol&gt;<br /> &lt;li&gt;Таблиця порівняння одержаних файлів<br /> &lt;table border=1 width=95%&gt;&lt;tr&gt;&lt;td width=22% align=center&gt;'''Назва'''&lt;/td&gt;&lt;td width=20% align=center&gt;'''Хар-ка відео'''&lt;/td&gt;&lt;td width=20% align=center&gt;'''Хар-ка аудіо'''&lt;/td&gt;&lt;td width=15% align=center&gt;'''Якість зображення'''&lt;/td&gt;&lt;td width=15% align=center&gt;'''Якість звуку'''&lt;/td&gt;&lt;td&gt;'''Розмір'''&lt;/td&gt;&lt;/tr&gt;<br /> <br /> &lt;tr&gt;<br /> &lt;td align=center&gt;[http://upload.com.ua/get/902211561/SDuu.avi/ SDU.avi]&lt;br&gt;(некомпр. файл)&lt;/td&gt;<br /> &lt;td align=center&gt;640x480, 25.00 fps, XviD MPEG-4 ~422 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;44.1 kHz, Dolby AC3, 2 ch, ~128.00 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;Відмінна&lt;/td&gt;&lt;td align=center&gt;Відмінна&lt;/td&gt;<br /> &lt;td align=center&gt;14.7MB&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td align=center&gt;[http://upload.com.ua/get/902211486/SDu_wmv2.mkv SDU.mkv]&lt;br&gt;(компр. файл)&lt;/td&gt;<br /> &lt;td align=center&gt;320x240, 20.00 fps, WMV ~192 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;44.1 kHz, MPEG Audio Layer 3, 2 ch, ~56 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;Задовільна&lt;/td&gt;&lt;td align=center&gt;Задовільна&lt;/td&gt;<br /> &lt;td align=center&gt;4.53MB&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> &lt;li&gt;Так як цей ресурс не підтримує завантаження даного формату файлів - файли було завантажено на сторонній ресурс<br /> &lt;/ol&gt;<br /> <br /> === Висновок ===<br /> <br /> Виконуючи дану лабораторну роботу я більш детально засвоїв єтапи створення відео бібліотеки. Використовуючи стандартній програвач Windows Media Player я зробив висновки, що ця программа досить не зручна, але всеж має всої переваги.<br /> Використовуючи программу для конвертації відео файлів, а саме Virtual Dub я зрозумів, що хоть вона і має невеликий розмір, але дуже потужна для роботи з відео. Вона використовує встановлені в систему кодеки і не потребує встановлення допоміжних. Программа дозволяє швидко конвертувати файли з мінімальними втратами якості, але великою зміною розміру, тому її застосовують більшість риперів.</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_5 2010-12-22T12:37:38Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із відео. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів відео файлів<br /> <br /> === Теоретичні питання: ===<br /> <br /> # [[Відео | Відео, як складова мультимедіа]]<br /> # [[Формати_відео_файлів | Формати відео файлів]]<br /> # Конвертація відео файлів в різні формати.<br /> # Представлення відео в проекті.<br /> # Особливості оцінювання відео файлів.<br /> <br /> === Практичні завдання ===<br /> Для організації перегляду власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]<br /> <br /> [[Файл:Win_V.JPG|thumb|350px|center|Моя відео бібліотека ]]<br /> Щоб створити бібліотеку достатьно зайти на вкладку Параметри програвача Winamp і вказати в розділі бібліотека ті каталоги за якими Winamp<br /> буде наблюдать і автоматично знаходити Video файли та заносити їх автоматично до бібліотеки<br /> [[Файл:Win b.JPG|thumb|350px|center|]]<br /> Для конвертації відеофайлу скористаємося програмою [http://www.any-video-converter.com/products/for_video_free/ Any video Converter ]. Для цього перетягуємо відеофайл у цетральну область програми. Етапи конвертування:<br /> &lt;ol&gt;<br /> &lt;li&gt;Вибираємо початкову та кінцеву позицію<br /> &lt;li&gt;Вибираємо кодек<br /> &lt;li&gt;Вибираємо розширення відео<br /> &lt;li&gt;Вибираємо бітрейт відео та частоту кадрів<br /> &lt;li&gt;Вибираємо налаштування аудіокодека<br /> &lt;/ol&gt;<br /> &lt;li&gt;Таблиця порівняння одержаних файлів<br /> &lt;table border=1 width=95%&gt;&lt;tr&gt;&lt;td width=22% align=center&gt;'''Назва'''&lt;/td&gt;&lt;td width=20% align=center&gt;'''Хар-ка відео'''&lt;/td&gt;&lt;td width=20% align=center&gt;'''Хар-ка аудіо'''&lt;/td&gt;&lt;td width=15% align=center&gt;'''Якість зображення'''&lt;/td&gt;&lt;td width=15% align=center&gt;'''Якість звуку'''&lt;/td&gt;&lt;td&gt;'''Розмір'''&lt;/td&gt;&lt;/tr&gt;<br /> <br /> &lt;tr&gt;<br /> &lt;td align=center&gt;[http://upload.com.ua/get/902211561/SDuu.avi/ | SDU.avi]&lt;br&gt;(некомпр. файл)&lt;/td&gt;<br /> &lt;td align=center&gt;640x480, 25.00 fps, XviD MPEG-4 ~422 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;44.1 kHz, Dolby AC3, 2 ch, ~128.00 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;Відмінна&lt;/td&gt;&lt;td align=center&gt;Відмінна&lt;/td&gt;<br /> &lt;td align=center&gt;14.7MB&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td align=center&gt;[http://upload.com.ua/get/902211486/SDu_wmv2.mkv |SDU.mkv]&lt;br&gt;(компр. файл)&lt;/td&gt;<br /> &lt;td align=center&gt;320x240, 20.00 fps, WMV ~192 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;44.1 kHz, MPEG Audio Layer 3, 2 ch, ~56 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;Задовільна&lt;/td&gt;&lt;td align=center&gt;Задовільна&lt;/td&gt;<br /> &lt;td align=center&gt;4.53MB&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> &lt;li&gt;Так як цей ресурс не підтримує завантаження даного формату файлів - файли було завантажено на сторонній ресурс<br /> &lt;/ol&gt;<br /> <br /> === Висновок ===<br /> <br /> Виконуючи дану лабораторну роботу я більш детально засвоїв єтапи створення відео бібліотеки. Використовуючи стандартній програвач Windows Media Player я зробив висновки, що ця программа досить не зручна, але всеж має всої переваги.<br /> Використовуючи программу для конвертації відео файлів, а саме Virtual Dub я зрозумів, що хоть вона і має невеликий розмір, але дуже потужна для роботи з відео. Вона використовує встановлені в систему кодеки і не потребує встановлення допоміжних. Программа дозволяє швидко конвертувати файли з мінімальними втратами якості, але великою зміною розміру, тому її застосовують більшість риперів.</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_5 2010-12-22T12:33:14Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із відео. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів відео файлів<br /> <br /> === Теоретичні питання: ===<br /> <br /> # [[Відео | Відео, як складова мультимедіа]]<br /> # [[Формати_відео_файлів | Формати відео файлів]]<br /> # Конвертація відео файлів в різні формати.<br /> # Представлення відео в проекті.<br /> # Особливості оцінювання відео файлів.<br /> <br /> === Практичні завдання ===<br /> Для організації перегляду власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]<br /> <br /> [[Файл:Win_V.JPG|thumb|350px|center|Моя відео бібліотека ]]<br /> Щоб створити бібліотеку достатьно зайти на вкладку Параметри програвача Winamp і вказати в розділі бібліотека ті каталоги за якими Winamp<br /> буде наблюдать і автоматично знаходити Video файли та заносити їх автоматично до бібліотеки<br /> [[Файл:Win b.JPG|thumb|350px|center|]]<br /> Для конвертації відеофайлу скористаємося програмою [http://www.any-video-converter.com/products/for_video_free/ Any video Converter ]. Для цього перетягуємо відеофайл у цетральну область програми. Етапи конвертування:<br /> &lt;ol&gt;<br /> &lt;li&gt;Вибираємо початкову та кінцеву позицію<br /> &lt;li&gt;Вибираємо кодек<br /> &lt;li&gt;Вибираємо розширення відео<br /> &lt;li&gt;Вибираємо бітрейт відео та частоту кадрів<br /> &lt;li&gt;Вибираємо налаштування аудіокодека<br /> &lt;/ol&gt;<br /> &lt;li&gt;Таблиця порівняння одержаних файлів<br /> &lt;table border=1 width=95%&gt;&lt;tr&gt;&lt;td width=22% align=center&gt;'''Назва'''&lt;/td&gt;&lt;td width=20% align=center&gt;'''Хар-ка відео'''&lt;/td&gt;&lt;td width=20% align=center&gt;'''Хар-ка аудіо'''&lt;/td&gt;&lt;td width=15% align=center&gt;'''Якість зображення'''&lt;/td&gt;&lt;td width=15% align=center&gt;'''Якість звуку'''&lt;/td&gt;&lt;td&gt;'''Розмір'''&lt;/td&gt;&lt;/tr&gt;<br /> <br /> &lt;tr&gt;<br /> &lt;td align=center&gt;[http://upload.com.ua/get/902211547/SDu.avi]&lt;br&gt;(некомпр. файл)&lt;/td&gt;<br /> &lt;td align=center&gt;640x480, 25.00 fps, XviD MPEG-4 ~422 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;44.1 kHz, Dolby AC3, 2 ch, ~128.00 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;Відмінна&lt;/td&gt;&lt;td align=center&gt;Відмінна&lt;/td&gt;<br /> &lt;td align=center&gt;14.7MB&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td align=center&gt;[http://upload.com.ua/get/902211486/SDu_wmv2.mkv]&lt;br&gt;(компр. файл)&lt;/td&gt;<br /> &lt;td align=center&gt;320x240, 20.00 fps, WMV ~192 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;44.1 kHz, MPEG Audio Layer 3, 2 ch, ~56 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;Задовільна&lt;/td&gt;&lt;td align=center&gt;Задовільна&lt;/td&gt;<br /> &lt;td align=center&gt;4.53MB&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> &lt;li&gt;Так як цей ресурс не підтримує завантаження даного формату файлів - файли було завантажено на сторонній ресурс<br /> &lt;/ol&gt;<br /> <br /> === Висновок ===<br /> <br /> Виконуючи дану лабораторну роботу я більш детально засвоїв єтапи створення відео бібліотеки. Використовуючи стандартній програвач Windows Media Player я зробив висновки, що ця программа досить не зручна, але всеж має всої переваги.<br /> Використовуючи программу для конвертації відео файлів, а саме Virtual Dub я зрозумів, що хоть вона і має невеликий розмір, але дуже потужна для роботи з відео. Вона використовує встановлені в систему кодеки і не потребує встановлення допоміжних. Программа дозволяє швидко конвертувати файли з мінімальними втратами якості, але великою зміною розміру, тому її застосовують більшість риперів.</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_5 2010-12-22T12:31:45Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із відео. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів відео файлів<br /> <br /> === Теоретичні питання: ===<br /> <br /> # [[Відео | Відео, як складова мультимедіа]]<br /> # [[Формати_відео_файлів | Формати відео файлів]]<br /> # Конвертація відео файлів в різні формати.<br /> # Представлення відео в проекті.<br /> # Особливості оцінювання відео файлів.<br /> <br /> === Практичні завдання ===<br /> Для організації перегляду власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]<br /> <br /> [[Файл:Win_V.JPG|thumb|350px|center|Моя відео бібліотека ]]<br /> Щоб створити бібліотеку достатьно зайти на вкладку Параметри програвача Winamp і вказати в розділі бібліотека ті каталоги за якими Winamp<br /> буде наблюдать і автоматично знаходити Video файли та заносити їх автоматично до бібліотеки<br /> [[Файл:Win b.JPG|thumb|350px|center|]]<br /> Для конвертації відеофайлу скористаємося програмою [http://www.any-video-converter.com/products/for_video_free/ Any video Converter ]. Для цього перетягуємо відеофайл у цетральну область програми. Етапи конвертування:<br /> &lt;ol&gt;<br /> &lt;li&gt;Вибираємо початкову та кінцеву позицію<br /> &lt;li&gt;Вибираємо кодек<br /> &lt;li&gt;Вибираємо розширення відео<br /> &lt;li&gt;Вибираємо бітрейт відео та частоту кадрів<br /> &lt;li&gt;Вибираємо налаштування аудіокодека<br /> &lt;/ol&gt;<br /> &lt;li&gt;Таблиця порівняння одержаних файлів<br /> &lt;table border=1 width=95%&gt;&lt;tr&gt;&lt;td width=22% align=center&gt;'''Назва'''&lt;/td&gt;&lt;td width=20% align=center&gt;'''Хар-ка відео'''&lt;/td&gt;&lt;td width=20% align=center&gt;'''Хар-ка аудіо'''&lt;/td&gt;&lt;td width=15% align=center&gt;'''Якість зображення'''&lt;/td&gt;&lt;td width=15% align=center&gt;'''Якість звуку'''&lt;/td&gt;&lt;td&gt;'''Розмір'''&lt;/td&gt;&lt;/tr&gt;<br /> <br /> &lt;tr&gt;<br /> &lt;td align=center&gt;[http://upload.com.ua/get/902211451/SDu.avi]&lt;br&gt;(некомпр. файл)&lt;/td&gt;<br /> &lt;td align=center&gt;640x480, 25.00 fps, XviD MPEG-4 ~422 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;44.1 kHz, Dolby AC3, 2 ch, ~128.00 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;Відмінна&lt;/td&gt;&lt;td align=center&gt;Відмінна&lt;/td&gt;<br /> &lt;td align=center&gt;14.7MB&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td align=center&gt;[http://upload.com.ua/get/902211486/SDu_wmv2.mkv]&lt;br&gt;(компр. файл)&lt;/td&gt;<br /> &lt;td align=center&gt;320x240, 20.00 fps, WMV ~192 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;44.1 kHz, MPEG Audio Layer 3, 2 ch, ~56 kbps&lt;/td&gt;<br /> &lt;td align=center&gt;Задовільна&lt;/td&gt;&lt;td align=center&gt;Задовільна&lt;/td&gt;<br /> &lt;td align=center&gt;4.53MB&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> &lt;li&gt;Так як цей ресурс не підтримує завантаження даного формату файлів - файли було завантажено на сторонній ресурс<br /> &lt;/ol&gt;<br /> <br /> === Висновок ===<br /> <br /> Виконуючи дану лабораторну роботу я більш детально засвоїв єтапи створення відео бібліотеки. Використовуючи стандартній програвач Windows Media Player я зробив висновки, що ця программа досить не зручна, але всеж має всої переваги.<br /> Використовуючи программу для конвертації відео файлів, а саме Virtual Dub я зрозумів, що хоть вона і має невеликий розмір, але дуже потужна для роботи з відео. Вона використовує встановлені в систему кодеки і не потребує встановлення допоміжних. Программа дозволяє швидко конвертувати файли з мінімальними втратами якості, але великою зміною розміру, тому її застосовують більшість риперів.</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_5 2010-12-22T12:16:55Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із відео. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів відео файлів<br /> <br /> === Теоретичні питання: ===<br /> <br /> # [[Відео | Відео, як складова мультимедіа]]<br /> # [[Формати_відео_файлів | Формати відео файлів]]<br /> # Конвертація відео файлів в різні формати.<br /> # Представлення відео в проекті.<br /> # Особливості оцінювання відео файлів.<br /> <br /> === Практичні завдання ===<br /> Для організації перегляду власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]<br /> <br /> [[Файл:Win_V.JPG|thumb|350px|center|Моя відео бібліотека ]]<br /> Щоб створити бібліотеку достатьно зайти на вкладку Параметри програвача Winamp і вказати в розділі бібліотека ті каталоги за якими Winamp<br /> буде наблюдать і автоматично знаходити Video файли та заносити їх автоматично до бібліотеки<br /> [[Файл:Win b.JPG|thumb|350px|center|]]<br /> Для конвертації відеофайлу скористаємося програмою [http://www.any-video-converter.com/products/for_video_free/ Any video Converter ]. Для цього перетягуємо відеофайл у цетральну область програми. Етапи конвертування:<br /> &lt;ol&gt;<br /> &lt;li&gt;Вибираємо початкову та кінцеву позицію<br /> &lt;li&gt;Вибираємо кодек<br /> &lt;li&gt;Вибираємо розширення відео<br /> &lt;li&gt;Вибираємо бітрейт відео та частоту кадрів<br /> &lt;li&gt;Вибираємо налаштування аудіокодека<br /> &lt;/ol&gt;</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_4 2010-12-22T12:01:53Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із звуком. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів аудіо файлів <br /> <br /> === Теоретичні питання: ===<br /> <br /> #[[Аудіо | Звук, як складова мультимедіа]]<br /> #[[Формати_аудіо_файлів | Формати звукових файлів]]<br /> #Конвертація звукових файлів в різні формати.<br /> #Представлення аудіо в проекті.<br /> #Особливості оцінювання звукових файлів.<br /> === Практичні завдання: ===<br /> Для запису звукового файлу використовуємо стандартну програму windows XP - &quot;Звукозапись&quot;.<br /> [[Image:zapis_XP.jpg|thumb|350px|right|Звукозапись]]<br /> Для організації прослуховування власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]<br /> <br /> [[Файл:Win.JPG|thumb|350px|center|]]<br /> Щоб створити бібліотеку достатьно зайти на вкладку Параметри програвача Winamp і вказати в розділі бібліотека ті каталоги за якими Winamp<br /> буде наблюдать і автоматично знаходити аудіо файли та заносити їх автоматично до бібліотеки<br /> [[Файл:Win b.JPG|thumb|350px|center|перший крок]]<br /> Проводим компресію файлу. Для компресії використаємо вільну программу [http://audacity.sourceforge.net/?lang=ru Audacity]<br /> <br /> [http://upload.com.ua/get/902211355/Nightwish_-_Over the hills &amp; far a way.ogg| Середня якість]<br /> <br /> [http://upload.com.ua/get/902211357/Nightwish_-_Over the hills &amp; far a way_1.ogg| Максимальна компресія]<br /> <br /> [http://upload.com.ua/get/902211364/Nightwish_-_Over the hills &amp; far a way_2.ogg| Найкраща якість]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_5 2010-12-22T12:01:27Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із відео. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів відео файлів<br /> <br /> === Теоретичні питання: ===<br /> <br /> # [[Відео | Відео, як складова мультимедіа]]<br /> # [[Формати_відео_файлів | Формати відео файлів]]<br /> # Конвертація відео файлів в різні формати.<br /> # Представлення відео в проекті.<br /> # Особливості оцінювання відео файлів.<br /> <br /> === Практичні завдання ===<br /> Для організації перегляду власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]<br /> <br /> [[Файл:Win_V.JPG|thumb|350px|center|Моя відео бібліотека ]]<br /> Щоб створити бібліотеку достатьно зайти на вкладку Параметри програвача Winamp і вказати в розділі бібліотека ті каталоги за якими Winamp<br /> буде наблюдать і автоматично знаходити Video файли та заносити їх автоматично до бібліотеки<br /> [[Файл:Win b.JPG|thumb|350px|center|]]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_5 2010-12-22T11:59:55Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із відео. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів відео файлів<br /> <br /> === Теоретичні питання: ===<br /> <br /> # [[Відео | Відео, як складова мультимедіа]]<br /> # [[Формати_відео_файлів | Формати відео файлів]]<br /> # Конвертація відео файлів в різні формати.<br /> # Представлення відео в проекті.<br /> # Особливості оцінювання відео файлів.<br /> <br /> === Практичні завдання ===<br /> Для організації перегляду власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]<br /> <br /> [[Файл:Win_V.JPG|thumb|350px|center|перший крок]]<br /> Щоб створити бібліотеку достатьно зайти на вкладку Параметри програвача Winamp і вказати в розділі бібліотека ті каталоги за якими Winamp<br /> буде наблюдать і автоматично знаходити Video файли та заносити їх автоматично до бібліотеки<br /> [[Файл:Win b.JPG|thumb|350px|center|перший крок]]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_5 2010-12-22T11:59:14Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із відео. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів відео файлів<br /> <br /> === Теоретичні питання: ===<br /> <br /> # [[Відео | Відео, як складова мультимедіа]]<br /> # [[Формати_відео_файлів | Формати відео файлів]]<br /> # Конвертація відео файлів в різні формати.<br /> # Представлення відео в проекті.<br /> # Особливості оцінювання відео файлів.<br /> <br /> === Практичні завдання ===<br /> Для організації перегляду власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]<br /> <br /> [[Файл:Win_V.JPG|thumb|350px|center|перший крок]]<br /> Щоб створити бібліотеку достатьно зайти на вкладку Параметри програвача Winamp і вказати в розділі бібліотека ті каталоги за якими Winamp<br /> буде наблюдать і автоматично знаходити аудіо файли та заносити їх автоматично до бібліотеки<br /> [[Файл:Win b.JPG|thumb|350px|center|перший крок]]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%A1%D1%82%D1%83%D0%B4%D0%B5%D0%BD%D1%82%D1%81%D1%8C%D0%BA%D1%96_%D1%80%D0%BE%D0%B1%D0%BE%D1%82%D0%B8_%D0%B7_%D0%BC%D1%83%D0%BB%D1%8C%D1%82%D0%B8%D0%BC%D0%B5%D0%B4%D1%96%D0%B9%D0%BD%D0%B8%D1%85_%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D1%96%D0%B9 2010-12-22T11:53:35Z

<p>I Shevchenko: /* Шевченко Ігор */</p> <hr /> <div>Розміщуємо посилання на ваші сторінки й зовнішні ресурси<br /> <br /> == [[User:vad_zel|Зеленський Вадим Сергійович]]==<br /> <br /> [[Лабораторна робота №1-2 | Лабораторна робота №1]]<br /> <br /> [[Лабораторна робота №1-2 | Лабораторна робота №2]]<br /> <br /> [[Лабораторна робота №3 Зеленський | Лабораторна робота №3]]<br /> <br /> [[Лабораторна робота №4 Зеленський | Лабораторна робота №4]]<br /> <br /> [[лаба 5 | Лабораторна робота №5]]<br /> <br /> [[лаба 6 | Лабораторна робота №6]]<br /> <br /> [[Laba_7-8 | Лабораторна робота №7]]<br /> <br /> ==[[User:NICOLE| Паршенков Віталій Сергійович, 36 група ]]== <br /> <br /> [[Лаб_роб №1 | Лабораторна робота №1]]<br /> <br /> [[Лаб_роб №2 | Лабораторна робота №2]]<br /> <br /> [[Лаб_роб №3 | Лабораторна робота №3]]<br /> <br /> [[Лаб_роб №4 | Лабораторна робота №4]]<br /> <br /> [[Лаб_роб №5 | Лабораторна робота №5]]<br /> <br /> [[Лаб_роб №6 | Лабораторна робота №6]]<br /> <br /> [[Лаб_роб №7 | Лабораторна робота №7]]<br /> <br /> == Волошин Віталій Миколайович ==<br /> <br /> [[Лаб_Роб_№1-2 | Лабораторна робота № 1-2]]<br /> <br /> [[Лаб_Роб_№3 | Лабораторна робота №3]]<br /> <br /> [[Лаб_Роб_№4 | Лабораторна робота №4]]<br /> <br /> [[Лаб_Роб_№5 | Лабораторна робота №5]]<br /> <br /> [[Лаб_Роб_№6 | Лабораторна робота №6]]<br /> <br /> [[Лаб_Роб_№7 | Лабораторна робота №7]]<br /> <br /> == Бакуменко Володимир Олксандрович ==<br /> <br /> [[лаораторна робота №3 | Лабораторна робота №3]]<br /> <br /> [[лаораторна робота №4 | Лабораторна робота №4]]<br /> <br /> [[лаораторна робота №5 | Лабораторна робота №5]]<br /> <br /> [[лаораторна робота №6 | Лабораторна робота №6]]<br /> <br /> [[лаораторна робота №7 | Лабораторна робота №7]]<br /> <br /> == [[User:Бєлінський_Андрій|Бєлінський Андрій]] ==<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;[[Лабораторна робота 1: Мультимедійні технології (Beliand) | Лабораторна робота 1]]<br /> &lt;li&gt;[[Лабораторна робота 1: Мультимедійні технології (Beliand) | Лабораторна робота 2]]<br /> &lt;li&gt;[[Лабораторна робота 3: Мультимедійні технології (Beliand) | Лабораторна робота 3]]<br /> &lt;li&gt;[[Лабораторна робота 4: Мультимедійні технології (Beliand) | Лабораторна робота 4]]<br /> &lt;li&gt;[[Лабораторна робота 5: Мультимедійні технології (Beliand) | Лабораторна робота 5]]<br /> &lt;li&gt;[[Лабораторна робота 6: Мультимедійні технології (Beliand) | Лабораторна робота 6]]<br /> &lt;li&gt;[[Лабораторна робота 7: Мультимедійні технології (Beliand) | Лабораторна робота 7-8]]<br /> &lt;/ul&gt;<br /> <br /> ==[[User:demo1420 | Пшиник Ігор Олександрович ]]==<br /> <br /> [[лаб_роб_3|Лабораторна робота №3]]<br /> <br /> [http://www.slideshare.net/demo1420/wi-fi-windows-6270036#| Лабораторна робота №6 Пшиника Ігор]<br /> <br /> [[Лабораторна робота №7 Пшиника Ігора# | Лабораторна робота №7]]<br /> <br /> ==[[Користувач:I_Shevchenko| Шевченко Ігор]]==<br /> [[Lab_1,2| Лабораторна робота№1,2]]<br /> <br /> [[Lab_3| Лабораторна робота№3]]<br /> <br /> [[Lab_4| Лабораторна робота№4]]<br /> <br /> [[Lab_6| Лабораторна робота№6]]<br /> <br /> [[Lab_7| Лабораторна робота№7,8]]<br /> <br /> == [[User:Viper|Григоржевський Василь Аркадійович]], 36 група ==<br /> <br /> <br /> [[Лаб1,2| Лабораторна № 1]]<br /> <br /> [[Лаб1,2| Лабораторна № 2]]<br /> <br /> [[Лаб3| Лабораторна № 3]]<br /> <br /> [[Лаб4| Лабораторна № 4]]<br /> <br /> [[Лаб5| Лабораторна № 5]]<br /> <br /> [[лаб6| Лабораторна № 6]]<br /> <br /> [[lab_7_8| Лабораторна № 7]]<br /> <br /> [[lab_7_8| Лабораторна № 8]]<br /> <br /> == [[Користувач:BuMeRok91 |Антонов Олексій Сергійович]], 36 група ==<br /> <br /> [[Лабораторна робота №1 (з предмету мультимедіа)| Лабораторна № 1]]<br /> <br /> [[Лабораторна робота №2 (з предмету мультимедіа)| Лабораторна № 2]]<br /> <br /> [[Лабораторна робота №3 (З предмету мультимедіа)| Лабораторна № 3]]<br /> <br /> [[Лабораторна робота №4 (З предмету мультимедіа)| Лабораторна № 4]]<br /> <br /> [[Лабораторна робота №5 (З предмету мультимедіа)| Лабораторна № 5]]<br /> <br /> [[Лабораторна робота №6 (З предмету мультимедіа)| Лабораторна № 6]]<br /> <br /> [[Лабораторна робота №7 (З предмету мультимедіа)| Лабораторна № 7]]<br /> <br /> == [[Користувач:Nopasha |Суховещенко Павло Костянтинович]], 36 група ==<br /> <br /> [[ 1 | Лабораторна робота № 1]]<br /> <br /> [[ 1 | Лабораторна робота № 2]]<br /> <br /> [[ Labs_-3 | Лабораторна робота № 3]]<br /> <br /> [[ Labs_-4 | Лабораторна робота № 4]]<br /> <br /> [[ Labs_-5 | Лабораторна робота № 5]]<br /> <br /> [[ Labs_-6 | Лабораторна робота № 6]]<br /> <br /> [[ Labs_-7 | Лабораторна робота № 7]]<br /> <br /> [[ Labs_-7 | Лабораторна робота № 8]]<br /> <br /> ==[[User:Нагорний| Нагорний Сергій Сергійович, 36 група ]]== <br /> <br /> [[Лабораторна робота №1 Нагорного | Лабораторна робота №1]]<br /> <br /> [[Лабораторна робота №2 Нагорного | Лабораторна робота №2]]<br /> <br /> [[Лабораторна робота №3 Нагорного | Лабораторна робота №3]]<br /> <br /> [[Лабораторна робота №4 Нагорного | Лабораторна робота №4]]<br /> <br /> [[Лабораторна робота №5 Нагорного | Лабораторна робота №5]]<br /> <br /> [[Лабораторна робота №6 Нагорного | Лабораторна робота №6]]<br /> <br /> [[Лабораторна робота №7 Нагорного | Лабораторна робота №7]]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_4 2010-12-22T11:51:52Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із звуком. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів аудіо файлів <br /> <br /> === Теоретичні питання: ===<br /> <br /> #[[Аудіо | Звук, як складова мультимедіа]]<br /> #[[Формати_аудіо_файлів | Формати звукових файлів]]<br /> #Конвертація звукових файлів в різні формати.<br /> #Представлення аудіо в проекті.<br /> #Особливості оцінювання звукових файлів.<br /> === Практичні завдання: ===<br /> Для запису звукового файлу використовуємо стандартну програму windows XP - &quot;Звукозапись&quot;.<br /> [[Image:zapis_XP.jpg|thumb|350px|right|Звукозапись]]<br /> Для організації прослуховування власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]<br /> <br /> [[Файл:Win.JPG|thumb|350px|center|перший крок]]<br /> Щоб створити бібліотеку достатьно зайти на вкладку Параметри програвача Winamp і вказати в розділі бібліотека ті каталоги за якими Winamp<br /> буде наблюдать і автоматично знаходити аудіо файли та заносити їх автоматично до бібліотеки<br /> [[Файл:Win b.JPG|thumb|350px|center|перший крок]]<br /> Проводим компресію файлу. Для компресії використаємо вільну программу [http://audacity.sourceforge.net/?lang=ru Audacity]<br /> <br /> [http://upload.com.ua/get/902211355/Nightwish_-_Over the hills &amp; far a way.ogg| Середня якість]<br /> <br /> [http://upload.com.ua/get/902211357/Nightwish_-_Over the hills &amp; far a way_1.ogg| Максимальна компресія]<br /> <br /> [http://upload.com.ua/get/902211364/Nightwish_-_Over the hills &amp; far a way_2.ogg| Найкраща якість]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_4 2010-12-22T11:51:11Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із звуком. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів аудіо файлів <br /> <br /> === Теоретичні питання: ===<br /> <br /> #[[Аудіо | Звук, як складова мультимедіа]]<br /> #[[Формати_аудіо_файлів | Формати звукових файлів]]<br /> #Конвертація звукових файлів в різні формати.<br /> #Представлення аудіо в проекті.<br /> #Особливості оцінювання звукових файлів.<br /> === Практичні завдання: ===<br /> Для запису звукового файлу використовуємо стандартну програму windows XP - &quot;Звукозапись&quot;.<br /> [[Image:zapis_XP.jpg|thumb|350px|right|Звукозапись]]<br /> Для організації прослуховування власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]<br /> <br /> [[Файл:Win.JPG|thumb|350px|center|перший крок]]<br /> Щоб створити бібліотеку достатьно зайти на вкладку Параметри програвача Winamp і вказати в розділі бібліотека ті каталоги за якими Winamp<br /> буде наблюдать і автоматично знаходити аудіо файли та заносити їх автоматично до бібліотеки<br /> [[Файл:Win b.JPG|thumb|350px|center|перший крок]]<br /> Проводим компресію файлу. Для компресії використаємо вільну программу [http://audacity.sourceforge.net/?lang=ru Audacity]<br /> <br /> [http://upload.com.ua/get/902211355/Nightwish_-_Over the hills &amp; far a way.ogg| Максимальна компресія]<br /> <br /> [http://upload.com.ua/get/902211357/Nightwish_-_Over the hills &amp; far a way_1.ogg| Середня якість]<br /> <br /> [http://upload.com.ua/get/902211364/Nightwish_-_Over the hills &amp; far a way_2.ogg| Найкраща якість]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_4 2010-12-22T11:50:31Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із звуком. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів аудіо файлів <br /> <br /> === Теоретичні питання: ===<br /> <br /> #[[Аудіо | Звук, як складова мультимедіа]]<br /> #[[Формати_аудіо_файлів | Формати звукових файлів]]<br /> #Конвертація звукових файлів в різні формати.<br /> #Представлення аудіо в проекті.<br /> #Особливості оцінювання звукових файлів.<br /> === Практичні завдання: ===<br /> Для запису звукового файлу використовуємо стандартну програму windows XP - &quot;Звукозапись&quot;.<br /> [[Image:zapis_XP.jpg|thumb|350px|right|Звукозапись]]<br /> Для організації прослуховування власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]<br /> <br /> [[Файл:Win.JPG|thumb|350px|center|перший крок]]<br /> Щоб створити бібліотеку достатьно зайти на вкладку Параметри програвача Winamp і вказати в розділі бібліотека ті каталоги за якими Winamp<br /> буде наблюдать і автоматично знаходити аудіо файли та заносити їх автоматично до бібліотеки<br /> [[Файл:Win b.JPG|thumb|350px|center|перший крок]]<br /> Проводим компресію файлу. Для компресії використаємо вільну программу [http://audacity.sourceforge.net/?lang=ru Audacity]<br /> <br /> [http://upload.com.ua/get/902211355/Nightwish_-_Over the hills &amp; far a way.ogg Максимальна компресія]<br /> <br /> [http://upload.com.ua/get/902211357/Nightwish_-_Over the hills &amp; far a way_1.ogg Середня якість]<br /> <br /> [http://upload.com.ua/get/902211364/Nightwish_-_Over the hills &amp; far a way_2.ogg Найкраща якість]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_4 2010-12-22T11:48:52Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із звуком. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів аудіо файлів <br /> <br /> === Теоретичні питання: ===<br /> <br /> #[[Аудіо | Звук, як складова мультимедіа]]<br /> #[[Формати_аудіо_файлів | Формати звукових файлів]]<br /> #Конвертація звукових файлів в різні формати.<br /> #Представлення аудіо в проекті.<br /> #Особливості оцінювання звукових файлів.<br /> === Практичні завдання: ===<br /> Для запису звукового файлу використовуємо стандартну програму windows XP - &quot;Звукозапись&quot;.<br /> [[Image:zapis_XP.jpg|thumb|350px|right|Звукозапись]]<br /> Для організації прослуховування власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]<br /> <br /> [[Файл:Win.JPG|thumb|350px|center|перший крок]]<br /> Щоб створити бібліотеку достатьно зайти на вкладку Параметри програвача Winamp і вказати в розділі бібліотека ті каталоги за якими Winamp<br /> буде наблюдать і автоматично знаходити аудіо файли та заносити їх автоматично до бібліотеки<br /> [[Файл:Win b.JPG|thumb|350px|center|перший крок]]<br /> Проводим компресію файлу. Для компресії використаємо вільну программу [http://audacity.sourceforge.net/?lang=ru Audacity]<br /> <br /> [http://upload.com.ua/get/902211355/Nightwish_-_Over the hills &amp; far a way.ogg ]<br /> [http://upload.com.ua/get/902211357/Nightwish_-_Over the hills &amp; far a way_1.ogg]<br /> [http://upload.com.ua/get/902211364/Nightwish_-_Over the hills &amp; far a way_2.ogg]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_4 2010-12-22T11:46:40Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із звуком. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів аудіо файлів <br /> <br /> === Теоретичні питання: ===<br /> <br /> #[[Аудіо | Звук, як складова мультимедіа]]<br /> #[[Формати_аудіо_файлів | Формати звукових файлів]]<br /> #Конвертація звукових файлів в різні формати.<br /> #Представлення аудіо в проекті.<br /> #Особливості оцінювання звукових файлів.<br /> === Практичні завдання: ===<br /> Для запису звукового файлу використовуємо стандартну програму windows XP - &quot;Звукозапись&quot;.<br /> [[Image:zapis_XP.jpg|thumb|350px|right|Звукозапись]]<br /> Для організації прослуховування власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]<br /> <br /> [[Файл:Win.JPG|thumb|350px|center|перший крок]]<br /> Щоб створити бібліотеку достатьно зайти на вкладку Параметри програвача Winamp і вказати в розділі бібліотека ті каталоги за якими Winamp<br /> буде наблюдать і автоматично знаходити аудіо файли та заносити їх автоматично до бібліотеки<br /> [[Файл:Win b.JPG|thumb|350px|center|перший крок]]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_4 2010-12-22T11:39:59Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із звуком. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів аудіо файлів <br /> <br /> === Теоретичні питання: ===<br /> <br /> #[[Аудіо | Звук, як складова мультимедіа]]<br /> #[[Формати_аудіо_файлів | Формати звукових файлів]]<br /> #Конвертація звукових файлів в різні формати.<br /> #Представлення аудіо в проекті.<br /> #Особливості оцінювання звукових файлів.<br /> === Практичні завдання: ===<br /> Для запису звукового файлу використовуємо стандартну програму windows XP - &quot;Звукозапись&quot;.<br /> [[Image:zapis_XP.jpg|thumb|350px|right|Звукозапись]]<br /> Для організації прослуховування власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]<br /> <br /> [[Файл:Win.JPG|thumb|350px|center|Моя Audio Бібліотека]]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_4 2010-12-22T11:36:43Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із звуком. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів аудіо файлів <br /> <br /> === Теоретичні питання: ===<br /> <br /> #[[Аудіо | Звук, як складова мультимедіа]]<br /> #[[Формати_аудіо_файлів | Формати звукових файлів]]<br /> #Конвертація звукових файлів в різні формати.<br /> #Представлення аудіо в проекті.<br /> #Особливості оцінювання звукових файлів.<br /> === Практичні завдання: ===<br /> Для запису звукового файлу використовуємо стандартну програму windows XP - &quot;Звукозапись&quot;.<br /> [[Image:zapis_XP.jpg|thumb|350px|right|Звукозапись]]<br /> Для організації прослуховування власної бібліотеки використовуємо програму [http://www.winamp.com/ Winamp]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_4 2010-12-22T11:35:41Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із звуком. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів аудіо файлів <br /> <br /> === Теоретичні питання: ===<br /> <br /> #[[Аудіо | Звук, як складова мультимедіа]]<br /> #[[Формати_аудіо_файлів | Формати звукових файлів]]<br /> #Конвертація звукових файлів в різні формати.<br /> #Представлення аудіо в проекті.<br /> #Особливості оцінювання звукових файлів.<br /> === Практичні завдання: ===<br /> Для запису звукового файлу використовуємо стандартну програму windows XP - &quot;Звукозапись&quot;.<br /> [[Image:zapis_XP.jpg|thumb|350px|right|Звукозапись]]<br /> <br /> <br /> <br /> <br /> <br /> <br /> Для організації прослуховування власної бібліотеки використовуємо програму</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Labs_-6 2010-12-22T11:34:36Z

<p>I Shevchenko: </p> <hr /> <div>'''Лабораторна робота №6'''<br /> <br /> '''Тема:''' Текст та презентації<br /> <br /> '''Мета:''' Вивчення правил оформлення текстових об'єктів<br /> <br /> === Теоретичні питання: ===<br /> <br /> # Текст, як складова мультимедіа. <br /> # Правила набору тексту. <br /> # Презентація.<br /> # Розміщення презентації в мережі.<br /> <br /> === Практичні завдання: ===<br /> &lt;ol&gt;<br /> &lt;li&gt;Тема моєї презентації - Mustafa Kemal Ataturk -засновник Турецької республіки. Програми spyware. Презентація була розміщена на таких ресурсах:<br /> &lt;ul&gt;<br /> &lt;li&gt;[http://www.slideshare.net/xxxSACREDxxx/ss-6288376 SlideShare.net]<br /> &lt;/ul&gt;<br /> &lt;li&gt;Створюємо візитку з допомогою сервіса [http://www.facebook.com/profile.php?id=100001316853186 facebook.com]&lt;br&gt;<br /> [[Файл:Badgehp.png]]<br /> &lt;/ol&gt;</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/Lab_4 2010-12-22T11:33:16Z

<p>I Shevchenko: </p> <hr /> <div>'''Тема:''' Робота із звуком. Збереження та відтворення.<br /> <br /> '''Мета:''' Вивчення форматів аудіо файлів <br /> <br /> === Теоретичні питання: ===<br /> <br /> #[[Аудіо | Звук, як складова мультимедіа]]<br /> #[[Формати_аудіо_файлів | Формати звукових файлів]]<br /> #Конвертація звукових файлів в різні формати.<br /> #Представлення аудіо в проекті.<br /> #Особливості оцінювання звукових файлів.<br /> === Практичні завдання: ===<br /> Для запису звукового файлу використовуємо стандартну програму windows XP - &quot;Звукозапись&quot;.<br /> [[Image:zapis_XP.jpg|thumb|350px|right|Звукозапись]]</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:Win_V.JPG 2010-12-21T20:03:57Z

<p>I Shevchenko: </p> <hr /> <div></div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:Win_b.JPG 2010-12-21T20:03:33Z

<p>I Shevchenko: </p> <hr /> <div></div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:Win.JPG 2010-12-21T20:02:56Z

<p>I Shevchenko: </p> <hr /> <div></div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9A%D0%BE%D1%80%D0%B8%D1%81%D1%82%D1%83%D0%B2%D0%B0%D1%87:I_Shevchenko 2010-12-21T19:48:59Z

<p>I Shevchenko: </p> <hr /> <div>[[Файл:DSC00965.JPG|300px|thumb|Right|]]<br /> = Про себе =<br /> <br /> <br /> Я, Шевченко Ігор Віталійович, студент [http://www.kspu.kr.ua/ Кіровоградський державний педагогічний університет ім.В.Винниченка], навчаюся на фiзико-математичному факультетi, кафедра Iнформатики, 36 група.<br /> <br /> <br /> <br /> = Мої Інтереси =<br /> <br /> Цікавлюся<br /> <br /> <br /> <br /> <br /> = Лабораторні роботи =<br /> <br /> <br /> <br /> <br /> ==[[ з курсу MultiMedia ]]==<br /> <br /> <br /> == [[ з курсу Сервісне програмне забезпечення ]] ==</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9A%D0%BE%D1%80%D0%B8%D1%81%D1%82%D1%83%D0%B2%D0%B0%D1%87:I_Shevchenko 2010-12-21T19:48:44Z

<p>I Shevchenko: </p> <hr /> <div>&lt;a href=&quot;http://www.testip.ru&quot; target=&quot;_blank&quot;&gt;&lt;img src=&quot;http://www.adslnet.ru/anonimity/bars/anonimity.dyn-png&quot; alt=&quot;TestIP.RU - Узнай свой IP&quot; border=&quot;0&quot; /&gt;&lt;/a&gt;<br /> [[Файл:DSC00965.JPG|300px|thumb|Right|]]<br /> = Про себе =<br /> <br /> <br /> Я, Шевченко Ігор Віталійович, студент [http://www.kspu.kr.ua/ Кіровоградський державний педагогічний університет ім.В.Винниченка], навчаюся на фiзико-математичному факультетi, кафедра Iнформатики, 36 група.<br /> <br /> <br /> <br /> = Мої Інтереси =<br /> <br /> Цікавлюся<br /> <br /> <br /> <br /> <br /> = Лабораторні роботи =<br /> <br /> <br /> <br /> <br /> ==[[ з курсу MultiMedia ]]==<br /> <br /> <br /> == [[ з курсу Сервісне програмне забезпечення ]] ==</div>

I Shevchenko https://wiki.cusu.edu.ua/index.php/%D0%9A%D0%BE%D1%80%D0%B8%D1%81%D1%82%D1%83%D0%B2%D0%B0%D1%87:I_Shevchenko 2010-12-21T19:48:16Z

<p>I Shevchenko: </p> <hr /> <div>[URL=&quot;http://www.testip.ru&quot;][IMG]http://www.adslnet.ru/anonimity/bars/anonimity.dyn-png[/IMG][/URL]<br /> [[Файл:DSC00965.JPG|300px|thumb|Right|]]<br /> = Про себе =<br /> <br /> <br /> Я, Шевченко Ігор Віталійович, студент [http://www.kspu.kr.ua/ Кіровоградський державний педагогічний університет ім.В.Винниченка], навчаюся на фiзико-математичному факультетi, кафедра Iнформатики, 36 група.<br /> <br /> <br /> <br /> = Мої Інтереси =<br /> <br /> Цікавлюся<br /> <br /> <br /> <br /> <br /> = Лабораторні роботи =<br /> <br /> <br /> <br /> <br /> ==[[ з курсу MultiMedia ]]==<br /> <br /> <br /> == [[ з курсу Сервісне програмне забезпечення ]] ==</div>

I Shevchenko