Подтвердить что ты не робот

Почему программирование пользовательского интерфейса так много времени, и что вы можете сделать, чтобы смягчить это?

По моему опыту, программирование пользовательского интерфейса очень трудоемко, дорого (дизайнеры, графика и т.д.) и подвержено ошибкам - и по определению ошибки или сбои пользовательского интерфейса очень заметны.

Что вы делаете для смягчения этой проблемы?

Знаете ли вы о решении, которое может автоматически конвертировать API в пользовательский интерфейс (желательно веб-интерфейс пользователя?).

Возможно, что-то вроде консоли JMX

  • с хорошими настройками по умолчанию
  • может быть изменен с помощью css
  • где поля могут быть настроены как радиокнопка или выпадающий список, текстовое поле или текстовая область и т.д.
  • локализуемым
  • и т.д.
4b9b3361

Ответ 1

Разработка пользовательского интерфейса занимает много времени и подвержена ошибкам, поскольку включает design. Не только визуальный или звуковой дизайн, но, что более важно, дизайн взаимодействия. Хороший API всегда нейтрален в нейтральной модели взаимодействия, что означает минимальные ограничения на фактический рабочий процесс, локализацию и представление информации. Основным драйвером этого является инкапсуляция и повторное использование кода.

В результате невозможно получить достаточную информацию только от API для создания хорошего пользовательского интерфейса, адаптированного к конкретному случаю использования API.

Однако существуют генераторы UI, которые обычно создают экраны CRUD на основе данного API. Излишне говорить, что такой сгенерированный пользовательский интерфейс не очень хорошо подходит для частых пользователей с требованиями к повышению эффективности пользовательского интерфейса, и их особенно легко изучить в случае более крупной системы, поскольку они не очень хорошо обмениваются изображением системы или последовательности взаимодействия.

Требуется много усилий для создания хорошего пользовательского интерфейса, поскольку оно должно быть спроектировано в соответствии с конкретными потребностями пользователя, а не из-за какой-то мирской задачи конвертации API-UI, которая может быть полностью автоматизирована.

Чтобы ускорить процесс создания пользовательского интерфейса и снизить риски, можно предложить либо вовлечение профессионалов пользовательского интерфейса, либо получение дополнительной информации о работе самостоятельно. К сожалению, нет ярлыка или волшебной палочки, так сказать, что будет создавать качественный пользовательский интерфейс, основанный исключительно и только на API без большого количества дополнительной информации и анализа.

Пожалуйста, также замечайте отличный вопрос: "Почему хороший дизайн пользовательского интерфейса так сложно для некоторых разработчиков?" который имеет некоторые очень проницательные и ценные ответы, в частности:

Ответ 2

Я не верю, что программирование пользовательского интерфейса занимает больше времени, чем любое другое программирование, и это не является более склонным к ошибкам. Однако ошибки в пользовательском интерфейсе часто более очевидны. Проявление ошибки в компиляторе часто намного сложнее.

Одно явное различие между программированием пользовательского интерфейса заключается в том, что у вас есть человек на другом конце, вместо другой программы, что очень часто бывает при написании компиляторов, парсеров протоколов, отладчиков и другого кода, который ведет переговоры с другими программ и компьютеров. Это означает, что сущность, с которой вы общаетесь, не очень хорошо указана и может вести себя очень неустойчиво.

EDIT: "непредсказуемый", вероятно, является более подходящим термином./Еспер

Ваш вопрос о преобразовании API в пользовательский интерфейс просто не имеет смысла для меня. О чем ты говоришь?

Ответ 3

Похоже, вы ищете архитектурный образец "Обнаженные объекты". Доступны различные реализации.

http://en.wikipedia.org/wiki/Naked_objects

Ответ 4

Я не предлагаю решение, но я попытаюсь ответить на вопрос почему.

Поэтому я не говорю для всех, но для меня, по крайней мере, я считаю, что одна причина заключается в том, что программисты склонны концентрироваться на функциональности больше, чем на юзабилити, и они, как правило, не слишком артистичны. Я думаю, что они просто имеют разные типы творчества. Я нахожу, что мне требуется много времени, чтобы создать правильную графику по сравнению с тем, как долго мне требуется писать код (хотя, по большей части, я не делал проектов со слишком большим количеством графических требований).

Ответ 5

Автоматическое создание пользовательских интерфейсов может быть возможно до некоторой степени, поскольку оно может генерировать элементы управления для требуемого ввода и вывода данных. Но дизайн пользовательского интерфейса гораздо более востребован, чем просто установка необходимых элементов управления на экран. Чтобы создать удобный пользовательский интерфейс, необходимо объединить знания из таких дисциплин, как графический дизайн, эргономика, психология и т.д. Существует причина, по которой человеко-компьютерное взаимодействие становится самостоятельной дисциплиной: его нетривиально для создания достойного пользовательского интерфейса.

Таким образом, я не думаю, что существует реальное решение вашей проблемы. Дизайн пользовательского интерфейса - сложная задача, которая просто требует времени для правильной работы. Единственная область, где относительно легко выиграть некоторое время, - это инструмент: если у вас есть мощные инструменты для реализации дизайна пользовательского интерфейса, вам не нужно вручную указывать каждый пиксель пользовательского интерфейса.

Ответ 6

Вы абсолютно правы, когда говорите, что пользовательский интерфейс занимает много времени, дорого и подвержен ошибкам!

Отличный компромисс, который я нашел, выглядит следующим образом.

Я понял, что многие данные (если не большинство) могут быть представлены с использованием простой таблицы (например, JTable), а не постоянно пытаться создавать пользовательские панели и привлекательные графические интерфейсы. Сначала это не кажется очевидным, но оно вполне прилично, полезно и визуально привлекательно.

Почему так быстро? Поскольку я смог создать многоразовую структуру, которая может принять коллекцию конкретных моделей и без особых усилий может отобразить все эти модели в таблице. Так много повторного использования кода, его невероятное.

Добавив панель инструментов над окном, моя инфраструктура может добавлять, удалять или редактировать записи в таблице. Используя полную мощность JTables, я могу скрыть (путем фильтрации) и отсортировать по мере необходимости путем расширения различных классов (но только если/когда это необходимо).

Я нахожу, что каждый раз, когда я хочу отображать и управлять новыми моделями, я многократно использую много кода. Я широко использую значки (за столбец, строки или ячейки и т.д.), Чтобы украсить экраны. Я использую большие значки в качестве заголовка окна, чтобы каждый экран "казался" другим и привлекательным, и он всегда выглядит как новые и разные экраны, но всегда остается одним и тем же кодом.

Вначале потребовалось много работы и усилий, чтобы сделать основу, но теперь она окупилась большим временем.

Я могу написать графический интерфейс для совершенно нового приложения с 30-50 различными моделями, состоящими из множества экранов за долю времени, затрачивая меня на использование "пользовательского интерфейса".

Я бы рекомендовал вам оценить и изучить этот подход!

Ответ 7

если вы уже знаете или можете научиться использовать Ruby on Rails, ActiveScaffold отлично подходит для этого.

Ответ 8

Одна из причин заключается в том, что у нас нет хорошо разработанной модели для UTDD - разработки, разработанной для пользователей. Я также не видел много хороших примеров сопоставления пользовательских историй с модульными тестами. Почему, например, так мало учебников обсуждают "Истории пользователей"?

Ответ 10

Это сложно, потому что большинство пользователей/клиентов глупые и не могут думать прямо!:) Это требует много времени, потому что пользовательские интерфейсы/дизайнеры настолько обсессивно-компульсивны!:)