From the shores of the Muddy Branch

In two different contests, Morse code wins over SMS for speed texting.  First at the Powerhouse Museum in Sydney, Australia then on the Tonight Show –

Need to ask Russel Beattie when the first mobiles will be out with a Morse key and text converter!

AirSet a new web-based beta calendaring application was launched this week.

From their press release:  Airset Client Transforms Mobile Phones into Networked Personal Information Managers (PIM)  – includes address books, to do list, calendaring, messages, and blogs. 

On the calendaring end, seems to be a closed system – no iCalendar support no publishing of calendars for non-AirSet members to see.

Anarchogeek does a great review of Trumba, EvDB and Upcoming.org.  The comment that caught my eye was:

"It’s [calendaring is] a hard problem, and i am not sure what the right solution is, but i know i haven’t seen it. It’s a very different problem that that of a PIM or a business group / team scheduling. The majority of calendar apps are PIM focused, which is not my personal interest, as my life is not full of business meetings."

This was one of the reasons for the putting forward RFC 2445 iCalendar Basic – it strips the standard of the PIM releated activites that are not interoperable including to do’s, journals, recurrance rules and timezones.

Joel quoted Eric J. Smith who wrote that “FogBugz could single-handedly manage my support requests, sales requests, bug tracking and project management for CodeSmith.”   I have been testing FogBugz on a new product development effort and it has not been a great fit for me outside of tracking issues.

I usually work directly with business owners, delivering vision briefs, high level goals, and the requirement documents for use by the development teams. In general, the vision statement and high level goals are transformed into product features and the features are broken down into specific requirements: UI, business process, interface to other applications, etc. The benefit I was looking for is the ability to track items from thought to completion while providing structure collaboration in ways email and MS Word cannot. The drawback is when using any tool you accept the necessary evil that you need to record the information to fit the way the tool works.

In the end, the vision statement, high level goals, and features were in MS Word and the resulting requirements in FogBugz. So, no online collaboration during the requirements phase.  Also, the development team when reading specific requirements need to go somewhere else to understand the full feature, high level goal, or vision.  At a minimum, I needed the ability to breakout a single case into sub cases, where each sub case could be assigned and managed.  I thought of creating separate projects or areas for each feature, but did not like the idea of forcing the tool that much to meet my needs. The ability to modify the resolve status listings was high on my wish list too.

Hopefully, Joel’s new summer project will tackle the needs for new product development and requirements gathering.

We had several inches of rain and the Muddy Branch overflowed it’s banks – glad they left the flood plain around the creek to catch the overflow.

Muddy Branch Overflowing in Gaithersburg Maryland

The last two weeks had many calendaring related announcements, the 2nd (or 3rd) try effort to getting calendaring interoperability though the IETF,  and   Esther Dyson’s PC Forum with two event based companies Trumba and EVDB  presenting.   

Next week may be even better as, EVDB is suppose to go to live for beta as reported by Om Malik, senior writer with Business 2.0 magazine.

Plus, Upcoming.org announced new development soon to be released that was inspired by Jon Udell.

Up first: Exporting your event history, current and past event lists for venues as RSS and iCal, tagging events, listing private/personal events, and a REST API for retrieving user, venue, and metro information. For other items on the pending list, see the rest of the current To-Do list. I’ve decided to develop an API for adding events, as well, but that may take a little longer.

The following goals will be used to draft a new charter for IETF consideration.  The hope is to have a working group by the next meeting.

• Assess what interoperates now, advance that subset to draft standard
• Document what is unsatisfactory
• Consider upgrade/version/transition issues
  • eg negotiation, file export
• Draft standard approach
• Fix desired features that are fixable without ratholes
• XML transformation of revised format
• Clarify extension procedures (IANA etc)

Courses of Action:

1. •Are we prepared to ‘break’ existing implementations.

2. •What is in scope for changes and what is out of scope.

Possible Approach #1 – fix known errata and ambiguities and redesign recurrences

Discussions are around that if it was just errata ad ambiguity data then we would not be here.  Timezones discussions – which have been covered before.  My thoughts is it is best to let the client handle the users timezone calculation – not the sender.  More discussions on how much in RFC 2445 does not work. 

More on CalConnect and it various commitments, most interesting is the Min-IOP which establish what is the minimum standards being implemented by vendors.

Issues in Calendaring and Scheduling

• Interop Events results showed vendors were not 100% compliant
• Recurrence – primary area were compliance is missing
• Timezones  – required for recurrence only
• Internationalization
• Calendar Spam (SCAM0