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 13, 2012

User Interface Designers neglect Nesting and Linking

A common problem of user interface designers is that they neglect hierarchy and linking.

E.g. for note-taking programs: sometimes you want a note within a note, a note attached to a note.

E.g. for calendar programs:

  • notes on calendar items
  • links between calendar items
  • to-do lists and checklists attached to calendar items
For to-do lists and checklists:
  • notes on the top level lists and checklists
  • notes on individual items
  • links to calendar items
  • checklists nested within checklists
  • checklists nested within each other and linked to each other
    • e.g. when I go travelling on business I take all of the electronics I lug around every day, ++
For reminders: (which I am only recently realizing are distinct objects in their own right)...

You get the picture: all of the basic data types of my imaginary PIM (Personal Information Manager)
  • text notes
  • drawings and bitmaps (e.g. screen captures, although I still like vector grapics)
  • time scheduling and tracking
    • recording: diaries, logs, and journals
    • scheduling and planning:  calendars and schedules
      • hey, writing this made me realize that schedules and to-do lists and checklists are related
        - e.g. might want to reuse a schedule/plan for arranging a trip or a meeting - I guess that is like a template for a trip on a travel website - and when instantiating such  a template drop items onto your calendar/schedule relative to the target date (although likelihood is that you will tweak the dates
... and I am sure that I have forgotten some ...

All need the ability to be embedded in other objects, and to have other objects embedded in them.

(I want to say "of course there will be leaf types" ... but do there need to be?  Can we come up with a rendering scheme that is completely self recursive, without having to introduce leaf types (like TextNote, versus TextNoteThatCanHaveOtherStuffEmbeddedWithinIt). Certainly a data representation like XML, without DTDs, can be completely self recursive[*])

([*]: actually, it seems, based on tests, that DTDs permit recursion.  Which is okay by me: I like being able to have DTDs, as long as they can be optional.)

9 comments:

Andy Glew said...

Example in point: labels (e.g. on Blogger and in Gmail - and in the patent tagging effort at a former employer).

So many tagging systems start off "flat". No hierarchy.

Grudgingly they may later add hierarchy. Which basically means that you can tag something A/B.

But I haven't seen many tagging systems that allow linking.

What you really want is that tagging something B will imply A/B. Or A.

By which I mean "in the tag database, i.e. the database of tags and their meanings (as opposed to the database of objects that are tagged) when you tag an object B also tag it A, or A/B". And maybe some user interface.

Note that this may just be a default. I.e. you may not want all Bs to be As or A/Bs. But you may want that to the default, suggested.

I.e. most of my posts about PIMS (Personal Information Management Systems) also apply to CIMS (Collaborative Information Management Systems). But perhaps not all.

Going further: I may want B to be A/B and also A/C. I.e non-struct hierarchy. Linking. Perhaps DAG.

But I may want non-DAG - B to imply A or A/B, and A to imply B, or B/A as a default.

This is what I always hoped Bll Joy was going to solve. Some elements of a query path commute, and some do not.

Andy Glew said...

But these blog comments are more of an example of the problem: AFAIK yoy cannot label comments independent of the original blog item they apply to.

Andy Glew said...

Or link specifically to a comment... Surely....

Andy Glew said...

I'll give Google Tasks credit - at least they understand the notion of subtasks.

Although they lose: AFAIK their task lists cannot be nested.

And the tasks themseelves are simple text. No links or inclusions.

Moreover, "Due Date" is applicable to only some classes of tasks.

Andy Glew said...

GTask lists do not have hierarchy or nesting. (Some lists should be sublists of other lists.)

Andy Glew said...

GTasks - can merhge split tasks by typin carriage enter or deleting at end of task title.

It is as if just editing lines of text in a file.

Error prone.

Andy Glew said...

In the "Sort by Due Date" view, any notion of subtask hierarchy is lost. You just see the subtasks. There doesn't

Andy Glew said...

If you move a subtask to a different task list without moving the paent, the super-sub task relationship is lost.

Andy Glew said...

There is no way to see all tasks from all lists at the same time.

What I really want is for tasks to be like Google Calendars - grouped, and I can turn particular groups on and off in my view.