e enjte janar 06, 2005

This post is not about my weblog skin, I use a default theme coming with Roller, but about how tools and culture interact to affect how we collaborate, and more precisely how our culture, personal or corporate, affects how we use weblogs, mailing lists and wikis to collaborate.

At Sun we've historically been mailing lists people: we live in our mail client and mailing lists are the primary form of informal knowledge sharing. At Netscape we were web page people: everyone had their own web server internally, and an external web site at http://people.netscape.com (nostalgia, I remember the rotating cube logo and the old black and white Andersen Consulting mugshot with a tie:-).

I had trouble adapting to Sun culture when I switched to Sun in 2000 (doing the same job in the same team, as part of the iPlanet joint venture): I was used to organize all my docs my own way, on my own server, and had to switch to Sun habits where you usually have a big common server where all formalized engineering docs are organized, and most active knowledge sharing happens in mailing lists.

The difference in web publishing was not so much in the technology used, as in the culture: Netscape was all about individual personality, Sun about conformance to a process. At Sun you showed your personality in emails, at netscape in web pages.

There are drawbacks to both approaches: the Netscape intranet was a mishmash of unorganized content, and you had to know which people's page to look for the right information. This was possible for a 2000 people company it was at that time, but was beginning to show scaling issues when we were bought by AOL. At Sun the drawback, for me at least, is that you have to follow a process, which changes regularly, use templates, and my personality does not fit very well in processes (I liked that quote form the Nicolas Cage character in David Lynch's Wild at heart: "This snake skin jacket symbolizes my individuality and belief in personal freedom!")

I continued to publish many of my docs my own way, either on my own server, or in me personal account on the internal server. But it does not work very well: my server machine was moved and stopped working very often, rendering my documents unreachable, and Sun IT changed my UNIX login name so all my urls went 404.

Today I use a mix of internal blog, external blog, internal and external mailing list, internal wiki, and internal project publishing site to share my docs and thoughts. The advantage of blogs over personally managed web sites is that the blog server (as externally we use Roller internally) is managed by Dave (thanks Dave), so it's always up, but it lets me personalize my page and posts. The best of both worlds.

How do blogs, internal or external compare to mailing lists: there's a new balance to find between both and we're experimenting with these modes of collaboration since a few months. Most of the informal knowledge at Sun was traditionnally shared through mailing lists. Since a few years people have been experimenting with internal wikis as well, and these have started really picking up steam in the past 6 months.

The problem with mailing lists is not technical but behavioral. We have some good web based search for mailing list answers so you could say that a post to an internal weblog and a post to a mailing list are equivalent: they both can be reached through a url. Technically it's true, but the behavior when answering a question in a mailing list and writing a weblog post is different. For mailing lists the main mode of access is through a mail client, and information is considered transcient, because difficult to search. Better desktop search tools, such as Google, Microsoft or Copernic maybe will change that perception. The excellent web based gmail which puts search at the center of email management will probably also change this, but it's not available for intranets yet. So when you answer an email you're in a mode, or mood, where you create something for the purpose of this only interaction, and where reuse is difficult. To the contrary, when posting to your weblog you think that you publish something that will live forever at the end of a url, so you try to make it more general, less conversational, more long lived.

This attempt at behavioral psychology in the wild (*) is not very scientific and I look forward to see real sociologists or psychologists analyze how our cognitive behaviors are impacted by the tools we used, but I think it's a useful distinction to keep in mind when analyzing how people collaborate with email and weblogs.

Simon Phipps had an interesting post about flows of conversations between wikis, weblogs and email. I'm not sure wether his picture is right, I think it is too early to say: we're just starting experimenting with these various tools and I expect many surprises down the road as the tools evolve (podcasting will soon add an extra dimension to this landscape, adding voicemail in the picture). These are good times for experimentation.

At my level, I decided to post more to my weblogs, internal and external. I've been pretty active in a few internal Sun mailing lists in the past few years, especially in Portal land, which is my main specialty. But I never posted anything related to Portal on my public weblog. I'm going to start blogging about Portal more, instead of answering in the mailing list: I'll just answer with links to my weblog, internal or external depending of the confidentiality of the information. Let's see where this leads me.

I look forward to your comments about this topic, to which I will come back after more experimentation.

Today I got the following question from Rick Evans, our course developer. I'll answer in my weblog in order to start sharing this kind of information with the community, and hoping to trigger interesting comments. It has been a while I wanted to talk more about JES Portal in this weblog and this will be a good start.

I am curious what "the professionals" consider the best practice when creating a new portal in the field.

Or more importantly, what best practices do you want your customers to be taught?

-------
The following alternatives occur to me:

1. Customize/modify the Sample Portal itself.
2. Do not install the sample portal during Java ES installation, and create a new portal from scratch.
3. Create a new portal and install it as a new additional top-level portal.
4. Continue to use a suborganization for the new portal - hey, it works!
5. Other alternatives?

I appreciate any and all comments on what you recommend and the advantages/disadvantages of each approach.

Best regards,

Rick Evans
Portal Server Course Developer
"Good training makes everyone's job easier." 

I'm a Portal architect and developer, so usually I either work on the guts of JES Portal, or develop new Portlets to be included in the release, or used by Professional Services or internally. So I'm not best qualify to answer this one, but I'll give my perspective. Professional Services folks such as Ulf Feger, Marc Perret or Jeremie Van Renterghem will probably have much better answers.

In order to develop a new Portlet I usually use the sample Portal as is, and create a test role. I then create a small display Profile fragment to add that portlet to the role, and create a channel using this portlet in one of the containers of the sample Portal. I then use dpadmin to upload the fragment to a running vanilla Portal for my role.

Thta is the easiest way to develop a Portlet, or Provider, with JES. It also has the advantage that when people who use your Portlet get your code, they have a small easy to understand display profile fragment to work with in order to test it in their staging Portal before real deployment.

On one project I also developed a container, ie something that lays out portlets on a page. For this I used the same methodology.

But I never developed a full Portal for a customer, but my take on this kind of project is to follow the good old XP (Extreme Programming) practice of working in small iterations getting at any time something that works. This rules out trying to develop a new Portal from scratch (which means creating a brand new display profile). Instead, reuse as much as you can of the sample Portal.

But which kind of reuse? Inheritance, using a suborg and specializing the display profile for it, or code level reuse, modifying the sample display profile. I'd say it depends on the scale of what you're doing: if you develop something really different from the sample (using custom containers for example) I'd say code level is best, else inheritance is best.

Anyway what I'd recommend is a bit different from the options you list. I'd leave the sample Portal as is, as a baseline and test that your system works fine. I would create a new Portal copying the sample one. Then start modifying the display profile, or create suborgs depending on the needs. But once more I may not be best qualify to answer this question: comments from field practitioners are welcome: Ulf, marc, Jeremie, when do you start your weblog?

calendar

search

navigation

links

rss feeds

referers

Today's Page Hits: 130