Dashboards: are they worth even trying to develop?

Yahoo Archive
1
Most of the dashboards I have set up are really simple.
They contain just one query view and a tracker that allows the end user to filter records returned.
The more complicated requests always seem to end up as to reports, forms or raw data sent to other applications.

>> right-click navigate to other objects
And "Copy to Excel"

>> orders, quotes, shipments, etc
and Orders on Hold/Credit Hold

>along with the subpar email notification capabilities.
email does seem like it's overdue for review

--- In vantage@yahoogroups.com, "pbparker" <scrumbus@...> wrote:
>
> The concept of dashboards is excellent, it's just the implementation of them that isn't great. They serve their purposes in our company for easily seeing a grid of data across various tables, and then allowing people to right-click and navigate to other objects (orders, quotes, shipments, etc).
>
> However, I just find the dashboard interface clunky, ugly, limited in overall look/feel capabilities and poor tools to visualize and summarize large sets of data.
>
> I wish they'd completely trash and overhaul the dashboards along with the subpar email notification capabilities. I want HTML based email with proper formatting and links back to objects.
>
> Maybe some year this will happen.
>
> --- In vantage@yahoogroups.com, "chan213419" <chan213419@> wrote:
> >
> > Thanks everyone! It's interesting that I'm getting a wide variety of opinions on them already. From what I gather, it looks like I'll have to continue to get better with them before I 'close the door' on dbds all together. The Web interface is a great idea, but a hard sell if you are working with many clients.
> >
> > I appreciate the time to lay down your 2 cents everyone!
> >
> > Chan
> >
> > --- In vantage@yahoogroups.com, "chan213419" <chan213419@> wrote:
> > >
> > > I am looking for developer opinions on dashboards. Lets face it, if you have ever build a dashboard (dbd) you've undoubtedly run into issues with them once the dbd gets remotely complicated.
> > >
> > > Adding a search button, which should be as easy as adding one to an application, is a pain. Getting the BAQ results to refresh appropriately is a pain. Getting all of the windows to refresh accordingly is a pain, and god forbid you want to update data within a dbd!
> > >
> > > What I'm getting at is if a customer requests a dashboard, what do you normally do? Do you immediately create a new Form without even attempting a dbd? Do you try a dbd first, and if that fails, create a form?
> > >
> >
>
2
I am looking for developer opinions on dashboards. Lets face it, if you have ever build a dashboard (dbd) you've undoubtedly run into issues with them once the dbd gets remotely complicated.

Adding a search button, which should be as easy as adding one to an application, is a pain. Getting the BAQ results to refresh appropriately is a pain. Getting all of the windows to refresh accordingly is a pain, and god forbid you want to update data within a dbd!

What I'm getting at is if a customer requests a dashboard, what do you normally do? Do you immediately create a new Form without even attempting a dbd? Do you try a dbd first, and if that fails, create a form?
3
Dashboards can be a pain. One reason to use them is its something the client might be able to maintain on their own. If you don't get too crazy with what you want to do they work more times than not. That you can do updateable dashboards is sometimes worth the grief.

From time to time I will do a direct progress call to build the dataset which is then shown in an infragistics ultrawingrid which allows nice drill down capability. The direct progress call lets me build the dataset using any set of tables and logic needed including external tables. I use a UD table form as the scaffold, hiding all of its controls including the toolbar to get a blank canvas. Put controls to get the selection criteria, call the progress routine which returns a dataset that is used as the datasource for the grid. Can pass the dataset to Crystal if they want a report and easy to add download to Excel if desired.

Jim Kinneman
Encompass Solutions, Inc

--- In vantage@yahoogroups.com, "chan213419" <chan213419@...> wrote:
>
> I am looking for developer opinions on dashboards. Lets face it, if you have ever build a dashboard (dbd) you've undoubtedly run into issues with them once the dbd gets remotely complicated.
>
> Adding a search button, which should be as easy as adding one to an application, is a pain. Getting the BAQ results to refresh appropriately is a pain. Getting all of the windows to refresh accordingly is a pain, and god forbid you want to update data within a dbd!
>
> What I'm getting at is if a customer requests a dashboard, what do you normally do? Do you immediately create a new Form without even attempting a dbd? Do you try a dbd first, and if that fails, create a form?
>
4
Once you learn the "Tricks", they aren't so bad. The refresh thing is the only major pain for us. But the convenience of being able to see a wide variety of information all in one place is wonderful. We have Sales Graphs & Charts that are fabulous for info at a glance. Our business is very fluid and tracking things would take hours if we didn't have the overall views. And like Jim said the updateable dashboards are an awesome time saver. Add a service connect on the end of it or a button or two of custom code and then the fun really starts. So YES I think they are WAY worth developing and the time it takes to get good at them is time well spent.

Brenda

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of jckinneman
Sent: Monday, July 08, 2013 7:03 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Dashboards: are they worth even trying to develop?



Dashboards can be a pain. One reason to use them is its something the client might be able to maintain on their own. If you don't get too crazy with what you want to do they work more times than not. That you can do updateable dashboards is sometimes worth the grief.

From time to time I will do a direct progress call to build the dataset which is then shown in an infragistics ultrawingrid which allows nice drill down capability. The direct progress call lets me build the dataset using any set of tables and logic needed including external tables. I use a UD table form as the scaffold, hiding all of its controls including the toolbar to get a blank canvas. Put controls to get the selection criteria, call the progress routine which returns a dataset that is used as the datasource for the grid. Can pass the dataset to Crystal if they want a report and easy to add download to Excel if desired.

Jim Kinneman
Encompass Solutions, Inc

--- In vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com>, "chan213419" <chan213419@...<mailto:chan213419@...>> wrote:
>
> I am looking for developer opinions on dashboards. Lets face it, if you have ever build a dashboard (dbd) you've undoubtedly run into issues with them once the dbd gets remotely complicated.
>
> Adding a search button, which should be as easy as adding one to an application, is a pain. Getting the BAQ results to refresh appropriately is a pain. Getting all of the windows to refresh accordingly is a pain, and god forbid you want to update data within a dbd!
>
> What I'm getting at is if a customer requests a dashboard, what do you normally do? Do you immediately create a new Form without even attempting a dbd? Do you try a dbd first, and if that fails, create a form?
>



[Non-text portions of this message have been removed]
5
I agree with you. I've elected to stay away from Epicor dashboards. I have
set up a web server configured for ASP and I create all of my "dashboards"
in a nice easy web interface using ASPRunnerPro. It uses ODBC at the web
server level (no need to have ODBC set up on every client). Within a matter
of *minutes* after creating your query, you can have a professional looking
grid-like dashboard with search and sort capabilities as well as other
functionality all in a familiar web page that can be launched directly from
the Epicor menu.



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
chan213419
Sent: Monday, July 08, 2013 6:43 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Dashboards: are they worth even trying to develop?





I am looking for developer opinions on dashboards. Lets face it, if you have
ever build a dashboard (dbd) you've undoubtedly run into issues with them
once the dbd gets remotely complicated.

Adding a search button, which should be as easy as adding one to an
application, is a pain. Getting the BAQ results to refresh appropriately is
a pain. Getting all of the windows to refresh accordingly is a pain, and god
forbid you want to update data within a dbd!

What I'm getting at is if a customer requests a dashboard, what do you
normally do? Do you immediately create a new Form without even attempting a
dbd? Do you try a dbd first, and if that fails, create a form?





[Non-text portions of this message have been removed]
6
Thanks everyone! It's interesting that I'm getting a wide variety of opinions on them already. From what I gather, it looks like I'll have to continue to get better with them before I 'close the door' on dbds all together. The Web interface is a great idea, but a hard sell if you are working with many clients.

I appreciate the time to lay down your 2 cents everyone!

Chan

--- In vantage@yahoogroups.com, "chan213419" <chan213419@...> wrote:
>
> I am looking for developer opinions on dashboards. Lets face it, if you have ever build a dashboard (dbd) you've undoubtedly run into issues with them once the dbd gets remotely complicated.
>
> Adding a search button, which should be as easy as adding one to an application, is a pain. Getting the BAQ results to refresh appropriately is a pain. Getting all of the windows to refresh accordingly is a pain, and god forbid you want to update data within a dbd!
>
> What I'm getting at is if a customer requests a dashboard, what do you normally do? Do you immediately create a new Form without even attempting a dbd? Do you try a dbd first, and if that fails, create a form?
>
7
The concept of dashboards is excellent, it's just the implementation of them that isn't great. They serve their purposes in our company for easily seeing a grid of data across various tables, and then allowing people to right-click and navigate to other objects (orders, quotes, shipments, etc).

However, I just find the dashboard interface clunky, ugly, limited in overall look/feel capabilities and poor tools to visualize and summarize large sets of data.

I wish they'd completely trash and overhaul the dashboards along with the subpar email notification capabilities. I want HTML based email with proper formatting and links back to objects.

Maybe some year this will happen.

--- In vantage@yahoogroups.com, "chan213419" <chan213419@...> wrote:
>
> Thanks everyone! It's interesting that I'm getting a wide variety of opinions on them already. From what I gather, it looks like I'll have to continue to get better with them before I 'close the door' on dbds all together. The Web interface is a great idea, but a hard sell if you are working with many clients.
>
> I appreciate the time to lay down your 2 cents everyone!
>
> Chan
>
> --- In vantage@yahoogroups.com, "chan213419" <chan213419@> wrote:
> >
> > I am looking for developer opinions on dashboards. Lets face it, if you have ever build a dashboard (dbd) you've undoubtedly run into issues with them once the dbd gets remotely complicated.
> >
> > Adding a search button, which should be as easy as adding one to an application, is a pain. Getting the BAQ results to refresh appropriately is a pain. Getting all of the windows to refresh accordingly is a pain, and god forbid you want to update data within a dbd!
> >
> > What I'm getting at is if a customer requests a dashboard, what do you normally do? Do you immediately create a new Form without even attempting a dbd? Do you try a dbd first, and if that fails, create a form?
> >
>