Taking Baby Steps (part 3): Dashboards - A managerial love story

Overview
Part 2 of this series "Taking Baby Steps (part 2): Only one person reads my Blog and I've already won" discussed some ways in which posts to personal, work-related Blogs (aka Knowledge Bases) are relevant to our team-mates and managers. Additionally, techniques on targeting posts through use of Tags were also presented.

In this 3rd post, I will talk about Dashboards, what they're for and how to set them up.

The Basic Unit of Information about which people relate at work
Projects.

Just the "sweet spot", please
There is an inverse relationship between someone's social proximity (in a "Social Degrees of Separation" sense) and their

1. Tolerance for Irrelevant Information
   
2. Amount of time willingly spent extrapolating "important" information

That is, the farther apart two people are in a socio-professional environment, the smaller their overlap of interests. Let's say 70% of my time is dedicated to Project A and 30% to Project B. My colleague Bob also dedicates 30% of his time to Project B. What this means is that out of all the information and knowledge I deal with on a daily basis, only 30% of it is relevant to Bob and I only have 30% of my time available to share this information.

Furthermore, depending on the roles being played, it is important to understand which 30% of Project B Bob focuses on. If Bob is the Project Manager, odds are that the details of your application's algorithm beyond a statement that "it works" is not very relevant to Bob. Including Bob in day-to-day, back-and-forth conversation about algorithm optimizations negatively impacts Bobs productivity given his slice of the pie. This should not be interpreted as "Bob should be left in the dark for the other 70%". Rather:

• Amount of information sent through the pipe is important.
  
• Quality of information is very important
• Order of information is also important

Some elaboration. For example, most people skim through email until something of importance catches their eye. Then they will read around that which jumped out. This is an act of validation. The reader is Gauging and Confirming Level of Relevancy. As was stated earlier, we all have a threshold. Whether this is acknowledged or not, we all associate Quality of information relayed to us with the originator of the communication. We even have functionality built into our email clients to reward those sources of information that we believe to consistently relay High Quality information. People whose communications I wish to help penetrate through "my" noise get their own Mail Folder and a Rule. The Folder makes it into my Top 5 and so on. Rather than skimming I tend to read these communications "normally". High Quality/Highly Relevant information from the originator creates a level of Trust. Perhaps its a bit too cliche to claim that Trust allows for solid Feedback Loops. Rather, its very clear that a lack of Trust results in a well stocked Trash.

Ideally, communications to Bob are well targeted bringing the 30% of the project Bob is involved in to the forefront. (Bob thanks me for not wasting his time.)

A not so "Side Note". I really dislike emails that say "FYI" followed by a long thread of bracketed who-knows-what. Figuring out the part that is in fact For My Information will require me to skim not just one email, but all the accompanying threads. Cliff Notes at the top, please!

Information Trickle
Why do "executive" summaries exist everywhere but in our routine communications within our Social Networks? The "Cliff Notes" quip above actually deserves some discussion. Clues about content subject matter and how it pertains to "me" are very helpful because they grant me the opportunity to cash out sooner rather than later. Tags are great but not as great as a one-sentence summary that speaks right to my forehead. Descriptive titles/subjects also help a great deal!

Whether we skim, or jump back and forth as we consume written information, it is still done (for must of us) in a linear way. Pardon the nerdy analogy but this is like a Disk Head tracking back and forth over a Hard Drive. Meta information about files, directories etc in all File Systems is also at the "top". Search Engines construct indexes that pull out relevant information so that from then on the engine can gauge a match - "this data is relevant" - as quickly and efficiently as possible. There are many other examples of almost identical optimizations that happen in technology because we demand it. Somehow, similar optimizations fail to make it into routine meeting, emails, phone conversations, and so on. It would be nice to have that Trickle from High Level but High Quality information to Low Level details in all mediums of communication.

Dashboards are about creating this kind of Information Trickle for other forms of Project-related information.

Dashboards and RSS Feeds go hand in hand

My Dashboard at work contains the following:

• Tab 1: 20,000 feet -
  Idea here is to create that High-level but informative "At-A-Glance" View of team-wide activity. This High Level but High Quality landing page is relevant to anyone who may be interested in the activities of the team. For a manager 1 or more Social Degrees away, this is a good place to begin "dipping" into our "world" without being overwhelmed by all the details. For my team-mates, this Tab can serve as the Sync-Point for meeting agendas, follow-ups, Iteration refinement and so on. My team-mates will most likely want/need to drill deeper, the manager 1 or more Social Degrees away will not!
  
  Specifically, our first Tab contains:
  
• Changes to Production - Feeds that describe changes to portions of the "production" environment we are responsible for. This is a feed coming out of our Turnover Control System. It's not RSS at this point but hopefully will be soon.
  
• Work plan for the entire team spanning 2 weeks time (this is the Two-week Iteration). This is just an aggregate feed that collates Two-week Iterations from individual product blogs based on the "iteration" Tag.
• Top 5 Bugs or Issues spanning all our products. This is yet another RSS Feed filtered for items tagged or flagged as "important" from our issue tracking system.
  
• Links that allow the reader to subscribe to any of the RSS feeds exposed on the page
  

• Tab 2-x: Product-specific pages
  Each of these Tabs is dedicated to a specific Product/Project the team works on. These tabs are a natural "drill-target" from the 1st Tab. My Product Tabs contain:
• Changes to productions affecting this specific product
• Iteration posts for this product. This is a regular RSS Feed coming form my Product Blog filtered on the "iteration" tag.
• News Items or Alerts coming from the Blog or the Product Site. (The Product Site tends to target the end-user/customer. It's not very technical but provides enough insight about the Product's stage in it's life cycle, and the standard "what" and "how")
• Top 5 Bugs or Issues for this specific product/project
• Links that allow the reader to subscribe to any of the RSS feeds exposed on the page

RSS Feeds are a natural way to "summarize" content that lives elsewhere. As you can see, no content is actually managed by the Dashboard. The Dashboard simply assembles information into easily consumable pieces. The Trickle is enabled by:

• At-a-Glance views of tightly-correlated information
  
• Ability to stay High-Level yet still obtain more detail. The reader can explore Product-specific Tabs without leaving the context of the Dashboard.
• Link-backs to the source of information. The reader can drill even deeper by clicking on any item in any of the feeds and be taken to the full "article". The reader does this by choice - this is key.

Technologies at Play

1. Blogs with RSS capabilities -
   Blogs tend to be more appropriate for Weekly Summaries and Iteration posts. My Blog allows me to publish via email so I don't have to change my habits to post. I publish from my Email Client.
   
2. RSS Web Part -
   RSS is not just about getting news from slashdot. It can be a very powerful Glue for information that lives everywhere yet needs to be correlated in a single View.
3. A portal framework with a Tabs Layout -
   The Sharepoints of the world all have this built in. Acquiring RSS Web Parts is also not too difficult. Some Wikis out there (like Twiki or Confluence) allow you to inject all sorts of content into a single page view, including RSS. These are all basic things. As always, your friendly neighborhood IT department will have some options for you.
   

How to get started
Naturally, I recommend taking "baby" steps. Most teams will fall into two categories:

1. A lot of unorganized documentation floating around in multiple formats
2. All project-related know-how is stored in the brain of the guy two weeks away from retirement

For folks that fall into the 1st group, it's a matter of figuring out the kind of information that is most useful to highlight on a dashboard. Some teams I've worked with went straight to:

• Top Bugs
• Testing Results
• Latest activity around portfolio work for a client

Folks falling into the 2nd category should consider starting with Personal, Ad-hoc Knowledge Bases and expanding out from there.

In general, the type of information that is of Highest Value to your social network should be exposed first. The gains will be emergent and will inspire further investment into not just the Dashboards but also into creating and persisting the High Quality data underneath.

Conclusion and what's up next
Dashboards just front the Collaborative Environment. If the information in Product Blogs, Wikis, etc is not up-to-date, Dashboard's highlights are meaningless. It does take some work and consistency to provide this kind of transparency to your team, your manager and your customers.

Typically, gate-keeping Knowledge Bases and their Dashboards is the responsibility of Team Leads and Product or Project Managers. To get started though, all you need is a Champion, someone who will get the team going, while incrementally proving value. Once your manager is convinced (unless of course you are the manager) some top-down "encouragement" never hurts.

In my next post, I will propose a 10-Step Plan to putting these concepts to practice so we can move on to topics such as Wikis, Issue Tracking, and Interruption Management.

Firefox EWG - Meeting #3

Summary
Call on Sept 19th was about useful Extensions for the Enterprise. A larger portion of the meeting, however focused on the apparent dwindling interest in Enterprise Firefox within the larger community.

Is the Enterprise simply not ready to bring Firefox in-house? Or, are the majority of institutional adopters simply happy with a consumer product floating about?

Perhaps one of the problems is that we still talk about Firefox as a Web Browser as opposed to a "Productivity Platform" for the Desktop.

Firefox is a Productivity Platform
All the features that make Firefox a consumer favorite deal with productivity. Tabs, keywords, search bars, extensions, dictionaries, etc help us be effective and productive in our work and home lives. When consumer says "better usability", enterprise says "better productivity".

Mike Kaply spoke about adoption at IBM. Developers are finding ways to enhance the end-user experience by writing custom extensions for Firefox. Whether the extensions glue several applications together or simply automate the tedious process of filling out web-forms, end result is a boost to productivity.

If Firefox is the gateway or glue between what's on the Desktop and what's on the network, potential for productivity-boosting application is something to ponder.

Raising awareness
Mike and I are going to take lead on a few initiatives to help raise awareness on the Enterprise Firefox front:

• 10 Steps to adopting Firefox in the Enterprise -
  Now that we've begun to pool experiences, we should be able to bake out a definitive guide of sorts for things to consider when bringing Firefox into an enterprise environment
• Good Ol' Conference -
  We will begin looking at opportunities to present at some Conferences
• Blogging - check...
• Code Day and Training -
  The learning curve for any kind of Mozilla-related development is rather high. Perhaps training targeting institutions and enterprises (like an Enterprise track) will help developers scale this wall.
  
• Enterprise Firefox Incubator -
  Talk has alway been cheap. As we address settings management, security, tools etc we will kick off projects within the Enterprise Working Group.
  

Enterprise Working Group Incubator
On my end, I'm going to kick off some projects for the Incubator. Specifically there has been interest in:

• Mission Control - how to get up and running, what the back-end implementation can look like and benefits over GPO
• Customized Reporter Extension - so that you can redirect Broken Website reports to a repository on your intranet
• Managed Security Zones for Firefox - how to configure and lock capabilitiy.policy settings in Firefox, how to create a "trusted" zone and fully leverage Web2.0 technologies within your trusted intranet.

As always, if any of these topics or projects are of interest to you, please visit http://enterprisefirefox.org, participate in the calls or simply leave a comment on this here Blog.

Third Firefox Enterprise Working Group Meeting August 22nd

Third call is scheduled for Wednesday, August 22th at 10:00am Pacific, 1:00pm Eastern, 17:00 UTC. Details:

• 650-903-0800 or 650-215-1282 x91 Conf# 280 (US/INTL)
• 1-800-707-2533 (pin 369) Conf# 280 (US)
• IRC - irc.mozilla.org - #ewg

The theme is “Extensions.” Please check out the EWG Wiki page for more information.

Firefox EWG - Meeting #2

Overview
This call focused on the Enterprise Wishlist. What are some common problems that need resolving and what features can we vote "up" as a Community?

Topics covered:

• Addon Management
• Do enterprises wish to control updates to addons or the application itself?
  The general sentiment seems to be "yes". At one extreme an enterprise may wish to allow the user's browser to pull updates directly from Mozilla. At the other extreme, an enterprise may wish to provide an intermediary point so that all internal browsers pull updates from this point. The intermediary infrastructure then has to have a way of pulling latest updates from Mozilla, either manually or automatically.
  
  So, first, we need to understand how to configure for each scenario. Second we need to understand how to set up our internal infrastructure to facilitate the second scenario.
  

• Distribution
• MSI packaging -This seems to be something everyone wants.
• Ability to easily repackage the browser so we can add in our own "default" addons.
  
• Distributors that create packages for others to deploy cannot use the Firefox brand as part of their package. However, enterprises that deploy for internal audience only can use the Firefox brand. Can we work through these issues to make distribution channels more accessible?
  

• Settings Management
• Group Policy - a non-trivial problem to solve. Need to work on proper GPO integration!
• GPO vs Mission Control - pros and cons - will schedule a separate meeting to discuss these issues.
  

• Security Zones
• By design, Firefox does not allow cross-domain scripting. For an intranet, this can effectively break Web2.0 where developers want web technologies to federate. With IE, subdomains on a common domain are placed in a Trusted Security Zone. The relaxed security settings allow full-blow AJAX federation and interoperability. Similar capabilities exist in Firefox but they are no where near on par with IE.
  
  Firefox has a notion of a "security setting". There are even policy.* settings that make it possible to simulate Security Zones. This is great! However, Firefox treats policy.* and other security settings differently from rest of the settings. In fact - according to Mike Kaply - it is a completely different API. Mission Control cannot manage these settings which means we can't enable them across the Firm. This is a real challenge. How can we allow Mission Control or GPOs to enable these settings in a managed manner?
  

Personal Musings
My team compiles our own version of Firefox from the latest "stable" source. We make no changes to the code base. Why do we do this?

1. Set our own version and timestamp info for the executable and the dlls. This helps us differentiate between "supported" Firefox and a "renegade" Firefox within the Firm. We actively discourage users from installing vanilla or "renegade" versions of anything. This is simply a security precaution for a Fortune 500. All software deployment goes through this pipeline. An unpatched Firefox within our environment that admits an exploit vector could be disastrous for business.
2. We enable and compile in the "Autoconfig" mode that allows us to run Mission Control for settings management.
   
3. We introduce some custom extensions and themes that we want to include in our package.
4. We drop in config files for Mission Control

Points 3 and 4 don't really have much to do with compilation. Using Mike Kaply's technique for repackaging Firefox (see here) we can drop in our custom stuff without having to re-compile. Points 1 and 2, however really prevent us from taking advantage of a third-party MSIs. In fact all packages of "vanilla" Firefox are pretty much useless to us.

My point, we really do need an Enterprise Firefox package that's separate from the Consumer package. But what is it? What's the common denominator? One enterprise will want to manage settings with GPOs. Another one will want Mission Control. A third will want both. Is it possible to instrument a flexible package that can be configured? Maybe asking enterprises to compile their own version is not such a big deal when instructions on doing so are bullet proof. Much to think about...

Agile Development Methodology

The original version of this document was created and put into action by my friend and ninja, Azubuko (Buko) Obele while we worked at our first start-up. The document has since undergone some revisions as I've adopted it for my own purposes over time. This is an agile, iterative approach to product life-cycle management and it work in small and large firms alike. (Buko, you're a genius).

Processes and Methodologies

This document specifies recommendations for the software development process and the IT infrastructure strategy for developers and managers.

Overview

Philosophy

The intent of this document is to establish a foundation for development traditions and ultimately a company culture whose central philosphy of the development strategy is to maximize communication, collaboration, feedback and transparency. In doing so, the company will succeed in constructing an adaptive development infrastructure that can rapidly address changing business requirements and market realities.

Communication will ensure that the company's software and infrastructure development efforts are focused on addressing concrete business requirements.

Colaboration will allow the company to encapslate areas such as knowledge and distribution, reuse and automation, and proper allocation and management of resources. This will ensure productivity and efficiency.

Transparency will ensure that the company's development efforts are generating value and that risks are apparent.

Feedback will ensure that the development efforts are in fact meeting concrete business requirements and allow governence teams to understand the "current" situation and plan for the future.

Core Competency

Middle-tier vendors are moving into the forefront consolidating and standardizing services that may be purchased "off the shelf". This long list of solutions includes groupware solutions, Customer Resource Management (CRM) solutions, datasource abstraction tools, corporate communication tools, and enterprise-level SDKs and utilities among many. While it may "seem" easier to integrate vendor components, long-term customization and Quality of Service (QoS) costs may hinder the company's competitive edge. On the other hand there is no sense to "re-invent the wheel" especially when the middle-tier vendors have nearly perfected the services and components they sell.

Finally, it is always advantageous for the company to participate in IT Infrastructure Strategies mentorship and advisory programs offered by such industry leaders as the META Group, Inc.

Product Driven

Development Teams are encouraged to think in terms of "products" as opposed to "projects". A product is a deliverable with a well defined cost and risk and one that will create some well-defined value for the customer and company. A "product" should include all implementation, development, and operation costs of underlying infrustructure and application. The composite should be treated as part of the company's "portfolio". Tactical and Strategic methodologies will allow the company to effeciently grow and reassess the portfolio.

Tactical or "per-project" planning is conducted for each new application or infrustructure-driven project. The phases of Tactical planning are described as part of the Development Process section.

Strategic or "periodic" processes deal with periodic reassessment of the company's IT portflio, including Infrastructure Impact Assessment (IIA) and Prdictive Cost Modeling (PCM).

Agility and Velocity

The development process should capitalize on the company's energy and small size. The ability to quickly respond to evolving requirements and market conditions will allow the company to remain agile and adaptive. The ability to quickly initiate product development while sustaining a high, predicatble rate of development will allow the company to retain a high velocity. To accomplish this, the development process itself must follow "Agile" methodologies with a focus on Test-driven development while keeping unnecessary documentation and meetings to a minimum.

Risk Management

Enterprise-scale infrastructure deployment and large-scale software development is inherently a high-risk/high-rewards endeavor. Methodologies and processes must reduce risk whenever possible. Risk assessment must take complexity, time to market, and specific business-related value into account. Commitment to collaboration, communication, transparency and feedback will also help make high-risk scenarios manageable. Long-term projects with large iterations should be avoided as they tend to require large investments of time and resources and are inherently lacking in agility. It is recommended that focus is on test-driven development, continuous integration, short iterations to create immediate value and to produce tangible returns, centralization, and portfolio view of infrastructure patterns and services.

Development Process

Inception

The goal of the product inception phase is to identify and define the business problem. The result of the inception phase is a high-level description of the product's purpose and a non-exhaustive set of produt requirements. It should be clear from the onset who the product is used by, what "pain" the product should "cure" or "alleviate", what potential value the poduct brings to the company and in technology-neutral, abstract terms, what the product should do. How the product will work is irrelevant at this stage; only the Why and What matter. A product idea may only pass this phase if the risk is justified by value.

Business, Infrastructure, and Software development governance teams should be heavily involved in this process to present a holistic view of risk and reward. The deliverables of this phase should be (1) Meeting Notes and (2) Product Requisition Document (PRD).

Service Level Metrics, Feature Planning, Use Case Definition

The goal of this phase is to evaluate risk and to ultimately bring it under control. At this stage, the infrustructure planner should work with the product managers to define a potential solution and agree upon service levels. The product managers should describe a series of well-defined use cases and rate them in terms of risk. These use cases will describe the solution to the business problem from the application perspective.

Business specialists working with Software development management teams and Infrastructure planners should deliver a Feature Specification Document (FSD), Service Level Metrics Document (SLMD).

Development Planning

The primary goal of the stage is to bring the technical risks under control. Issues such as performance, scalability, reliability, and security should be addressed and metrics for product success should be established. The infrastructure planner should leverage as much existing infrastructure as possible, and infrastructure standards and processes where innovation allows. The planner should propose a blue-print for solving the business problem on the infrastructure level. Application management teams should define the solution in terms of application architecture. The infrastructure planner and application managers should collaborate to address technical risk and anticipate future risks and requirements. Application architecture and infrustructure architecture must address services, service level matrices, the complexity of the solution, estimated time to market and provide a model of projected costs. A basic prototype or other form of "proof-of-concept" should be used in a Test Lab setting to evaluate the doability of the proposed solution.

At this stage, the deliverables are a Release Plan (RP), Application Architecture Specification (AAS), Assemble Infrastructure Plan Draft (AIPD), and Predictive Cost Model Document (PCMD), Functional Prototype (optional).

Implementation

In this phase product development is borken down into a series of iteration cycles. The length of the iteration cycle will depend on the complexity and scope of the product. It is recommended that the iteration cycle be between two and four weeks in length.

This strategy puts concrete deliverables in the hands of customers who will inevitably provide invaluable feedback. The result of this kind of iterative loop is a quantifiable reduction of risk.

The deliverables are Iteration Plans and Checkpoints.

Release

A product is expected to transition through multiple "minor releases" before a "major release". Minor releases should occur frequently (at the discretion of product management). The purpose of any release is to determine of a set of risks has been successfully eliminated. Major releases will generally evaluate a much larger set of risks than Minor releases and will ultimately determine the success or failure of the product. Each release must be accompanied by a Release Contract in order to define and hold accountable every party involved in the release. The Release Contract must be approved by each party involved before the Release Conract is executed.

All functionality deemed in "alpha" or "beta" stages should adhere to release procedures as they will ultimately face some or all clients. Monitoring utilities should be enabled on live systems, customer feedback forms should be integrated into the product along with automated critical error/crash reports if possible. Feedback and system logs are envaluable in qualifying product performance in "live" environments.

Deliverables for this stage are Release Contract, Product, Product Evaluation

Deployment

Test-driven development requires continuous integration of code written by the development teams. Integration may take on the form of code merges within a Code Versioning repository (CVS) followed by deployment to Testing or Staging servers in the Test Lab. A "Release" is merely a deployment to "Live" (client-facing) environment with the assumption that the release passed all testing in the Testing Lab under live conditions. Deployments to Testing environments should occur frequently (on a daily or even bi-daily basis) by developers acting individually or in teams. Focus must be on unit, functinoal, and stress testing which for most cases, can be automated by easily atainable tools and utilities (JUnit, Cactus, etc.).

Testing will provide insights into the problem domain and expose architectural weaknesses in the infrastructure and the application forcing the management teams to revisit the planning stages. All "bugs", suggestions, and issues must be submitted to a task management application (JIRA) and resolving the riskiest ones should be a priority while the problem area is still "fresh".

Deliverables for this stage are Regression Testing Reports (RTR) as well as tuned Application Architecture Specification (AAS), Assemble Infrastructure Plan Draft (AIPD), and Predictive Cost Model (PCMD) documents.

original: Azubuko Obele
contributions: Yuriy Krylov

Taking Baby Steps (part 2): Only one person reads my Blog and I've already won

Overview
My last post entitled "Taking Baby Steps (part 1): Personal, Ad-hoc, KB", suggested that Knowledge Workers should embrace a Blog (at work) as a personal Knowledge Base. The focus was on the Network of One and some of the wins on a, facetiously, "selfish" level. Laying a foundation for productivity-focused collaboration is realizing that the "hidden hand" also works wonders in a collaborative setting.

In this post, I will talk about some ways in which this Network of One also benefits folks One Social Degree away -- even if it's just one other person. This is the Network of Two.

Who is One Social Degree Away?

• People who directly depend on your work
• People whose work you directly depend on
• Your manager
• Your intern
• Your service team overseas
• Your client
  

At work, our "social network" of peers is typically well established. We are hired into teams, we have colleagues, team-mates, customers. Someone depends on what you produce - these people will benefit from the knowledge you share.

Syndicate updates via RSS/Atom
Any good Blogging software already has syndication capabilities built in. Simply advertise the URL to your Blog's "feed". All you need is an RSS reader. Some come integrated with your email client, others are standalone or web-based. Your friendly, neighborhood IT department should have something to meet your needs.

But this is a post on the Network of Two. Your manager is, in fact, the first person to whom you should advertise your RSS feed. Your immediate manager will always be your #1 fan.

Managers love Workstreaming
Once your manager subscribes to your RSS Feed, and you make a selfish commitment to maintain your very own knowledge base, you will automagically keep your manager concurrent with the happenings in your daily work-life.

The Network of Two and effective Workstreaming will emerge when you begin to cater "some" posts to your immediate audience. Hint to your manager that something is especially important to her with Tags such as "important" or "for larry".

The key is to allow the Blog/KB to become part of your natural routine. There are no rules of how much to post or how often. Just keep things relevant.

Completing the Feedback Loop
You know you've established a successful Feedback Loop within your Network of Two when:

• You find a "comment" on your Blog from your manager

I really want that first point to stand out - there are other indicators and emergent efficiencies when this Feedback Loop is completed:

• Meetings between you and your manager are shorter and more to the point
• You spend less time figuring out things you've forgotten
• You manager seems more helpful and, in general, more knowledgeable about what you are working on
  
• Sometimes the last point allows your manager to spot problems early and offer some very timely wisdom.
  

And so on...

Extra Brownie Points
The rarely seen but often sought after "Manager's Blog" where you get to leave comments.

Reverse Mentorship
I read my intern's blog every morning and I learn a book's worth every week. Just yesterday, I received a very in-depth refresher course in Java's SOAP API.

What about the team-mates?
My team works on many projects at the same time. I'm only a lead on one or two of them. This means that I need extra help staying up to speed on projects where I play a secondary or tertiary role. I read my peers' Weekly Update-tagged posts only. Good Blogging software will allow you to subscribe to a filtered subset of all the posts based on one or more Tags. How does my RSS reader know it's a Weekly Update? The Tag is "weekly".

For these secondary projects, reading "weekly" posts is enough for me to stay on track. This is especially helpful when I come back from vacation and dread opening my INBOX.

Non-urgent Information Only
Many folks try to misuse RSS by using it for Alerting purposes. This is not what the syndication medium is for. If you want to catch someone's attention because you require Immediate Feedback, use the phone, send an instant message, meet them at the Cooler.

RSS is best suited for Knowledge sharing that does not require immediate response. Your audience consumes the content at their own leisure, at their own pace. If you use RSS for anything else, it will very soon become as noisy and convoluted as email is today.

Final note of advice here -- turn desktop popups for RSS Updates off. Unless the Alerting mechanism is really smart, it will never know what is truly important to justify the time wasted recovering from the Interruption. I'm busy and need to focus, stop competing for my attention because my feed from pizza.com has an update.

Up Next, Too many Feedback Loops?
Every communication medium will be abused and misused. You may find yourself subscribed to too many feeds claiming importance. My next post will talk about cutting through noise with RSS and Tag-powered Dashboards.

Firefox EWG's first call is a success!

Thanks to everyone who attended the first Enterprise Working Group for Firefox call. We're still waiting for a statistic on how many folks were on the call and on the irc channel -- I'd ballpark the figure to be somewhere in the mid 20s.

Special thanks to Mike Kaply for MCing the call and to JT Batson and Basil Hashem from Mozilla for providing insight and effectively validating this initiative.

Very Brief Summary
The theme of this meeting was "Experience". Folks on the call shared their personal experience with Firefox in an enterprise environment. There were clear areas of interest and overlap.

My main take-away has been this: It cannot be understated nor unappreciated that "Enterprises" do, in fact, share pain-points and challenges and therefore must come together to form a real, effective Community.

Some identified synergies
By no means a completed list, but here is what jumped out at me:

• Packaging.
  
• Story around MSIs and MSTs vs some open source formats. Most Enterprises are heavy Windows users. At what point does the lack of these hinder adoption?
• What is feasible? What can Mozilla own and what can and should the Enterprise Community own?
  
• Patch Management.
• If an organization is not very Agile and agility assumes that not everything is perfect out of the box, is Mozilla's patch cycle too agile for "enterprises"?
  
• How are others patching Firefox on desktops without having to uninstall and install the entire product?
• Settings Management.
  
• What are some trade-offs between GPO and Mission Control?
  
• Not all settings are manageable.
  
• What settings should be exposed by all extensions to enable pref-level lockdown?
• Can we drive best practices for deploying plugins and extensions? There is very little documentation on where Plugins should go and how to configure in the registry.
• How do we prevent some critical settings from being "tattooed" into prefs.js? I.e. mcontrol and user agent settings should never be written to prefs.js when in Enterprise mode.
• User Profiles
• How can profiles/certificates be migrated with minimum impact to the end-users?
• Does having Firefox and IE share bookmarks help adoption? Can Firefox "piggy-back" on Favorites? How can it be done easily?

Follow-ups
Attendees were asked to contribute content to the http://wiki.mozilla.org/Enterprise wiki. Content will be refactored as we overflow. Mike and I will put up a page for each Meeting where we can post and track agendas, follow-ups etc and will work to keep content organized.

Up Next (August 8th)
Next call is scheduled for August 8th, same time, same station. Topic will be "Enterprise Wish List" and should be a fun, rowdy call!

Come one, come all. Help us spread the word.

To be politely blunt, we're committed to helping this community thrive. There will be wins. To my "enterprise" peers, you cannot afford to not have your interests represented - the potential for the Enterprise Web Browser as the Knowledge Worker's Killer App is too real.

Taking Baby Steps (part 1): Personal, Ad-hoc KB

Overview
This collection of posts is part ideology and part methodology aimed at Knowledge Workers still struggling to embrace the Blog and Wiki whateveryoucallit. I don't blame them. The words "Blog", "Wiki", "Tag", and so on, meant very little to me as well until I put each of the technologies to a very specific use.

What started out as a system to manage developer teams overseas turned into a Pipeline for Knowledge Sharing within a Team.

To me, collaboration is a Bottom-to-Top story. It begins with a very selfish Network of One. And that's OK! If you can't prove value to yourself, how can you prove it to the guy sitting next to you at meetings?

Mental Filters
Like many Knowledge Workers, I suffer from information overload and a bad memory. First step is always admitting you have a problem, right? Now, I tend to ask myself two questions whenever I deal with information:

• Is it useful to me now?
• Might it be useful to me later?
  

If there's even a remote chance that I'm dealing with Useful Information, it needs to go into my Knowledge Base. This is my Mental Filter. All incoming information competing for my attention goes through this and other filters.

A Blog is a Personal, Ad-hoc Knowledge Base
It just so happens that the simplest and most complete Knowledge Base I know of is my Blog. It's mine. It's for me. I don't care about structure, colorful phrasings, or a full bibliography. I just need useful knowledge sans the BS. If I take the time out of my Very Busy Schedule to throw something into my Knowledge Base (KB), I owe it to no-one but myself to only post useful and Highly Relevant information.

I also haven't figured out how to not live in my INBOX so I want to be able to email my KB.

Side Note: But wait, why not store everything in email and search there? With Blogging, selfishness turns into something very useful for the rest of the Team. Email just doesn't have that kind of potential for collaboration.

Finally, I want control over the organization of my Knowledge Base but I don't have time to organize into pretty folders. I just want the information I need at my fingertips with minimum management. And while on the topic of being selfish, I want the search functionality to work for me; I want to help it help me. I want to be able to Tag my KB posts with words or phrases that serve as Keys to Knowledge in my head. It should be easy for me to share these Keys with the cyborg extension to my head that is my personal KB. The search functionality in my KB should pay special attention to these Tags a.k.a Keys. It's a matter of improving relevancy and hence my productivity.

A note about Privacy Concerns
Start with a Blog that your Firm provides for you. It should be internal and inaccessible from the outside world by the outside world. Don't worry about protecting your posts from the prying eyes of colleagues. Focus on yourself. Only your immediate network will ever care about what you have to say anyway. Post openly, but only post work-related information. Remember, you don't have the time to post on anything else.

What kinds of things should I post about?
It took me a bit of trial and error to figure out my Blogging sweet-spot. At first you'll post too much or too little. Remember, it's for you so figure out what works for you.

Some ideas on what you may want to track in your KB:

• You figure out how to do something, save yourself brain space, write yourself a mini how-to
  
• You solve a problem, post solution so you don't have to solve it again
• Someone owes you a TPS report
• You've identified follow-up items at your 3-hour meeting
• You wish to condense your meeting to 15 minutes by posting an Agenda to your KB
• Someone else posted something that may be useful to you later

Ans so on...

Conclusion
When picking out a KB starter-kit, be selfish. My recommendation is to go with a Blog. Blogs have many useful features; clearly I've only scratched the surface. But really, the other features will come in handy later. Here is what you should ask of your Personal, Ad-hoc Knowledge Base Blog:

• Can you email it?
• Can you tag posts?
• Can you tag posts within your email?
• Can you search it?
• Are your search results influenced by the tags you assign to your posts?

Good news is most Blog implementations already do this. Your friendly, neighborhood IT department will help you set one up.

Up Next
In my next post, I will talk about how KB-directed Selfishness is, in fact, very useful to Team-mates.

Ant Build Script for Mozilla Extensions

I play with Mozilla Extensions in EclipseIDE and generally like the Ant build system. Not an expect at Ant by any means so if anyone out there wants to make improvements to these, please share. The relative paths to directories are set in the build.properties file so that it shouldn't matter what folder layout one uses. If I make improvements to this over time, will post updates, feel free to drop feedback.

build.xml

<?xml version="1.0"?>

<project name="Firefox Extension Builder" basedir="." default="package">
 <property file="build.properties" />
 
 <target name="setup" description="create dir structure for project">
  <mkdir dir="${content.dir}"/>
  <mkdir dir="${skin.dir}"/>
  <mkdir dir="${install.dir}"/>
  <mkdir dir="${locale.dir}"/>
  <mkdir dir="${defaults.dir}"/>
 </target>
 <target name="clean" description="Delete previously generated jars">
  <delete file="${install.dir}/**" verbose="true"/>
 </target>
   <target name="createjar">
    <delete file="${install.dir}/${project.name}.jar" verbose="true" failonerror="false"/>
     <zip destfile="${install.dir}/${project.name}.jar" excludes="*CVS*/**">
      <zipfileset dir="."
           includes="${content.dir}/**, ${skin.dir}/**, ${locale.dir}/**"/>
     </zip>
   </target>

   <target name="createxpi" depends="gen_manifest,createjar">
     <zip destfile="${install.dir}/${project.name}.xpi">
        <zipfileset dir="${install.dir}" includes="${project.name}.jar" 
                  prefix="chrome" />
            <zipfileset dir="${install.dir}" includes="${manifest.src}"/>      
      <zipfileset dir="." includes="${install.src}" />
      
   </zip>
   </target>
   
   <target name="gen_manifest">
    <copy file="${manifest.src}" tofile="${install.dir}/${manifest.src}" overwrite="true"/>
    <replaceregexp file="${install.dir}/${manifest.src}" 
     match="^(content\s+\S*\s+)(\S*/)$"
     replace="\1jar:chrome/${project.name}.jar!/\2"
     flags="g" byline="true"/>
    <replaceregexp file="${install.dir}/${manifest.src}"
     match="^(skin|locale)(\s+\S*\s+\S*\s+)(.*/)$"
     replace="\1\2jar:chrome/${project.name}.jar!/\3"
     flags="g" byline="true"/>
   </target>
   <target name="package" depends="clean,createjar,gen_manifest,createxpi"/>       
</project>

build.properties

project.name=${your_project_name}
content.dir=chrome/content
skin.dir=chrome/skin
locale.dir=locale
defaults.dir=defaults
install.dir=install
manifest.src=chrome.manifest
install.src=install.rdf

Enterprise Firefox Adoption Part 2: Where are my Bookmarks?

All these Bookmark syncing engines out there are great. Unfortunately, many large enterprises are simply at a point where policy restricts or greatly limits an employee's ability to expose information outside of their Firm. Bookmarks are no exception to the rule. Talk to a friend who works in Finance, you'll hear interesting stories directly from the battle field.

I don't have a solution for the above - this will take more scaffolding work. I do, however, want to raise the issue of synchronizing bookmarks between different browsers on a single Desktop -- for starters.

Some more realities of Firefox Adoption in the Enterprise:

• Not every business critical application will work with Firefox on Day 1 if all you have deployed Firm-wide is the Not Firefox Browser.
  
• Users will continue to use the Not Firefox Browser. Assume this is forever.
  
• Mose users will have years of bookmarks stored in the Not Firefox Browser and this list will grow.
  

As you can see, simply "Importing" Not Firefox Browser's bookmarks into Firefox just doesn't solve the problem. When multiple browsers live side-by-side in an Enterprise, users will want bookmarks to always be in sync between All browsers on All Desktops that they may ever use.

This is a two-step project:

• Step 1: how do I make Not Firefox and Firefox share bookmarks on a single Desktop?
  
• Step 2: how do I roam these as I move around from Desktop to Desktop?

Challenges
Theoretically, it is not very difficult to write a Desktop application that will listen for changes to your Not Firefox and Firefox bookmarks, resolve the differences, update each repository, etc.

But did you know that with Firefox 2, there is no easy way to reload bookmarks from disk while Firefox is active? The Bookmark Service just doesn't expose that functionality. Furthermore, when you shut Firefox down, it will out-dump bookmarks stored in memory back into the bookmarks.html file, effectively trumping any changes you've made to the file with your Syncing Engine.

Of course, there are workarounds and it is possible to hack your way around everything BUT who has the time or the will to do that??

What would an Architect say?
Managing two or more discrete, proprietary repositories for Bookmarks on the Desktop is a huge pain for the End-User, the Support servicing these Users, and for IT trying to enable this synchronization.

Any architect would already be thinking: "Centralize & Federate - store in one spot, leverage the one spot, make things easy".

Plain Old Favorites indeed!
At what point does it make sense to replace Firefox's Bookmarking engine with something else? I don't want to replace the whole interface per se, just don't want bookmarks stored in bookmarks.html anymore.

In fact, I want to leverage the Favorites folder for storage on my Windows Desktop.

Perhaps the File System implementation for bookmarks is not as flexible as what Firefox 3 promises to deliver via SQL Lite for Places. Still, the Favorites solution exists today and it is the greatest common denominator for a bookmark datasource. That is, by design, every browser can understand the File System with ease. Not to mention, it is a lot easier to get Firefox to read files for bookmarks than it is for IE to learn to read bookmarks.html - for example.

This is why I think that Alex Sirota's PlainOldFavorites extension is brilliant as a vehicle for Firefox Adoption.

Immediately, I spot some some tiny performance issues and a feature gap between what Firefox's bookmarks engine offers and how much of it is implemented under the auspices of "Favorites". Still, this is much simpler than having to engineer synchronization for two distinct data sources.

This also makes Step 2 much more light-weight and simpler to implement.

Part 3 of this post will focus on my research on PlainOldFavorites as an Adoption vehicle. I hope Alex Sirota will help me out...