Власні елементи управління: за і проти, HTML, XML, DHTML, Інтернет-технології, статті

На певному щаблі еволюції майже будь-якого програмного продукту цей продукт починає обростати нестандартними, написаними спеціально для нього, елементами управління. Іноді це виявляється добре, іноді – ні.

У виробництві, орієнтованому на нескінченний випуск нових версій, рано чи пізно виявляється, що подальше розширення функціональності продукту виявляється практично непомітним для користувачів. У самому справі, якщо користувач вже не вміє користуватися значною частиною функціональних можливостей, навіщо йому можливості нові? У таких випадках майже єдиним виходом служить зміна інтерфейсу (Якщо вже неможливо подальше поліпшення нефункціональних властивостей продукту, таких, як надійність). Самим же організаційно простим (хоча, взагалі кажучи, не найдешевшим) способом зміни інтерфейсу є заміна стандартних елементів управління нестандартними. Сама по собі така зміна інтерфейсу зовсім не погана. З нею, однак, пов’язані певні проблеми.

Справа в тому, що розробка власних елементів управління є справа досить складна. Гаразд ще, коли за мету ставиться розробка елемента, у якого є добре працюючий прототип (інша система, наприклад), з яким можна постійно звірятися. Якщо прототипу немає, можлива і, більше того, імовірна ситуація, при якій елемент управління вийде хоч і естетично привабливим, але «якихось не таким». Складні елементи мають досить складними алгоритмами роботи, до того ж у них багато дрібниць, які дуже важко відразу зробити правильно. Мова не йде про те, що елемент не буде виконувати свої функції; елемент буде їх виконувати, але, наприклад, занадто швидко або занадто повільно. Рахунок тут йде на мілісекунди і пікселі. Крім того, що вийшов елемент не просто повинен добре працювати, але й відповідати логіці роботи стандартних елементів управління з ОС. Інакше користувачі, працюючи c системою, будуть постійно відчувати деяку незручність і незручність, при цьому вони навіть не зможуть висловити їх причин. Для вирішення цієї проблеми розроблені елементи потрібно тестувати, що сильно збільшує терміни і вартість розробки.

В результаті розробка (або покупка готових) нестандартних елементів управління виявляється дорогим задоволенням. Навіть модифікація стандартних елементів засобами їх API займає досить багато часу, що вже тут говорити про написання з нуля.

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



  1. Вони, як виявляється з їх назви, стандартні, від чого всі програми схожі одна на одну. Це добре з точки зору швидкості навчання, але погано щодо брендингу.
  2. Вони або навмисно зроблені візуально нейтральними (читай – нудно виглядають) або вже приїлися постійним користувачам (наприклад, мало хто відчуває естетичний захват від виду стандартного інтерфейсу Windows 95, хоча в момент його появи контраст між ним і інтерфейсом Windows 3.1 був разючий).
  3. Як правило, стандартні елементи управління досить великі за розміром (виняток – Apple OS X, в якій кожен елемент управління реалізований у великій і дрібній версіях).
  4. Номенклатура стандартних елементів управління завжди невелика, так що деякі завдання вирішуються ними неефективно.

Таким чином, застосування нестандартних елементів часто є виправданим. Хитрість у тому, що нестандартні елементи ефективніше вводити не в кінці життєвого циклу продукту, але на його початку. Це не зменшує число можливих версій, зате в меншій мірі вимагає перенавчання у існуючих користувачів. Крім того, продукт з інтерфейсом, який використовує адекватні елементи управління, з більшою ймовірністю захопить ринок. Важливо тільки серйозно підійти до якості елементів. Інтерфейс не стане автоматично краще, якщо стандартні елементи замінити нестандартними. Він стане краще, якщо стандартні елементи замінити кращими.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*