Memory System Redesign (completed)

[mbavec]

Hello, if you recall at our last meeting there were quite a few ideas proposed about changing up the (at the moment) very simple snapshot system. There seemed to be a general desire for a more file-like management of memory but there was a lot of conflicting visions on the exact details so I have opened this discussion to discuss in more concrete terms what your wishes are for the memory system.

So far I've come up with this outline for the system:

1. In memory, specimen's consist of a name, a URL and a "last saved date"
2. In memory, there are two reserved slots called "currentURL" and "currentName" which store the URL signature of the specimen being currently worked on and the name of the file that said specimen is attached to respectively.
3. The two "current" slots are updated constantly and without any manual input from the user whenever there is a parameter change or a new specimen is opened.
4. There will be two buttons used for saving, "save" and "save as". Save will simply override the URL associated with currentName in memory with the new currentURL. It will also update the "last saved" date. Save as on the other hand will create a new URL-name pair in memory.
5. If a user is working on a specimen which is not yet saved and clicks "save" instead of "save as" it will save the specimen as "untitled (n)" where n is the number of untitled specimens in memory. (Alternatively, we could also force the user to name all saved specimens, do let me know which option you prefer.)
6. Since memory is based on names of specimens, all names must be unique.

I hope that sufficiently details the specifics of the system I'm envisioning. This is in my opinion the most realistic (given the time frame) system we can implement while also being a big improvement over the old system. Let me know about any disagreements or questions you might have about this.

[gwhitney]

Soliciting input also from @katestange and @Vectornaut. Reviewing your points, here are my thoughts/questions, followed by my feedback on each of your points.

A) You and we together have already felt/decided that specimens should have associated names, and that it should be easy/intuitive to name the currently shown specimen. (That's not a change from anything you say, just laying the foundation.)

B) I am unclear on whether a brand-new specimen starts with a name, or if instead the spot where the name would be shown starts empty but there is some clear way to add a name. It would certainly be fine with me if the name started as "Untitled (n)" and there is simply always a name showing.

C) That point does then beg the question of how you create a brand-new specimen? Is there a "New Specimen" button somewhere? If not, then it seems the only way to create one is to start with an existing specimen and rename it. If so, then the question of what/whether/when to name new specimens becomes moot.

D) Since names are unique, that leads to the question of whether the namespace for the "curated" specimens and "my specimens" are distinct. I.e., if there is a curated specimen named "Rainbow" am I allowed to have my own distinct specimen named "Rainbow"? Or is it the case that if I open the curated "Rainbow" in the specimen editor, and then if I do anything that would change the URL, the name autochanges to "My Rainbow (n)" to keep names globally unique? (Or something like that.)

E) Did we agree that when the page is first loaded, if there is a currentName and currentURL in the browser memory, then Numberscope opens up showing that specimen? That would be fine by me.

F) Is the name encoded in the URL so that if I give someone the URL for my specimen, it comes up in their browser with the name I gave it? (Seems desirable, I think.)

Now, to each of the points you list:

1. I am fine with each specimen being associated to a name, url, and last modified date, if that's not too complicated for you.

2. Seems good. Possibly the displayed name should be suffixed with "(edited)" when the currentURL does not match the URL associated with the currentName (although for a different scheme, see my thoughts on (4).)

3. Sounds good.

4. To me, in the system as otherwise envisioned here, you need at most one save button. When you change the name of the specimen, that in effect operates as "Save as" -- it creates a new specimen in My Specimens with that new name and the contents being whatever's currently shown.
   The question of whether you need the regular save button is whether the specimen associated with the current name also auto-updates on every save. If it does, then no save button is needed at all. But maybe then it is annoying/confusing if I open up my favorite specimen and "play around with it" then I have lost that favorite specimen in the state I started with? That's a real worry, so I guess my recommendation would be to have a save button, and not change the URL associated with the current name until the save button is clicked. (But I could be convinced the other way if someone has arguments for no save button at all, especially if there is an undo button.)

In any case, with easy renaming I don't see any need for a "Save as". And we definitely want to keep the controls as simple as possible for the functionalities we envision.

5. If in point (B) above brand-new specimens always start with a name, then this is moot. I would probably myself choose for brand-new specimens to start with some name, but I am perfectly comfortable with whatever decision you make on that point.

6. Agreed.

[gwhitney]

2. New users accessing the site for the first time will be immediately presented with some default specimen chosen by the Numberscope team

I think our suggestion for this is just one of the curated specimens, chosen at random.

[gwhitney]

5. The name will indeed be included in the URL, but this has no bearing on the functioning of the memory system which will still rely on URL-name pairs.

But I mean, there won't be any way for a specimen named "Unicorn" to correspond to a URL that encodes "Rainbow," will there? Seems like that could get weird/confusing.

[gwhitney]

"save" and "save as" buttons into one by making it so that "save" acts as "save as" when the specimen name is changed in the editor (if I understood the idea correctly).

Well actually, I was proposing that simply the act of changing the name does an implicit save under the new name, because why not? But your proposal that changing the name doesn't have any immediate effect, but then at the next save it just saves under the new name, is also fine. I am OK with you doing as the team feels best.

I also see the point that if I have specimens named "Lamppost" and "Whirlwind" and I edit the Lamppost specimen and while I am doing that I type Whirlwind into the name field, then at some point it ought to ask me if I really mean that. I don't think it's too critical though; feel free to implement or not as you see fit, and if you do implement such a warning/check, feel free to pick which you think is the more appropriate time: when the duplicated name is entered, or when the person first tries to save under the duplicated name.

[mbavec]

5. The name will indeed be included in the URL, but this has no bearing on the functioning of the memory system which will still rely on URL-name pairs.

But I mean, there won't be any way for a specimen named "Unicorn" to correspond to a URL that encodes "Rainbow," will there? Seems like that could get weird/confusing.

No definitely not. The name of the specimen will always correspond to the name in the url.

[mbavec]

"save" and "save as" buttons into one by making it so that "save" acts as "save as" when the specimen name is changed in the editor (if I understood the idea correctly).

Well actually, I was proposing that simply the act of changing the name does an implicit save under the new name, because why not? But your proposal that changing the name doesn't have any immediate effect, but then at the next save it just saves under the new name, is also fine. I am OK with you doing as the team feels best.

I also see the point that if I have specimens named "Lamppost" and "Whirlwind" and I edit the Lamppost specimen and while I am doing that I type Whirlwind into the name field, then at some point it ought to ask me if I really mean that. I don't think it's too critical though; feel free to implement or not as you see fit, and if you do implement such a warning/check, feel free to pick which you think is the more appropriate time: when the duplicated name is entered, or when the person first tries to save under the duplicated name.

Yes, so the way we've decided to do it is that renaming + saving is the way to make a new specimen. In other words, the user first renames the specimen then hits save. We think this is more usable because it prevents typos in the name from being saved as specimens in their own right and just makes the action of saving much more deliberate.

[gwhitney]

Otherwise I think you and I have converged, but you may at this point want to wait until Monday to see if @katestange or @Vectornaut have any input (or if they chime in before then). Thanks!

[gwhitney]

OK, I think we are settled on this discussion, with our meeting as of today. Locking the conversation.

[gwhitney]

Now I guess instead of "locking" a conversation, we can just "close" it. Doing so.