What is the best way to create a flexible dashboard in a vs2012 VB application?


We are creating a new menu system for an application we have in visual basic using vs2012.

The main screen is a menu across the top, and shortcuts down the left side of the screen, and then a large blank area for the rest of the screen.

In that area we want something like a 'dashboard' with 'gadgets' that will be SSRS charts, reports, graphs, etc.  We want them to be configurable by user.  So the sales manager can configure his user to load sales reports and graphs, and the bookkeeper can configure his to be invoice and collection reports, etc.

I was thinking we could use MDI forms for each, and then load the ones based on the user's configuration??

Ideally the user would be able to minimize, close, or resize them individually - but I'm not sure that is a requirement.

Am I going in the right direction?  Or is there a better way to approach this with the configurable requirements?

Who is Participating?
Jacques Bourgeois (James Burger)Connect With a Mentor PresidentCommented:
Discuss with the people that will be using the stuff. I have seen many instances where people were talking about dashboards because it has became a buzzword, where they never needed to see 2 elements at the same time, or where the type of stuff they wanted to see became so small that it was useless. A TabControl is often more appropriate, and requires only a click to move from one tab to another. It also offer a far better performance, because you can load the data in a tab only if required. On a dashboard, everything has to be fetched even if not needed, and that can take quite a while, depending on the amount of data needed.

I would not go for MDI forms "for each", they would be overkill in such a situation. And if you think of one MDI form that contains all your gadgets, while it offers a lot of versatility in disposing things manually on the screen, it could be a pain to control the location of the gadgets through code. And the title bars of the gadgets could end up taking up a lot of useful display space.

I would try with UserControls instead. A UserControl is a little surface on which you put controls and under which you program their interaction the same way you do it with a Form. But it becomes a Control that you use as any other Control.

A fact that is often overlooked (or unknown) is that a Form is a Control. You can put a form anywhere you put a Control. So your gadgets could each be a Form. More overhead than a UserControl, but it has more events, so in some situations it can be more interesting.

A combination of both is no problem.

Both can be added dynamically to a Form, basically, all you need to do is to record the preferences of each user somewhere such as in the Settings.

You biggest problem will probably be to dispose them in a proper manner on the screen. A 2 gadgets screen needs to display things differently than a 3 gadgets screens. And if each gadget is a different size, the algorithm for gadgets placement can become quite complex.

If all the gadgets are close to the same size, you could use a FlowLayoutPanel to add them to the screen. If they are of very different sizes, maybe a TableLayoutPanel might be more helpful. If your user needs to resize them individually, then SplitContainers, are probably the way to go. They offer 2 panels by default, but since you can put another SplitContainer inside of one of these panels, you can end up with as many panels as you want.
lthamesAuthor Commented:
WOW.  What a lot of great information.

This gives me a lot to think about.

Regarding using the tabs instead . . . .  Each user's commonly used reports are accessed easily from their shortcuts, so they are already at a one-click access.  

The items we have in mind for 'gadgets' on the dashboard are not as much reports as 'at a glance' information that is relevant to each user's job.  Kind of like a status update that tells them if they need to check for further information in the area.

The examples I gave were not good ones . . . . since I talked about reports.  What I really meant was graphs or charts.   The idea though, is that the information would make the user aware that there is either a problem they need to deal with (and provide a link to a more detailed report if needed), or it keeps the user up to date on information they they need to know throughout the day in their job.  

The information about using user controls is really helpful.  I think we will try that first.  

I don't really have any specific follow up questions (since you were VERY thorough) . . . . so I will close this question but may have some follow ups when we actually begin implementation.

Thanks again for your quick and excellent response.
lthamesAuthor Commented:
Extremely helpful!  Thank you!
lthamesAuthor Commented:
I'm not sure if it's too late . .  but I did think of a follow up question.

This isn't a requirement, and I am guessing that this isn't possible.   But one of the things on the wish list is to be able to create new 'gadgets' in the future that can be downloaded and installed without having to download and install a new version of the full application.

Do you know of a way to include user controls or forms into the application at runtime instead of compiled into them?
Jacques Bourgeois (James Burger)PresidentCommented:
You could store the UserControls in a dll instead of inside the application. In that dll, have a Public method that lists the available controls to enable the user to select the ones he want. When new controls are added, distribute a new version of the dll.

The main problem of that approach is that you cannot change the version number of the dll because the application would not use it, so you would have to design a custom version system that could be queried so be able to determine which edition of the dll is actually on a given computer.

One possible benefit of that approach if that you could have special versions of the dll for specific groups of users. That could be a pain to manage however because each dll would need to have the same name and version number, even if they all contain different sets of gadgets.

You could also think of a dll for each gadget or for specific groups of gadgets. A little more complex to work out, but is you provide the dlls along a file that lists the available dlls, you simply have to send any new dll with an updated list when needed. The main problem for this one is that you will not able to reference the dlls at runtime, so you will have to work with the classes in the System.Reflection namespace to dynamically load the required dlls from the information in the list.

Or what I would do if possible, because this is my preferred way of distributing and installing applications that needs to be updated often, specially for in-house applications, is to use ClickOnce as your distribution method. By default, ClickOnce applications check for an update each time they are started and update themselves automatically. Distributing a new version of the application with new gadgets requires only a couple of minutes of your programmer time, and the update is made automatically on the user's computer. There are some limitations of working with ClickOnce, like the fact that you cannot control where the application will be installed on the user computer and that it cannot handle updates of dlls stored in the GAC, but when it is suitable for a given application, it works like a charm.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.