Email arrives.
A rule determines that it is low priority. So I want it to be labelled Inbox/Low_Priority.
I.e. I do NOT want to see it in my normal Inbox. Aka my priority Inbox.
But I *do* want to see it as a subfolder of my Inbox. So, here is an example of a case where I do not want the browseable interface to the label graph to show all items with label - where the fact that it has a sublabel (of a particular type) implying that it should not be shown as the default query for Inbox. But of course I might want to be able to see all items tagged Inbox, ewven though sublabels imply hiding.
Possibility: steal an idea from Bazaar DVCS: Inbox/* => all items with label Inbox, but not with "masking" sublabels. Whereas Inbox/** => all labels tagged Inbox, even with masking sublabels.
Inbox|Some_Other_Label - independent, not really path oriented
Inbox/NonMaskingSubLabel
Inbox//MaskingSubLabel
I probably won't get around to processing such Inbox/LowPriority emails very often. But when I do, and I handle them, I probably want to change the label from Inbox/LowPriority to straight LowPriority.
I.e. LowPriority is not just a sublabel. It is actually an independent label. But the instance on a particular item may indicate the masking sublabel relationship to Inbox.
If something gets tagged Inbox/SubLabel initially, and then just becomes SubLabel, and then is moved back to Inbox, should it go back to being Inbox/Subel? Or should it be Inbox|SubLabel?
If Inbox/SubLabel -> SubLabel -> Inbox/SubLabe, should this be
a) because it was originally Inbox/SubLabel - i.e. based on history of the labelling?
or
b) because SubLabel is marked as being in a possibly subservient relationship to Inbox?
Inbox is a special case.
Disclaimer
The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.
See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.
See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment