Добавление рендеринга текста / поля ввода в Access для удобства взаимодействия с пользователем

Question

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

Является ли размещение элемента управления веб-браузером HTML / ms очевидной платформой для создания сценариев вызовов?

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

Думая о сложностях построения представления менеджера, которое переводит предполагаемый сценарий в HTML / Javascript, я создаю свой собственный простой язык описания документов с тегами для тех функций, которые мне нужны, и «механизм рендеринга» в VBA - решение, которое вы могли бы рассмотреть для этого?

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

Какие у вас есть предложения по реализации этого?

Answer 1

Фактические требования к пользовательскому интерфейсу для пользовательской части вашей системы кажутся довольно минимальными (задать вопрос, получить ответ, перейти к «следующему» вопросу). Я не думаю, что есть какая-то «очевидная» платформа для использования. Как всегда, система на основе браузера облегчает географически распределенным пользователям использование централизованной системы, но, вероятно, будет стоить дороже с точки зрения разработки.

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

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

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

Answer 2

Существует довольно много систем опроса и вопросов (создания тестов), встроенных в систему доступа. Я не вижу никаких реальных проблем в использовании доступа в отличие от какой-либо системы.

Преимущество HTML или текстовых систем в том, что они, как правило, поддерживают более динамичный тип экранов.

С другой стороны, для вопросов и отображения текста при доступе большой трюк состоит в том, чтобы поместить элемент формы в форму, а затем во время выполнения просто «установить», какая форма должна отображаться в этом элементе форма (правильность исходного объекта). Фактически, в Access 2010, элемент управления nav делает именно это, и он отображает формы в виде подформы.

Также для Access 2010 мы можем создавать веб-приложения. В этом видео вы видите, что на полпути я переключаюсь на запуск приложения в стандартном браузере.

http://www.youtube.com/watch?v=AU4mH0jPntI

Однако вышесказанное мало что значит здесь, так как я не уверен, что вы подразумеваете под каким-то типом движка рендеринга. Каждый вопрос + ответ будет просто текстом на экране, и, таким образом, вы можете просто отобразить / изменить этот текст, изменив базовый reocrdset.

И, если вам нужен хороший форматированный текст с различными шрифтами и т. Д., То в Access 2007 теперь есть поддержка расширенного текста (текста разметки). Поэтому я не думаю, что вам действительно нужно динамическое создание экрана. Между изменением источника записи для отображения любого текста, который вы хотите, и возможностью отображения различных форм (шаблонов) на лету путем изменения «исходного объекта» подформ, вы можете легко изменить часть своего экрана, чтобы отобразить другой текст коробки с очень маленьким кодом.

С другой стороны, если у вас есть все инструменты .net и вы хотите создать приложение на основе браузера, вы можете это сделать. Я полагаю, вы также можете подождать, пока Access 2010 создаст приложение для браузера.

Если вы хотите сохранить простоту, то доступ - отличный выбор. Если вам нужно приложение на основе браузера, то у меня нет доступа к выбору здесь.

Answer 3

Я склонен согласиться с тем, что веб-интерфейс является оптимальным для чего-то подобного, однако WPF также является отличной альтернативой со многими преимуществами веб-интерфейса и мощью настольного приложения. Как веб, так и WPF дадут вам значительный контроль над тем, как выглядит и чувствует приложение, используя все возможности .NET Framework. Одним из недостатков веб-приложения является то, что у вас меньше возможностей напрямую взаимодействовать с телефонной системой, но я уверен, что эту проблему можно довольно легко решить с помощью некоторого AJAX. Большим плюсом для опции веб-платформы является то, что у вас будет доступ к множеству интерактивных библиотек на стороне клиента, таких как jQuery, которые позволят вам более легко полировать приложение; с WPF вы, вероятно, будете платить за множество необычных элементов управления пользовательским интерфейсом.