The content of this blog is my personal opinion only. Although I am an employee - currently of Imagination Technologies's MIPS group, in the past of other companies such as 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.

Saturday, October 27, 2012

Tag items not just with labels, but label paths

Gmail Adds Nested Labels and Message Preview:
'via Blog this'

Brain flash: I was, for the umpteenth time, looking for better mail reading and organization tools, when I re-read this article on Gmail nested labels from 2010.

Which suck.

It sucks that:
Nested Labels is just a cosmetic change that lets you create labels which are displayed hierarchically. If you enable this experiment and create a label like Mailing-Lists/Linux, you'll notice that Linux is displayed as a subfolder of Mailing-Lists. Unfortunately, all the other places that let you interact with labels show the label as Mailing-Lists/Linux.
.. this poor behavior is the default behavior on so many systems that use labels.

My brain flash:  messages, items, tasks need to be tagged not just with a set of labels, but with a set of label-paths.  I.e. label-paths may want to be a top level object.

A label path is a sequence of labels that might otherwise be considered top level independent, but which we are imposing some structure on.


  • Mailing Lists
    • Linux
    • Android
    • Agile
  • Technical
    • Operating Systems
      • UNIX-like
        • Linux
          • Kernel
          • Distributions
          • Mailing Lists
        • Android
          • Mailing Lists
        • iOS
        • Solaris
      • Windows
    • Software Engineering
      • Agile
        • Mailing Lists

 I have often talked about stuff like this - the issue of which hierarchy:  Mailing List/Linux versus Linux/Mailing List.  Labels get that right.

But I have only recently started thinking of label paths as something that get applied to individual mssages. I have hitherto thought f label paths or hierarchies as being properties of the labels themselves.

Perhaps it should be thought of as browsing similarly labelled objects:  A/B/C/D is equivalent to A&B&C&D, or even the reordered D&C&A&B.  But we can apply the operator "up" to a label-path A/B/C/D to get A/B/C, whereas "up" is not meaningful for commutative A&B&C&D.

Similarly, A/B/C/D/* is equivalent to saying D&A&C&B and ... either any other label or


I've been thinking mainly in terms of co-labelling suggestions: applying a label like "Linux" automatically suggests the path Technical/Computers/OS/UNIX-like/Linux.

It is a suggestion, because not all things labelled "Linux" may want to be labelled with the full path.  E.g. I might have something with a label-path Mailing Lists/Linux/Meetup, but I may not want a meetup social invite to appear in my technical hierarchy. (Not by default - but I may want to broaden, sibce sometimes a social invite turns into a place for technical notes get recordered).


Is it meaningful to attach a label-path to an item, rather than to the label itself?  I think that I just answered that question: yes.  A social invite may want to be Mailing Lists/Linux/Meetup but not Technical/Computers/OS/UNIX-like/Linux.

But I also want to associate label paths with labels.  So I can just say "Linux", and have the default label paths suggested.

The default label paths may be suggested not just by label, but also by context.  For example, in my to-do list organizer, default paths ToDo/.../Linux may be suggested.   If I am reading an email...


Again, think of it as browsing.  Label path hierarchy like a folder tree browser.

Looking at A/B/C  may start off by looking at all items labelled explicitly with the label path A/B/C.

But I may click to widen to A&B&C.

And similarly click to widen to all labelled C.

I think of this latter operation as something that takes me from viewing A/B/C to C.

I think of the folder browser as having (a) the current path tio what you are looking at, and (b) alternate paths that get to the same place.  To give you more ways to go up.  And sideways.


Everything I have said about applying label paths is also applicable to applying label DAGs or more general graphs.  Paths are just easy to type.   But I can easily imagine wanting to apply one label and automatically have it appear by default in several places in the "path" oriented browsing hierarchy.


Andy Glew said...

By the way, what prompted this: I am pretty unhappy with the way Google Tasks handles task lists.

I would prefer to have GMail style labels for tasks.

So I got the bright idea of just trying to track my tasks in GMail, with labels for task complete, etc.

So I started looking for a decent Android GMail reader. Since the default GMail reader for Android does not understand labels very well. It has a label view, but it is flat.

So I was reminded that GMail labels are darned flat. Annoyingly so.


Bottom Line: I still don't have a task manager that I like.

Andy Glew said...

Here's a thought: there's a key difference between a filesystem path like A/B/C, and thinking of "ls A/B/C" as almost equivalent to select items tagged with labels A&B&C:

In a filesystem, "ls A/B/C" finds everything that is just in A/B/C, but not in subdirectories.

"find A/B/C" is equivalent to saying "select A&B&C".

"ls A/B/C" is something like saying "select A&B&C and NOT any other tags (at least those marked possibly subsidiary to A/B/C"