Woa... Marc! your answer is overwhelming. There's no chance that I'll be able to answer it all, and I'm quite sure we already lost any potential reader who we may have wanted to hear from in this discussion...

We must find a way to break the discussion into smaller chunks. Perhaps in separate blog posts (e.g., that you answer in your own blog rather than in a lengthy response here), though, I must repeat, the best would be to use a forum.

Regarding navigation, I think the basic guidelines should be:
1. minimize the number of clicks the user has to make
2. avoid confusion

This should be applied for all types of users: newcomers as well as regular users, single-community members as well as those participating in many communities.

For newcomers, we must make sure the navigation bar does not overwhelm them, and right now, it does.
For single-community members, clearly, the mix with the other communities is at best unnecessary, and at worst a real disturbance.
But even for those who are active in several communities, while they need to be able to access all their communities, it is not clear that they need to view all info at once. Attention management would suggest that we allow them to focus on one community, while still leaving the rest of the communities "close by". Meaning, that the information of the one community they work on at the moment should be one click away, and the rest of the communities may require more clicks to be read. This paradigm would imply that the blogs link (one click) should point directly to the blogs of the community, while if you want to see all blogs you need to click more. In today's paradigm, the one click blogs links shows you all communities, and to see just your communities blogs you need to click more. And this is true for the rest of the information types as well.

In order to avoid confusion, consistency is also required. But right now, the different parts of the site have different navigation paradigms - in the wiki, the navigation bar is indeed static. But in the blogs, it changes. In BSCW, it disappears.

As for tags, I believe this argument was already decided by the audience - the world has shifted towards tags, folksonomies, etc. The belief that too many tags will be added to items or that synonyms will be confusing was proved wrong in enough systems, and Web 2.0 is very much about tags.

One important element to take into account when discussing about the navigation concept is that members of the AMI@Work global community (or family of communities as named by Olavi Luotonen) are very often members of several communities and not member of one single community.
I'm persuaded it is a very important element to take onboard of the UI (User Interface) design and this is what we have been doing with Rudolf and Stanislav when we have been designing the AMI@Work UI and discussing about the navigation concept.

So, in the current layout there 3 areas or columns. The left hand side column is for the AMI@Work level navigation. The tow other columns are the dynamic ones. The center column is personalised according to the user selected context (e.g. community page, project page, Libray page, Event page, News page) with a specific "skin" (or template of predifined layout). The right column is for context specific information boxes(e.g. leaders of the community or project, coming-up events, related documents) which is also part of the "skin" definition.

As soon as a member of the AMI@Work global community (user) knows about it then I do beleive he can easily adopt this layout for the following different reasons:
the left hand side column (overall navigation) allows to explore the different available contexts (e.g. Communities, Projects, Library, Events and News). This isn't a dynamic navigation in the meaning that all elements are pre-determined and don't change whatever is the selected context. It also means that no-one can be lost and therefore can easily go to any available context from whatever is the current level of exploration. So, there is absolutely no risk of being lost in the middle of no-where.
Members can easily move from one community (or project) context to another one by a simple click on "communities" (or projects) in the left column (or overall navigation) as very often they are members of several communities.
As this AMI@Work Collaborative Web Environment (CWE) is based on the use of wiki, blog and shared workspace, there is a community tools box as well where members (users) can move from one tool to another without to have to enter their username/password simply because there is a single logon in this CWE.
Last but not least, there is a wiki search box and a wiki tools box simply because the main CWE UI is based on the use of wiki pages which means that every member can contribute in editing those wiki pages. It also explains why there are wiki commands on the top side of the center and left columns to easily discuss/edit/purge/move/watch wiki pages.
Username and all my"things" are easily accessible on the top side of the overall UI window which allows to quickly check those "things".
The center and left columns are dynamic and self-explanatory as they mainly provide vital (like the AMI@Work explanation including its history) or new information and related links.

In conclusion, personaly, I dont see any navigation problem there but for sure every member as to know at least a little bit about AMI@Work (in case he doesn't know he still can click on the appropriate visible link for it) and at most how to use a wiki community environment (e.g. Wikipedia), blogging and shared workspace.

The main problem we (Rudolf and I but also Annika looking at what we have been doing to improve the LL Open Community page during the training/workshop at Fraunhofer-FIT) foresee is that members (users) don't know exactely what they can find and do (or more precisely contribute to) there.

During a specific AMI@Work CWE training in June 2006, we have tried to involve community leaders and members that were volunteers for it and to train them on how to use this CWE. For sure hopping then that community leaders would train their members....

Unfortunately, it did not work. This is why we are willing to include an online training directly available in the AMI@Work CWE in order to make sure that every member can have access to a simple training on the basic things like using a wiki community environment, blogging and shared workspace and how to contribute, where to find things and how to collaborate in this CWE.

Personaly, I would strongly recommend to do that and see what will happen before to decide to re-design the UI.

Regarding the blogging environment, which has been built with Drupal, the TAG cloud as always been there but it is showing the CATEGORIES could. what's the difference in between "tags" and "categories"?

Beside the name, tags or categories are a specific blog entry attribute which allow users to find easily all blog entries having the same attribute content (named either keyword or concept). For example, listing all blog entries related to the keyword "FP7".

So, the difference reside in the fact that "categories" are defined at the community level (an individual member cannot define its own) while more generally speaking "tags" could be defined by any individual member without any restriction (in this case, it comes often to a long list of keywords). A good way of understanding "tags" is to think about users (community members) stamping blog entries according to certain criteria.

To make it simple, let's say that "categories" are a federated set of "tags" (could be named "community-tags") among community members. In this case, there is a lower number of tags and no risk of having several tags that are synonyms but is less flexible as it could be a quite long process to create a new category or community-tag as members have to agree with its usefulness.

For sure, all of that is very abstract as any structural or organisational approach. For example, one may decide to combine "categories" and "tags" in using "categories" as a set of federated tags (so, a restricted number of community-tags) to quickly get into a first ganularity of entries and then to use "tags" as individual-tags (the ones defined by any individual member) inside each category or across all categories.

Within the design of the AMI@Work blogging, we decided to first use "categories" (community-tags) and then make observation on its use before to decide whether "indivudal-tags" would be useful in this context.

So, it is wrong to say that DRUPAL system does not support tags. It is not a DRUPAL lack as such but the way the application has been designed and developed.

Tags or "individual tags" are nowadays available in the BSCW blogging where we are currently experimenting its use. Soon or later we should be able to come to a conclusion to use both "categories" and "tags" (community and individual tags in other words) or one of them.
In the near future, it should be possible to combine individual profiling with tagging....

Two years ago we started to do research on the "People-Concepts Networking" approach as a mean for connecting members and external people on the basis of complementary concepts. People using keywords or concepts to tag (stamp) documents, blog entries or what so ever is one element of the "People-Concepts Networking" approach. Other elements are for example what members read and contribute to.

In this perspective, it should also be possible to play with those concepts according to the current context but this is another research action into the ECOSPACE project.

It is also wrong to say "We should probably choose one blogging system and stick to it."
Why? simply because the "communist" approach of rationalising has a bad effect....in the fact that everyone knows only one environment and loose the possibility to make compareason with other environments!

I'm not "Superman" but I'm able to use different blogging environments without really any big problem which allow me to have a better understanding of blogging possibilities.

Another reason is that one blogging environment (or tool) could be more appropriate than another according to a specific context. This explains also why the main goal of ECOSPACE is to make those tools collaborating together in the sens that every user can decide which ones he is willing to use. For sure, to be able to do that a collaboration protocol should be designed like the one for example used for eMailing.

My very last comment is that it is also wrong to say "I'd prefer to use the BSCW system, if only it could be open to everybody in the community."

BSCW objects are restricted to the group of people allowed to access a "floder" (or shared workspace). In the case a folder is a "public" folder, then everyone can access its objects. In the case the folder is a "community group of people" folder, then all members can access its objects.

Overall conclusion, designing and developing CWE is quite complex but thanks to god we have a lot of ideas, discussions and confrontations and the Living Lab approach and Action Research methodology that should allow us to make a step forward in better understanding why and how community members are interacting together, what are the roles of the various collaboration tools and features in their interactions and what is missing.