Thoughts on Joey

• It will mimic Chandler to a great extent - many things they just got right. Eg, all items show up in one flat space.
• It will not have folders at all - only tags a la Gmail.
• Everything will first show up in the main dashboard which is effectively the inbox. There will be no explicitly named folder called inbox
• similarly there will be no Sent items folder. They will automatically tagged as "reference" or "info" or show up in the dashboard with a sent tag. The idea behind this is that there is really no other use for sent items than as reference material unless we're expecting a response and want to watch it. So the user has the option to tag it as watching before its sent, in which case it will automatically trigger a tickler when the user needs to be reminded if a response came, or a follow up needs to be sent.
  
• Projects and subprojects will be handled via hierarchical tagging, instead of the much more complicated route of have tasks and sub tasks. This comes from the insight I had that a) you cannot execute a project, only its tasks, and b) at the execution level, it need but just a flat todo-list. So taking the hierarchical aspect out of the task list helps, and we still retain that structure in the hierarchical tagging. So my strawman design for hiearchical tags is:

simple tag: home, fun, work
hierarchical tag: Projects. Project A. task1, Projects. Project B. Sub Project B1. task 3

• Bring ubiquity/awesome bar concept to PIMs. This is already there in Chandler, but enhance it to make that a primary use vector.
• Make it generic enough that the PIM can be made behave either like a GTD PIM, or like Outlook, if so required.
• Nice to have: Tasks show up in Calendar view if no date is provided, so that allocation can happen right there.
  

Design thoughts

• The core of Joey will know only about items and display them. The user can then setup a profile that has rule on what to do with the items.
• Items can be automatically got from an Exchange/IMAP/POP server or created by hand; and Joey will not do anything special with them like putting them in a special folder called "Inbox". Instead the rules of what should go where will be created by the user.
• Similarly the actions that can be done on an item would be configurable in the profile, and they're effectively two kinds:
  
• tag it
• change its type
• "act" on it. which depends on the item's type. For a mail its to respond. For an event its to attend and dismiss it, etc.
  
• The profile, therefore, will say the following:
• what to do with an item when its rendered on the dashboard - tag it to a particular type or not
  
• what action to take on it when the user "acts" on it.
  

New ideas

I've had a bunch of ideas lately that are sitting on a post-it on my desk, so thought this would be the better place to dump them:

• Twitterbot to show traveler updates: The idea is that you'd add the bot as a friend, and send it a tweet asking it to track your trip, and it would pull the itinerary and send tweets to your account with the progress of your trip. This way your followers (which i'm hoping are family) can keep up with where you are, and if you reached on time.
• Ruby Route for Tax Software: This is the idea that I use Route to create an open source tax prep software that mimics the manual forms
• AST Editor: already expanded on in previous posts. Look at IntelliJ's MPS as a potential solution that already exists. But not quite - I'm interested in maintainability, they're interested in creating a DSL ecosystem.
• Map reduce for code comprehension and static analysis: This comes from my efforts to get XRadar to work for Novo codebase, which it balked on. So the idea is to use map-reduce to break the problem down into manageable size, and still be able to do static analysis of large codebases.
• PIM based on Chandler: This is the new incarnation of my long-standing PIM idea: I recently went back to see how Chandler is getting along, and it seems like they have some great ideas, which seem even greater in the light of my recently drinking the GTD koolaid. But its slllllooooowww as hell - not good for a productivity tool, and it still doesnt do mail. So my idea is to create a PIM tool that does mail, and has all of Chandler's goodness. Chandler itself is not an option because its slow. So I looked for existing open source java mail clients that I can convert, and found Columba which seems to be really mature, but the source seems really impenetrable. Plus it still didnt do Outlook, which is on the top of my list of required integrations. Why have a GTD PIM, if you still have to import/export from the most used email client in the world? So now I'm investigating writing the thing in Ruby. I'm tentatively calling it Joey, as in we already have Chandler, so why not Joey :)?
  

Visual Programming: how it should really look

A meandering walk through the net that started at LtU and ended in Source code in Database led me to thinking (again) about how the real visual programming environment should be. And here's what I came up with:

• It should reflect the fact that code is essentially a graph. It should therefore be basically a graph editor.
  
• At the single program level, however, this graph is essentially left to right, top to bottom, so a standard representation (as shown by current editors) will be natural
• Folds and hyperlinks are still useful to have around, though; and this represents the 2.5D solution to what is essentially an n-dimensional graph
• It should have the ability to move in at least 3 dimensions - zoom in and out being the 3rd axis. This should behave according to usability principles - zooming way out from a single program should show its package within the other packages' context, but highlighted; while zooming just a little should show more of the program, but not fold or summarize it in anyway (font zooming goes away completely- we are looking at code, not text)
• Multiple views should always be available - eg, package view must be vieweable as a tree, or a treemap, or a graph, or a list of packages
• editing must be keyboard based to allow for a completely console based implementation if required. The focus is on exposing the true structure of the program, not to sugar coat its display
• Constructing programs must be a structural editing task, not a text editing task.
  
• language constructs such as keywords, classes, packages etc must act as single "characters" and be deletable atomically.
  
• since the AST is being represented visually, the editor must provide auto-complete and hints as to expected parts of the current statement being constructed. Eg, typing an "if" or choosing a command to insert an if statement should allow autocomplete to finish choosing if, and provide VB/eclipse style popup hints as to the other components expected.

Ted Neward's Languages talk

Ted Neward gave a talk at my office, and spoke about Languages, and how we're seeing a renaissance of languages currently. I spoke to him afterwards about visual programming, and his comment was:

"You know, every time I do this talk, someone comes to me afterwards and asks about visual programming. The thing is: text is currently the most succinct way to represent code"

I had to agree with him. But I thought some more about it later, and felt that while that that's true for presentation of code, it need not be for its persistence. Why should text also be the storage mechanism?

define: roomba football

Roomba Football (room-bah fut-bol): The practice roomba owners have of kicking crud towards the path of a running roomba so that it gets a second (or third, or fourth...) chance at picking it up.

Its quite an interesting sport, especially because the device is prone to make crazy changes in course, as any player of the sport will attest.