A supplement suite of office programs?

[Alex Tweedly]

Lynch, Jonathan wrote:

>I don't know what they are developing Chandler in, but this quote from
>that page says a lot:
>
>"The next release of Chandler is 0.6 and will include usable calendar
>functionality."
>
>
>Calendar functionality just isn't that big of an accomplishment. Task
>Mage has a very functional calendar, and I built it by myself in the
>mornings before coming to work.
>
>  
>
The calendar functionality you have is, I suspect, a tiny portion of 
what Chandler will have (I don't know how far they've got so far). Their 
calendar is a shared calendar / scheduler, including multiple views, 
overlapping calendars, resource scheduling, etc.  This allows for 
partial visibility into other people's calendars (to allow meeting 
scheduling, but without being able to see *why* another participant 
isn't available - unless they've made it a public event, etc.)

I do not believe that in a few mornings you have built anything within 2 
orders of magnitude of the capabilities they have.

I do think Chandler has fallen into the trap of over-architecting their 
solution - but nevertheless they have tackled a hard problem, and have 
built a foundation on which the complete (and secure) sharing of all the 
PIM info should be doable..

btw - it's being built in Python, by a group including some pretty smart 
people.

>With Rev we can create a suite of supplemental office-ware that is much
>better than what is out there, and we can quickly modify and upgrade to
>meet the suggestions and demands of our client base. It is not just what
>we start with, but what we finish with.
>
>I would see the tool as being more comprehensive than Chandler. They
>say:
>
>"Chandler is a next-generation Personal Information Manager (PIM),
>integrating calendar, email, contact management, task management, notes,
>and instant messaging functions."
>
>
>There is no end to the number of apps we could include. We can certainly
>include the same functionalities as they have, but there are many other
>possibilities - like a simple-to-use billing program, or an application
>that guides sales people through a step-by-step process for selling
>their product, or an application that helps you create easy-to-use
>checklists that you can link to directly from the other applications. 
>
>  
>
Other than  a name, what would you expect to be common between these 
different apps ? (i.e. why are they called Somethin'Mage). Should they 
have common UI ? common menus ? auto-shared info where possible ? a shared
library of functions to handle data access and requests, etc.

>In addition to the freeware components, we can include optional paid-for
>components (stacks) for specified uses (or professional versions).
>
>For example, Task Mage is an intuitive to-do list/task management
>program that integrates notes and 2nd level to-do lists into each task
>file. It is designed to be run either on your own computer, or on a
>shared drive (I am considering other manifestations as well). One
>possibility would be a program called "Management Mage" (or maybe
>something less dorky sounding) that does various things to help
>managers, including the capacity to update the manager on the status of
>each task of each employee. Management Mage would be sold a-la-cart,
>separately from the Work Mage suite.
>
>Work Mage would (among other things) serve as a vehicle for selling lots
>of different applications produced by RunRev developers. If a user wants
>to buy one of these apps that are sold separately from the freeware
>suite, they just download it and save it to the same folder that
>contains Work Mage. Next time they run Work Mage, the app will appear in
>the list of applications, and they can run it.
>
>The way to divvy up work seems pretty straight forward. Anyone wanting
>to participate can contribute an application(s) to the suite. If two
>apps need to communicate with each other, then the developers working on
>those apps need to work that out together. 
>
Ouch.
  Two-way communication between developers who may or may not know the 
other exists until too late.
  N^2 agreements (potentially) needed.

I think there is a need for some more prescriptive mechanism for 
co-operative use of data ...

>Any freelance work that is
>generated by the suite could be bid on by any (or all) of the developers
>who have contributed. Any customization work would go directly to the
>developer of the specific app that is to be customized. Any a-la-cart
>sales would go to the developer of that particular a-la-cart component.
>However, in order to contribute an a-la-cart component, you should also
>have contributed a freeware component.
>
>I am open to all ideas, of course. These are just ideas off the top of
>my head. 
>  
>

I don't want to sound negative - I think this is a great idea. But it 
would be easy to "under-architect" a solution, and finish up with a 
bunch of vaguely related apps with no common theme, no common "feel", 
duplicated (and therefore out of date) data, and other similar problems.

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.3/209 - Release Date: 21/12/2005