Хорошие примеры GUI разрабатывают для ориентированного на бизнес, тяжелого ввода данных (CRUD) [закрытые] приложения
Вот ваш упрощенный код с некоторыми примерами данных (вот как вы должны задать вопрос здесь).
library(raster)
f <- system.file("external/rlogo.grd", package="raster")
Landsat <- raster(f, 1)
AVHRR <- raster(f, 3)
error <- Landsat - AVHRR
#You can do
#[1] 25.52578
#mae <- mean(abs(values(error)))
#mae
#[1] 15.28597
Но безопасным для памяти способом было бы сделать
cellStats(error, "rms")
#[1] 25.52742
cellStats(abs(error), "mean")
#[1] 15.28597
Обратите внимание, что я возвращаю единственное «глобальное» значение, тогда как ваши функции возвращают растр - предполагая, что возможно Вы хотите "локальную" статистику ошибок. Но это имеет смысл, только если у вас есть многослойные растровые данные. В вашем примере вы не делаете; но см. ниже для местного примера.
Так в чем причина вашей ошибки? Вы делаете
#actual <- c(Landsat)
#predicted <- c(AVHRR)
#error <- actual - predicted
Или с нашими примерами данных
error <- c(Landsat) - c(AVHRR)
#Error in c(Landsat) - c(AVHRR) : non-numeric argument to binary operator
Это потому, что c(Landsat) создает list и вы не можете вычесть два списка.
class(c(Landsat))
#[1] "list"
Вы можете сделать
error <- c(Landsat)[[1]] - c(AVHRR)[[1]]
(но зачем вам)
Если вы хотите «локальные» значения, вы можете сделать что-то вроде ниже:
library(raster)
f <- system.file("external/rlogo.grd", package="raster")
Landsat <- stack(f)
AVHRR <- Landsat[[3:1]]
error <- Landsat - AVHRR
mae <- mean(abs(error))
plot(mae)
8 ответов
У меня нет примеров, на которые можно было бы указать. По правде говоря, многие из этих экранов может быть трудно найти в Интернете по той простой причине, что большинство из них имеют тенденцию быть «уродливыми». Такие экраны редко бывают красивыми.
Я могу дать несколько советов из долгой истории работы с этими вещами.
Последовательность. Сделайте так, чтобы все "работало одинаково" и работало одинаково все время. По сути, вы должны иметь возможность вводить данные, глядя на форму, а не на экран. Все эти вспышки, промежуточные итоги и цвета хороши после ввода формы, но не во время самого ввода. Там вам в основном нужны звуковые оповещения, чтобы они знали, что «что-то не так». Классический сценарий «тик-тик-тик-тик-бип-бип-бип-бип», когда пользователь обнаруживает, что он ввел неправильное поле на 4 поля назад. Пользователи не совсем слепы, но они не будут смотреть на ваш экран. Данные находятся в форме.
Лучше работать модально и ОСТАНОВИТЬ ИХ на случай ОШИБОК, чем позволить им продолжать работу. Для больших форм сканирование всей этой информации и поиск ошибок постфактум очень сложно. Остановите их, когда они ошибаются, чтобы они могли исправить это и двигаться вперед, а не возвращаться, чтобы исправить это в конце. Чем больше бизнес-правил, проверок и правоприменения вы укажете в форме, тем лучше. Всплывающие окна, предупреждения, сборщики, если это требует их внимания, модальный модальный модальный. Здесь с глиной не работают. Они не пишут великий американский роман и не моделируют мировую экономику.
Подведите итоги выборочной проверки. Например, введя заказ, они должны иметь возможность смотреть на общую сумму заказа и количество позиций, чтобы увидеть, "правильно ли" они получили заказ, как своего рода контрольную сумму, вместо того, чтобы сканировать свое поле ввода за полем. У большинства рабочих процессов есть неизбежная фаза перекрестной проверки, на которой они проходят ввод для проверки данных, но это должно быть после «необработанного ввода» данных. Люди работают быстрее, когда они находятся в режиме «массового ввода», а не точечно проверяют каждого, каждый раз, когда они его вводят. Это нарушает их ритм. Упростите обнаружение и исправление исключений после выполнения базовой проверки и ввода ключей. Если некоторые поля важнее других (и вы знаете, какие именно), их визуальное выделение на экране И на бумажной форме творит чудеса.
Если формы и тому подобное спроектированы хорошо (как компьютерные, так и бумажные формы ввода), ошибки должно быть трудно вводить (например, неправильный покупатель, неправильный элемент и т. Д.). Возможно, в некоторых примечаниях или специальных инструкциях есть опечатка, но не везде. Если они неправильно наберут предмет или количество, скорее всего, заказ не будет суммирован должным образом, поэтому простая контрольная сумма поможет им его уловить.
Возвращаясь к «согласованности», убедитесь, что такие вещи, как сборщики и тому подобное, работают с то же самое. Постарайтесь свести количество специальных функций к минимуму, так как это упрощает обучение и позволяет пользователям просто «плавно переходить» к своей работе.
Сочетания клавиш и навигация - это требование, а не вариант. Настоящей проблемой здесь могут быть подробные области (например, структуры таблиц). Вам может понадобиться ярлык для входа и выхода из таблиц. Вы, возможно, видели множество примеров, когда вы можете "Tab" войти в таблицу, но не можете вернуться назад. Используйте специальную клавишу «мета-вкладка» для перехода в разделы и выхода из них. Требовать мыши для перехода из раздела - нет.
Используйте одну горячую клавишу для сборщиков. В идеале им не придется использовать их слишком часто. Возможно, для поиска клиентов большинство других кодов они неизбежно запоминают, или они будут введены в форму ввода. Сделайте сборщики фильтруемыми.
Прокрутка - дьявол. Прокрутка - зло. Нет прокрутки! Листание лучше, чем прокрутка, потому что «поля не перемещаются», они всегда «в одном месте» на экране. Как часто вы «прокручивали» и приходилось искать, чтобы забрать » если можно запросить почти все поля, это позволяет им делать это, не задумываясь о том, что им понадобится, а что нет. В Informix 4GL была впечатляющая система QBE (
> 01.04.2009для дат после 1 апреля 2009 г.,12345 | 23456для кодов товаров 12345 или 23456). Хорошее выражение QBE, скорее всего, не будет проверяться в типичном поле, это особый случай. (Вот почему сегодня вы редко видите QBE, это требует слишком много работы - но это ОН так приятно.)Помните, пользователи не знают ПОЧЕМУ или КАК они делают что-то, они знают только ЧТО делать. Они знают «когда я хочу сделать A, я нажимаю клавишу Y » они не знают, ПОЧЕМУ это Y, где Y находится, клавиши X и Z могут делать похожие вещи к А, потому что они ' повторно сгруппированы вместе. Нет, они не знают вашу таксономию команд. Они не знают ваших абстракций. Они знают, что нужно сделать A, нажать Y . Хотите выделить слово жирным? Наберите Ctrl - B . Возможно, Ctrl - I выделение слова курсивом очевидно для вас из-за мнемоники, но не для большинства пользователей. Возможно, Ctrl - B и Ctrl - I находятся в меню
Format, красиво сгруппированные. Неважно. Ctrl - B == Жирный, как мне набрать курсив?
Обратной стороной этих интерфейсов является обучение. Они проходят обучение, чтобы их можно было использовать. Но, по правде говоря, для любого достаточно сложного бизнеса пользователю в любом случае потребуется обучение гораздо большему, чем просто процесс ввода. Экран ввода не будет обучать их бизнес-политикам, бизнес-правилам и т. Д. Вы можете применить их в приложении, но пользователю все равно нужно будет узнать их самостоятельно.
Но это нормально, потому что в конечном итоге это просто более эффективно. Здесь игра эффективно получает данные от пользователя и единообразно представляет их им. Я не буду говорить «логический» способ, поскольку, хотя логика может быть логикой, это может быть не логика пользователя. Итак, вы можете быть логичны, если хотите, называйте это как хотите, но будьте последовательны для своих пользователей.
Еще один анекдот, мы использовали для возврата 10 ключевых данных. Обычно это были просто числовые списки, такие как код товара и количество. Для наших целей проще, чтобы пользователи вводили эти данные дважды подряд, чем что-либо еще. Улавливает опечатки, перестановки и т. Д. В сочетании с контрольными суммами пакета значительно ускоряет процесс ввода. Эти ребята смотрели на экраны только тогда, когда они начали, когда они закончили, и если они получили ошибку.
Наконец, несмотря ни на что, ваши экраны и процедуры БУДУТ изменяться. Какую бы форму вы ни использовали в этом году, она изменится в следующем году. Это просто реальность, так что, к вашему сведению, будьте к этому готовы.
Удачи в вашем проекте.
Я фанат пакета http://www.37signals.com/ . Я считаю, что их формы и графический интерфейс хорошо продуманы.
Вы знаете, есть Openerp , что вы можете получить программу, исходный код, документацию бесплатно.
ps: эта ссылка подходит мне, если вы не можете ее открыть, ищите openerp в google.
Вот примеры того, чего не следует делать !: Худший пользовательский интерфейс, который вы когда-либо использовали
Я использовал много - но трудно вспомнить какое-либо конкретное приложение, так как действительно хорошие пользовательские интерфейсы почти легко забываются.
Я могу вспомнить множество плохих. Любой, кто беспокоится о лотосовых нотах, очевидно, никогда не использовал приложения на основе форм SAP или ORACLE.
Для максимальной эффективности я бы посоветовал вам взглянуть на старую программу бронирования авиабилетов SABRE. Две строки текста без пробелов и других знаков препинания.
Первая строка - информация о рейсе. Вторая строка - детали платежа. Примерно так можно было бы забронировать и оплатить рейс:
123109BA176Y
276.00GBPAM1122123412341234
турагенты пристрастились к этому и в течение многих лет отказывались принимать супер-пупер окна Замена GUI вместо этого запускает эмулятор терминала с зеленым экраном. Я думаю, он умер только тогда, когда авиакомпании перешли на трехбуквенные коды и четырехзначные номера рейсов.
Я считаю, что сайт Dashboard Spy является одним из лучших для вдохновения.
Может быть, вам стоит рассмотреть подход 37signals Getting Real , учитывая, что ваши приложения кажутся сложными. Getting Real поможет вам разработать эффективный и полезный интерфейс, который сделает пользователей счастливыми.
Вам действительно стоит посетить Зал стыда интерфейсов , где вы найдете не только самые причудливые графические интерфейсы, когда-либо придуманные, но и возможные решения проблем юзабилити, которые они создают. .