---

Instant Messaging #

Open questions

• Simple IM?
• Something comparable to Mozilla IRC chat?
• Only works on Jabber? Not interoperable with AIM, IRC, etc.
• Buddy list?
• Text only?
• Presence indication?

---

Generic Viewer #

• notes from the Design Group meeting on 5 Feb 2004
  • in scope for Canoga: a capplet/view that lets you work with simple tables -- a basic "spreadsheet" view like the mixed view in 0.3
  • Post-Canoga: a more feature-rich, complex table-outline view

• notes from the Design Group meeting on 17 Feb 2004
  • include a generic viewer as a 0.4 goal
  • have this generic viewer be built on a generic table widget
  • have it display one item per row
  • have it display one attribute per column
  • attributes are editable in-line, in the cells of the table
  • editing affordances in the cells are type-specific -- different affordances for cells with dates vs. cells with strings vs. cells with enums

• notes from the Design Group meeting on 19 Feb 2004
  • the 0.3 "mixed view" uses a table widget to display all possible PIM kinds
  • the generic viewer will be built on a generic table widget
  • the generic table widget will have UI affordances for adding columns
  • the generic viewer will have UI affordances for picking what kinds to display, and what attributes of those kinds to displays
  • open issues
    • need to define what UI affordances we want the full-blown table widget to offer

• more questions:
  • Table view?
  • Outline view?
  • Table/outline view?
  • Super widget?
  • Pivot table?
  • Can display any kinds of items?
  • Can edit any kinds of items?
  • Standard widgets for different data types (date, string, text, etc.)

---

Dashboard View #

---

Nav Bar #

See 0.3 Nav Bar Design

---

SidebarSpec #

---

Search #

---

Import/Export #

Open questions

• from Chandler to Chandler
• from Chandler to ...
• from ... to Chandler

---

#SyncML

SyncML #

---

Web Services #

• for Canoga -- no web services style features

• post-Canoga options:
  • HTTP server in Chandler client
    • serve HTML
    • serve RDF
    • serve XML
  • RSS feed from Chandler client

---

Agent Design #

• DesignGroupMeeting20040205
  • open issue: Do we plan to expose agents in the Canoga UI

---

End User CPIA Design #

• DesignGroupMeeting20040205
  • no plans to expose any CPIA UI-builder capabilities in Canoga

---

Install/Update #

Open questions

• Install
  • Installers for Windows, Max, Linux
  • something akin to InstallShield?
• Update
  • Install on top of existing installation?
  • Automatic notification of updates?
  • "Check for updates" button?

---

End User Notification #

Open questions

• Notification
  • sounds
  • email
  • system tray
  • blinking/bouncing icon
  • dashboard
  • IM

• what's our notification strategy
  • How do we want to do notifications for sharing?
  • How do we want to do notifications in general?
  • What sort of change notifications does a user get regarding shared items that have changed?

---

#Trash.ThirdPartyCapplets

Third Party Capplets #^?

• Ideas from Jan 2004
  • see ThirdPartyCapplets^?
  • basic chandler functionality is baked in -- not swappable -- mail, contacts, calendar, IM, etc.
  • 3rd parties can write parcels/capplets
    • capplets appear as new trays in the sidebar, with new views in the trays
    • capplets can create new content model kind that subclass from ContentItem
      • Chandler's generic info management tools will work with items of the new kinds -- you can put them in projects, make collections of them, create notes about them, share them with other people, etc.
      • capplets can also not create new kinds, and just provide new views for existing kinds
    • minimal effort spent making sure UI's of 3rd party capplets are consistent with Chandler
    • minimal effort spent on making "utility services" be pluggable -- spell checking, spam filters, export tools, etc.

• Mitch's notes from 11 Feb 2004
  • We need to bring clarity to how the user experiences parcels and caplets. For simplicity's sake, I am proposing a scheme which avoids the need for the concept of a caplet as something distinct from a parcel. This has to be vetted against engineering reality and, in the case of things not yet implemented, engineering feasibility.
  • From a user perspective, there will be two kinds of parcels, main parcels and helper parcels, the distinction being that a main parcel has a user-facing content model and user-facing visual and interactive elements like views, whereas helper parcels lack both of these and are designed to help main parcels do things Examples of helper parcels might be recognizers or a spell-checker. Functionality designed to do work for a single parcel, such as a spam filter, could be packaged as a separate helper parcel but doesn't have to be. We can probably come up with a better name for "main parcel".
  • Chandler will ship with a PIM parcel which is responsible for PIM functionality. Other functionality, such as a Repository Viewer, RSS Reader or MP3 player will be contained in separate parcels. It follows that the definition of any kinds needed for the RSS reader, e.g., defining "RSS item" will be contained in the RSS parcel.
  • It will be possible to have a Chandler without the PIM.
  • Important engineering question: which kinds are defined in "core Chandler" and hence are available to any parcel and which are defined in the PIM parcel? "Content item" belongs in the core. What about email, event, note, and contact? To discuss: reasons for and against putting them in the core or the PIM.
  • Another engineering question: Can you download a parcel while Chandler is running and see it show up?
  • Each open content tab is associated with one main parcel.
  • Chrome and Parcels
    • Each parcel takes over the sidebar when a content tab or window associated with that parcel has the focus. This implies a pulldown affordance in the sidebar to switch to a different parcel. If that parcel currently has open tab(s) the tab which was last in front when the parcel was active is brought to the front. If that parcel has no open tabs, the parcel does its standard initiating behavior as if it had been booted into.
    • Each parcel controls the toolbar (and agent bar if we have one).
    • There is one menu bar shared by all parcels. The bookmark bar is shared by all parcels.
    • Issue to discuss: is there is a need for "ownership" of kinds by parcels, and discovery of kinds and their owning parcels.

• Notes from Design Group meeting on 19 Feb 2004
  • Open issue:
    • What is a capplet?
    • Proposed answer: A capplet is like the user facing side of a parcel. There is a 1-to-1 relationship between capplets and the entries in the capplet pop-up menu at the top of the sidebar. Exactly one menu item for each capplet.
    • Example capplets:
      • ZaoBao
      • Chandler PIM capplet -- including Mail, Notes, Calendar, Dashboard, etc.
      • Sandy's third party capplet
  • Open issue:
    • What is a parcel?
    • Proposed answer: "Parcel" is an engineering term, but a parcel may have a "user-facing" meaning as well, bridging both worlds. Parcels are represented as items in the repository. A parcel is an item that can contain other items -- kinds, views, blocks, agents -- the building blocks of Chandler. In that way, a parcel is like a file or folder in a file system. Parcels can be nested inside other parcels, and parcels can have dependencies on other parcels. A parcel can publish a capplet. (Open issue: Can a parcel ever publish more than one capplet?) A parcel can also not publish a capplet.
    • Need to reflect above description in the glossary entry for "Parcel"^?
  • Open issue: * Need to define the content model for parcels and capplets.
  • Open issue: * On a component by component basis, specify what's shared between capplets and what's done per-capplet: side bar, bookmark bar, nav bar, menu bar, etc.
  • Open issue: * There needs to be a way for parcels to register themselves (and the kinds they define) with the app. Needs to be an API for parcel discovery.

• see KatieNotes20040312

---

Printing Features #

• DesignGroupMeeting20040205
  • Basic printing is more important than many of the other "mundane" features listed (like "auto-update", or a clean, crisp UI design for preferences). Printing doesn't need to be outstanding, just functional -- get the first 80% working, without spending tons of time on bells and whistles.

• Post-Canoga features to consider
  • Page Setup -- standard features: paper size, margins, portrait/landscape, headers/footers, page numbers, etc.
  • Print Preview -- standard features: zoom, multiple pages, portrait/landscape, etc.
  • Print -- standard features: choose printer, choose page range, duplex, print to file, find printer, multiple copies, zoom, scale, print selection, etc.

---

Media Handlers #

Open questions

• HTML view/edit
• .gif view
• .jpeg view
• sound players (for notification beeps, etc.)
  • .wav
  • .mp3

---

Text Services #

• DesignGroupMeeting20040205
  • Spell checking
    • Q: in-line spell checking vs. batch spell checking?
    • A: in-line spell checking is a requirement for Canoga

• Open questions
  • Recognizers
  • Spam filters

---

Preferences #

Open questions

• Preferences Panel
• "Just like I left it"
  • window size
  • window position
  • selected view
  • view layout
    • columns
    • column widths

---

Help #

Open questions

• Built-in Help
  • native help system vs. consistent UI?
  • Web-style interface -- back, links, etc.
  • non-modal help
  • Help "entry points"
    • Glossary
    • Index
    • Search
    • Table of Contents
• Web-based Help
  • different web sites for different releases?
• Tooltips
• Fancy features
  • "What's This?" -- balloon help
  • "Why the Beep?"
  • Help Agent

---

Internationalization/Localization #

• DesignGroupMeeting20040205
  • We don't need to ship Canoga in a variety of different langauges, but we would like to ship it with all the infrastructure in place so that 3rd parties can produce localized versions. We need to look into what's involved, and either validate that goal or shoot it down as being too hard.

---

ZaoBao #

---

Contributors

• BrianDouglasSkinner - 2 Feb 2004 to 11 Feb 2004

---

---

#Trash.CommentsWelcome2

Comments Welcome!

This is a place for posting comments. Anyone is welcome to contribute here, with any sort of comment