Minor UI issue with DEVONthink To Go

After a recent update I went to edit a note in DTTG, and when I was done editing I couldn’t find the save button. I hunted around for a while, and eventually decided to copy everything to the clipboard just in case, and tap the X-in-a-circle icon at top right as that was where I vaguely remembered the save button used to be.

Turns out, (X) is used for save in recent versions of DTTG. This is really confusing, as it’s used everywhere else to mean Cancel, as a quick web image search will show. In fact, it’s used in desktop DEVONthink to mean “cancel, throw away the input” – just type something into a search box to see.

Actually, like in most iOS apps, there is no “Save” button at all but changes are automatically saved for you. Tapping the circled X hides the toolbar but all changes are saved in any case when you switch away from the document, put the app into the background, or, like you say, when you hide the toolbar.

2 Likes

Even on iOS, (X) is used to mean “discard input and cancel”. Try searching in Safari, for example.

So maybe it shouldn’t be a save button in DTTG, but it shouldn’t be a cancel button either.

@meta I hear what you’re saying. It may seem a bit ambiguous that the (x) simply closes the menu bar and has no impact on the data. As you point out, iOS uses it, but it also has the effect of (x) to close windows, such as safari or finder. Again, ambiguity. X can discard, or X can close. It’s interesting to think about how best to construct a UI that is intuitive, yet simple enough not to clutter the limited screen real estate on the iphone app. I would be curious to know what the developers considered and why they decided on what they did…

That being said. Creating the note seems to be where the hazard of saving or discarding the data rests within the app. When in the app, (+) > [New item] Text brings up the initial text input, but, crucially, it has not created a file yet, since the next step is to chose the file type “rich text” “formatted note” etc.

This is the point where I originally found the save/delete confusion. Initially, I assumed (admittedly I did not spend much time reading the manual), that by selecting (+) Text that I was already writing to the database and there was no need to be concerned with saving or discarding. I thought the (<) arrow would just bring me back to the previous screen. However, this is where one encounters the message “You have unsaved data. Keep or Discard.” Here the (<) also functions as a delete/discard, although necessary to click the prompt. To “save” the data, one has to select (>) and choose the file type. Once that happens the file is created, and at this point, since this is a database application, I would now certainly expect that any changes I make to the file are being directly written without a need to explicitly save/delete (unlike word processors eg. MS Word).

Once the file is created the (< Back) button has no impact on the data. And the (x) button pertains to the editor menu.

In the DT desktop program. Clicking on the (+) actually begins by creating the file. So the discard can only be done manually by moving to trash using a separate function.

However, the OS level menu bar icon (the DT shell icon) will call a note app. In this case it is possible to delete the note without ever creating a file in the database, similar to the app. One has to chose the file format and click (apply) before the data is written. Otherwise clicking on the (reverse loop) bottom right will remove the data. However, there is no prompt when clicking the (reverse loop) that data will be removed, unlike in the app where there is an explicit prompt.

Anyway, it’s interesting to consider UI design, and what the user finds most intuitive vs streamlining the appearance and functionality of the app. Overall, I haven’t had a problem with losing data in DT. And I generally find I can quickly get used to the UI changes. One of the reasons I keep using this app is the DT development team and moderators here are very responsive and do take care to listen to users, even if they don’t implement changes based on all of our concerns.

A bit longer than I anticipated! But thanks for prompting this interesting discussion.

1 Like

Thank you for your thoughts on the workflow for creating notes. The UI element for this that we call the New Document Assistant is one of those that we plan to rewrite eventually. The design decision to first let the user enter data and then decide which file format it should get seemed to be a good idea at first but has its flaws. As it’s a complex element don’t expect a change next week but it’s certainly on our radar.

3 Likes

@eboehnisch Thanks for taking this into consideration. It’s a relatively minor observation/concern based on the original comment in this post. I use the DTTG app for field notes and overall it works great. I will look forward to any future UI innovations!

1 Like

Oh yes, I’ve been confused by the “New document assistant” and lost text from that too.

I am finding an instance in which text is not (immediately)* saved in a note after creation. I think it’s slightly different than the way @meta originally framed the question for this thread so here is the attempted disambiguation.

  1. Created a new Rich Text note in DTTG.
  2. Clicked on the created note.
  3. NOT clicking the edit button
  4. Tapped in blank space to bring up cursor
  5. Typed text
  6. Clicked <Back button

Discussion/Comments: Text not saved (immediately).
If, AFTER, typing in the text 1) click the Edit button, 2) then (x), then <Back the text is saved immediately.

*I say immediately because the input text disappears, and then will reappear (in some cases) after about 30 seconds.
If I click out of the note and back in, and then input more text, the vanishing text does not appear to be saved.

It seems that the intended action is that all text input in the note should be saved. And that it is not specifically necessary to call the Edit menu (since text input is allowed). Text should be written to the database and the <Back should just return us to the previous screen, should not imply or cause deleted/vanishing text.

@BLUEFROG not sure what is going on here. Please advise.

This is a glitch in version 3.5.4 and will be fixed in 3.5.5 where editing will only be possible in edit mode.

1 Like

@eboehnisch Thank you. Appreciate the development team’s responsiveness on these issues.

FWIW, I can see it both ways. 1) being able to tap into the note to enter text and then hitting the <back button is only two actions.
2) the Edit menu has expanded formatting options, but it’s four actions. (click edit, click to move the cursor, click to close the editor, click back).

Ideally, both types of text input/editing would be welcomed. 90% of the time I find that I just need to jump into a note to add some text with DTTG and only 10% need to adjust formatting. True, four actions is not that many, but over large data sets two additional clicks starts to add up. Anyway, this is just the user’s perspective, no idea what’s possible from the development side.

Tap-to-edit is, of course, possible. We deactivated it to avoid other UI quirks but might re-add it now that we have a proper editor in place.