Last blog post I mentioned a problem with the selections, and it has been problematic in many areas for months. As I began to understand it more—because it was an afterthought, "isn't selection is just a bit set on some structure?"—I realized I need to go back to first principles.
I repeatedly go to Polya's How to Solve It for inspiration, and one of the main steps is understanding the problem. And under that is draw a picture. And introduce proper notation. It is math book, but I think that is so great. Proper notation so that you have the units or concepts that you can then manipulate on their own.
And I always underestimate drawing a picture, because usually it seems too simple. Just a box with two arrows, I should be able to keep that in my head. But I'm wrong, it's not about what I can do—it is about making the problem as simple as possible for you. Because the end result is what you create, not the method you took to get there.
I drew this:
And actually I'm cheating because that has the undo system on top, and below that I added restoring selections. And once I drew it, I was like: "oh yeah, just grab the current selection before you do an operation, and another after the operation. Then when you undo, use them again."
But I could not see that without a picture.
And all of a sudden dozens of bugs are fixed all at once.
I repeatedly go to Polya's How to Solve It for inspiration, and one of the main steps is understanding the problem. And under that is draw a picture. And introduce proper notation. It is math book, but I think that is so great. Proper notation so that you have the units or concepts that you can then manipulate on their own.
And I always underestimate drawing a picture, because usually it seems too simple. Just a box with two arrows, I should be able to keep that in my head. But I'm wrong, it's not about what I can do—it is about making the problem as simple as possible for you. Because the end result is what you create, not the method you took to get there.
I drew this:
And actually I'm cheating because that has the undo system on top, and below that I added restoring selections. And once I drew it, I was like: "oh yeah, just grab the current selection before you do an operation, and another after the operation. Then when you undo, use them again."
But I could not see that without a picture.
And all of a sudden dozens of bugs are fixed all at once.
What has gone well so far
I have been working on saved views, which are like sheets in Excel or tabs in Chrome. Since view changes are already designed to go on the undo stack, it is easy to take one and reapply it.
It came together much faster than I expected.
What I got wrong
1. File management
I underestimated the value of having an existing model of how file management works. And I didn't realize that people would want to separate certain types of ideas such that they aren't connected with other ideas.
One of the rules in the design philosophy is to not have file management, and the design benefited from the constraint by allowing huge outlines to be performant.
I'm hoping that saved views alleviate some of the pain from now having things in separate files, by allowing different "windows" to be switched to by clicking on the saved view.
But now I do see that it is important for a lot of users to have completely separate outlines in the form of files.
While I didn't envision this scenario beforehand, it should be a quick feature—I mean computers want everything in files.
2. Selection
There are a bunch of little ways that operations don't respect what element was previously focused.
Nobody has said anything about it, but I notice it all the time and it breaks the flow of doing everything with the keyboard. You don't need the mouse or anything, but you have to bring the focus back on the item you had before. It is more prone to happen when you are undoing an operation.
I have never written a game before, but somewhere I picked up an idea from John Carmack of having a single path for drawing a frame, and to try to keep that under 16.6ms or whatever in the worst case.
I don't have any hard bounds on the sizes of things, but I think Stepanov says that everything that is log(N) is constant time because it isn't going to be bigger than 32, so practically constant time—I really like his lectures.
Anyways, the complication here—and what I need to redesign—is that selection is applied again at the end of building a frame, like another layer on top of the model, which is on top of the view.
I could go patching these little problems, but I feel I didn't understand the problem when I was writing it as I do now, and I can probably do better now.
I have been working on saved views, which are like sheets in Excel or tabs in Chrome. Since view changes are already designed to go on the undo stack, it is easy to take one and reapply it.
It came together much faster than I expected.
What I got wrong
1. File management
I underestimated the value of having an existing model of how file management works. And I didn't realize that people would want to separate certain types of ideas such that they aren't connected with other ideas.
One of the rules in the design philosophy is to not have file management, and the design benefited from the constraint by allowing huge outlines to be performant.
I'm hoping that saved views alleviate some of the pain from now having things in separate files, by allowing different "windows" to be switched to by clicking on the saved view.
But now I do see that it is important for a lot of users to have completely separate outlines in the form of files.
While I didn't envision this scenario beforehand, it should be a quick feature—I mean computers want everything in files.
2. Selection
There are a bunch of little ways that operations don't respect what element was previously focused.
Nobody has said anything about it, but I notice it all the time and it breaks the flow of doing everything with the keyboard. You don't need the mouse or anything, but you have to bring the focus back on the item you had before. It is more prone to happen when you are undoing an operation.
I have never written a game before, but somewhere I picked up an idea from John Carmack of having a single path for drawing a frame, and to try to keep that under 16.6ms or whatever in the worst case.
I don't have any hard bounds on the sizes of things, but I think Stepanov says that everything that is log(N) is constant time because it isn't going to be bigger than 32, so practically constant time—I really like his lectures.
Anyways, the complication here—and what I need to redesign—is that selection is applied again at the end of building a frame, like another layer on top of the model, which is on top of the view.
I could go patching these little problems, but I feel I didn't understand the problem when I was writing it as I do now, and I can probably do better now.