A truly stupid bug

DEVONthink Tips
1

I’m becoming disillusioned with the number of bugs that there appear to be in DevonThink 2. I really have to wonder about the quality of the testing being done. Here’s the latest bug I’ve come across (I don’t have the time to report most of them unfortunately but bugs like the following are really annoying.)

To replicate the bug.

  1. Create a new sheet with say two columns
  2. Open the sheet in a separate window
  3. Use the ‘Add New Record’ button to add say 4 records
  4. Enter some text in the first record in Col 1
  5. Press return and enter something in Col 1 on Row 2
  6. Repeat until you are in the first cell on the fourth row
  7. Click on the ‘Delete Selected Records’ button to delete the blank row you are currently in
  8. Ok the warning message
  9. The first record is deleted!!!

I wish this was an isolated incident but unfortunately it’s not and this particular bug bit me in a much larger sheet. When I eventually realised that the first records on my sheet had been deleted it cost me a lot of time and effort tracking down the missing information.

In trying some other variations in deleting records it seems clear that deleting records in sheets is badly broken. Speaking as a programmer myself, anything that results in loss of data by users is a serious issue and should be given a high priority for being fixed especially when the results are unpredictable and may not even be noticed by the user at the time.

Why isn’t it possible to undo deleting a record in a sheet? In an age when virtually any user action can be reversed it’s hard to understand why something as simple as deleting a row in a sheet can’t be undone.

2

Of course. Because the first row is still the selected one (assuming that you’ve clicked on the first column/row in step 4)

3

I repeated the steps, had the cursor on the 4th row, with that empty cell clearly in editing mode, and would never expect anything other than that 4th row to disappear.

@psymth, when DT gets feedback like this, they tend to rationalize what happened instead of listening and looking for places where their horrible UI really clashes with user expectations.

I can only hope that they do something more serious with the feedback back in their offices, away from the public forums. Unfortunately, I doubt that is the case.

4

Sophie, if you follow psymth’s instructions exactly and hit the Toolbar button to delete a record, a warning message appears.

It asks whether you really want to delete the selected record(s).

Before you confirm the deletion, LOOK at the UI. Which record is SELECTED? Note that selection results in highlighting one or more records.

In psmyth’s example, the first record is selected. It is the one that will be deleted. This is not a bug.

I’m used to Excel behavior. It would be wrong in Excel to assume that editing a cell in a row selects that row. If one has made that assumption and doesn’t examine the UI before confirming the Delete operation, and the result is entirely unexpected, is that a bug? I would argue that it is not a bug. The user made a wrong assumption, perhaps deleting a column rather than a row, or finding that the contents of the selected cell had moved upwards or to the left. Ignoring the pane presented when Delete is chosen and automatically clicking ‘OK’ can be a big mistake.

Click in a cell in Excel and choose Edit > Delete. Four options are presented, only one of which is to delete the row. Another option is to delete the column in which that cell is located. And of course there are othe speadsheet applications that use different conventions.

Bottom line, editing a cell in a record (DT Sheet) or row (Excel sheet) does NOT automatically select the record or the row. This behavior is not a bug in DEVONthink or in Excel.

The UI in a DT Sheet for designation of one or more selected records is unambiguous. Look at the Sheet and it is clear which records have been selected and which have not been selected.

5

Bill,

You cite Excel. OK, please tell us how to leave row 1 selected in Excel when shifting the cursor down into editing mode in the cell in row 4, column 1.

Or, how to get Excel to delete row # 1 when editing row 4, column 1.

I also look forward to your explanation about the missing undo.

Psymth did nothing to explicitly select row #1. Nothing. When he selected the first cell of the first row, DT decided to select that row. When he moved to the first cell of the next row with a return, DT decided to not change the selection to that second row.

Needing to spell this out like this is absurd, and explains why DT’s UI is still stuck where it is. Warning dialogs do not fix UI flaws. As @psymth said, this is not an isolated point.

It is unfortunate that you and DT continue to “explain” every last bit of non-intuitive behavior in DT, where DT would benefit if you’ll were less defensive and more reflective. See my “can only hope …” note in my previous post.

An occasional simple “Hmmm… I can see where that could be confusing, or unexpected, or seem like a bug. We will add it to the list and, when prioritized, see how we can improve it …” would be a much better idea.

Sigh.

6

Sophie, I’m not trying to be defensive about every little thing in DEVONthink. The applications have in fact evolved by seeking user input and suggestions over the years. Version 2.x will continue to evolve. But the developers have properly spent a lot of effort on what’s “under the hood”, the major improvements in speed, searching, memory usage and stability.

But if I move from one Mac application to another, for example from Excel to Numbers and find that in a great many respects they differ in the results of an operation I’m used to doing, should I conclude that Numbers isn’t intuitive? My presuppositions about how Numbers should behave can either frustrate me, or I can learn how to use Numbers as a tool to get work done. There are some things that Numbers cannot do that Excel can do. But for many purposes I find Numbers more pleasant to use. After doing certain neat things in Numbers, I wish Excel would operate that way. The fact is that they are different environments and I have to adapt to the differences to use each of them effectively. I’m becoming fascinated by Numbers for the iPad, which is a very different working environment in which what might be considered “intuitive” could be a hindrance. Preconceptions can be dangerous!

About Undo in a Sheet. Usually I’m editing a preexisting Sheet that I select and open in its own document window, so that I’ve got the convenience of the Toolbar with special commands for Sheets.

I now have two copies of the Sheet open, one in Three Panes view and one in the document window. When I make changes in the document window copy, I can go back and look at the copy displayed in Three Panes and see that it has not changed. In fact, the copy in the view window, which reflects the state of the Sheet when last saved to disk, will not change until I press Command-S in the open document window copy, or close the document window copy and respond to the dialog asking whether I wish to save the changes or not, and choose Save. If Save is invoked in either way, the disk copy is update and the view window copy is updated with those changes.

Perhaps Undo will appear in the future for Sheets. But if I fairly frequently invoke Save to update the file on disk, and then make a mistake such as deleting the wrong record or column, I can close the currently open document window without saving the mistaken change, reopen it and have effectively undone the mistake.

When I’m experimenting with the design of a new Sheet for a purpose I’ll often try various layouts. If I adapt to the way Sheets currently behave I can do that non-destructively, throwing away changes that don’t work out but perhaps creating several variants in the process until I’m satisfied with one. I would find Auto Save a hindrance rather than an advantage in such circumstances.

There will be a neat new script for Sheets in the next update.

7

I’ll reply to the previous posts when I have a bit more time. For those of you who seem to think that DT is perfect here’s another one.

  1. Create a sheet
  2. Add two columns. Notice the sheet appears with a single row.
  3. Double click on the sheet in the list of files
  4. The sheet window appears sans row!!
8

…and there’s more. Continuing from my previous post.

  1. Add a row and enter some data
  2. Add a row and enter some data
  3. Add a row and enter some data
  4. Click to bring the main window back to the front. Notice the sheet still shows just a single row
  5. Click on the pre-existing first row and enter something different

There are now two copies of the same document containing different and inconsistent data.No doubt Bill and Eric will probably say that because neither document has yet been saved then that is the way it is supposed to operate. Here’s the key question though - why would any user want it to operate in this way? The user created one document and as far as they are concerned they are editing the same document in each window.

Try this in Excel using New Window to generate a copy of a spreadsheet in a separate window and place them side by side and notice that changes made to one are also made to the other. The data is common to both instances of the document. Also notice that in Excel this works whether the document or the changes have been saved.

9

Yes, that has been the behavior of DEVONthink for years when one is editing a document — text, Sheet, image or PDF — that is open in both a view and document window. If one performs an edit in one of the windows the other is not updated until the change has been saved.

Yes, that means that it’s possible for the user to make a mistake by attempting to edit in both windows. One of the two editing environments will overwrite the other when Save is invoked in either one.

But the behavior is consistent and predictable. I find it advantageous when I’m editing documents. For example, if I’m polishing a document (or modifying the layout of a Sheet) I can rewrite a section in the document window and compare the revised version to the original one. If I like it, I press Command-S to save the revised version. If not, I close the document window without saving the change, or invoke Save in the other window to restore the document window to the state of the view window.

If one understands the behavior it becomes useful; one can see both the original and changed versions while editing, and Auto Save doesn’t “break” that ability. The user makes the Save decisions.

I’ve seen feedback from a number of DEVONthink users who are delighted by this behavior and would strongly object to changing it.

10

What I hear you saying is that these Sheet behaviors are just what we need, just right, quite adequate, not in need of improvement. Assuming that is DT’s position, it is pointless to discuss further.

Wow. What an an astonishingly creative way to say:

[]Multiple windows do not sync their contents[/]
[]Undo is missing and is needed even more in data-loss scenarios[/]

11

Sophie, please understand that I’ve never said that DEVONthink is perfect, or that it won’t keep evolving in response to user suggestions.

DEVONthink has been around since 2002. It has thousands of users.

This thread has been specifically about some behaviors in Sheets and more generally about the editing environment within DEVONthink, especially in the case of two windows open for a document.

You don’t like the current behavior of DEVONthink. I understand that. As to some of your other comments on other matters, I agree with many of them, though not all.

There are reasons that some of the behaviors of DEVONthink have persisted for almost 8 years, other than some strange kind of obtuseness or unresponsiveness on the part of the developers. At least in some cases, and I think this is an example, there are advantages as well as possible disadvantages in DEVONthink’s behaviors. The important point to emphasize is that the behaviors are consistent and predictable. Once one becomes accustomed to them, they function as expected.

There are some quite well-known writers and researchers who find advantages in DEVONthink’s differences in the content of a document open in a view window and in its own document window, and who would strongly disagree with your recommendation that they should always display the same content. They find utility in what you find objectionable. That, I’m sure, is why that behavior has persisted in DEVONthink so long.

DEVONthink’s focus is on collecting and maintaining document collections and on finding and manipulating information content. The simple text editor is a subset of TextEdit and DEVONthink has no plans to incorporate a full-fledged word processor or outliner into the application; there are lots of word processors, outliners and layout applications that can be used in conjunction with DEVONthink. Sheets are a simple spreadsheet-like way of presenting text in column/row format and I’ve often found Sheets useful. Although simple calculations can be done with scripts, DEVONthink will not develop a full-fledged spreadsheet to compete with Excel or Numbers. Excel sheets can be stored, viewed and opened from within the database, for example. If I’m going to do anything involving number-crunching I’ll do that in Excel or perhaps in some cases Numbers.

I agree with you that Undo might be useful in Sheets. But the way I modify an existing Sheet by opening the Sheet in its own window allows me to undo a mistake by reverting to the former state, if I haven’t hit Save after making the mistake.

As for Excel with its multiple Undos, I learned long ago that if I’ve set up a complex sheet, then start tinkering with it. my safest approach is to work with a copy of the sheet. Those multiple Undos can get really confusing when I’m trying to work back to the step where I made a mistake, and it’s easy to mess up a sheet that was functioning perfectly before tinkering with it. Sometimes a moment of stupidity can overcome any safeguard. :slight_smile:

12

And here’s yet another wonderful “feature” in sheets.

Create a new sheet and save it.
Add three columns and save.
Double click on the sheet to open it.
Add four rows with the following data.

col 1; col 2; col 3
1; 2; 3
4; 5; 6
7; 8; 9
10; 11; 12

(Note that I’m using “;” as a column separator)

Now click on the second cell on the second row, i.e. the one containing the number 5. Note that the row is selected. Click on the delete button on the toolbar and Ok the warning message that appears. You now have the following data

col 1; col 2; col 3
1; 2; 3
7; 5; 9
10; 11; 12

Wasn’t it nice of DT to keep the data in the cell I was in and throw away the data in the cell ON THE NEXT LINE!

13

I don’t know what version of Excel you’re using Bill but when I click on any cell in an Excel spreadsheet that cell is selected and the current row is now the row that cell is in.

The key thing here is that all of the options apply to the current cell and not some other location in the sheet.

If it is designed to work that way then technically it isn’t a bug. Nevertheless from a users perspective is is highly undesirable behaviour.

I don’t find that to be the case at all. For example when I click on a cell on a line the line is highlighted in yellow. After then deleting that line the following line is now highlighted in grey. What exactly is the significance of being highlighted in grey? If the line is not selected why is it highlighted in grey?

If I select a line by clicking on it and then press return it moves me to the next line but does not select it. Try the same in Excel and the next line also becomes the current line i.e. is selected. Perhaps you can explain to me why DT behaviour is desirable in this situation? Frankly I cannot think of a good reason except perhaps that the programmers cut a corner?

This is one of the daftest things I heard. The correct approach is to duplicate the document and then you can edit one copy while viewing or referring to the other. Your solution is to open the door to having two instances of the same document in different states. In computer parlance this is called an inconsistent state and in any well-designed computer program is a highly undesirable situation. Duplicating the document and editing it provides all the functionality you want without the creating such an inconsistent state.

This is a bit of smoke screening. I haven’t asked for any such features and I don’t want to use the sheets for anything other than tables of textual information. No calculations or other sophisticated features are required other than the ability to search the sheet. what is required is that the behaviour of the sheet be consistent and bug-free.

All I can say is that I can’t think of any other applications that work this way and I use a lot of applications and have been working in the IT industry for nearly 20 years. Editing a duplicate of a document provides all of the benefits you refer to without the risks associated with having a document in an inconsistent state.

But you know what, you guys win, because I’m going to switch to using Excel instead of DT sheets. At least there I can rely on the application behaving in a reasonably consistent way. I do however want other users to be aware of what they are getting into if they decide to use sheets for possibly important data.

14

Thanks for the bug report, v2.0.3 will fix this.

15

A simple and hopefully satisfying end to this topic. :slight_smile: