Microstrategy Blog

I’m sure any MicroStrategy consultant who has worked on this kind of stuff before has dealt with…things change. In this case, I started working on the dashboard for my client, and it was going well, I had a basic graph that presented the inventory and sellthrough yada, yada, yada….but, what followed was a barrage of requests not for the dashboard, but new data points. Adding previously uncaptured extracts from the web and other systems so that MicroStrategy could normalize it all in one place and they could see MORE MORE MOREEEEE!!! There’s only two of us right now…and the other guy is a PERL guru…

It’s funny, when I started Orange Box I really thought that most of the business would be in the actual MicroStrategy development…I was wrong. Data points, web scraping for prices, feedback, randomness, then compiling, subdividing and filtering, all with the intent of eventually getting it into a report, we just haven’t reached the intent part yet. Know wat I mean folks? The taste of the dashboard made them data addicts. This is how heroin started…take note.

I’ve created a forum. It’s not substitute for the MicroStrategy Forum, but since I don’t hang out there, and I do hang out here, if anyone has any questions, or is looking for something feedback a little more critical (and humorous if I dare say), then please post here and I’ll respond to as many questions as I can.

Since this dashboard is going to be built around the the ability to select different products, a panel is going to be necessary. When you select the dashboard template that you’re going to be using, the left hand menu is going to have a several options. We’re going to focus on the second option called “Data Structure” right now (the first one being data sets). The “Data Structure” will show the layered flow of your Dashboard as you progress.

MicroStrategy utilizes the right click…a lot. I like this option, though people have complained about the softwares dependence on the interface. All of the menus that are on the right can be right clicked, at which point you see the different options that are available for the specific object that you’ve picked.

In the image below, we’ve selected the properties for the base layer.

I’m going to make a simple gradient background, white to blue, top to bottom. Select the “properties and formatting” option, and under “colors and lines” select gradient. The rest of the walk through is relatively simple to perform, but play around with the color pallete until you find what pleases you, or your client. For me, this is just a back layer, that’s eventually going to be covered with the panel layer, logos, and selectors.

Next, we’re going to insert the panel itself. Under the “Insert” section of your toolbar/ribbon bar/whatever you call it, you’ll see the option to create a panel (outlined in a blue box). Select this and then, much like a standard paint program, draw the box onto the area that you want. If it’s not perfect, that’s not a problem, the right click will always allow you into the menu to measure out the specifics of the margins and the width.

There are a few formatting options that I prefer with the panel stacks. First, I make sure that name the panel properly. In my opinion there are two ways that you name them, either by item_function or function_item. I prefer the first, so that when you’re browsing the items in a menu, they’re grouped by type first. So, in the case of this panel, I’m going to name it “PANEL_MAIN” descriptive enough. Say this was a title of a report instead, I have a tendency to name it “TITLE_REPORT_REVENUE”, then the report that goes with it “REPORT_REVENUE”. The other option is “REVENUE_REPORT” or “REVENUE_REPORT_TITLE”. The difference comes from how you view them as far as design. When I decide that I want to make a formatting change, related to the font of the titles, I want to make sure I can scroll through them relatively quickly, and as a group…instead of trying to find whether or not I added a title to a specific group. Maybe I’m spending too much time of this, but for ease of element browsing, it makes a big difference for me. Things as simple as horizontal lines that I add are much easier to find if I tag them “LINE_BLAH”. Keep in mind, it’s good practice to name the element as soon as you create it, otherwise it’s easy to lose track of all of the various items, and what their use is.

As a general rule, as you can see in the image above, there’s an option for “Show Title Bar”…I hate the title bar. It’s crappy font, crappy colors, and useless in a panel stack. Remove it. You’ll be cool in my book.

I wouldn’t say that it’s commonly overlooked, but I’ve seen it overlooked by some developers…simple and streamlined data sources. There’s basically two ways that this can be achieved: single reports, multiple reports.

Keep in mind as you are creating these reports that you don’t want to design a report that will be used as a data source that contain more that what you need. If you just need the current price of an item on your store front, make sure that your report is built to pull back the current price…not every single price with a view filter for “today”. A lot of the usability and functionality of a Dashboard comes from the amount of time that it takes to run it. Trust me when I say executives don’t like to wait for 5 minutes just so they can see what the inventory level of one product is. Make sure there’s a little “cubing” and every attribute and metric that exists in the report, you’re actually going to be displaying.

As a rule, I like to create reports specifically for dashboards, that way I can work with them from Development to Production, and I know exactly what to expect. I tend to not make these reports visible.
I put them all in a hidden folder, in this case called “Source”, and under folder properties, there’s an option to make it hidden. I don’t want these reports accessible to the general public, unless there’s a specific search, and I don’t want to deal with security issues and user group functionality, so I just avoid dealing with those settings in this case. We’re keeping this higher level, so for clarification purposes, this is a dashboard that is going to be visible by everyone. There are no user or object level security in anything that I’m going to be going here.

Once you’ve selected your data set, the next option is to select what kind of dashboard you actually want to create. MicroStrategy has several templates at your disposal, as seen below.

Four our purposes, we’re starting from scratch. The image above is actually in Desktop…but, the medium I’m going to be doing most of this in is web, simply because it’s easy to flip back and forth in the web environment, and actually see what you’ve created, as it’s meant to be seen. As another note, if you’re on a developer box, and you’re not necessarily sure about your companies IT rules, now is a good time to check.

MicroStrategy works on all of the major browsers, and you’ll see some differences in some of the data as presented in Firefox, IE, and especially Safari. I’m going to be doing my development on IE and Firefox for the most part, so if you’re a Mac shop, or you have weirdos that browse in Safari or Chrome, there’s some extra homework you’re going to have to put into the process.

Next post, I present my sketch/storyboard for what I’m going to be presenting. I’m thinking right now this is going to be a two tabbed report, with a selector on each page. So, conceptually, this means two reports. One is going to be at the “Item Group” level…since my project is going to be cell phones, that group is going to be “Manufacturer”; think Blackberry or Apple. The next report is going to be specific to the Models. I’ll have the data aggregated at the two levels that I care about. I’m going to avoid from getting specifically into what drives the values of the reports (trade secret), and some of the data might be jumbled.

One of the clients that I have through my side gig (Orange Box Tech) has given me permission to document the Dashboard creation I’m going to be doing for him. I know that this is a subject that many are interested in…simply because what Google Analytics tells me so. So what I’m going to be doing over the next few weeks is taking you through the steps that I do when I create a dashboard, from concept to execution, hopefully as granular as I have the patience for, and hopefully with lots of community feedback.

So, the first step, which I can’t really do screen caps for, is to sit down, and in depth figure out from the end user, NOT EXCLUSIVELY JUST THE DATA, what questions they have, and what they’re trying to glean. This doesn’t just mean put all of the data on one screen, but instead, get at the root of the problem that they’re trying to solve. This means a lot of questions…and learning and understanding the application of the business application of the data and not just the data itself.

This is just the basic intro, and the “face of things to come” I suppose.