Created by Elyahu Jacobi @Elyahu41 and Maor @NightScript
@NightScript is contracted to help build this website.
Improved website based on Elyahu41.github.io/RabbiOvadiahYosefCalendar/
The current implementation of Shabbat Mode mirrorly increments the screens y position by about 3 px every absolute 50mil, which makes for a non-smooth scrolling. The indicator that this isn't a bug but rather a feature is with an absolute positioned banner on the top that reads Shabbat mode as long as the 5 times the text is defined wouldn't disappear if your screen is too wide because a 6th element wasn't added. To disable this, you first need to click on the banner to disable it, then get the screen to scroll to the nav bar and finally disable it from there...
...needless to say, this did not take into account the recent advancements we made for desktop users. With all the horizontal width we take advantage of, there is no scrolling that could happen on a 1440p screen. As such, only the fact that there is a blue bar is the indicator.
To fix this, I would like to rename Shabbat Mode to "Auto Mode", which would be inclusive of Yom Tov and convey the purpose in the name. With that, there would actually be three implementations:
Even if chaitables is implemented in the website, there should always be an option to always show mishor sunrise regardless whether or not there is a time available for visible sunrise. Many kehilot use this time since they do not use chaitables.com and we want people to see it as well to not be overwhelmed by other people saying the time for sunrise is different.
As mentioned in issue #15 , there should be an option/setting to allow the user to always see mishor sunrise.
Currently, our weekly view UI implemented in the Mobile Application only accounts for the fact that it would be shown in portrait mode, on a device that could scroll. However, when considering the fact that this will be shown on a computer, we need to account for that as well. To show a table with 7 columns won't do us any good, but perhaps we could split it? Problem is how are we going to split it?
Of course, our implementation also needs to account for the fact that on mobile, we would like to have it match the mobile app's view layout. Thereby, when it comes to maintaining a good implementation that can account for both, we would need to use negative margins and such for mobile.
Surprisingly, the actual Zmanim implementation worked offline for me, giving me the correct Zmanim for the area I already specified
If so, we should make it so that only auto locationer is broken, rather than letting the browser assume that it needs to be online to work.
Currently the website just shows the accordions as a substitute dialog for the apps, and only the calculations for the zmanim are shown. However, there are multiple dialogs/accordions missing that I think are needed for users that do not know as much. Here is a list of dialogs missing:
These are the main three that are misssing, however, you can add more dialogs if you want. Like for Hallel and other simple features.
This monthly view is going to be interesting, because it basically needs all the screen-realestate it can get. Where Rabbi Dahan could get away with making font sizes smaller due to how printer quality can usually indicate letters by feeling + the fact that words are "rendered" in a vector-like format, that will not work for the pixel-based screens of laptops, televisions and other things.
One thing we should make clear is that this is the one area where a mobile version will not be supported. While I will get feature parity for everything else, this cannot be ported over due to how the mobile sizing works. However, since printing is independent of mobile, they can instead be featured with a print button, which can allow them to save the document as a PDF they could easily open and read.
The way I will be handling this from a UI perspective is that you can swap among the "pages" of the different months. Years will be handled by a dropdown menu, which will account for a range of 50 within the year that your current page is on. For example, if you select the year 2701, your options will be 2651-2751. To get to 2801, you'll have to select 2751 and then go to 2801.
Of course, when printing, all the different months of the current year will be shown.
In the old file, everything was handled via JavaScript, whether it was the info modal (which we're using a details dropdown instead), the times or even the names of the time. Now, on the premise that JavaScript should be handling functionality rather than the metadata, I've started moving all of it towards being read by element attributes (rather than the ones that need special attention).
However, I did not finish. Here's the leftovers:
This needs to be reflected for both the TV layout and the regular wide layout
As mentioned in issue #15 , there should be an option/setting to allow the user to see if this shabbat is shabbat mevarchim. There is a method for this in KosherZmanim that should make this trivial.
To make this into a full webapp, this will also need to implement JS notifications. Unfortunately, all custom implementations are AWFUL and anything good is paid.
We'll need to figure this out in a better way.
As mentioned in issue #15 , there should be an option/setting to allow the user to see the seconds of the zmanim.
Not sure if you want this, however, in the apps, there is an option to hide the dialog pop ups. It is not so applicable to the website, however, if you want, you can add an option that hides the accordions
As mentioned in issue #15 , there should be an option/setting to allow the user to hide the accordions.
The layout is probably the most important thing to consider right now. On the default website, there is much wasted space because of a max width, which meant scrolling was necessary. However, on a screen which can accommodate more content, why not use what we're given?
Thereby, it's time we designed three different layouts for the daily view, depending on which screen size you have available:
Desktop Layout
The rules and information should really all stay in the same y axis as the times it'd be for. Thereby, I've came up with a grid mechanism, with a sidebar that'll span 40% of the screen and the zmanim that'll span the other 60%. The Zmanim will be listed in an accordion style, meaning clicking on the name for one of them will mean bringing up the info immediately below it. Also, the sidebar is split into two different sections.
TV Layout
These TVs have A LOT of horizontal space, but not vertical. Thereby, since they either way won't be seeing the information on the zmanim, we could just trim out all the horizontal fat by putting all the zmanim in the same horizontal line, similar to weather apps.
If they want to see information, they can click on the zman name to have a modal pop up with the relevant information. The information will be split into three, and span on top on top of the zmanim themselves
Mobile Layout
This is not necessarily a mode, but rather a feature of creativity within limitation. Since there is no extra space to use, there wouldn't be a way to implement a grid in the first place, so the layout of being a big column stays the same. However, it will still be affected by the setting of whether it would have been under the desktop layout or the TV layout had the screen been bigger. While the times will still be the list design regardless of the layout, hitting the button would carry over the property from the specific layout:
Now, within the pillar, the groups of information will also persist from the modes presented prior. In other words, users who set their mode to desktop will get two groups while users who set their mode to TV layout will get three groups.
The real question is, though, what's the cutoff point? Bootstrap's breakpoints should be a good reference of when to start hosting it in pixel size, but if we could do by minimum aspect ratio, I'd like to instead suggest having 16:9 be the above full layouts with below being the mobile mode.
All rabbanim agree that the Ohr Hachaim calendar should be used in Israel. I just tested the website by putting in "Jerusalem" and it put me in Israel, however, it was still using the amudei horaah calendar. There needs to be a check in place to always set the calendar to ohr hachaim if the inIsrael boolean is true.
The browser already does the heavy lifting for us. It is rather pointless to implement it ourselves
Right now, by default, the zman for Rabbeinu Tam is shown everyday. Whereas, by default, in both of the calendars, RT is hidden everyday unless it is Shabbat/Yom Tov. As mentioned in issue #15 , there should be an option/setting to show RT everyday if the user wants it. However, by default, it should be hidden except for shabbat/yom tov.
In Amudei Horaah mode, we display shabbat ending at 7.14 degrees after sunset. However, in Ohr HaChaim mode we show 40 minutes.
We should show 30 minutes after sunset in Israel for the Ohr HaChaim calendar as that was Rabbi Ovadiah's psak. (Check the isInIsrael boolean)
As mentioned in issue #15 , there should also be an option/setting to allow the user to change when shabbat ends in minutes after sunset.
For example, in NY, people usually end shabbat after 50 minutes. So maybe the user wants to override the 40 minute setting.
Printing is probably one of the most essential things when it comes to this website, in particular because of the "כל מי שיש לו שמרטפון" crowd that rejects looking at screens. Thereby, we need to make sure that the site can provide its content when printing without printing out the site itself.
Jews will always want options; that's why we have two Jews and three opinions. Our site will definitely be used by people everywhere, and while we'll have the best defaults, we need to make sure the options would highlight exactly what the end-user would like. Thereby, I'd like to separate all available options into different categories:
Zmanim
Visuals
Functionality
This issue is very important. If the user is in Israel or Canada or somewhere where they use a 24h clock, the website should be updated to display 24h times.
Hebrew should not be shown to the user unless they choose it for their zmanim.
You should only make the entire website Hebrew if the user's default language is in Hebrew.
Right now, every time I open the website on a new computer, the website is entirely in hebrew. Then I need to navigate to the settings (which I do not know how it is written in hebrew) and change it there in order to use the website. The website needs to be in english first and foremost as that is our target audience. We can make another website with co.il extension for people in Israel if needed.
Either way this issue needs to be a priority.
This is really just a cosmetic thing and you can ignore this, however, it is always nice to give the user the ability to change the colors/background of the website to customize it to their liking.
As mentioned in issue #15, there should be some form of customization to the theme of the website. (No pressure for this at all as light mode and dark mode satisfy 95% of the users)
As mentioned in issue #15 , there should be an option/setting to allow the user to change when candle lighting is according to his/her minhag. While the Amudei Horaah calendar put candle lighting at 18 minutes because that is the minhag. In the Ohr HaChaim calendar, it shows 20 minutes and 40 for those that are strict.
Currently there is not way to change this time.
Right now, the current site (elyahu41.github.io/royzmanim) has everything as separate pages. With the exclusion of the Molad calendars, I'd prefer handling the extra content as a modal rather than a separate page.
The way the Java app has it now is that it downloads a file into its memory, converts it to data the language can understand, then use that data to get the netz timing.
For the website, we'll need to implement an API instead, since it cannot do that very first thing without being wasteful to the client side (downloading the file and its interpreter). I can easily write this in Deno and host it on my VPS.
Of course, if there is a web filter that disables access to the API link, fallback to current implementation
To implement, I will need to find the relevant Java code and see how I can replicate it from a backend perspective.
I will use a standard routing system for now, eventually replacing it with Deno.serve once it becomes stable
Right now the website displays the zmanim according to either the Ohr HaChaim calendar or the Amudei Horaah calendar. There are some setting that have been added to the android and ios apps that help customize what zmanim to show if the user so chooses it. I will make a separate Issue for each setting.
This might be something you want to leave out. However, in the apps, I by default round up the zman of Rabbeinu Tam because I figured most people would want that. And if people do not want that, I made an option to disable it.
As mentioned in issue #15 , there should be an option/setting to allow the user to choose whether or not they want to round up RT.
As mentioned in issue #15 , there should be an option/setting to allow the user to see both times for the tekufot I.E. according to the Ohr HaChaim calendar and according to the Amudei Horaah calendar. As mentioned before, the difference between these times is just 21 minutes. In the apps, if the user decides to see both of the times for the tekufot, I show both of the times as separate listings. However, what you could do is to merge the times and overlap them.
For example: Let's say that according to the Ohr Hachaim calendar, the tekufa happens at 9:30am. Then you would not be able to drink water from 9 - 10 am. The Amudei horaah calendar would subtract 21 minutes from both these times. So the tekufa would come out to 9:09am and you would not drink from 8:39 - 9:39 am.
You could show this as two separate listings if the user wants to see both, OR you could just merge them and put the earliest and latest time I.E. 8:39am - 10am.
I leave it up to you.
As mentioned in issue #15 , there should be an option/setting to allow the user to see both options for the tekufot.
If Web Filters cannot allow us to access the elevation APIs, then elevation should be disabled. Currently, we just crash the whole app.
So this feature is implemented in the backup website https://elyahu41.github.io/RabbiOvadiahYosefCalendar/
Change the date to any friday and you will see the red box on top of the zmanim list.
This was added as an option in the apps because some people wanted to see when shabbat ends the day beforehand. It was especially annoying because shabbat mode did not show the next day's zmanim until 12AM.
For the website, we do not need to add when shabbat ends into the list of zmanim, since we have space, we can make a separate box for it. See picture below for example. (You could also show rabbeinu tam if you have space).
As mentioned in issue #15 , there should be a box to display when shabbat/yom tov ends. Also a setting to disable this if you feel it is needed.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.