На определенной ступени эволюции почти любого программного продукта этот продукт начинает обрастать нестандартными, написанными специально для него, элементами управления. Иногда это оказывается хорошо, иногда - нет.
В производстве, ориентированном на бесконечный выпуск новых версий, рано или поздно оказывается, что дальнейшее расширение функциональности продукта оказывается практически незаметным для пользователей. В самом деле, если пользователь уже не умеет пользоваться значительной частью функциональных возможностей, зачем ему возможности новые? В таких случаях почти единственным выходом служит изменение интерфейса (если уже невозможно дальнейшее улучшение нефункциональных свойств продукта, таких, как надежность). Самым же организационно простым (хотя, вообще говоря, не самым дешевым) способом изменения интерфейса является замена стандартных элементов управления нестандартными. Сама по себе такая смена интерфейса вовсе не плоха. С ней, однако, связаны определенные проблемы.
Дело в том, что разработка собственных элементов управления есть дело довольно сложное. Ладно ещё, когда целью ставится разработка элемента, у которого есть хорошо работающий прототип (другая система, например), с которым можно постоянно сверяться. Если прототипа нет, возможна и, более того, вероятна ситуация, при которой элемент управления получится хоть и эстетически привлекательным, но «каким-то не таким». Сложные элементы обладают достаточно сложными алгоритмами работы, к тому же в них много мелочей, которые очень трудно сразу сделать правильно. Речь не идет о том, что элемент не будет выполнять свои функции; элемент будет их выполнять, но, например, слишком быстро или слишком медленно. Счет здесь идет на миллисекунды и пиксели. Кроме того, получившийся элемент не просто должен хорошо работать, но и соответствовать логике работы стандартных элементов управления из ОС. Иначе пользователи, работая c системой, будут постоянно испытывать некоторое неудобство и неловкость, при этом они даже не смогут высказать их причин. Для решения этой проблемы разработанные элементы нужно тестировать, что сильно увеличивает сроки и стоимость разработки.
В результате разработка (или покупка готовых) нестандартных элементов управления оказывается дорогим удовольствием. Даже модификация стандартных элементов средствами их API занимает довольно много времени, что уж тут говорить о написании с нуля.
В то же время нестандартные элементы управления имеют множество достоинств, проистекающих из недостатков элементов стандартных. Недостатки же стандартных элементов таковы:
- Они, как явствует из их названия, стандартны, отчего все программы похожи друг на друга. Это хорошо с точки зрения скорости обучения, но плохо в отношении брендинга.
- Они либо намеренно сделаны визуально нейтральными (читай - скучно выглядящими) либо уже приелись постоянным пользователям (например, мало кто испытывает эстетический восторг от вида стандартного интерфейса Windows 95, хотя в момент его появления контраст между ним и интерфейсом Windows 3.1 был разителен).
- Как правило, стандартные элементы управления довольно велики по размеру (исключение - Apple OS X, в которой каждый элемент управления реализован в крупной и мелкой версиях).
- Номенклатура стандартных элементов управления всегда невелика, так что некоторые задачи решаются ими неэффективно.
Таким образом, применение нестандартных элементов часто является оправданным. Хитрость в том, что нестандартные элементы эффективнее вводить не в конце жизненного цикла продукта, но в его начале. Это не уменьшает число возможных версий, зато в меньшей степени требует переучивания у существующих пользователей. Кроме того, продукт с интерфейсом, использующим адекватные элементы управления, с большей вероятностью захватит рынок. Важно только серьезно подойти к качеству элементов. Интерфейс не станет автоматически лучше, если стандартные элементы заменить нестандартными. Он станет лучше, если стандартные элементы заменить лучшими.