usage of structured feature map

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

usage of structured feature map

nnako
This post was updated on .
Hi,

today, I had some time and started a feature map which could be used to overview ALL the features of Freeplane in a structured and user relevant (not implementation oriented!) way. The map could be put into the WIKI for users to get various information from it. It has been my great wish to be able to achieve the following benefits by creating/using such a feature map:

- see the richness of Freeplane on one sheet of paper
- see the development state of individual user-relevant features
- easily follow links to further usage documentation and feature discussion
- help the user to guess, when which features might be expected in a future release
- enable the user to easily compare Freeplane and other mindmapping solutions
- spot, which developer is currently working on which feature [optional]
- ...

Here are some requirements for us as developers if we decide to put the feature map to work for us:

- complete the feature map with currently missing features (I don't know all) [INITIAL]
- complete the feature map with links from features to documentation and discussions [INITIAL]
- update the feature status within the feature map as soon as a status changes [OCCASIONAL]
- ensure clean structure (this would be done by myself) [REGULAR]

That's all.

Here you find the first concept version: Freeplane feature map (DROPBOX)

On the left side of the map there is information about the scope and usage of the feature map. On the right side there are the hard facts ;-) . The feature map uses some basic initial categories "general usability", "map handling", "node handling" and "expandability" to hold the features (there are further sub_categories). We could discuss about different keywords or structural changes.

What do you think? Please, go through the map and give me some feedback in this forum thread, whether you think it makes sense to proceed in this way and invest time for further creation and update of this feature map.

Please note, this is NOT an other or a new usage documentation. It is a structured feature map. Usage documentations are already existing within other maps and the WIKI on the site and these (as well as relevant postings in the open discussion and developer forums) should be linked from within the feature map.

Looking forward to your feedbacks.

Thanks.
nnako


PS: In some weeks I will have some weeks off work, so I'm looking forward to further contributions :-)
Reply | Threaded
Open this post in threaded view
|

Re: usage of structured feature map

theworldbright
Hello Nnamdi,

I’m liking this feature map idea. As you posted it would definitely be useful to have links from features written on each node to the documentation and discussions. The map is definitely well-structured.

Personally I feel that the map is a bit “crowded," but given how the map is there to show the vast amount of features FP has, I guess it may be a good thing. Perhaps when this goes on the wiki the whole left hand side could be removed and placed as a introductory paragraph before the link to the mindmap itself. Or there could be a large link on the map pointing to a tutorial/guide on the wiki explaining what this mindmap is.

Regards,

Kent
Reply | Threaded
Open this post in threaded view
|

Re: usage of structured feature map

Dimitry Polivaev
Administrator
Hello Nnamdi and Kent,

as I looked into the map I was lost very fast because it combines content with structure in a way
which seems to be very complicated and therefore I have no opinion about its content as I can not
percept is. I just have some ideas about the structure. After the structure is reworked it could be
that I like the content and it could be that I do not like it. Now I just can not understand it at all.

I would like to make some suggestions about the structure. I am not writing it as a "lead" assigning
you a "task". If you like to follow them please do so, if you don't like them please just ignore, in
this case I would just not be able to contribute to the feature map or like it.

Basically the semantical meaning of a node should be expressed in the name of its style rather than
its position.

Instead of having two level category structure I suggest that the category structure is free.
Right now the rule to use subcategories even where there are no such categories makes the map more
clattered and difficult to read.

Instead of using style "klein and grau" (which is German for "small and grey") I suggest that the
corresponding style used for the categories has name "Category".

Please do not use any node specific formatting, do all kinds of formatting in styles to make sure
that node meaning is  visually clearly expressed by the format it has. Also do not use any other
visual or textual indications like brackets in node "[ productivity ]". They are superfluous if you
use styles, they distract readers from the map content, they are also redundant and therefore a
little bit hard to maintain when the map is being created.

I also think that use of attributes for expressing content like link to the forum and the developer
working on an issue could help to keep the map smaller and easier to overview. By the way, no
developer is assigned to any feature, the opposite is true namely features are picked up by
developers (unless the issue is a bug report related to some issue the developer have been working on).

And if you like some of my suggestions please respond to this mail so that I can know whether any of
you is implementing them.

Regards,
Dimitry

> Hello Nnamdi,
>
> I’m liking this feature map idea. As you posted it would definitely be useful to have links from
> features written on each node to the documentation and discussions. The map is definitely
> well-structured.
>
> Personally I feel that the map is a bit “crowded," but given how the map is there to show the vast
> amount of features FP has, I guess it may be a good thing. Perhaps when this goes on the wiki the
> whole left hand side could be removed and placed as a introductory paragraph before the link to the
> mindmap itself. Or there could be a large link on the map pointing to a tutorial/guide on the wiki
> explaining what this mindmap is.
>
> Regards,
>
> Kent

Reply | Threaded
Open this post in threaded view
|

Re: usage of structured feature map

nnako
This post was updated on .
Hi,

thank you for your replies.

@Kent: great suggestion to take the left side out and put in into
descriptive text so that the feature map holds just features.

@Dimitry: I would appreciate your contributions. Your suggestions are
very welcome.

As I still look on Freeplane from a "novice" perspecive, this first shot
of a helper tool was trying to catch the user's eyes rather than the
developer's. So the *categories* were meant to cover the main groups of
activities a user could compare and evaluate mind mapping tools: general
usability, working with and viewing/transforming the maps as a whole,
handling and specifying of node contents, and the what and how regarding
the extension of existing functionalities. *Sub categories* were thought
of as more specific "use cases" a user would likely try to perform while
working on tasks belonging to the categories.

The feature map was not finished, yet. Just a rough idea expressing some
sort of structured overview. About the current style names: they will
definitely be named  according to their function and not according to
their look or position. And, yes, the level depth of categories and sub
categories should match the content (i.e. feature) and not be too rigid.


> Please do not use any node specific formatting, do all kinds of
> formatting in styles to make sure
> that node meaning is  visually clearly expressed by the format it has.
> Also do not use any other
> visual or textual indications like brackets in node "[ productivity
> ]". They are superfluous if you
> use styles, they distract readers from the map content, they are also
> redundant and therefore a
> little bit hard to maintain when the map is being created.
On the other hand, an additional visual "effect" on top of mere color
and style would underline the content's function. For me, square
brackets carry the visual impression of a folder, a structural aid. But
I would not be too demanding on this bit, even though I like to use it
this way.


> I also think that use of attributes for expressing content like link
> to the forum and the developer
> working on an issue could help to keep the map smaller and easier to
> overview. By the way, no
> developer is assigned to any feature, the opposite is true namely
> features are picked up by
> developers (unless the issue is a bug report related to some issue the
> developer have been working on).
I don't use attributes so much (the usage and look does not find my
personal approval, yet). And I think, creating and using clickable
local/external links within additional nodes are the easiest and fastest
way to connect to additional information. People not interested in
further information could just fold subsequent information linking nodes.
About the "assignment" of developers: This was not meant to pin
developers down to certain features. This would never work, as "fun" and
self-determination seem to be key factors for contribution, here. On the
contrary, names should be put in only by the developer himself! The one
who likes to work on a certain feature (maybe over a certain period of
time) and wants to signal his personal commitment. But at the same time,
it could tell other developers to be gentle concerning their
contribution to that other developer's assigned field.

Looking forward to further feedback.
nnako
Reply | Threaded
Open this post in threaded view
|

Re: usage of structured feature map

Dimitry Polivaev
Administrator
> The feature map was not finished, yet. Just a rough idea expressing some sort of structured
> overview. About the current style names: they will definitely be named  according to their function
> and not according to their look or position. And, yes, the level depth of categories and sub
> categories should match the content (i.e. feature) and not be too rigid.

:)

I generally prefer compactly organized maps without duplication of content and where you can reach
your content with possible few clicks.

>
>> Please do not use any node specific formatting, do all kinds of formatting in styles to make sure
>> that node meaning is  visually clearly expressed by the format it has. Also do not use any other
>> visual or textual indications like brackets in node "[ productivity ]". They are superfluous if you
>> use styles, they distract readers from the map content, they are also redundant and therefore a
>> little bit hard to maintain when the map is being created.
> On the other hand, an additional visual "effect" on top of mere color and style would underline the
> content's function. For me, square brackets carry the visual impression of a folder, a structural
> aid. But I would not be too demanding on this bit, even though I like to use it this way.

Have you tried to assign icons to styles? It allows to create strong visual accents without changing
the textual content.

> I don't use attributes so much (the usage and look does not find my personal approval, yet).

Why?

> And I
> think, creating and using clickable local/external links within additional nodes are the easiest and
> fastest way to connect to additional information. People not interested in further information could
> just fold subsequent information linking nodes.

Attributes have some advantages and I would like to ask you to try them out.

1. When attribute value contains a link it can be followed by click.
2. Filtering and search is optimized for attributes. You can easily find and localize nodes
containing certain attributes.
3. Attributes require much less space than nodes and therefore you can create more compact maps for
the same content.
4. There are drop-down boxes for attribute names and values making entering of already know values
easier.

> About the "assignment" of developers: This was not meant to pin developers down to certain features.
> This would never work, as "fun" and self-determination seem to be key factors for contribution,
> here. On the contrary, names should be put in only by the developer himself! The one who likes to
> work on a certain feature (maybe over a certain period of time) and wants to signal his personal
> commitment. But at the same time, it could tell other developers to be gentle concerning their
> contribution to that other developer's assigned field.

Sure. I only suggest to replace word "assigned" by something like "developed by".

Regards,
Dimitry
Reply | Threaded
Open this post in threaded view
|

Re: usage of structured feature map

nnako

I generally prefer compactly organized maps without duplication of content and where you can reach
your content with possible few clicks.

you are thinking as an "optimized" developer ;-) . But users might think different, depending on their technical knowledge an their level of structural thinking. One user is looking for information about the feature "computable content using formulas" within the [node handling] / [content] category while another user might look for it within [expandability] / [plugin] / [formula] or [node handling] / [linking]. And the feature belongs to any of these categories (it connects them). So any category is meant to redundantly list all relevant features, not just the explicit ones.
If there is a way to universally assign one well defined feature to just one category while ensuring a "clear" structure for any user, I would be very happy to create the feature map that way.


Have you tried to assign icons to styles? It allows to create strong visual accents without changing
the textual content.

I personally don't like any icons in my maps, except for the exclamation and question marks. Using them, the map tends to appear too playful and colorful for my taste, which I think distracts from the deliberately chosen colors of the feature texts, which are intended to be chosen development status dependent.


> I don't use attributes so much (the usage and look does not find my personal approval, yet).

Why? ...

I just added attributes containing possible links for [map handling] / [presentation] / "presentation slide generation using mindslide" into the feature map. When general visibility of attributes and the attribute icons are switched OFF, this seems to be a good way to make the map more compact and showing additional information only on demand (on mouse-over). Ok. I'm ready to use attributes.

Here again, the link to the feature map:
Freeplane feature map (DROPBOX)

When we agree, I'll install it in the WIKI and create the description text outside the map, as Kent suggested. Is there a good way to make a map available within the WIKI (maybe there is already a link to an existing documentation)? So that users could interactively fold and unold it, while developers could change it?
Reply | Threaded
Open this post in threaded view
|

Re: usage of structured feature map

nnako
Hi devs,

some more about the feature map idea I introduced in the middle of March this year...

I now have created a repository on GITHUB where any developer could access and modify the feature map. The idea is that this map would be connected to the WIKI on sourceforge in order for users to browse, filter, search it acording to the JAVA applet export features.

Now, there are some "online" mindmaps in the WIKI, e.g. under Freeplane functions. But I haven't found out, yet, where within the WIKI file structure to put the mindmap file (the original or the JAVA applet export?) in order for the following WIKI command to work and show the mindmap in a proper (flexible) environment:

[[File: <preview_picture> |thumb|right | [http://freeplane.sourceforge.net/mapsOnline/?map= <mindmap_file> <title_text> ]]]

How does the mechanism work so that <mindmap_file> is flexibly displayed within the WIKI? Is there maybe a description in the WIKI for this?

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: usage of structured feature map

theworldbright
Hello Nnako,

It is good to see the feature map idea being pushed forward. I have sent in a pull request that adjusts the formatting of the README page: https://github.com/nnako/freeplane-feature-map/pull/1.

Regards,

Kent
Reply | Threaded
Open this post in threaded view
|

Re: usage of structured feature map

nnako
In reply to this post by nnako
Hi Devs,

some weeks ago, I was asking for some help concerning how to practically realize an "interactive map" within the WIKI (original message). Sorry for my repeated question, here. I hope that someone has some minutes for an explanatory answer.

The current feature map resides on GITHUB and can be modified by anyone. Currently this would be done using pull requests: https://github.com/nnako/freeplane-feature-map .

Please, could you help me find a way to offer an interactive map within the WIKI?

Thanks.
nnako