Как сделать хороший интерфейс отчетности - PullRequest
3 голосов
/ 23 августа 2010

У меня есть тонна связанных данных, вращающихся вокруг школы, учеников, учителей, классов, мест и т. Д. И т. Д.

Я столкнулся с проблемой, поставленной четвертым моим клиентом;они хотят иметь отчеты по всему .Это означает, что они хотят иметь возможность перекрестной ссылки на точки данных в любом случае, и я думаю мне просто не хватает симпатичного построителя запросов.: /

Этот вопрос стека направлен на сбор мнений о том, как красиво структурировать интерфейс отчетности.

Любые предложения, ссылки, примеры, плагины jQ и т. Д. Были бы удивительными.

Спасибо!

Ответы [ 3 ]

6 голосов
/ 23 августа 2010

Мне кажется, что построитель запросов Trac вполне приемлем для того, для чего он предназначен.

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

4 голосов
/ 24 августа 2010

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

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

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

1 голос
/ 24 августа 2010

Во-первых, я могу поддержать только другие голоса: проработайте с клиентами то, что им действительно нужно.Хороший аргумент: «Я могу это сделать, но это будет стоить вам X тысяч долларов, каждому пользователю потребуется Y часов обучения, а для его поддержки вам потребуется разработчик на 100 000 тысяч долларов в год».

(К сожалению, большинство клиентов в этот момент предпочитают выбирать парня, который говорит: «Да, можно сделать дешевле!»)


Только второй, и только если клиент говорит: «Да, нам все нужно»:

Хорошо работает прогрессивная фильтрация представления списка / сетки.Вместо того чтобы строить SQL-запрос, а затем запускать его, пользователь может напрямую работать с результатами: например, щелкнув правой кнопкой мыши ячейку и выбрав «ограничение на это значение», можно добавить ограничение WHERE colN = <constant>.

Вы можетегенерировать предложения для столбцов из вызовов SELECT DISTINCT - если он возвращает меньше, скажем, 20 значений, вы можете предложить флажки для комбинации ИЛИ возможных значений.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...