The files here are versioned and the versions are kept for 30 days by default so that data loss risk is reduced. We can also use this folder to integrate contributed maps into the big documentation maps.
I have already uploaded your first maps and images and also added file freeplaneTutorial.mm
Would you like to integrate your contributions into this file (which has a lot of context sometimes wrong) or start a completely new documentation map?
Regards,
Dimitry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to add that synchronization with google drive has risk of data loss in particular case where many people work on the same file at the same time. After they upload their modified versions only the last one is kept. Software developers use more sophisticated version control systems, which require some learning efforts. Therefore let us try the easy one for the beginning being aware of this possible problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would you like to integrate your contributions into this file (which has a lot of context sometimes wrong) or start a completely new documentation map?
I would like to use the current map only as a starting skeleton. I don't much care for the floating nodes.
I also don't like the way nodes are moved toward the root so they appear as paragraphs under a heading (as though this was a book). The first time I used this map, years ago, I could not get the hang of pressing the right arrow to get to a node that was directly beneath the heading node. I have the urge to press the down arrow.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Because you have already completed documentation of changing node size (I have added some questions to its thread) we want to integrate it soon. But where?
How you want to use freeplaneTutorial map? If you are not going to integrate your contributions their I would remove it from the folder. And in this case we need other map to integrate the new documentation. It means also that we can not ship the new map until it contains enough documentation to replace the existing one. How do you see it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Part of the chanllenge of having multiple people edit a map is tracking/finding changes. Currently you would have to compare the two maps unless there is a "track changes" like in Word. We should have a method for suggesting changes that is easy to note a suggestion for a change has been made. This will make it easier to follow its evolution. One person should have the authority and responsibility to make the actual change to the map after some approval process has occured.
Perhaps a child node with the changes with a red boarder? People could make a child node off the suggestion with appoval or other suggestions?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think each task can be developed in its own mind map so that there are no collisions there. When it is finished it should be integrated by simpe copy and paste. So even if collision happens on the intetration map no content is lost and the contribution can be easily merged again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is cleaning up to do and every part should be reviewed, corrected, and the new commands integrated.
How would the new standard contribution look like next to the current nodes?
The look wouldn't be consistent although it would meet the purpose of informing.
To do things right, we should revise all the commands and see how much we can recover.
The attached mindmap is my tentative idea of structure of documentation map.
The left side is taken from the current Documentation map. Basicaly it reflects the menu structure (the Where to find the command and What it does).
The right side is taken from the current Tutorial ( the How to use the program).
I didn't immediately know what the items on the left were but once I figured it out it seemed a decent organization. I altered the outline to make them look more like navigation and changed the title of the parent. I put a edited version of the basic start on the right to give an example of what I would see as the "flavor" that would be good for a beginer. If this is the go to document for experts as well I doubt they would be going to this section. The conversational style engages the user much more than minimized text an expert would prefer.
I am also still not clear on the conventions for working on these. Do we post them on google drive or do we post them in the thread that they relate or originated?
If I got it right, FreeplaneDocumentation min map is just a idea how the resulting documentation map could look like. We have not agreed on it yet. I think it is actually too big to serve as a style example and base for the futur work.
And I still do not understand where small pieces of documentation currently developed by Ken und Maggv can be collected. I think we can figure it out soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have created a google drive folder where we can collect all maps, images and other files.
https://drive.google.com/open?id=0B0x8X0FcVefpeUZmbXd6Ti1GOEE
The files here are versioned and the versions are kept for 30 days by default so that data loss risk is reduced. We can also use this folder to integrate contributed maps into the big documentation maps.
I have already uploaded your first maps and images and also added file freeplaneTutorial.mm
Would you like to integrate your contributions into this file (which has a lot of context sometimes wrong) or start a completely new documentation map?
Regards,
Dimitry
I would like to add that synchronization with google drive has risk of data loss in particular case where many people work on the same file at the same time. After they upload their modified versions only the last one is kept. Software developers use more sophisticated version control systems, which require some learning efforts. Therefore let us try the easy one for the beginning being aware of this possible problem.
I would like to use the current map only as a starting skeleton. I don't much care for the floating nodes.
I also don't like the way nodes are moved toward the root so they appear as paragraphs under a heading (as though this was a book). The first time I used this map, years ago, I could not get the hang of pressing the right arrow to get to a node that was directly beneath the heading node. I have the urge to press the down arrow.
Because you have already completed documentation of changing node size (I have added some questions to its thread) we want to integrate it soon. But where?
How you want to use freeplaneTutorial map? If you are not going to integrate your contributions their I would remove it from the folder. And in this case we need other map to integrate the new documentation. It means also that we can not ship the new map until it contains enough documentation to replace the existing one. How do you see it?
Part of the chanllenge of having multiple people edit a map is tracking/finding changes. Currently you would have to compare the two maps unless there is a "track changes" like in Word. We should have a method for suggesting changes that is easy to note a suggestion for a change has been made. This will make it easier to follow its evolution. One person should have the authority and responsibility to make the actual change to the map after some approval process has occured.
Perhaps a child node with the changes with a red boarder? People could make a child node off the suggestion with appoval or other suggestions?
I think each task can be developed in its own mind map so that there are no collisions there. When it is finished it should be integrated by simpe copy and paste. So even if collision happens on the intetration map no content is lost and the contribution can be easily merged again.
There is cleaning up to do and every part should be reviewed, corrected, and the new commands integrated.
How would the new standard contribution look like next to the current nodes?
The look wouldn't be consistent although it would meet the purpose of informing.
To do things right, we should revise all the commands and see how much we can recover.
The attached mindmap is my tentative idea of structure of documentation map.
The left side is taken from the current Documentation map. Basicaly it reflects the menu structure (the Where to find the command and What it does).
The right side is taken from the current Tutorial ( the How to use the program).
I find the reference part on the left confusing.
I hate loosing work that has been done. Can someone be assigned the task of downloading the contents of the google drive on a schedule?
Manning, I do not see any scenario we could loose anything.
Google saves all revisions 30 days long. They are available for each file of the drive.
What do you mean?
I didn't immediately know what the items on the left were but once I figured it out it seemed a decent organization. I altered the outline to make them look more like navigation and changed the title of the parent. I put a edited version of the basic start on the right to give an example of what I would see as the "flavor" that would be good for a beginer. If this is the go to document for experts as well I doubt they would be going to this section. The conversational style engages the user much more than minimized text an expert would prefer.
I am also still not clear on the conventions for working on these. Do we post them on google drive or do we post them in the thread that they relate or originated?
If I got it right, FreeplaneDocumentation min map is just a idea how the resulting documentation map could look like. We have not agreed on it yet. I think it is actually too big to serve as a style example and base for the futur work.
And I still do not understand where small pieces of documentation currently developed by Ken und Maggv can be collected. I think we can figure it out soon.