Re: [Freemind-developer] FreeMind Design aspects
A premier mind-mapping software written in Java
Brought to you by:
christianfoltin,
danielpolansky
From: Ray B. <ray...@co...> - 2008-01-23 17:22:18
|
Dimitry, I agree with you that we need to understand where we are going before we start the refactoring. I'm not yet in agreement that we should go with a small kernel model for the new design. I'm not saying we shouldn't, it's just that the only designs that have been offered, so far, are stick to the old design, or go with a radical new small kernel design. Your design may turn out to be the best choice, but I don't know that, yet. A Mind Map Editor, which is what we have, is very different from an operating system or a browser. We should think about what the software is supposed to do, and evaluate each possible design based on those goals. Below is a partial example of the kind of analysis I'm talking about: -------- First, we identify the overall goals for our software: 1) Make it easy to create and edit mind maps: a) Each mind map is a single document b) Each node contains: * Text * User Defined Properties * A Time/Date Stamp for when it was created, and when it was last edited. * An optional Note * An edge coming from the parent node * (optional) Edges leading to any children nodes * pointers to children nodes * pointer to the parent node * formatting information c) The document starts with a single root node which cannot be deleted w/o destroying the document. d) The user should be able to create a child node with a single keystroke or mouse click. e) The user should be able to create a sibling node for any node, except the root, with a single key stroke or mouse click. 2) The user should have fine control over the grouping of nodes {Identify all possible grouping mechanisms, like clouds, and how they behave.} 3) The user should have fine control over the appearence of the mind map: a) The color, font, size, and formatting of text b) The color, style, and size of edges c) The color and style of clouds. General Principles 1) The most commonly performed operations should be one click or one key-stroke operations. 2) Our user interface should conform to generally accepted interface standards used in Windows and Linux applications. 3) The application behave in a consistent manner. For instance, if the user moves the application to one side of the window and closes it, the application should start back up in the same place it was closed, unless that is impossible. (For instance, if it was moved to a monitor that is no longer attached to the system.) Potential extensions 1) Add the ability to transform a given node into a root node. That would create a new document rooted by that node. All children nodes for the new root would be transfered into the new document. The new root node would be replaced in the current document by a proxy node, which would allow the node to be represented as a link to the document, or by replicating the graph of the document in the current mind map. -------- Basically, it's a design that is documenting the current capabilities of the system and additional features we consider important. I don't think we have to write down every detail, just enough that we're pretty sure we've covered the scope of tasks that the software is expected to accomplish. Once we have that, we can evaluate each new design proposal against our requirements, and determine which one helps us meet those requirements in the best way. One of the things that people have consistently praised about FreeMind is the speed with which you can work. I think we have to be careful when refactoring to make sure we don't sacrifice the responsiveness of the program for our users on older hardware, or, if we are going to make such a compromise, we make sure we tell them about it. If we try to make the kernel too small, we'll wind up using lazy loading for elements of the architecture that are used all the time. Ray Dimitri Polivaev wrote: > Ray, > > >> It might be best to think about taking the refactoring in steps. >> > > I see it like you. The refactoring should be performed incrementally. The new design model however should be completed before we start with the refactoring itself. Afterwards we could define the steps. > > So in the proposed "Kernel-Extensions" design we could stepwise extract the properties from the kernel classes and move them to the property packages. > > Dimitry > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Freemind-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemind-developer > > |