Potential bug in Table View - the persistence of untitled notes

Tinderbox Tasks
1

I think this could be a bug which I came across with my main working file and was able to reproduce with a simple demo. Consider the following simple set of notes

image
image916×333 30.7 KB

I switch to Table View (fantastic addition to TB by the way - I use it all the time)

image
image771×268 35.3 KB

So far so good. In Table View I create a new untitled note.

image
image763×289 36.6 KB

Unlike Map View untitled does not disappear after some seconds. Could be a feature… I don’t know. However, if I now delete the note “untitled” using CMD+D I get what I expect in Table View - the note is gone.

image
image777×260 32.7 KB

However, I now switch back to Map View and lo and behold there is a new note called “untitled”. It seems my deletion in Table View was not carried over or implemented.

image
image831×303 22.4 KB

2

I don’t think ⌘-D is normally a shortcut in Table View.

Table View (ands Gaudí View as well) support two different ways to remove a note. Hide Note removes the note from the Table View by setting $TableHidden, but the note remains for use in other views. Delete Note deletes the note entirely. I believe The Delete key currently invokes Hide Note.

Automatic deletion of untitled notes is not yet adopted in Table View. It is a bit tricky to implement in Table View, since it’s essential to give users a chance to edit the note before sweeping it away.

3

Thank you @eastgate. I assume by Delete Note you mean the Delete option on the menu under edit as illustrated in the screenshot below ?

image
image1920×1003 102 KB

I’ve just tried it and it doesn’t seem to do anything with the selected note. Perhaps someone else can confirm ?

I also noticed that I did not find Hide Note in any of the menu’s so I assume implemented only as a keyboard shortcut ?

4

I meant the Delete Note menu item in the contextual menu that appears which you right-click or ctrl-click an item.

5

I think I see the disconnect here. User assumptions != app design intent. No fault, but the disconnect has consequences.

I think the cause is that, like some other views such as Crosstabs, the view is a report rather than a fully consistent read/write view. Noted here:

In this view, the Delete (Backspace) key hides the selected row(s) rather than deleting them.

I suspect Edit ▸ Delete, like the above maps to Hide. Not a bug so much as a false signal and an unintentional UI/UX fail: menus should do what they say. If the user doesn’t know in advance that ‘Delete’ means ‘Hide’, hilarity ensues.

This suggests several issues to address (oddly missed by testers—myself included :face_with_open_eyes_and_hand_over_mouth: ):

  • If the active view is ‘Table’ then the Edit menu’s ‘Delete’ option should be replaced with ‘Hide’ … as that is what the command does.
  • If Delete is possible in Table view, offer both ‘Hide’ and ‘Delete’ menu options.

But the context (right-click) menu for a row does offer both hide and delete options options: see. Of course, how would the user guess these commands are hidden in a context menu. You don’t know what you don’t know! Plus, experience shows most people are remarkably un-inquisitive (I don’t mean that as judgement) in this scenario. It’s the malaise of us expecting software to be (subjectively!) ‘intuitive’. IOW, we expect not to have to guess, even though a different part of our brain might know a little exploration might help.

1 Like