Andy "Krazy" Glew is a computer architect, a long time poster on comp.arch ... and an evangelist of collaboration tools such as wikis, calendars, blogs, etc. Plus an occasional commentator on politics, taxes, and policy. Particularly the politics of multi-ethnic societies such as Quebec, my birthplace.

The content of this blog is my personal opinion. It is not that of my employer. See Disclaimer.

Photo credit: http://docs.google.com/View?id=dcxddbtr_23cg5thdfj

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.

Saturday, October 27, 2012

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.

E.g.

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.