[pjb]

Being able to access the address book database directly, similar to Mail, would be sweet. I'm not sure I have to have it as an element of every action as an iCal event has attendees or in a column as in several of my custom OO files (where I still have to drag the card out of AB. OO already recognizes URLs and address cards as specific item types based on content and finding that item amongst all your databases (OW history, etc) as you start typing and placing it in the meta-data would be the next advance (like having LaunchBar inside your app).

In the future, Arbitrary meta-data will be most useful once we also have smart items.

In the meantime, if I have a name in OF I use LaunchBar to find it in Address Book (highlight name, OF:Services/Send to LB, navigate per LB to either display or dial or whatever). I suppose QS could do the same thing.

[whalt]

Originally Posted by SpiralOcean

I don't understand your point here.
In LB, if I wanted to see all Computer items, I could create another Computer context and include my Work>computer and my Home>Computer, but I would never do this. I don't want to be using my own time to work on work items. And I don't want to be distracted at work and see my personal items. They aren't paying me for working on my personal items.

Although I will admit that my work/personal boundaries may be looser than yours that's not really the point. I was just trying to give a hypothetical scenario. I think you're getting too hung up on the particulars of my example. Perhaps I should have used X, Y and Z.

Originally Posted by SpiralOcean

I don't even know why anyone would ever have a category called Computer>Work and Computer>Home.

Um, you wouldn't. That was my point.

Originally Posted by SpiralOcean

How long have you used Life Balance?
...

The difference between LB inclusion and OF hierarchical is minor.

Let me preface to say, I've been using LB for about 5 years, and have done things with it that are only dreamt of in your philosophy.

I have used LB off and on for several years including the Palm edition but fine I will be happy to bow to your superior knowledge of the product EXCEPT for this one issue of Places/Contexts. If you can't see how the LB multiple inheritance model, for better or worse, is fundamentally different from the straight hierarchy of OF contexts then I'm not sure you've thought about it very much.

Whatever the case may be, apparently it didn't work conceptually for you and getting into an academic discussion about set theory and how any tagging model can be recreated using LB's Places model is probably not really going to help anyone but I assure you that if you give me any arbitrarily complex tagging scheme I could recreate it as a set of LB Places which is something that OF contexts simply cannot do.

Originally Posted by SpiralOcean

Okay... now that is something we both agree on. I don't want the tag soup either.

Common ground at last.

Originally Posted by SpiralOcean

All I can say is... an entire world opens up when tagging is allowed. But it has to be a structured tagging, otherwise, it can get messy.

Whether or not you ever hit that wall may depend on the type of job you have and how you are working with other people. Tagging allows the flexibility you need to quickly bring up lists of things for other people, or if the environment changes rapidly you can adapt with it.

Yes, I agree with all that but in other tagging apps I've used, that functionality is outweighed by having to type in a long string of keywords/tags and separators with every item. I want to still have the auto-complete as well as the ability to drag tasks into contexts that I have now. That's why I suggested the LB model as a point of departure because it provided some of the flexibility of tagging (whether you believe me or not) along with concrete items that could be pointed to.

Originally Posted by SpiralOcean

Some of the examples are... having lists of things to do for interns while still having the items on a list for me to do, without duplication.

Ok, this is an easy one so I can't resist. The same logic holds for your other two examples so I'll leave those for you to work out yourself.

Contexts:
Either
Me (includes Either)
Intern (includes Either)

So you have three items, one that only you could do, one that your intern needs to do, and one that either one of you could do. You place each item into the most appropriate context above.

Context Either contains only the one item that both of you can do. Context Me includes two items, the one only you could do and the one inherited from Either. Context Intern contains two items, the one only the intern can do and the one inherited from Either.

There it is with no duplication. Now explain to me how OF contexts would accomplish this?

Of course you can do the same thing with tagging and maybe that's a conceptual cleaner way to handle it as long as the interface still maintains the sense of a context and not just a set of amorphous keywords.

I will say that I still prefer the ability to just assign one context as in Either above and have it show up in multiple contexts rather than having to assign multiple tags like Me and Intern to every item that can be both.

Originally Posted by SpiralOcean

If the contexts were more tag oriented... I wouldn't have any duplication of contexts. Right now I have duplicates of all my contexts at work and at home. If I could tag contexts, I wouldn't need those duplicates.

Wait, wasn't that my point? I thought you said that there was no overlap between your work and home lives so why would this be a problem for you?

Oh well. I'm really not trying to start/continue an argument. I think we probably agree more on how we might want an ultimate solution to look like than we disagree. The fact that we are both passionate about the future direction of the product I think speaks well of what Omni has accomplished so far but they do have a long way to go and therein lie the pitfalls.

[whalt]

Originally Posted by Ken Case

First off, thanks everyone for your discussion on this, and especially for providing some concrete examples of what you're trying to do!

It's really encouraging to know that you guys are making note of this stuff because I think it is an important area that needs some improvement.

Since you are looking for concrete examples of how the current context hierarchy is less than useful sometimes I'll share one of my current head scratchers.

I have a very loose work schedule. I do work for a company and not myself but I pretty much set my own hours. The company has different shifts and the building is accessible by me 24 hours a day. I find that some things are best taken care of during the regular business day such as discussing an expense report with someone in the accounting department. Other tasks are better left for the evening when many people have gone home such as performing maintenance on the accounting department computers. Many tasks can of course be handled anytime I'm at the office.

So if I break these into contexts I get Work Day, Work Night, and Work General. Now what I would love to be able to do is click on one context and see everything that is currently available in that location. For instance, if I'm at the office and the sun is shining I'd like to be able to click on Work Day and see all of my available actions for being at work during the day. Unfortunately, right now that takes a multiple selection of contexts.

So what I'm looking for is contexts that include other contexts within them. That sounds like what is available with OF's nested context feature. Looking offhand at my three contexts above you might assume that the following hierarchy would make sense.

Work
--->Day
--->Night

But that provides for exactly the opposite of the functionality I'm looking for and in fact provides less functionality than the separate contexts themselves. If I select Day, I still only see what's available under Day and see none of the generally available Work items. If I now do a multiple selection of Work and Day as I did above, I see everything including Night tasks which I'm specifically trying to avoid.

I can regain some of the functionality I'm looking for if I reverse the hierarchy for one of my shifts.

Day
--->Work
Work Night

Now by clicking Day I get one of the inclusive views I'm looking for but now the Night items are left out in the cold and even worse, all general Work items now are visually categorized under a false taxonomy of Day items.

That is what I was getting at with my recommendation to take a look at the LifeBalance context inheritance model for which this kind of classification is easy. I guess you could solve this with Perspectives as well if they now respect both context and project selections, the last time I tried them they didn't yet, but it still seems less intuitive then just clicking on one context to see what's up. Maybe once Perspectives get a better UI (i.e. named and not just living in the menu bar) the differences may be moot.

[curt.clifton]

Why not:

Work
- Anytime
- Day
- Night

Then you select both Anytime and Day if you're there during the day. Once perspectives are fully implemented you would just open the Work Day perspective to get this selection.

I used LifeBalance for awhile and really liked their "places", which provided groups of contexts. But it seems like perspectives is exactly that. Am I missing something (or forgetting it)?

[whalt]

Originally Posted by curt.clifton

Why not:

Work
- Anytime
- Day
- Night

Then you select both Anytime and Day if you're there during the day. Once perspectives are fully implemented you would just open the Work Day perspective to get this selection.

I used LifeBalance for awhile and really liked their "places", which provided groups of contexts. But it seems like perspectives is exactly that. Am I missing something (or forgetting it)?

Well your solution is pretty much the same as what I had before putting them into a hierarchy. You still have to make a multiple context selection which is what I was trying to avoid and which I still think is counterintuitive and cumbersome. It also highlights how useless nested contexts are functionality wise in OF.

I agree that Perspectives seems to be the way they are trying to solve this but right now the interface for them is kinda lame. It also adds another layer of categorization (a set of work contexts and a set of work perspectives) but I guess I can get used to that.

I'm glad to hear that someone else at least appreciates the LifeBalance Places concept.

[curt.clifton]

Yeah, the multi-select thing is kind of annoying. I'm withholding judgment until the Perspectives interface is complete. I'm hoping for some at-a-glance way to see what Perspective I've selected.

I agree that the context hierarchy doesn't add much value for the current example. But I do find hierarchical contexts useful for some things though. For example, I have a Computer context with several subcontexts for different modes of work (Planning, Editing, Coding, Email, Web). If I'm at the computer and not in a particular mode, then I'll just select the Computer context and get all the subcontexts also. (Places would support this as well, of course.)

Hmm, if the perspectives were all listed in the top part of the sidebar, that would be a lot like Places. It would still be a different category of things, but the UI might actually be cleaner than the Places UI in LB. You could click a perspective and immediately see all the contexts that were included. That might actually be the best of both worlds. What do you think?

[SpiralOcean]

Originally Posted by whalt

Ok, this is an easy one so I can't resist. The same logic holds for your other two examples so I'll leave those for you to work out yourself.

Contexts:
Either
Me (includes Either)
Intern (includes Either)

So you have three items, one that only you could do, one that your intern needs to do, and one that either one of you could do. You place each item into the most appropriate context above.

There it is with no duplication. Now explain to me how OF contexts would accomplish this?

You missed the point. But I'm sure I've missed quite a few points...

I would not want to put a task in a me context or an intern context. It's like working out of the inbox... One massive group of tasks to complete.

I guess following your example I could create subcontexts for me & intern...

Me
-computer
-email
-calls...

wait... what am I doing? It's like I'm typing for no reason because you are not going to see what I am talking about...

never mind... it's not worth the effort.

[Craig]

Originally Posted by curt.clifton

Yeah, the multi-select thing is kind of annoying. I'm withholding judgment until the Perspectives interface is complete. I'm hoping for some at-a-glance way to see what Perspective I've selected.

While we're waiting for Perspectives (which I agree will be the solution), I've found the script contributed here to be a handy way of selecting frequently used multiple contexts at once (in my case via Quicksilver).

[brianogilvie]

Originally Posted by whalt

I'm glad to hear that someone else at least appreciates the LifeBalance Places concept.

I appreciate it too and mentioned it in another thread (back in May). But my internet access is too sporadic now to keep chiming in!

[whalt]

Originally Posted by SpiralOcean

You missed the point. But I'm sure I've missed quite a few points...

I would not want to put a task in a me context or an intern context. It's like working out of the inbox... One massive group of tasks to complete.

I guess following your example I could create subcontexts for me & intern...

Me
-computer
-email
-calls...

wait... what am I doing? It's like I'm typing for no reason because you are not going to see what I am talking about...

never mind... it's not worth the effort.

Yes, I think we are talking past each other here. I'm trying to discuss a general concept that I would like Omni to consider and you seem annoyed that I'm not interested in discussing your particular situation right down to the exact context names you want to use. I'm not saying that Me, Intern, and Either are realistic categories just an abstract simplification to match one of your given examples.

I think I've shown that the feature you derided is indeed more capable than you gave it credit for, certainly more so than OF's current implementation. Whether you would like to see it in OF is another matter. I, for one, would and perhaps others might as well that's why I brought it up and continue to defend it. If it's implemented in a fashion that looks more like tagging (which fundamentally it's very similar to) then that's fine as long as the flavor of concrete contexts are kept and some of the pitfalls that many tagging implementations have fallen into are avoided.

Well I think I've stated my case plainly enough and like I said I'm not trying to gin up a flame war. I'm happy to agree to disagree on this point and I will try to read your future posts on this and other matters with fresh eyes.