Gerrie Shults

Neither of my issues from last year—only one window allowed and app window occupying the whole screen on launch—has been addressed.

I still consider the app unusable if I can't have multiple windows open. This makes the desktop app very unlike the browser system, contrary to the claim in the documentation for the Desktop that they are essentially the same.

I, too, consider this essential.

Attempting to understand these relationships today is an extremely tedious manual process. My current attempt to make an automated visual solution is not yet functional. And it still has the manual step of finding all tags and fields locally, then copying and pasting a text file. I post-process the file with Wolfram Mathematica (probably a rare tool among Tana users).

This is more than a little annoying. Using app is not "quick" when it hides the rest of the world.

I really need multiple windows. I regularly have content from multiple places in Tana open in different browser windows. Multi-panel in a single window is not sufficient. I can place these windows on different screens, where I can refer to Tana content with different apps placed next to the Tana window.

I suggested a general purpose standardized approach to date formatting in my comment https://ideas.tana.inc/users/321/comments under the request for Formula Fields

I also consider this an essential feature, so that collected information can be displayed in concise and readable formats. Beyond date calculations, I need robust date formatting. My standard time & date displays use one of the following formats: YYYY-MM-DD, YYMMDD or YY.MM.DD, with time optionally appended as either "-HHmm" or " HH:mm". I virtually never include day of week or the month name instead of number. Also, many times only the year or year and month are important or even relevant. Tracking books and reading is a popular theme in Tana examples, and an important thing for me in my reading history is sorting books by copyright date, which is only a year. Ideally, I could enter only a year for a date, but if I have to be more granular on entry I still don't want to see "January 1, YYYY" on output, like I've had to do in other apps.

As for implementation, the Unicode forum has made code available to support this functionality for years. They have user level specifications for date/time formats, which can be found at https://unicode-org.github.io/icu/userguide/format_parse/datetime/#datetime-format-syntax. The root node for the complete description of these and other Unicode forum services is at https://unicode-org.github.io/icu/userguide/icu/.