Converting year weeks to continuous without gaps in Power BI graph - scroll

I have weekly sales data from 201601-201835 and i have to create a graph to see the trend. Since the data is categorical, a scroll bar is appearing on the graph. I want to view the complete graph at once.
I tried converting the data to continuous, but there is a gap in the graph as there is no data from 201653 to 201699 and hence the graph is wrong.
Is there a way of viewing the complete data without a scroll bar?

I would add summary fields to the Axis above the Week, e.g. Year, Month, Quarter. You will probably need a reference table for your weeks or some fancy calculations.
With those fields in place, you can expand or drill into the levels before getting down to the Week level. As the higher levels are Categorical and have fewer categories, you are less likely to see scroll bars.
A side benefit is the user has more control e.g. they can drill down on just a section of the weeks, e.g. for one year.

Related

Foundry-workshop : sorting capabilities

I build a chart with 2 layers in Workshop, the only difference is the date bucket. As far as segmentation is the same, I would like each layer being displayed with the same color.
In the chart above, you'll see 2 series: one to display the monthly evolution of a property, the second one to display the yearly average. Each series is segmented by the same object (listed in the table above, coming from an hidden filter). This is achieves by defining 2 layers, with exactly the same definition, except the X-axis: the date is bucked either monthly or yearly. The property is calculated on a monthly basis, so the monthly average bucket displays the input value, and the second chart dynamically calculates the yearly average.
The main issue is that the 2 blue lines are not related to the same object.
I also would like, as far as possible, to have only one legend, instead of one per layer. Currently, my workaround is to display in one case the code, in the second one the description.
Maybe I missed something, but I did not find any way to define precisely the chart colors: am I wrong?
Thus, I was wondering if there was any way to sort input data. The filter is based on the object's primary key, is is possible to sort the queryset accordingly ? Maybe the segmentation would be displayed in the same order and the colors match this order.
Or is there any other way to proceed?
The answer to the title's question is quite easy: actually, the segmentation is not exactly the same. In the first layer, the segmentation is based on a code, the second one on the object's name. Thus, the order is slightly different.
Then solution is: use exactly the same segmentation.
I still wonder how to manage the display: view the legend for only one layer, choose lines' colors... But it looks like it's another subject and I'll probably open a new topic.

How to create visualization using ratio of fields

I have a data set similar to the table below (simplified for brevity)
I need to calculate the total spend per conversion per team for every month, with ability to plot this as time based line chart being an additional nicety. The total spend is equal to the sum of Phone Expenditure, Travel allowance & Misc. Allowance, this can be a calculated field.
I cannot add a calculated field for the ratio, as for some sales person, the number of conversion can be 0 for a given month. So, averaging over team is not option. How can I go about this?
Thanks for help and suggestions in advance!
I've discussed the question with the Harish offline. I've learned that he is trying to calculate ratio per group, not per row.
To perform calculations per group, users can add calculated fields inside a QuickSight analysis and use level aware aggregation expressions. (Note that level aware aggregations can only be used in an analysis, not in the data prep view). Here is a link to the documentation about level aware aggregations if you want to learn more about this area https://docs.aws.amazon.com/quicksight/latest/user/level-aware-aggregations.html

Display time series of open issues in Kibana

I want to have a time series visualization showing the amount of existing open issues per, e.g., week, whose range can be adjusted with the time picker.
Say I have an index with issues, which has openDate, closeDate, and a list of other fields like, team, department that I would use to filter the issues shown in the visualization.
In Kibana it would be trivial to show issues opened or closed each week, as counting events is trivial.
However, showing open issues is counting states. It is not rocket science, if you have a timeStart and timeEnd, the number of open issues is given by the filter:
openDate < timeEnd and (not exists(closeDate) or closeDate>timeStart)
Is there any way of solving this with Kibana? I imagine that it is possible to write such a query with ES, but how to link it to the time picker? how to use the values it return in a visualization, etc....

Algorithm to find areas of support in a candlestick chart

I am in the process of designing an algorithm that will calculate regions in a candlestick chart where strong areas of support exist. An "area of support" in this case is defined as an area in the chart where the price of a stock rises by a large amount in a short period of time. (Please see the diagram below, the blue dots represent these strong areas of support)
The data I am working with is a list of over 6000 TOHLC (timestamp, open price, high price, low price, close price) values. For example, the first entry in this list of data is:
[1555286400, 83.7, 84.63, 83.7, 84.27]
The way I have structured the algorithm to work is as follows:
1.) The list of 6000+ TOHLC values are split into sub-lists of 30 TOHLC values (30 is a number that I arbitrarily chose). The lowest low price (LLP) is then obtained from each of these sub-lists. The purpose behind using this method is to find areas in the chart where prices dip.
2.) The next step is to determine how high the price rose from each of these lows. For this, I take the next 30 candlestick values from the low and determine what the highest high price (HHP) is. Then, if HHP / LLP >= 1.03, the low price is accepted, otherwise it is discarded. Again, 1.03 is a value that I arbitrarily chose, by analysing the stock chart manually and determining how much the price rose on average from these lows.
The blue dots in the chart above represent the accepted areas of support by the algorithm. It appears to be working well, in terms of that I am trying to achieve.
So the question I have is: does anyone have any improvements they can suggest for this algorithm, or point out any faults in it?
Thanks!
I may have understood wrong, however, from your explanation it seems like you are doing your calculation in separate 30-ish sub lists and then combining them together.
So, what if the LLP is the 30th element of sublist N and HHP is 1st element of sublist N+1 ? If you have taken that into account, then it's fine.
If you haven't taken that into account, I would suggest doing a moving-window type of approach in reading those data. So, you would start from 0th element of 6000+ TOHLC and start with a window size of 30 and slide it 1 by 1. This way, you won't miss any values.
Some of the selected blue dots have higher dip than others. Why is that? I would separate them into another classifier. If you will store them into an object, store the dip rate as well.
Floating point numbers are not suggested in finance. If possible, I'd use a different approach and perhaps classifier, solely using integers. It may not bother you or your project as of now, but surely, it will begin to create false results when the numbers add up in the future.

UI design for time tracking

I'm trying to think an interface for a time-keeping system that will let users see "at a glance" how much time still needs to be completed.
This is complicated by the fact that there are no fixed hours - employees must work at least 6 hours on any given week day, and at the end of each month should have worked 7.5 hours for each week day that month. 7.5 hours either way can be carried over to next month. Employees can also take up to 1 morning and 1 afternoon per month 'flex' time. Time needs should be recorded by 10.15 the following day, but this rule is bent during busy times, and end of week and particularly end of month boundaries become more important.
So what's the most readable format to display the currently entered time and highlight approaching deadlines for uncompleted entries, while still giving a feeling for how far ahead/behind track the employee is (i.e. if you have a week to go that month and you're 8 hours ahead you could schedule a little extra duvet time).
My first take was a bar chart for each day with a red line at 6. But this doesn't give you any idea of how far ahead or behind you are for each day or month or whether you are close to missing a deadline...
(Please excuse the horrible mockup)
Maybe I'm trying to convey too much info in one place?
--
Here's a mockup of time recorded v.s. time required as suggested by Dickon Reed
--
EDIT: this side works great for stuff like this. i'm going to kick some of these ideas around in the morning and hopefully get something posted back here.
Your first chart could be improved by showing the remaining time as shown below. The remaining time until the next weekly/montly deadline is divided evenly over the remaining days before the deadline. So the UI will answer to the question: "How many hours per day will I need to work to meet my deadline?" If the user wants to take one morning/afternoon off (or did I understand you incorrectly?), you should have a checkbox for that day, after checking which the estimates will be adjusted accordingly.
You should also show the exact time on top of every vertical bar, so that the user doesn't need to estimate it in his head (I was lazy and added them to only a couple of bars in the mockup). Also highlight the current day, for example in the below picture this was done by circling "Thursday" and using a bold font for the time that the user has been working today. You could also use some visual effect for today's vertical bar.
improved bar chart http://img11.imageshack.us/img11/6755/20090216203339em2.png
For your second chart you should also draw in the weekly or monthly deadlines, as horizontal bars. In some cases the second chart might be better, but in this case I would settle with the first chart (with my improvements), because it might better correspond to the users' mental model, and that way you can also visualize the daily minimum 6h some way.
how about a "test tube/thermometer" image, like they have for charities... it fills up as you add time, trying to reach a goal (the red line).
Fill each day with a different color, and label accordingly... if the user works overtime M-T, they may have reached the line before Friday, etc.
similar to:
alt text http://goyamarketing.com/blog/wp-content/uploads/2008/11/goal_thermometer.gif
The char bar looks nice visually, but what you really need to know is how far behind/ahead you are in your hours totally.
If i understood correctly, you are interested only in your current saldo and your current deadline, so you could display that information in 2 seperate fields (e.g. below the chart). Of course, you could also mark the deadline with some horizontal line in the graph.
How about a pie chart where the total size represents the minimum goal and add pie slices for each day with actual days that met the minimum one color, days with extra time another and then fill the remaining days as gray slices with the number of hours the employee would have to work divided evenly among them?
A line plot with "working days elapsed" on the X axis and "fraction of monthly required work done" on the Y axis? With only a few data points, it should be clear by visually extrapolating whether you'll hit the top early or late. The plot would look like an irregular staircase.
ps. "The Visual Display of Quantative Information" by Edward Tufte is a great book for ideas on this kind of topic.
To take Dickon Reed's idea one step further, why not do each point as a +/- hours ahead or behind, with your baseline always 0. That way you have more detail. I'm not sure if I got my point across, but it's hard to do without an example, and I'm short on time.

Resources