Difference between revisions of "Harmonizing FP-menu"
(→Process step 1) |
m |
||
| Line 2: | Line 2: | ||
In the following I would like to invite you in helping to think over the menu structure of FP. I will follow the process steps indicated in my previous post. I will follow a process way of thinking, and ask you not to jump to the end result. Also, no decisions are final until the last step, the extreme being the decision that nothing will change if the end result is not evaluated as better than the current situation. | In the following I would like to invite you in helping to think over the menu structure of FP. I will follow the process steps indicated in my previous post. I will follow a process way of thinking, and ask you not to jump to the end result. Also, no decisions are final until the last step, the extreme being the decision that nothing will change if the end result is not evaluated as better than the current situation. | ||
| + | |||
| + | Once context menu’s are in place one may ask why one would need a top level menu. Fundamental and practical reasons I could think of are: | ||
| + | 1. To create toplevel objects. Once created each has a context menu for relevant functions of it, including creating the components (subobjects) it exists of and deleting itself. Each subobject has its own contextmenu. | ||
| + | 2. To apply a certain function simultaneously to a set of selected objects (e.g. delete object); however this functionality could also be connected to the contextmenu (e.g. not only delete itself, but all selected objects). | ||
| + | 3. To help new users orient and find their way without knowing which contextmenu’s might exist and how to select them. This could be solved with a toplevel menu containing a hierarchical list op contextmenu’s, possibly with descriptions how to find/select and use these. | ||
| + | 4. People expect particular menu’s because familiarity with common programs. | ||
| + | |||
| + | Keeping this in mind I prpose to evaluate the current menus and first strip it to the bare minumum from a functional point of view, before adding duplicate menu items for practical reasons. I also propose to evaluate the possible advantage of applying the mechanism of the FormatPanel more broadly as a priciple to give intuitive, quick and broad access to related functions. I propose to adress these subjects one by one, in a process like way. | ||
Revision as of 07:58, 6 March 2011
In this forum Stefan Ott posed some questions on how to improve the menu structure of Freeplane.
In the following I would like to invite you in helping to think over the menu structure of FP. I will follow the process steps indicated in my previous post. I will follow a process way of thinking, and ask you not to jump to the end result. Also, no decisions are final until the last step, the extreme being the decision that nothing will change if the end result is not evaluated as better than the current situation.
Once context menu’s are in place one may ask why one would need a top level menu. Fundamental and practical reasons I could think of are: 1. To create toplevel objects. Once created each has a context menu for relevant functions of it, including creating the components (subobjects) it exists of and deleting itself. Each subobject has its own contextmenu. 2. To apply a certain function simultaneously to a set of selected objects (e.g. delete object); however this functionality could also be connected to the contextmenu (e.g. not only delete itself, but all selected objects). 3. To help new users orient and find their way without knowing which contextmenu’s might exist and how to select them. This could be solved with a toplevel menu containing a hierarchical list op contextmenu’s, possibly with descriptions how to find/select and use these. 4. People expect particular menu’s because familiarity with common programs.
Keeping this in mind I prpose to evaluate the current menus and first strip it to the bare minumum from a functional point of view, before adding duplicate menu items for practical reasons. I also propose to evaluate the possible advantage of applying the mechanism of the FormatPanel more broadly as a priciple to give intuitive, quick and broad access to related functions. I propose to adress these subjects one by one, in a process like way.
Process step 1
Goal: strip all functions from the main menu bar which concern a selected node, node component (text, details, attributes, note), edge or connector.
This mindmap contains the starting point, the items of the main menu bar of FP 1.2.3_03. With green OK-icons is shown which menu items are top level functions which have effect on the mindmap as a whole and not on specific subobjects. With numbered icons is shown which items concern subobject: 1 means node level, 2 means edge level and 3 means node text level. If two icons are shown, there are two possibilities. A question mark icon symbolizes an item for which a decision still has to be made.
This mindmap shows the main menu stripped from items relating to subobjects (numbered icons). Different branches shows the items related to the Node level (1) the items related to the edge level (2) and the items related to Node text level (3).
Before proceding to the next step, I would like to ask if you would put the icons in the same way ? Please, give your comment in the this forum.
