Driving traffic to the OneStop homepage is near the top of our priority list. One of the ways we do this is by offering what we consider to be the best news at Sun.

Basically we try and stay abreast of everything Sun related, filter out the info that is not of interest to our audience, and publish the rest. We generally publish 3-6 items per day. The goal is to enable users to keep up with what's really cool and relevant, at a glance.

As Robert and I are both info junkies, and stay connected most of the day, it's very little burden to post timely and relevant information. Our sources include:

1. ZapTXT. A free tool that sends hourly updates for RSS/ATOM feeds of interest. The cool part is that you can filter the feeds for a string, such as "Sun". By watching feeds for The Register, eWeek, InfoWorld, CNET, ZDNet, and others we can catch all the late breaking stories.
   
2. Google News Alerts with Search terms of Sun, Solaris, etc.
3. "In Today's News". Sun PR publishes a daily news summary which is excellent.
4. Sun internal aliases. Robert and I both subscribe to dozens of internal aliases. Oftentimes when people see an interesting article they'll circulate it on an alias.

We try and add little fun to the mix by posting the Dilbert cartoons that we think are especially funny. The Dilbert items are consistently the most popular. We know this as we carefully track click throughs.

When Yahoo!News added javascript popup summaries I found it extremely useful, so we added the same functionality.

 

We've been struggling for some time with making OneStop more available for community editing. We've tried including a wiki section into each OneStop page, but found that mixing metaphors between html editing by one author, and wiki style editing by the community doesn't work well.

We have a very popular companion site to OneStop called CEpedia, which is a wiki based on the mediawiki codebase. As we'd like to minimize the number of sites  where users look for information, having  two somewhat overlapping locations is undesirable.

We now offer our users the ability to host their content on CEpedia, with all the advantages of community editing in a wiki, but also participate fully in the OneStop framework. The OneStop framework offers:

1. Search that works
2. Link check support
3. Page Status reports
4. Presence on OneStop homepage and menus, including most popular, recently updated, etc.
5. A-Z and browse

I particularly liked this in the Motley fool article article where they're talking about what we might annouce today.

"What a novel idea -- harness the enthusiasm, manpower, and expertise of "your entire customer base rather than micromanage your most valuable intellectual properties. Open platforms supported with open arms can do amazing things -- it's how IBM became the dominant system builder in the early days of the PC, picking standard parts off the shelf, and it appears to be working again for Sun. I'd draw parallels to the current state of the entertainment industry here, but that's fodder for a much longer article."

It works with authors too.  As Mike blogged yesterday - we often work on ideas, code and concepts with our author base. They're smart - some of them are really smart - they have great ideas for new functionality.

For example we're just had a great collaboration with Constantin  on a merged mediawiki / OneStop page ... really cool ...  wikis are the wave of the future ... wikis with a little more control, access control, content control etc ...   more to come later ..
 

We are pretty much the opposite of a traditional IT process  that includes analysis, specifications, design, implementation, test - and all that stuff.

When we see a need, or have a new requirement, we just do it. If it doesn't work, we back it out. Fortunately we have few interdependencies, so the downside is small. It helps that we have a staging machine and 4 production mirrors worldwide. If we mess up the staging machine we have all the production instances still working.

We use the SAMP stack (Solaris, Apache, MySQL, Perl/PHP) for most everything we do. In concept, at least from the infrastructure point of view, our stuff is really simple. We have no real need for robust transactional support, identity management, or many enterprise features at all.

Hacking up a new report in Perl/PHP, adding new javascript functionality, or adding new tools is something we can generally turn around in hours, or at most a small number of days. The process is generally:

1. Mike to Robert, or vice versa: "Seems like we should add this bit of functionality".
2. Robert to Mike: "Sounds good to me, why don't you change some part of it. Let's ask the authors if they like the idea"
3. Authors to M&R: "That sounds useful"
4. code, code for a few hours
5. test on staging machine
6. New functionality available

Sun has lots of internal sources of information - which is really why OneStop exists in the first place. It's the author's responsibility to post the latest and greatest information about their product/technology/program to their OneStop page.

This can be somewhat daunting as new collateral and information is continually generated. Authors generally follow aliases and interest groups in their domain to keep up, but it's still difficult.

To make life easier on our authors, on a weekly basis we run the content recommendation engine. This engine interrogates the top document repositories at Sun and grabs the titles of the documents that have been added or modified in the last week. It then submits these titles to the OneStop Search engine. (See the Search Needs to Work Post.) It makes note of the OneStop pages with the highest relevancy scores for each of these documents.

We do some slicing and dicing and a list of the new or updated documents that are relevant to each OneStop page is assembled. The OneStop page is then scanned, for each relevant document, to make sure the author hasn't posted the new information already. A list of "documents to consider posting" is then emailed to each author.

The four reports that Robert and I find most useful in keeping our fingers on the pulse are emailed to us daily. These are:

The Pages Updated in the Past 24 Hours report gives us a feel for how active the site is. On an average day ~25 pages are updated.

The Top Pages report shows us usage for the top 30 OneStop pages, including the home page. We'll scan these pages for robustness, ensure search finds them properly, and make doubly sure they are well cared for. On an average day the home page will get 4000-5000 hits.

The Worth a Look Activity Report shows us the usage for our Worth a Look Section - which is really OneStop News. We post 2-6 items every day, usually articles in the press concerning Sun, sometimes fun stuff like Dilberts we think are especially funny. The report lets us know which articles people are clicking through on.

The Stale Pages Report is a trigger for us to personally engage with authors whose pages might have gotten old.

By and large when a person utilizes the search box on your site they expect to quickly find what they need, not on the internet, not on the intranet, but on your site.

On OneStop we use Ultraseek. This is mostly because Sun has a site license, but it is a mature and very tunable search engine that delivers very good results on a per site basis. 

We are very careful to ensure that if someone uses a phrase in search of a particular OneStop page that describes a product, technology, or program - that the right page will appear on the top of the search results list.

We have a few factors working to our advantage:

1. There are less than a thousand OneStop pages. (A very bounded universe)
2. We have control of the content and can add meta data.
3. Ultraseek has many tuning parameters we can use to influence the results.

For example, each OneStop page is classified as active, static, or archived. We insert the meta tag

<meta name=status content=xxxx>

into each page as appropriate. We then tune the search engine to influence that results score as a function of this meta tag.

We give authors the capability to influence where their pages show on the search results list with the

<meta name=keywords content=xxxx> 

tag. This ensures that a page will show up properly when, for example, an acronym or term that isn't listed on the page - is listed in the <meta> tag.

Last but not least we do a lot of testing. We ask that each author search for their page(s) with multiple queries, and if they don't see the desired behavior, we fix it.

 
I nearly titled this "The Machine is Us/ing Us"
 

I used to rule the machine. I had limited ways to interact with it, limited ways to communicate with others electronically, limited places to go and get information but with 'web 2.0', now I'm part of the machine. It learns from me, my habits, my interests, it subliminally extracts information from me and when I interact with it, it changes what it does based on what it thinks I want or where it wants me to go.  It has more sources of information for me, more ways to present them and it's only going to get more complicated.

This makes holding a community of people together much harder. There are more distractions, more locations for interest - you have to try so much harder to keep your audiences attention.  But communities are normally bound by a simple thread - a common interest, stay on track with that common interest and you will remain their chosen, trusted, point for information.
 
So whilst new features and delivery mechanisms are always good to keep people entertained (we are a site for nerd run by nerds) content must be correct, it must be up to date, it's more important than anything else. For new features we use something we call "the dogfood test"  where if we have a new feature or piece of functionality we use it on our authors base first. This can be hard - we get lots of diverse requests for features - some of them are low hanging fruit / no-brainers but often they are complicated and take time but eating your own dogfood is a good test for most new features or functionality

.

Moderation - no not the drinking kind, and ownership, are key to OneStop's success. When your name and picture are on a webpage that is scrutinized by hundreds, sometimes thousands of your peers, you are careful to get it right. It's certainly a reflection of yourself.

We find that the best pages generally have one owner, though we do have pages with up to four. That person bears the unique responsibility for keeping the page up to date, and ensuring the content is accurate. That person also, of course, get the visibility and recognition of being the owner of that page. 

Our challenge is enable users to more easily contribute to a page. We would like to take advantage of the  expertise in the community to a greater extent. Perhaps the future role of some OneStop authors is more of a moderator.

For  pages where we anticipate community contribution we will soon be offering an optional environment where editing is done in the wiki. More on this in a future post.

Have you ever been frustrated in a request for support or for help? Have you ever met with  "I'm too busy to respond to you right now"? Have you ever gotten the feeling that your time is considered less important than the person you are asking for assistance?

In an environment where the content is coming from volunteer authors, any of these responses is unfathomable. 

We've made some mistakes with OneStop over the years. One of the mistakes was having too many cooks in the infrastructure team kitchen. At one point we had six people on the team, two full time. Any change to the environment, no matter how trivial got logged into a DB, clarified agreed to if necessary, then implemented in a batch. Response time for author requests such as new pages, author changes, etc. generally took 24 hours, and often as many as 48,

Our infrastructure team is now two people, part time. We're both in front of our machines most of the day so we see the requests immediately. We consider it poor form if we can't service requests within a couple hours, at least during the time one of us is online (5:30 AM - 9:00 PM PDT). [We really like the Sun work from home program!]

Not sure about you, but I sometimes have a short attention span. If I can get an immediate response from a support person on an issue I'm having that moment, that allows me to continue with my project - and not get distracted. Hence - productive!

We think the authors appreciate this level of responsiveness.
 

First of all, many thanks to Mike for inviting me to blog here! 

One popular discussion topic among OneStop authors is about which editor to use. Newbies often ask for a recommended editor, then veterans start discussing why this editor is better than that etc.

Old-school authors prefer vi or emacs (I'm a vi fan too). Alan recently blogged about his favourite $400(!) programmer's editor. But most users tend to ask for a true WYSIWYG editor.

But WYSIWYG in an HTML world is an illusion because you'll never know what web browser your reader is going to use and what its interpretation of HTML is going to look like. Or maybe your "reader" is actually a web crawler or a person using an alternative form of rendering HTML. Check out this great video for a 5 minute evolutionary tour from the written word to the magic of the  semantic web and you'll see how important the distinction between presentation and content is.

So, I ended up developing my own XSLT system that takes XML source (content), mingles it with XSLT style sheets (presentation) and spits out a complete OneStop page. This does not solve the WYSIWYG problem which wasn't my goal, but enabled me to concentrate on content while automating all the rest. And yes, I prefer using vi to edit the XML source and just about anything else.

Now the time is right to try something new. We have a Wiki system at Sun, based on the MediaWiki engine. I'll try authoring my next OneStop page using that Wiki, while trying to preserve as much of the OneStop look&feel as possible. Wikis aren't perfect, in fact they are a very pragmatic thing, but they are one step further from HTML towards what may become the future of OneStop. Let's see what happens.

Robert and I keep pontificating, perhaps even belaboring, the point that the OneStop authors are key, and credit should be given where credit is due.

But, you ask, why are you two the only people posting to this blog?

I'm happy to announce that this blog will evolve into a group blog. All of the OneStop authors will be invited to contribute. You'll get the information directly from the horse's mouth. The next posting will be from one of our top contributors, Constantin Gonzalez [blog].