Dev Blog #14: DocTree gets name, moves up schedule.
I posted a Feature Creep blog a couple of days ago about some ideas I was having about Davenport's undo/redo functionality - specifically that I was intending to make it fully non-destructive and part of the saved file, so that all your edits and changes of mind are preserved and you can work on any 'branch' you feel like at any time.
The more I thought about it the more I knew this was going to be a defining feature of the app, from the interface to the way the app itself is used. That meant two things: the idea needed a name, and it needed to happen now rather than later.
Thus the Davenport DocTree: a branching document where no edit is destructive. The core data structure and editing hooks are already mostly in place, so the next step is the user interface, which I'm imagining will look a bit like a railway map:
This would be the tree if you created a single note (green circle), edited it (white circle), deleted it (red circle), then hit undo and edited it twice more instead.
To prevent the tree view getting cluttered with minor corrections, I plan to visually 'stub' short side branches unless they are moused over or manually unfolded, so most of the time you would just see a 'prickly line' representing the active branch.
Mousing over one of the 'stations' on the line will show you a live preview of what that edit was, so between that and the colour-coding you can quickly find the point in your edit history you are looking for and return to that point.
You will also be able to call up edit-tree histories for individual notes, and mouse over each 'station' to see all the versions of that note there have ever been in every branch.
There are loads more features to come, but this ought you give you a flavour for what working with Davenport's DocTree will be like.
Update: Did a bit of research and found this interesting study about the usability of different tree representations. Nice when someone does the hard work for you!
The more I thought about it the more I knew this was going to be a defining feature of the app, from the interface to the way the app itself is used. That meant two things: the idea needed a name, and it needed to happen now rather than later.
Thus the Davenport DocTree: a branching document where no edit is destructive. The core data structure and editing hooks are already mostly in place, so the next step is the user interface, which I'm imagining will look a bit like a railway map:
This would be the tree if you created a single note (green circle), edited it (white circle), deleted it (red circle), then hit undo and edited it twice more instead.
To prevent the tree view getting cluttered with minor corrections, I plan to visually 'stub' short side branches unless they are moused over or manually unfolded, so most of the time you would just see a 'prickly line' representing the active branch.
Mousing over one of the 'stations' on the line will show you a live preview of what that edit was, so between that and the colour-coding you can quickly find the point in your edit history you are looking for and return to that point.
You will also be able to call up edit-tree histories for individual notes, and mouse over each 'station' to see all the versions of that note there have ever been in every branch.
There are loads more features to come, but this ought you give you a flavour for what working with Davenport's DocTree will be like.
Update: Did a bit of research and found this interesting study about the usability of different tree representations. Nice when someone does the hard work for you!
Comments
Post a Comment