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.)

Access control and notifications are similar

Access control: if you know the name, the path to an object, are you allowed to access it.

Notification: the object, a cop or a link, is pushed to people via some communication system, saying "Look at this now".

These are dual.

I want much, almost all, of what I write to be public. Like this blog.  It seldom hurts, and once in a while somebody notices, finds it in search, and replies and helps me out.

I.e. basically I am thinking out loud.  Talking to myself in public.  People walk to the other side of the Internet when they see me coming.

But I don't want to push most of what I want to do to people.  Once in a while I will - once in a while I will share something via Google+, or email it, or copy it to my wiki, or copy it to USEnet newsgroups like comp.arch.

But, these are dual.  In an ideal world almost the same concepts should control access control and notifications.

Certain posts I may want to make publicly accessible, but not push to my Google+ stream. Or push to a narrow list of friends.

Confusingly, when I post to Blogger a Google+ window pops up and asks me if I want to Share via Google+.   But this notion of "share" is notification.   It is not to be confused with access control.  AFAIK Blogger has no access control.

---

It's like preschool teachers, or the leaders of the psychobabble training sessions that Intel made us take: "Do you have anything you want to share with the group?"

Maybe... I'm willing to passively share lots of my thoughts.  Give you access if you ask.  But I am reluctant to push all of my thoughts to others, to actively share.

I want kill rings in my browser!!!!

Heck, I want an emacs kill ring in my GUI.

Why use blogger rather than Google+?

Waiting at carwash...

Why use blogger rather than Google+?

Mainly, I know how to export data from Blogger.  I don't know how to grab all of my posts from Google+.  (http://www.dataliberation.org/takeout-products/-1s says "At the moment, this only includes sites that you have +1'd (no posts)").

I.e. for some things exportability trumps convenience and access control.

Perhaps in 100 years we will have ubiquitous access control, exportability, etc.  And then the differences between wikis and blogs and ... whatever Google+ is, a stream of comments ... will be just user interface and how the information is structured.

I'd like a world where the blog/wiki/stream boundaries are blurred.  But I don't need.

Higher priority: it sucks that issues for things that should be ubiquitously available, like access control and exportability, are often the criteria for choosing which tools to use.   I wonder how many good UI ideas are dying because they don't do the other stuff right?  Certainly, the big reason why I use so many Google tools is that they at least show signs of doing the "utilities".

Rewriting history can be good (esp checkin messages)

It can be good to be able to rewrite history.

Or at least checkin messages - or, rather the text associated with a version.

Checkin messages are really what was entered at checkin time.  But if these are rewritten, may warrant a different name.


Writing good checkin messages can be hard.  Sometimes I hesitate to merge my changes because it will take too much time to write a good message - especially given our local rule of having a branch merge summarize all changes on the branch.  But slow to integrate is bad.   Or I write a sub-par checkin message.  But that is also bad.

Better to merge, integrate asap, with whatever you can say at that time.  And, if necessary, go back and rewrite the messages to improve them.

It's like refactoring.

LOD branches (Lines of Development)

Not sure if this is a Glewism, although Brad Appleton's book undoubtedly similar.

A LOD branch is not like a task branch.  A task brach ideally exists only briefly.

A LOD branch is long lived.  It may be periodically synchronized with other OD branches, and/or the mainline of development.  Bidirectionally synchronized - changes may be pushed and pulled.

For long periods of time a LOD branch may be collapsed - basically part of the main line of development.  But it may be revived as a separate LOD branch.


Examples of LOD branches:

* branches for different platforms, where there is not a single source tree with ifdeffing or other conditionals

* maintenance branches for old major releases

* branches where you are working on a new experimental feature or system

Closing and merging branches

I like developing on branches.  Task branches usually, short and sweet, merged back into the parent main line of development as soon as possible.  Sometimes longer lived "line of development" branches, merging to and from the mainline.  Named branches if I have had foresight, although Mercurial's anonymous branches are not so bad, although they can be misleading.  (Wanted: retroactive renaming of branches.)

Just now closing a doubly nested task branch, merging into its parent line of development branch, and merging that into the default trunk.

Straightforward.  But annoying in that I have to run tests at each stage of the merge. (Actually, I feel that I should run such tests - the project is not so well disciplined.)  Plus check in three times: once for the last change in the task branch, once in the LOD branch, and once in the default trunk. With three separate checkin messages.

Some of this testing is unnecessary.  E.g.

      hg update -r LOD

      // close and merge task branch into LOD branch
      hg merge -r task-branch
      make -j test
      hg merge -r default
      // LOD changes, but no changes wrt default. i.e. no LOD changes during task branch life.
     make -j test <--- unnecessary, because tested on task branch
     hg ci -m 'merged task branch'
   
     // merge from mainline before pushing back
     hg merge -r default
     // no changes.
     make -j test <--- unnecessary
     hg ci 'updated LOD branch from default trunk main line of development'

     // merge back into trunk
     hg update -r default
     hg merge -r LOD
     // many changes wret default, but no changes wrt LOD
     make -j test <--- unnecessary, since file contents same as LOD
     hg ci 'updated default trunk main line of development from LOD branch ...  need more description'

i.e. it is good to know when there have been no changes in the actual file contents wrt one of the parents.

unnecessary tests could be eliminated.

(unless, of course, the tests do stuff specific to whatever branch the workspace is on. Which we actually have a minor example of. :-( )

---


similarly for checkin messages:

we have the convention of having branch merge messages summarize everything done on the branch.

So above I end up writing almost the same checkin message twice.  Which is more hassle than it sounds.