Page 1 of 1
Labels / selection of multiple solunar types
Posted: Wed May 15, 2024 5:20 pm
by Jim Eshelman
In another thread, I suggested the following as a way to label some of the varieties of solunars for selection. I wrote:
So, it could look something like this maybe:
Code: Select all
[ ] SSR [ ] DSSR [ ] QSSR1 [ ] QSSR3
[ ] SLR [ ] DSLR [ ] QSLR1 [ ] QSLR3
[ ] NSR [ ] 10-Dy Solar
[ ] NLR [ ] 18-Hr Lunar
[...]
I've realized over the last few days that this works fine going backwards - looking at currently active charts - but not for going forward, where it gets more complicated.
TM allows three types of selections when you put in a date for solar and lunar returns:
- Active Charts: all selected solunars active at the given date and time.
- Forwards: the first chart of each selected solunar after the date and time.
- Backward: the last chart of each selected solunar before the date and time.
An example of the difference between Active and Backward is that if you pick SLR and DSLR as
Active, and you're in the first half of the month, you get only the SLR - it's the only one that is then active. But if you pick
Backward you get the current SLR and the DSLR before it (the most recent example of each.
This will take a while for me to write this all out - maybe the next 24 hours, maybe through the weekend. I just wanted to get it started.
Re: Labels / selection of multiple solunar types
Posted: Fri May 17, 2024 10:10 am
by Jim Eshelman
First, I want to summarize two different user interface concepts - one used by Solar Fire and one used by Time Matters. I don 't think we want to switch user interface paradigms (I know we don't need to do it now - it could be done anytime later - and I suspect we'll not want to do it later, either0. Nonetheless, I think understanding both will make some concepts and options clearer.
Solar Fire has what we might conveniently call the harmonic model of return calculation. It lets users pick the return(s) they want by picking the harmonic, then (unless you change the number of charts you request) it gives you the one most recent (or next one or most recent one) of that harmonic. There are a lot of small steps, but the concept is clear: You pick the planet you want (Sun, Moon, or other); whether you want the most recent, the next upcoming, or the closest; and you pick whether you want more than one return. But the main thing at the moment is that (unless you want a basic SLR or SSR) you pick the harmonic you want.
Consequence: If you pick, say, harmonic 2 on a lunar return, you get whichever ONE SLR or Demi-SLR is most recent (etc.) It makes no difference between the two, since they are both "harmonic 2" lunar returns. If you pick 4, you get whichever ONE SLR, Demi-SLR, or Quarti-SLR was most recent (or upcoming, of whatever you picked). If you pick forward ("next"), you get the same ONE chart going forward. For multiple charts, you pick the number of successive charts you want.
Time Matters has what we might conveniently call the explicit return model. It lets users pick precisely which returns they want, either picking the full SSR or SLR, and/or the Demi, and/or either (or both) of the Quartis. These can be picked in any combination, e.g., the SSR, SLR, and Demi-SLR. (The only way to pick multiple sequential returns is to pick the One Year option.)
These are quite different mental approaches to the question. They create different work paths. I think each has significant advantages and disadvantages. I could argue for either approach.
At the moment, I'm absolutely clear we don't need to reinvent how TM handles this. Also, I'm not sure we ever want to switch it to match Solar Fire - it's at least interesting and perhaps advantageous to have the programs work differently (and, at least, I haven't yet seen how it gets in the way). I just wanted to have both in mind before moving forward with the discussion.
Re: Labels / selection of multiple solunar types
Posted: Fri May 17, 2024 12:09 pm
by Jim Eshelman
In TM, you check the explicit box of whatever returns you want. (If you want a Quarti, you check the exact Quarti you want). You get the
one most recent of
each (if currently active) when you pick Active; or one of each one you pick if you choose Forwards or Backward.
NOTE: Currently the menu says "Forwards" and "Backward." These should match. American standard usage would drop the ending -s from both.
Most of the other return charts we want to calculate follow this model and could be easily populated. (I ignore for now the question of whether we want a long list of possible charts, a drop-down list if some sort not obvious to me, or something else.) The list might look like this:
Code: Select all
[ ] SSR [ ] DSSR [ ] QSSR1 [ ] QSSR3
[ ] SLR [ ] DSLR [ ] QSLR1 [ ] QSLR3
[ ] KSR [ ] DKSR [ ] QKSR1 [ ] QKSR3
[ ] KLR [ ] KSLR [ ] KSLR1 [ ] KSLR3
[ ] SAR [ ] DSAR [ ] QSAR1 [ ] QSAR3
[ ] SoLu [ ] DSoLu [ ] QSoLu1 [ ] QSoLu3
[ ] LuSo [ ] DLuSo [ ] QLuSo1 [ ] QLuSo3
[ ] SYR [ ] DSYR [ ] QSYR1 [ ] QSYR3
These all work whether Active, Forward, or Backward. If the current "All selected for one year" is picked, you get a logical result, either one of each solar picked or 13 of each lunar picked.
The problem comes with the Novienic solar and lunar returns (which is where this whole question started).
I previously proposed the following, which works just fine for Active Charts. NSR gives or NLR gives the single most recent 40° multiple. 10-Day Solar and 18-Hr Lunar give ethe
one most recent 10° multiple (whether also a 40° multiple or not). But how do these work with Forward and Backward variations?
Code: Select all
[ ] NSR [ ] 10-Dy Solar
[ ] NLR [ ] 18-Hr Lunar
The root of the problem is that all other types of returns listed above use TM's
explicit chart interface. The NSR and NLR, though (I think) need to work in the
harmonic interface. I think this because some of us are decreasingly confident that there is any difference between the 40° charts and the 10° charts (especially with the lunar and maybe even with the solar).
We could, of course, change this altogether by breaking out the 1-day solars and 18-hour lunars into three variations akin to quartis and a demi. That seems less efficient by itself, but does bring everything else back into the
explicit chart model. It becomes awkward, though, because in use I'd like to get the most recent 10° variation without having to calculate ahead of time where the Moon or Sun currently is and what I need to ask for.
Re: Labels / selection of multiple solunar types
Posted: Fri May 17, 2024 12:33 pm
by Jim Eshelman
We should keep the interface (and the more subtle elements of the underlying idea) consistent across all returns. This makes using it easier.
One step that doesn't solve this by itself but makes a couple of big steps in the right direction: Remove the "All selected... for one year" box and had a box to type the number of each chart that you want. (This box should be greyed out if Active is selected, and defaults to 1.) This is helpful - flexible - in several ways. For example, the active chart list really only is good for a bit more than a dozen charts, so you can't run a year's worth of lunars AND demi-lunars and have them fit. I do them separately. But one could pick six charts (each) instead, and pick both SLR and DSLR together, and they'd all fit.
(Later:) Aha! I've got it! I think this is the simple touch that makes the user's experience consistent (same with the program's logic).
Stick with this display:
Code: Select all
[ ] NSR [ ] 10-Dy Solar
[ ] NLR [ ] 18-Hr Lunar
Then, if
10-Dy Solar is checked, the program
blanks and then grey's out NSR. If
18-Hr Lunar is checked, the program blanks and then grey's out NLR.
Without having to explain it, this program toggles between the two UI models. 10-Dy and 18-Hr become harmonic-based (
including the NSR and NLR in their definitions) without needing to explain it (other than buried in the Help text).
Think through the common use scenarios:
(1) Somebody wants these charts for the current moment, or active for a particular date or event. They pick Active. They usually won't know where Sun or Moon was at the event. If they pick 10-Dy or 18-Hr, they get the current 10° chart. If they want to be SURE they got the Ennead/NSR (e.g.), they can then check that box instead and hit Calculate again - about three seconds to get it, hardly a hassle.
(2) Somebody wants the next upcoming chart. If they know they want the full NSR, they can pick it. If they want the "next whatever," they can pick it.
(3) Somebody wants a series of future charts. Pick Forward. If they want a year's worth of Enneads, pick NSR, then pick 9. If they want a year of 10-Day Solars, pick 10-Dy Solar and put 36 in the box (or 18 for six months, or 9 for three months). If they want a month of Novienic lunar 10° multiples, pick 18-Hr Lunar and pick 24 (or just put in 30 and deal with the few extra). These are the main use scenarios, I think.
OK, that resolved faster than I thought and simpler than I thought. What think ye all? Does this really make things straightforward?
Re: Labels / selection of multiple solunar types
Posted: Mon May 27, 2024 6:02 pm
by Mike V
I think this makes sense. I'm still pondering the concept of explicit Solunar return types vs Solar Fire's style of "whatever, you said the next 10 2nd Harmonic Lunar Returns, so here's all of 'em in a pile."
Re: Labels / selection of multiple solunar types
Posted: Mon May 27, 2024 6:13 pm
by Jim Eshelman
Yes. I'm intrigued by the different options and different use scenarios. I'm disciplining myself not to think uniformity with SF is necessarily better than going a different way.
I also think that programming would be more involved for rewriting the whole thing in a buffet fashion of "pick planet A, pick planet B, pick a harmonic, pick how many." Even if it IS eventually decided to be the better approach, does that mean it should be the first approach?
BTW, a variation of the above I thought of is to have one list that picks the type of return (e.g., SSR, SLR, KLR) and another single-line option that picks quarters (whole, half, Q2, Q4). This would be space efficient. I'm not sure, though, that it's a good choice since one usually wants different quarters, e.g., a common scenario being one SSR and the most recent SLR and/or Demi-SLR. - So maybe forget that idea.
The idea of a drop-down menu also grabs my attention for efficiency, but may make it harder to select a concierge mix of many different things. Also, despite all the other offerings, it should always be trivial to get a standard mix like, say, one SSR and the one or two recent half-lunars.
Design design design. I understand why people are getting degrees in UI/UX.
Re: Labels / selection of multiple solunar types
Posted: Mon May 27, 2024 6:56 pm
by Mike V
What do you think about coalescing the quarti options, and basically just picking the harmonic?
Something like this:
Code: Select all
SSR
[ ] full [ ] demi [ ] quarti
SLR
[ ] full [ ] demi [ ] quarti
NSR
[ ] full [ ] 10-Day
NLR
[ ] full [ ] 18-Hour
and so on...
If you pick "current" and full/demi/quarti, you can just end up with one chart if you're in the first quarter of a period, but that's fine.
I think my main point of confusion is why you would want one quarter and not the other, for example.
Re: Labels / selection of multiple solunar types
Posted: Mon May 27, 2024 7:19 pm
by Jim Eshelman
What if you want all four. (More likely in a Forward scenario, if one is into quartis.) To get Full Q2, Demi, Q4 you'd have to define quartis as meaning anything fourth harmonic. Otherwise, you only get the first one.
But if you define it as a 4th harmonic, and you're doing a Backward search from the fourth quarter, then you get the first quarti even though you don't want it.
There may be something here... but it's not QUITE that simple of one wants to produce the exact charts one wants.
You could, of course, program it to act differently forward and backward, defining "all relevant" backward as meaning the most recent version of each one beginning with the conjunction, and defining "all relevant" going forward as all within the harmonics selected for a full cycle. However, aside from programming tedium, does this unnecessarily confuse the end user because the rules are different? (Does anybody usually read the Help sections despite the need to have them?)
Surely there is a sane way to do this that meets all the needs.
Re: Labels / selection of multiple solunar types
Posted: Mon May 27, 2024 7:29 pm
by Jim Eshelman
Under the heading of "Here's a Crazy Idea" ...
To keep the priority role of basic SSR/SLR and their sub-charts, and to allow everything else, have all other return options - and, actually, all other predictive options perhaps - on a second page. Something like the way Midpoints are handled in Chart Options, where the only thing you see is the Midpoints button, you do stuff on the Midpoints page, and when you Save that page you trust that those settings are part of the Chart Options.
Similarly, one could have the same SSR/SLR/subs setup as now - no need to redesign that page at the moment - plus a More button (or some other wording). Put it before "Select All" so it is under Solar Return and Lunar Return row headers.
That More page (Other Returns or whatever) can just be a full page of other methods to calculate. All the other options are picked on the front page. (I doubt we exceed the 30 methods that could fit on one screen <g>.)
Bet of best is it doesn't require redesigning the whole Solunars page!