Adam J. Richman
Adam J. Richman's Comments
-
-
-
On a similar vibe, also would want to allow BUILD TITLE FROM FIELDS to work similarly. Right now, if I try to grab a ${Item.Icon} in the title and there's two Items listed in the node, it just breaks completely. Expectation and preference is that it grabs the icons from both listed items.
-
Nice. Came here to add this WF shortcut and glad to see it was already here. Sadly from 3 months ago but I am in a space now where this would be AMAZING to have for a bunch of clean-up work moving between all items in a queried list that I want to work on one at a time. Really missing those "move between sibling" shortcuts.
-
A great example is how to do this well is Airtable does this (generally, their design choices are really on point, too). Notice how I can seamlessly filter between three different tables (aka supertags in Tana's language) from one place. Here I am on the #contacts table and I'm able to filter by the #client tag that exists within a linked #project. So that's two filter layers deep into another table.
There's no current way to do this in Tana easily. I can't query against the the content's of a connected supertag's fields.
-
- Ideas
- Adding map locations to nodes, and include an ability to display certain selected nodes on a map.
This would be amazing. I would love to collect more simple things like restaurant recommendations, etc, but have Tana's powerful filtering built in. A location-enabled field, similar to how URLs, dates, etc. are "special" would be awesome.
-
-
-
More thoughts...
I don't want to ever feel like I'm giving my data to any company, despite their best intentions or aligning philosophically with the team.
I believe data can and should be trust-less interaction (by way of me having total control over mine).
Two decades ago we all trusted Google, and now many of us are actively trying to escape their platform after years of blatant personal data abuse.
-
Just pinging this request again since Tarjei had requested more details on this from users in the recent AMA. Didn't want to start another Idea for essentially the same request. Thanks for asking to hear more about this, Tarjei, if you're reading this.
Also, pulling in this related Idea: https://ideas.tana.inc/posts/64-let-tana-store-all-information-locally-without-syncing-to-cloud
There is a trend in new software to be privacy-first. I don't view Tana as being privacy-first. Sure, my data is encrypted in flight and at rest, but a data breach or a bad actor on the Tana team can still view 100% of my personal data because Tana owns the keys to my data. _Not your keys, not your data. _
I understand that it's the same with Gmail, which is a really bad argument because there is a growing contingent of folks that are actively de-Googling by using Brave, DuckDuckGo, platforms like Proton Mail for email, Signal for texts, encrypting our iCloud data, etc. Myself included, and most of my community.
I would like to store simple things like passwords and credit card data at the node-level in Tana, sure, but I also really want to keep a #journal entry in Tana, which I refuse to do until I own the keys to my data. I'd like to keep sensitive health information from being easily visible on Tana's servers. I'd like to keep sensitive client information in Tana, which I cannot (both ethically and by contract) do unless I own the keys to the data (I do a lot of work with banks, in the IPO space, etc. — all kinds of sensitive information that I could never store in Tana at current).
I want the ability to secure an entire workspace, secure specific nodes, secure specific tags, and/or secure specific fields. I understand that if I lose my keys I lose all the data — this is not as hard as folks make it sound — it's a feature, not a bug. Many of us learned all this (some of us the hard way) years ago with our crypto wallets. We have Yubikeys and Ledgers. We're comfortable with encryption and more and more are starting to require it in our everyday use apps.
We want our data shielded from ANY AND ALL companies, regardless of their best intentions. The primary reason Logseq rose in popularity was it was local-first, privacy-focused, and open-source. I'm in Silicon Valley and I can't in good faith recommend Tana to most of my personal community because many of them care far more about these things than they do the quality of the application, it's design principles, how powerful it is, etc. They are actively seeking institutions that prioritize privacy, local data, and now also: sensible limits for AI's reach.
This doesn't need to be the default for every workspace, it just needs to be an option. It can come with a dozen warnings, but please give us the ability to shield our data from Tana's servers, employees, data breaches, etc. and yes, until the quantum computers come. Realistically, at that point we'll have far greater problems than our personal data in Tana to resolve...
Thanks for reading!
-
- Ideas
- For Supertags and Fields, add an Emoji + Icon field that can be displayed instead of the Text ⭐❗ 🚀
Alternatively, simply have the CMD+K > Add Tags > list also search the Descriptions of the Tags, then we could set Emojis as the name of the tag but still search by way of their Descriptions.
-
Brings up a lot of data privacy concerns for me. That would mean you're giving your AI of choice API access to your entire graph, instead of specific nodes only. If data privacy were taken more seriously by either Tana or OpenAI (everything E2E encrypted, I hold the keys, and no data was used to train future models), I could get behind something like this. Until then, this type of integration is for me personally.
-
Has my vote, so long as there's a way to toggle the sidebar off completely. Definitely interested in a dockless + paneless + sidebarless Tabs alternative, too.
-
2023-07-09 at 09.47.37 - Workflowy - Workflowy - Sun Jul 9 2023 - WorkFlowy [Curïo].mp4
More context, now a couple months later, as this is still a major stumbling block in daily Tana adoption... Workflowy's absolutely fluid / frictionless "Move To..." experience on demo... I feel Tana needs to emulate this. Full graph access via Move To with incredibly fast fuzzy search and node creation.
-
Sadly this doesn't work when configuring tags, which is the most frequent annoyance with this issue.
-
Further, the fact that some commands that "take me places" exist in CMD+K and some in Search is disorienting. For example, I can open calendar dates for upcoming (highly specific only — not natural language dates) dates within the next week through CMD+K but not through Search.
And even finding specific terms in the command from CMD+K can be disorienting. For example, jumping to the next Monday (called Upcoming Monday)... it can't be found with Monday alone.
Instead you need to use more terms, like "cal Mon" to find it... which is again disorienting because expectaiton is that "Mon" alone would work.
https://ideas.tana.inc/posts/394-marksortmark-that-follows-node-markordermark-ie-for-statuses-with-emojis-img-alt-classemoji-draggablefalse-srchttpscdnjsdelivrnetghtwittertwemoji-at-latestassetssvg1f503svg