это, безусловно, можно использовать.
Для простых понятий это достаточно. Я обнаружил, что часто пытаюсь заставить пользователя ввести то, что он не понимает. Иногда это были данные, которые я не понимаю.
Тогда я чувствую, что ДЕЙСТВИТЕЛЬНО ВАЖНО получить хорошее представление о том, что именно представляют ваши данные, а затем вместо того, чтобы запрашивать таблицу чисел, найти способ проинформировать своего пользователя о том, что он вводит, одновременно с входом. это.
Например, в очень простом примере, который вы приводите (представьте, что он сложный), вы могли бы фактически отобразить на экране изображение коробки и данные. По мере ввода данных поле может немного сместиться или заметно изменить свой размер.
Затем вы могли бы продвинуть это, позволив им перетаскивать края поля и заставить перетаскивание обновлять поля.
Хотя это слишком простой пример, чтобы оправдать такого рода усилия, я добился большого успеха - например, установил схему, в которой вы должны содержать DS0 в группе DS0 внутри DS1 или T1, которая находится в связке T1 в OC-3, который находится на одном из 3 каналов в оптоволоконной петле.
На самом деле все было гораздо сложнее, и 10 инженерам потребовалось 2 дня, чтобы правильно документировать, как только они поняли, о чем я спрашиваю. В какой-то момент у нас было 4 доски, полные перестановок, а затем мы реорганизовали их в один (очень переполненный) лист бумаги.
Как только я смог это понять, я сделал для него БОЛЬШОЙ интерфейс.
Кроме того, эта бумага сама стала маркетинговым документом - они никогда не описывали, что на самом деле делает их коробка (и это именно то, что сказал их менеджер по маркетингу, когда он смотрел на бумагу).
Итак, более короткая версия на вынос: для всего, что не очевидно, постарайтесь полностью проанализировать и понять бизнес-проблему, стоящую за данными, которые вы предоставляете / запрашиваете у клиента. Когда вы это сделаете, выясните, что именно вызвало прорыв, и превратите его в графический интерфейс.