I'm trying to improve the schedule spreadsheet for the café I'm working at.
Our employees can be baristas, bartenders, or both. I made a table with checkboxes for that. That's the Employee list tab.
In the Schedule planning tab we specify which days in a given month we can come to work. Sometimes people can work both morning (AM) and afternoon (PM) shifts in the same day, but not always, so it needs to be specified too.
In the Finalized schedule tab our manager would split the shifts among employees manually, which is the most complicated and time-consuming part of the whole process. They would constantly switch between tabs, checking who can work which days and shifts, then juggle with what's available. Needless to say, there's plenty of room for error there and sometimes it's quite a mess.
I would like to automatize it a little bit. I know a little about spreadsheets, but can't figure out a few basic things here to even get started. I suppose my main issue is "connecting" several individual cells - to get a particular result only when their values correspond correctly.
I would be eternally thankful for tips on any of the following points.
(There's also going to be a calculator for hours worked in another tab, but I've already sorted that out.)
https://docs.google.com/spreadsheets/d/18W1ScIDT0e7A7esOwnTkvIVtWzoOkMPo6pfqkTVLn7E/edit#gid=1743092005
I imagine the tabs feeding into each other in the following manner:
Employee list tab would serve as the foundation for the rest of the sheet. The other two tabs would pull employee names out of it (to avoid typos and subsequent errors, especially in the hour calculator tab), as well as their roles.
In the Schedule planning tab, the only thing I have troubles with is automatically generating new sections for each employee. The sheet linked above is obviously faux, there's many more people working at our café and people often come and go, so it would definitely save time if a horizontal list of names from Employee list (B3:B) could be generated into (C1:1) of Schedule planning. Is that possible?
Other than that, what's crucial here is the date (B3:B) and shift (C2:C).
The last tab is the most complicated. This is what our manager sinks hours and hours into.
As you can see, for each day, there's up to six slots available - three per shift: one each for baristas and bartenders, and then one more in case an extra pair of hands would be needed on that particular day/shift. This extra slot can be filled out by anyone available regardless of their usual role.
Ideally, I would like to have a dynamic dropdown list in each slot that would pull data from the previous two tabs. The criteria are as follows:
Name is pulled from Employee list (B3:B).
Role is pulled from Employee list (B3:C). For example, John is a barista, so he should appear only in Barista and Support slots; Bill, on the other hand, can appear in any slot.
Date is pulled from Schedule planning (B3:B). For example, Patrick should only appear available in the March 1, 4, 6 and 9 slots (and also only in the Bartender slot, as that is his role).
Shift is pulled from Schedule planning (C2:C). For example, if we would need a barista to work in the morning on March 4, the dropdown list would contain only Cathy and Bill, as they both fill the role and are available for the AM shift on that day.
Additionally, if a person has already been selected from the dropdown list, they shouldn't appear in the other two dropdown lists for that shift, even if they satisfy all other criteria. For example, if Bill appears in D16 (Barista, March 8, AM shift), he's "taken" and can't work any other role at that moment. (In other words, the same person can only appear once on the same row. I'm not sure it can be done via dropdown lists, but perhaps color formatting would do.)
I understand it's quite a project I need help with, but I'm really stuck here and don't know where to begin. My hope is that for some of you it might also be a fun game figuring this out with me.
Thanks a lot to whoever can contribute to this in any capacity.
Related
I apologize if this is not allowed or too general or vague.
I am a teacher frustrated by the fact that I cannot find a pre-made Google Sheets gradebook to do what I want. I decided to try to write one myself. Of course I not great at writing script but through trial and error and trying to decipher others code I am picking it up.
What I really want to know... is it possible to do what I envision or am I wasting my time?
I want to have a list of students in column 1 and enter an assignment title, type of assignment (there are 3 with different weights) and grade for each student in subsequent columns.. and be able to display a running cumulative grade based upon weighting - I know all of this can be done. The extra part is being able to send the student and parent an email if an individual assignment grade is lower than a 70. I am pretty sure this can be done. The part I don't know is what that would look like. For instance, would there be a run script button that needs to be added for every assignment column in the spread sheet or....
I hope this makes sense and again apologize for my noobishness..
Found this:https://www.google.com/amp/s/www.groovypost.com/howto/google-sheets-send-email-based-on-cell-value/amp/
Your goal sounds doable assuming you are sending these mails from your gmail address or your org is using enterprise gmail.
Only other concern id say to watch out for is accidentally sending the emails out over and over for the same grade event.
As a student, if i recieved a recurring daily email about the same low grade assignment a month ago i might eventually spam flag the source, invalidating all that hard work.
i couldn't find any info on this anywhere.
i have a setup of users and items, where the items could became outdated pretty fast (in days). this means, i cannot show those items anymore, since the customer (who sells items) has no credit left and we don't know whether he plans to continue working with us (by charging more credit).
but i want to keep the user-items settings, because it is still valuable and the results are good. i'm afraid, that when getting e.g. 20 recommendations for a user, 15 out of 20 recommended items could be outdated.
is such a situation covered within mahout/myrrix, or do i have to implement my own filtering method via rescorerProvider (setting higher threshold for active items) or simply get 40 recommended items and filter first 20 of them which are still active?
there's one more solution that comes to my mind - erase old items from the user-item preference and put them as tags via the method http://myrrix.com/rest-api/#setusertag
That situation is not explicitly covered by either, in both you will have to introduce some custom logic.
Either solution you described should work (rescorer or generating more). However in my Myrrix you can use the pluggable CandidateFilter
I'm not so sure about the tagging trick, it might work since the tags act as pseudo users or pseudo items.
I have a products model and an iTunes sales model. At the moment i'm fairly successfully reporting sales through scopes and ordered hashes. One flaw in the approach i've taken is that if there's no sales for a particular date I don't get a zero entry, just a gap for that date, which proves to be an issue when using something like Highcharts to plot the results.
I'm also soon to add new models for sales data from other sources, which will mean a rewrite to pull these figures into the product view and with my current approach I can see this being a complete headache when one report contains sales for a date but another doesn't.
I'm thinking I should instead for any given product be producing a range of dates (last 30 days for example) and then for those dates bring in the associated sales from my iTunes and other sales models. I'm just not sure how to approach this or if this is even the best approach to take.
Does anyone have experience of building something similar that can offer some guidance here please?
Thanks in advance!
It might not be the "right way" but you could always through a date lookup table in your DB and left join on it. That way you can be sure you have all the dates in the period of question present in your query results regardless of whether they have data.
I am new to BI/Datawarehousing, and after building some easy samples, I have the need to build a more complex structure. My project initially involved product licenses, and I was measuring how many sold, by month/year and by program, and just counting the number of licenses.
Now the requirement is to introduce jump offs from those metrics. As in, when you come to a certain group of licenses, they want to see a whole different metrics of those. Such as, if 100 licenses were sold in mar 2011, how many of them installed, activated and cancelled the product. (we track that info, but not in the DW). So, I am looking for the best way to do this...I assume the first thing I have to do is add three dimensions for installed, activated and cancelled - and have three fact tables? Or have one fact table with each license, and have a row for cancelled, installed or activated? (so one license may be repeated). Or have one fact table, with different fields for installed, cancelled, activated? Also, how do you relate one fact table to another? Is it through dimensions, or they can related in some other ways?
Any help would be much appreciated!
EDIT:
Thanks for the post... I was also thinking the second option is probably the correct one. But in this implementation, I have a unique problem. So, one of the facts that is measured is the number of licenses that are sold - by date of course. Lets say I add a row for installed, cancelled, activated. The requirement is for them to be able to see a connected fact. For example, if I add individual rows, given a timeframe, I can tell how many were sold, and how many were installed.
But they want to see given a timeframe, how many were bought, and out of them, how many installed. e.g., if the timeframe is march, and 100 were sold in march, out of those 100, how many were installed - even though they could have installed much later than march, and therefore the row date would be not in the timeframe they are looking at....is this a common problem? how is it solved?
I assume the first thing I have to do is add three dimensions for installed, activated and cancelled - and have three fact tables?
Not really. A license sale is a fact. It has a price.
A license sale has has dimensions like date, product, customer and program.
An "installation" or "activitation" is a state-change event of a license. You have "events" for each license (sale, install, activate, etc.)
So a license has a "sale" fact, an "installation" fact and an "activation" fact. Each of which is (minimally) a relationship with time.
Or have one fact table with each license, and have a row for cancelled, installed or activated? (so one license may be repeated).
This gives the most flexibility, because each event can be rich with multiple dimensions. A sequence of events can be then be organized to provide the history of a license.
This works out very well.
You will often want to create summary tables for simple counts and sums to save having to traverse all events for the most common dashboard metrics.
The requirement is for them to be able to see a connected fact.
Right. You're joining several rows from the fact table together. A row where the event was sold, outer joined with a row where the event was installed outer joined with row where the event was activated, etc. It's just outer joins among the facts.
So. Count of sales in March is easy. Event = "Sale". Time is all the rows where time.month = "march". Easy.
Count of sales in march which became installs. Same "march sales" where clause outer joined with all "install" events for those licenses. Count of "sales" is the same as count(*). Count of installs may be smaller because the outer join puts in some nulls.
Count of sales in march which became activations. The "march sales" where clause outer joined with all "activation" events. Note that the activation has no date constraint.
Or have one fact table, with different fields for installed, cancelled, activated?
This doesn't work out as well because the table's columns dictate a business process. That business process might change and you'll be endlessly tweaking the columns in the fact table.
Having said it doesn't work out "as well" means it doesn't give ultimate flexibility. In some cases, you don't need ultimate flexibility. In some cases, the industry (or regulations) may define a structure that's quite fixed.
Also, how do you relate one fact table to another? Is it through dimensions, or they can related in some other ways?
Dimensions by definition. A fact table only has two things -- measurements and FK's to dimensions.
Some dimensions (like "license instance") are degenerate because the dimension may have almost no usable attributes other than a PK.
So you have an "sold" fact that ties to a license, a optional "installed" fact that ties to a license and an optional "activate" fact that ties to a license. The license is an object ID (the database surrogate key) and -- perhaps -- the license identifier itself (maybe a license serial number or something outside the database).
Please by Ralph Kimball's Data Warehouse Toolkit before doing anything more.
When a user is viewing a paged table and requests it to sorted by a particular column, what page is shown?
Is there a standard expected behavior for this scenario? I can imagine several possible outcomes, but want to know if there is a standard.
You mean which page to show among the n pages in the table? There are no good options –any possibility is likely to be disorienting and frustrating for the user precisely because there is no standard and no particularly good reason to chose one option over the other. If you were to test users, I doubt they’d have consistent expectations. Even the same user may expect different things at different times. Paged tables also provide relatively weak feedback on the current location in the table so it’s hard for users to understand where they are after sorting whatever option you use. Usable sorting is one reason paged tables are inferior to scrolling tables.
Of the possibilities:
If you have a way of showing a currently selected or focused item (row) in the table, then you can go to whatever page that item is on, under the assumption that the users chose to sort at that moment in order to see other items like the item they’re looking at. This is consistent with some implementations of scrolling tables. However, most web-app paged tables don’t support the selection of an item.
You can show the ith page that the users are on when they sorted (e.g., if they’re on the third page when they sorted, show the third page under the new sort order). This is consistent with some other implementations of scrolling tables. It also supports the case where the table is almost sorted correctly (e.g., on Send Date, when Received Date is need). Showing the ith page puts the users on about the “same page” they were before. This is however not the most common use case and users are likely to feel they’ve been thrown to an arbitrary page given the weak location feedback. This option will probably produce the greatest disorientation.
You can show the 1st page under the new sort order. Depending on your tasks, perhaps most of the time when a user sorts a table, the users are interested in the items with the highest or lowest value of the attribute they sorted on. By showing the first page, the probability of you being right can approach 50%. It’s the least disorienting because the user feels they’re back at a mental anchor point –the beginning. On the other hand, users may be frustrated if they feel they’re “starting over.” Overall, this is probably your best option.
Generally following a sort, users want to jump to items with a certain value on the attribute they sorted on. This is difficult with a paged table because paging is slow and the users don’t know what page number corresponds to what value. You could label the links for the pages with the range of values found on them, but that can consume a lot of real estate. At the very least, you should always provide a link to the first and last page of the table however many pages there are so users can get to the items with highest and lowest values in one click.
Alternatively, consider supporting filtering rather than sorting to accomplish the same purpose. Depending on your users’ task, that may work much better and be less confusing and effortful.
The answer of Michael Zuschlag is very good, but I think that the case #1 and #2 that he presents are really uncommon, and doing so can be more confusing than useful.
In my opinion, you should always show the 1st page under the new sort order. If the user has selected an item, usually he don't want to sort anything, because he already found what he was looking for.
If you want to give a sort order to a list, usually you want to see the real, complete order.
A classic scenario can be a torrent site:
I search for a torrent typing some
keywords.
After the search I a have
an unordered list, 50 items per
page.
I go to second page.
Now, I think that is better sort the results starting from the item that has the highest number of seeders, and click to the header of the seeds column.
I expect to see the item with the the highest number of seeders after action 4, so after sorting you have to show me the first page. And I think this is true for about any sorting situation.
First of all, AMEN to the previous answer (and +1)
Second, just for real life examples of what users are familiar with and may expect, Yahoo Mail does #3 (jump to page 1 after sort). So do many other web sites.
My personal recommendation - if feasible to implement - would be #1 above (allow jumping to the page containing the currently selected element). Make sure that element is STILL selected.
That is both somewhat intuitive, not very un-expected, and most useful in cases where the user cares what happens. Plus, the option #3 (jumping to first page) is only 1 click away for the user assuming your paging controls include "Go to page 1", whereas, as noted in previous answer, doing first page makes it hard and long for user who did want to stay with the current item.
I definitely support the "add filtering" idea as well if feasible - I find myself using Excel for >50% of the work with tables/lists originated from any app/website, due to its exceptional combination of filtering and sorting. Perhaps YUI has a decent filterable table element assuming your UI is HTML?