Sequence and visualizer switcher [cleaned]

[gwhitney]

By submitting this PR, I am indicating to the Numberscope maintainers that I have read and understood the contributing guidelines and that this PR follows those guidelines to the best of my knowledge. I have also read the pull request checklist and followed the instructions therein.

---

Switchers

• Adds a new button on each tab to change the sequence/visualizer. It is still not possible to switch to an OEIS sequence (that's added in the next PR in the sequence, but changing to all other sequences/visualizers should work, provided they work themselves.

Parameter Editor

• Updates the param editors to work with switching visualizers and specimens.
• More specifically, when a paramable is assigned to (like in the case of switching a visualizer specimen), the watch function gets called that makes sure to reset all the statuses of the parameters. This is so that no errors are carried over from the previous visualizer/sequence.

Specimen bar

• Refactors the buttons in the bar into a button container, and reworks the save button popup to fix some visual bugs.

Mobile

• Changes the mobile vs tablet-desktop breakpoint to 800px, as the specimen bar occupies a lot of horizontal space on the screen, and makes that breakpoint into a single global variable that can be changed in one place (the new src/assets/scss/_variables.scss file).

Scope

• Fixes some additional tab bugs, where the dropzones sometimes don't have the correct status. [This was the remaining concern about #377.]
• Mobile should be fully working at this point.

[gwhitney]

OK, in addition to base performance/code review which still need to occur (and anyone feel free to pitch in), I feel as though there are a significant amount of other questions/concerns/aspects to consider and possibly improve/fix prior to merging this PR into ui2. Several that immediately come to mind are:

[This first one needs some discussion of what design to pursue here.]

• [ ] The switcher buttons on the tabs are bulky, in large part because of the explanatory text that's needed because otherwise they are not clear. I think we should find a way to streamline them. In particular, I think that rather than the button where it is now, it would be perfectly clear to have it be one of those "Expand section" triangles (like ▸ or ›) that when clicked would rotate to point down and the Switcher popup would have its appropriate corner there, like a dropdown menu of sequences or visualizers. That would take up very little space while you are not switching. There of course may be other options for streamlining, including have just the icon as it is now, and having the explanatory text pop up on hover, like a tooltip.

[So far, there is consensus that the following items should be changed as described in order to merge this PR.]

• [x] The white-on-black blocks for the different sequence/visualizer options don't seem to mesh with the rest of the UI. In particular, I thought the design was that they would be SpecimenCards just like in the Gallery, but just keeping either the visualizer fixed to what it currently is and showing all of the different Sequences, or vice-versa for the Visualizer switcher. I propose that we switch to that design before merging this PR.
• [x] The dimensions of the Switcher pop-ups vs. the option blocks are awkwardly chosen so that (a) not quite four of them fit on a row, leaving a lot of useless whitespace at the right with only three on a row; and (b) almost exactly two rows of them fit in the Switcher, sometimes making it unclear you can scroll. We propose that the dimensioning should be changed so that an integer number of said blocks (or Specimen Cards, if we switch to that) fit on a row, with just a nice margin on the left and right, and that a "half-integer" number of them fit vertically, so that it is always pretty clear that you are going to need to scroll.
• [x] In the Sequence switcher, there's a lot of useless whitespace to the right of the title and search bar. I'd propose that they be put on one line, with the search bar to the right of the title. This seems to mesh with typical web browser layout, with the URL/search bar as part of the top bar.
• [ Superseded by dimensioning] When you first open a Switcher, there is no visual indication that you can scroll down to see more options. A very minimalist scrollbar appears on the right when your mouse enters the Switcher window, but it disappears pretty quickly. I'd suggest it just be always visible, and perhaps be slightly clearer as to the fact that it is a scroll bar (i.e., the full range should be visible, say in light grey, as opposed to now where just the current range shown is in black and everything else is in plain white, leaving us to intuit that's a bar that could be scrolled). I.e., I'd suggest that the view that's visible when the mouse is actually over the thin vertical line that constitutes the scroll bar be visible at all times.

There are likely other things, very open to suggestions, and will start to process/analyze/make fixes based on Kate's feedback above.

[katestange]

Regarding the switching icon, I agree it is too big. I may not be imagining your first suggestion in the way it was intended, but it seems like the user may not figure out how to switch in that scenario? Or does it look as if the title of the visualizer is inside a drop-down, which is an intuitive way to discover switching? I think the icon without text (text on mouseover) is pretty clear. I mean, if I was guessing what a big button next to the sequence or visualizer name with circle arrows on it was going to do, I'd guess it was something to the entire visualizer, so that's where I'd look for the capability to switch. This may need more thought or creativity, however, as I think discovering intuitively that switching is possible is crucial to the appeal of the tool. Some people are going to land there and just start playing to figure out what it is (even if we make a tutorial, I find I always click through those things without retaining anything). Maybe we could even make the switcher buttons dance until the user mouses over or uses one? Maybe that's a bad idea? I welcome more ideas!

[katestange]

• [x] The white-on-black blocks for the different sequence/visualizer options don't seem to mesh with the rest of the UI. In particular, I thought the design was that they would be SpecimenCards just like in the Gallery, but just keeping either the visualizer fixed to what it currently is and showing all of the different Sequences, or vice-versa for the Visualizer switcher. I propose that we switch to that design before merging this PR.

Agree wholeheartedly!

• [x] The dimensions of the Switcher pop-ups vs. the option blocks are awkwardly chosen so that not quite four of them fit on a row, leaving a lot of useless whitespace at the right with only three on a row. I propose that the dimensioning should be changed so that an integer number of said blocks (or Specimen Cards, if we switch to that) fit on a row, with just a nice margin on the left and right.

Agree! As wide as visual comfort allows (why not?).

• [x] In the Sequence switcher, there's a lot of useless whitespace to the right of the title and search bar. I'd propose that they be put on one line, with the search bar to the right of the title. This seems to mesh with typical web browser layout, with the URL/search bar as part of the top bar.

Agree.

• [x] When you first open a Switcher, there is no visual indication that you can scroll down to see more options. A very minimalist scrollbar appears on the right when your mouse enters the Switcher window, but it disappears pretty quickly. I'd suggest it just be always visible, and perhaps be slightly clearer as to the fact that it is a scroll bar (i.e., the full range should be visible, say in light grey, as opposed to now where just the current range shown is in black and everything else is in plain white, leaving us to intuit that's a bar that could be scrolled). I.e., I'd suggest that the view that's visible when the mouse is actually over the thin vertical line that constitutes the scroll bar be visible at all times.

Agree.

[gwhitney]

I may not be imagining your first suggestion [on the UI presentation of the sequence switcher] in the way it was intended,

OK, at some point when I have a chance I will make a branch off of this that presents it in this way and post a screenshot and/or the name of the branch you can pull to try it out.

[gwhitney]

Agree [on the latter four checkboxes in my preliminary concerns review]

OK, absent any counterpoint from @Vectornaut I will consider these last four items in that comment all to be "todo" items for merging this PR; I will edit that comment accordingly.

[gwhitney]

• In the Sequence switcher, there's a lot of useless whitespace to the right of the title and search bar. I'd propose that they be put on one line, with the search bar to the right of the title. This seems to mesh with typical web browser layout, with the URL/search bar as part of the top bar.

OK, how's that look now?

[gwhitney]

Regarding the switching icon, I agree it is too big. I may not be imagining your first suggestion in the way it was intended,

OK, I have created a branch switcher_by_arrow that you can pull and try. Rather than commenting any further or posting a screenshot, I figured I would just let you see how it feels. If it seems like a worthwhile direction, I can polish it up just a little and push it down to here. If it doesn't seem promising, I will just delete the branch, no harm done. Looking forward to your thoughts and to eventually settling down on a "clean" way to invoke the switchers.

[katestange]

I like the OEIS box in its new location. I guess in the longer term (beyond this PR) we might want OEIS sequences that the user adds to hang around in this dialog box for future use, with a delete button option.

[katestange]

I looked at switcher_by_arrow. It is much prettier than the current pr, but I worry it's too subtle. I don't think I would ever have moused over it or clicked on it, probably figuring it was just part of the static design. (Except that you told me to.)

[gwhitney]

I like the OEIS box in its new location. I guess in the longer term (beyond this PR) we might want OEIS sequences that the user adds to hang around in this dialog box for future use, with a delete button option.

Yes, we shall see what the Delft team cooked up when we get to the next PR. I don't think we ever saw a demo of that.

[gwhitney]

looked at switcher_by_arrow. It is much prettier than the current pr, but I worry it's too subtle.

OK, gotcha. I can delete that branch at an appropriate time. Next option to try? Maybe make the name of the visualizer (or sequence) look like an entry area, the kind that pulls down to a little menu when you click on it? Vaguely like the one in the center of this image but in our case when you do click to drop down the options, it will be a whole panel of thumbnails?

[gwhitney]

• I'd suggest that the view that's visible when the mouse is actually over the thin vertical line that constitutes the scroll bar be visible at all times.

It turns out that in the current versions of all the top browsers, these "disappearing scrollbars" are the default and they are not controllable by the webpage via css or html -- there is a user preference Settings > General > Browsing > Always show scrollbars if someone wants their scrollbars not to disappear in this way. Hmmph.

So as far as I can tell, the only way to make always-visible scrollbars is to use a within-javascript scrollbar package that draws the scrollbar itself (like with svg) rather than using the builtin browser scrollbars. There are a few such packages; we could add one to the project, whichever seems simplest to use. Or should we just leave this be, and figure that to switch to any of the options you'll have to mouse over the switcher popup and will probably notice the scrollbar indicator and likely understand that it means you can scroll? I could go either way: I am happy to do the work to integrate a scrollbar package, but could also see an argument that the departure from browser-standard scrollbars is not worth it.

[gwhitney]

Question to @katestange @Vectornaut: When you click a "change visualizer" or "change sequence" button, should the resulting list of options include the current visualizer/sequence, or should it leave the current one out (since there's really no point in switching to the one you're already using)? One possible functionality of switching to the one you are already using, though, is that all of its parameters will be reset to their defaults, so maybe we should leave it in the list?

[katestange]

About scrollbars:

1. On chromium and microsoft edge for me, they are always visible by default apparently.
2. On Firefox they disappear, and there's a problem that the overall window scrollbars actually obscure the Visualizer and Sequence docking pane scrollbars when the panes are docked right. This will be fixed when we get rid of the footer, I hope.
3. I see an argument for not departing from standard browser behaviour, especially as it seems very variable.
4. What about an alternative: we make the height of the chooser box such that some of the thumbnails are always half-hidden; that's a strong visual clue? This must (?) be what the browser designers were thinking?

[katestange]

Question to @katestange @Vectornaut: When you click a "change visualizer" or "change sequence" button, should the resulting list of options include the current visualizer/sequence, or should it leave the current one out (since there's really no point in switching to the one you're already using)? One possible functionality of switching to the one you are already using, though, is that all of its parameters will be reset to their defaults, so maybe we should leave it in the list?

Hmm, I was going to suggest changing "Change Visualizer" at the top of the change pane to "Choose Visualizer". I tend to think we should keep the current one...

[gwhitney]

• [The options in the Switcher] would be SpecimenCards just like in the Gallery

This has been implemented in the latest push to this PR. Please take a look and let me know what you think.

I was going to suggest changing "Change Visualizer" at the top of the change pane to "Choose Visualizer". I tend to think we should keep the current one

Yes, the first does seem more natural, and I agree that in that context keeping the current one also makes sense. These choices are incorporated into the latest push.

[gwhitney]

4. What about an alternative: we make the height of the chooser box such that some of the thumbnails are always half-hidden; that's a strong visual clue?

Good idea, I will change that to-do item accordingly.

[katestange]

I'm currently seeing inadequate space between the two parts of the Gallery (the words "Saved Specimens" are bunched upward too much. Is this new? I don't remember it.

[katestange]

There seems to be a max width to the choose visualizer/sequence modal which is just slightly too small for four thumbnails across, so there's a lot of whitespace on the right margin. Better to set max width just slightly larger than accommodating an integer number of thumbnails across?

[katestange]

The thumbnails on switching really seems to be working pretty well now!

[gwhitney]

I'm currently seeing inadequate space between the two parts of the Gallery

How about now?

[gwhitney]

There seems to be a max width to the choose visualizer/sequence modal which is just slightly too small for four thumbnails across, so there's a lot of whitespace on the right margin. Better to set max width just slightly larger than accommodating an integer number of thumbnails across?

Yes, that's the checkbox item about "Dimensioning the Switchers" that is up next on my list of to-do items for this PR: just over an integer number of panels wide, and roughly an odd number of half-panels high.

[gwhitney]

The thumbnails on switching really seems to be working pretty well now!

Great, have checked off that box on the to-do items.

[katestange]

I'm currently seeing inadequate space between the two parts of the Gallery

How about now?

looking good, resolving to hide this portion of the conversation

[gwhitney]

There seems to be a max width to the choose visualizer/sequence modal which is just slightly too small for four thumbnails across, so there's a lot of whitespace on the right margin. Better to set max width just slightly larger than accommodating an integer number of thumbnails across?

Yes, that's the checkbox item about "Dimensioning the Switchers" that is up next on my list of to-do items for this PR: just over an integer number of panels wide, and roughly an odd number of half-panels high.

OK, how does the size and location of the Switcher ("Choose Visualizer" and "Choose Sequence") popups seem now? You may want to try it in different browser window sizes. If the latest commit is working, you should see them sized to be (roughly) a whole number of thumbnails wide, and either (A) tall enough to fit all thumbnails, or (B) if that's not possible, then not close to a whole number of thumbnails high, except if there is only room for one thumbnail high, in which case there's nothing that can be done -- we don't want to make it less than one thumbnail high.

[katestange]

There seems to be a max width to the choose visualizer/sequence modal which is just slightly too small for four thumbnails across, so there's a lot of whitespace on the right margin. Better to set max width just slightly larger than accommodating an integer number of thumbnails across?

Yes, that's the checkbox item about "Dimensioning the Switchers" that is up next on my list of to-do items for this PR: just over an integer number of panels wide, and roughly an odd number of half-panels high.

OK, how does the size and location of the Switcher ("Choose Visualizer" and "Choose Sequence") popups seem now? You may want to try it in different browser window sizes. If the latest commit is working, you should see them sized to be (roughly) a whole number of thumbnails wide, and either (A) tall enough to fit all thumbnails, or (B) if that's not possible, then not close to a whole number of thumbnails high, except if there is only room for one thumbnail high, in which case there's nothing that can be done -- we don't want to make it less than one thumbnail high.

This is working on both Edge and Chromium. (Firefox just refused to load right now, not sure why.) I'm assuming the following is the desired behaviour (which seems good to me). To be precise, what I'm seeing is that if you resize dynamically with the dialog open, the box just scales linearly with browser dimension and doesn't "pop" or avoid anything, even after you finish resizing and let the mouse drag go. But if you resize and then reload or else close and reopen the dialog, it will choose a nice size the way you describe for the new dimensions. I didn't try mobile because it's still haywire. I did try with various docked/undocked positions.

[gwhitney]

This is working on both Edge and Chromium. (Firefox just refused to load right now, not sure why.)

Hmm, it's running on Firefox (version 124) for me right now, but it would be good to get independent verification of that. @Vectornaut?

I'm assuming the following is the desired behaviour (which seems good to me). To be precise, what I'm seeing is that if you resize dynamically with the dialog open, the box just scales linearly with browser dimension and doesn't "pop" or avoid anything, even after you finish resizing and let the mouse drag go. But if you resize and then reload or else close and reopen the dialog, it will choose a nice size the way you describe for the new dimensions.

Yeah, that's really sort of laziness on my part because I didn't really worry about someone resizing the screen with the popup open. Do you want it to try to adapt to resizing on the fly?

I didn't try mobile because it's still haywire. I did try with various docked/undocked positions.

Yeah, I'm kind of leaving mobile until the end because it's not as much in my comfort zone. Unless someone else wants to jump in (and if so, feel free!), let's get everything else working first.

As far as I can see, once we're comfortable with this popup sizing point, and aside from mobile, there are just two remaining points: (A) how to streamline the indication in the parameter tabs of how you pop up the Switcher dialogues, so that it takes up less screen space but is still as totally clear that you can change visualizers and how; and (B) how to deal with default values. On (B) I think the latest proposal is to add a "placeholder" setting to param descriptions that defaults to the default value for that param -- should I just go ahead and try implementing that as soon as the popup sizing is declared good?

[katestange]

Hmm, it's running on Firefox (version 124) for me right now, but it would be good to get independent verification of that. @Vectornaut?

No I meant Ubuntu refused to launch Firefox. Nothing to do with Numberscope. Probably my recent OS upgrade.

Yeah, that's really sort of laziness on my part because I didn't really worry about someone resizing the screen with the popup open. Do you want it to try to adapt to resizing on the fly?

I think it's perfect as-is. The whole choosing a size thing is to help when it first opens. By the time someone is resizing they should have figured out there's a scrollbar.

As far as I can see, once we're comfortable with this popup sizing point, and aside from mobile, there are just two remaining points: (A) how to streamline the indication in the parameter tabs of how you pop up the Switcher dialogues, so that it takes up less screen space but is still as totally clear that you can change visualizers and how; and (B) how to deal with default values. On (B) I think the latest proposal is to add a "placeholder" setting to param descriptions that defaults to the default value for that param -- should I just go ahead and try implementing that as soon as the popup sizing is declared good?

I think the pop-up sizing is declared good, at least from my perspective. And I'm ok with the latest proposal on (B).

[gwhitney]

OK, resolving all the discussion items concerning pop-up sizing and proceeding with the latest default-displaying plan.

[gwhitney]

OK, there are now placeholders for optional parameters. I have used them to reduce the descriptions of some of the parameters, because hopefully they make it clear enough what's going on. I also restored the Differences visualizer to default to the full triangle of differences. Let me know what you think.

[gwhitney]

When the placholders are good, the next item up is a new one from this discussion:

• [x] center the Switcher popups over the current visualizer canvas area, whatever it may be based on the positioning of the parameter tabs, and make the visualizer pause while the popups are shown.

[katestange]

Looks great (and I'm more sold on this approach now), only one request. I think the grey needs to be slightly paler. It looks like black to me, but the behaviour is different in that when you put your cursor there, you can't edit what's there, you just overwrite. So it needs to be clearer that it's a different colour.

[gwhitney]

I think the grey needs to be slightly paler.

How's this? Or we could go some pastel color, if you prefer.

[katestange]

I think the grey needs to be slightly paler.

How's this? Or we could go some pastel color, if you prefer.

I think it's good!

[gwhitney]

I think the grey needs to be slightly paler.

I think it's good!

Great, resolving all of the fill-in-defaults comments. Will tweak the popup positioning next.

[gwhitney]

OK, now the visualizer should be pausing itself while either of the Switcher dialogues are popped up. Will work on positioning centered over canvas next; it is trickier because the Switcher html element is not within the canvas, it's like an uncle of the canvas or something like that.

[gwhitney]

And now the Switcher should be centered over the visualizer canvas. Ready for checking how this looks to you.

[katestange]

Feedback:

1. The pause background works well, can resolve that.
2. The switcher centred works well at various sizes, can resolve that.
3. When the pop-up opens, you can click on the docked left or right regions, or the popup's X to close it. Should it also close when you click on the canvas or any other non-popup screen area? Currently that does nothing.
4. Also, I notice when you change visualizer, your dockers go back to the right. Perhaps the most desireable behaviour would be to have them stay where they are? People like to customize their setup.

[gwhitney]

3. When the pop-up opens, you can click on the docked left or right regions, or the popup's X to close it.  Should it also close when you click on the canvas or any other non-popup screen area?  Currently that does nothing.

Nice call. I didn't even realize I had changed behavior. Before my latest commit, clicking anywhere below the Specimen Bar (with the menu and specimen name and play/pause button etc.) but not on the Switcher popup would close it. Currently, clicking below the Specimen Bar but not on the visualizer canvas closes the Switcher. It would be slightly tricky and I think slightly odd for clicking on the Specimen Bar to affect the Switcher -- the Switcher is more part of the content of the page, rather than anything to do with the header, and in fact, all of the buttons on the Specimen Bar still work while the Switcher is popped up (yes, you can rewind the current visualization and have it start playing again underneath the popup if you want).

But I do think I know how I could also make clicking on the Specimen Bar close the Switcher (disabling all of the usual Specimen Bar interaction) if that's what we really want.

So, when the Switcher is up, where, other than its close button, do we want a click to close it? Reasonable possibilities I can think of include: (A) Nowhere else -- it's a modal, after all, and stays up until you explicitly dismiss it. (B) Only on a parameter tab (clicking back on one of the other subwindows, like for example you were going to start typing into one of the parameter values, closes the popup, but nothing else does). (C) Anywhere below the Specimen Bar but not on the Switcher itself (the Delft PR behavior as submitted). (D) Anywhere at all outside the Switcher, including the Specimen Bar.

In (D), the Specimen Bar can't have its usual functionalities; in (A),(B),(C) presumably (and unless we do some extra work) the Specimen Bar would continue to operate exactly as normal while the Switcher is popped up. However, we could by doing that bit of extra work suspend operation of the Specimen Bar while the Switcher is up, even if clicking on it doesn't close the Switcher, if that's really what's most desirable.

There may be other reasonable possibilities I am not thinking of, feel free to suggest. But I agree, the current behavior with my latest commit doesn't really make any sense and should be changed.

I don't have a strong sense/intuition of which of these is best/most intuitive/most appropriate for our user interface (probably because it never really occurred to me to click anywhere except the close button if I was done with the popup and wanted to dismiss it). So I am happy to either discuss at today's meeting or just go with whichever you pick -- just let me know.

4. Also, I notice when you change visualizer, your dockers go back to the right.  Perhaps the most desireable behaviour would be to have them stay where they are?  People like to customize their setup.

That's https://github.com/orgs/numberscope/discussions/6#discussioncomment-9970250, so out of scope for this PR (but happy to discuss/address it after the Delft PRs, perhaps along with human-readable URLs).

[gwhitney]

To summarize the agenda on this PR from the meeting today, there are three remaining to-dos:

• [ ] Restore the Delft-submitted behavior as far as clicks that close the switcher: option (C), Anywhere below the Specimen Bar but not on the Switcher itself.
• [ ] Remove the current "Change Sequence" button, render a bar that mimics the entry area of other parameters beneath the name of the current sequence, ending just to the left of a square button like the ones in the Specimen bar. The bottom of the box should be flush with the bar, and the bar and the box border should be the same weight. Inside the box should be mage:exchange-a icon. Clicking anywhere in the name of the icon and/or the box should bring up the switcher. The title of the box should be changed to "Current Sequence" and made smaller but left bold. The name of the sequence should be darkened to match the other input fields.
• [ ] Try to get mobile rendering (back?) in shape, since this PR claimed to complete it, but it currently has serious layout issues.

[gwhitney]

OK, that should take care of the first item.

[gwhitney]

OK, actually I just got involved with it and have pushed a commit that I think changes Switcher invocation in all the ways we discussed. Please check it out and beat on it and let me know what you think. If I missed anything in the plan just let me know.

[katestange]

It looks really good to me! And I think it does accomplish the "discoverability" really well, now that I see it in action. There are plenty of hints. I did beat on it a while and have no concerns except one small one: In the icon buttons on the header, the icons are slightly grey, not black. This should match (I think it's black right now).

[gwhitney]

In the icon buttons on the header, the icons are slightly grey, not black. This should match (I think it's black right now).

I matched the new buttons to the right of seq/vis names with the previously-existing buttons on the Specimen Bar: they are all dark grey, switching to black on hover, per the Delft team design. If you'd like different presentation/behavior, just let me know. Thanks!

[katestange]

In the icon buttons on the header, the icons are slightly grey, not black. This should match (I think it's black right now).

I matched the new buttons to the right of seq/vis names with the previously-existing buttons on the Specimen Bar: they are all dark grey, switching to black on hover, per the Delft team design. If you'd like different presentation/behavior, just let me know. Thanks!

Weird, I'm just not seeing that on my screen in either Edge or Chromium. It is always-black. I verified it with gpick on a screenshot without mouseover.

[gwhitney]

OK, I have to run now but when I next have a chance, I will compare Firefox (that I have been using) with Chromium. Edge isn't available for Linux, is it?

[katestange]

OK, I have to run now but when I next have a chance, I will compare Firefox (that I have been using) with Chromium. Edge isn't available for Linux, is it?

I have Edge on Ubuntu. I opened Firefox, I don't see grey there either.

[gwhitney]

Super weird. I will check all of FF, Chromium and Edge later and post screenshots.

[gwhitney]

Ah, you are absolutely right. I must not have checked again after making the icon into a component. Should be OK now, let me know.

[gwhitney]

I started taking a look at mobile because as far as I can see it is the only thing remaining on the to-do lists above, and despite what may have been said in the original submission of PR #359, at least in mobile emulation mode in Firefox developer tools, mobile still seems to be an absolute mess in this PR. To give the benefit of the doubt, maybe I messed up somewhere along in the cleaning/reintegration steps as the original PR sequence has now diverged quite substantially from the actual contents of ui2, and we really haven't been checking mobile for being at all reasonable along the way (since the original PR sequence didn't say mobile was "done" until #359).

So my proposal is: @katestange and/or @Vectornaut, please do final checking/evaluation of this PR in all the usual ways, but continuing to ignore mobile. When one or both of you is satisfied everything is OK, please merge this into ui2. Then we will add to our post-checklist an item to beat on and discuss the mobile ui and fix it up to our satisfaction, presumably in the next PR to ui2 after the Delft ones and definitely before ui2->main.

If this proposal is agreeable, then unless your checking reveals additional changes needed, which I am of course happy to work on, my plan will be not to do anything further on this PR and wait for it to be merged to ui2 (definitely squash!), at which point I will clean #360 and we will see how OEIS sequences work :-) etc. Thanks.