New Backend Plans

Jerud

Jay , you mentioned in another thread doing away with the “Document” naming scheme. What’s the new plan? You’ve explained how the changes to the database will improve Legend without compromising the current experience, but I don’t get why Docs should be called something else.

Jay

The naming doesn’t necessarily need to change. There will not technically be any difference between a top-level node and any other node, but we can still call top-level nodes Documents. As we get closer to the new system fully working we’ll put some more thought into naming and I’ll start a thread about it.

wecanseeformiles

Jay I don’t necessarily agree that the desktop version is a pretty poor experience on the Ipad. When docked into Apple’s Magic Keyboard with a trackpad, it’s pretty much the same experience as on a PC or Mac. I do agree that without a keyboard, a souped up mobile app is preferable on the iPad, but not when using an external keyboard and trackpad. In an ideal world I’d like to have both available on the ipad, dependent upon which mode I’m using the iPad. More and more people are using the Ipad as a desktop replacement or alternative on occasion.

Jay

wecanseeformiles Hmm, that’s an interesting point, I wasn’t thinking about trackpad usage. I added that to my planning document to think about as we get into working on the mobile app.

wecanseeformiles

Jay You might be interested in what Things 3 has included in their latest version for the ipad.

LauraH

I was thinking about the Tags issue if they are not separated by documents.
I like Jay’s three levels of tags - and also agree with @Jerud that I’d want to be sure it’s intentional if I’m choosing a tag that is NOT in the current node. I also don’t want something I have to click though - as adding tags is something I’m almost always doing with the keyboard; and I don’t want to interupt that flow.

Possible Solution:
In the “tag” pop up - show it in three columns. Use the breakdown Jay suggests, but show it in three columns (with small text to explain what they are); and allow me to use the arrow keys to move from one column to the next. Maybe even go so far as to have a confirmation request pop up if I type a tag that is NOT in my selected column?

Jay

LauraH Oh that’s interesting! Tags are generally pretty short so I think fitting into a three column view should be doable. I’ll look into that!

Jorge

Jay that seems like a good idea, just please make sure you adjust width for the tag length or allow horizontal scrolling for those of us that use prefixes to group tags because that makes the length of the tag text longer.

Jerud

Jorge I say adjust width as much as necessary but don’t ever throw a scrollbar on there; keyboard entry gets bad with scrolling.

Many of Legend’s pop-up dialog boxes seem to try and stay within the width of their parent Pane. This looks good but functionally I’d rather have all these boxes (especially the Move box) expand to be as big as they need to. It’s not like you can leave any of these boxes open and go work elsewhere in the Board – they have Focus until they are dismissed and making them bigger makes it easier to get done with what I’m doing in that box.

Exception to the above is Notes, which I do sometimes leave open before moving elsewhere.

Jerud

Here’s an alternative approach to @LauraH ’s 3-column idea, which I think I’d personally like better:

Retain the current simple list of auto-fill tags, but restrict the contents of that box to tags that appear within X “degrees” of the current Pane’s zoom level. Then, let users pick the value for X – ideally right there in the popup list. This could be defined in terms of how many ‘tiers’ down from root Legend will traverse when searching for tags. So X=0 means it looks at everything in all of Legend. X=1 restricts tags to the current ‘document’. This should be the default. X=2 restricts tags to the root-level parent of the Pane’s current zoompoint.

This way those of us who like a narrowly-scoped taglist can get that. And those who want to see tags from across their entire Legend portfolio can get that, too. And anywhere in between.

Jerud

@Jay do you have a rough timeline on when the document-structure change is likely to hit? With the holidays coming up I’m thinking not until next year?

I need to make some major revisions in my “system” but have been holding off until we see the new opportunities that restructuring brings. In the meantime though my stuff is getting kinda messy : )

Jay

Jerud Yes, likely next year. I had planned for earlier, but got distracted by helping my friends with some projects so I didn’t get it finished as quickly as I had wanted.

Now that it’s already December, I don’t want to release a massive core change during the holidays so I’m temporarily putting the backend change on the back burner and will spend this month working improving the new user experience, small bugs/features, and on growth. Then I’ll come back to finishing the backend in January.

LauraH

Jorge
I want to bring attention back to this: The idea of tags being hierarchical, and some kind of “tag manager”.

I could see this being very helpful. Like Jorge - I also use tag “Groups”, and it would be helpful to be able to say, "Show me all my “Errands” tags" or “View all context tags”.

Examples (as they sometimes help clarify):
Context tags: #home #computer #Office #garden #errands
#Errands Tags: #Hardware #grocery #costco #kidsclothing
Time Frame / Planning Tags: #Spring2022 #Summer2022 #Fall 2022 etc.

Also want to be clear, for something like this I would want a true, functional hierarchy.
Context
……Home
……Errands
………….hardware
…………. grocery
…………. Costco

clicking “context” should show me everything below it - even if nothing below it is specifically tagged “Context”.

Evernote is a good example of a program that FAILS at this. They introduced hierarchical tags… but it is visual only. clicking a “top level” tag still shows only that exact tag - no way to view all the items under it. Which is frustrating to say the least!! So, if introducing tag hierarchy, please don’t make that same mistake!

ghuth

Although I understand the technical motivation for the change to documents, I personally see only negatives in the way it’ll affect my use of the app. I already work primarily in a single document. I’ve set up a couple of other documents for discreet projects or issues and would much prefer that tags remain discreet in them.

I really think this hierarchical tag solution breaks the whole intention of tags. The power of tags is that I can filter for #work #finance OR #personal #finance OR #finance (only) …. That is the great flexibility of tags and I think it’d be a terrible idea to break that. (Sure, there maybe other ways to get the search result I’m after but I don’t think they get easier with hierarchies, only harder).

Additionally, imagine I’d created a separate document for a club I’m involved in, and I wanted to tag items with the names of the club members? I don’t want to see a list containing #frankJones #fredNerk #fredSmith #finance #fatherjohn #fun all mushed together because I’m now forced to merge tags across documents.

Perhaps hierarchy could be considered helpful in the example eg I could type #clubmember.frednerk and end up with the hierarchy, but I think it needs to be designed in such a way that the hierarchy system stays mostly out of the way.

Although even if it is kept out of the way, I think we’re working complexity into something that is powerful in simplicity. I think it’ll impose complexity and ugliness to tags. eg I MUST use a prefix/hierarchy for those names. What if I have two club “documents”? Now (because of my individual needs) I have to impose the use of #clubname.clubmember.frednerk even though that’s redundant for the members who are only in one club “document”.

I wonder if the simplest solution is to emulate documents as they currently are (even if the distinction is now logical instead of physical) and then provide an OPTION of “share my tags across documents” or “keep tags in their own documents”.

Jorge

ghuth

ghuth I can filter for #work #finance OR #personal #finance OR #finance (only) …. That is the great flexibility of tags and I think it’d be a terrible idea to break that. (

Why would having the tags grouped into hierarchies break the fact that you can filter for a single tag? You have all of legend outlines and you can still filter and search for a single item. The fact that tags are hierarchical wouldn’t prevent you from doing that search exactly in the same way.

ghuth I MUST use a prefix/hierarchy for those names

No you don’t… You can use the single tags in the same way, you would only have to specify the prefix if you would have duplicate tag names under different branches, because specifying just the tag would bring you all the items that have it (it wouldn’t distinguish between the two different tags as they are spelled the same). Imagine you search all your items for #Paris, ah but you have items that belong to #France.Paris and #Idaho.Paris, #Texas.paris, #Illinois.paris, your single search for #Paris would bring all of them. If however you only really wanted the ones that the amazing cuisine and beautiful view of the Champs Elisees then you would specify #France.Paris in your filter criteria.
The advantage of the hierarchy is that if I want everything that is located in that european country I would simply type #France and everything… #France.Paris, #France.Lyon #France.Marseille, #France.Nice would come in a simple search instead of having to type four different tags in the filter criteria to get it.

Now a discussion for implementation would be which option would be preferable when you select a tag to include in an item. Say you start typing #Paris in one of your items. The tag menu would popup showing you #France.Paris and #Idaho.Paris, and #Texas.Paris. When you select one of them the question would be do you want it representing the full hierarchy path (e.g. #Texas.Paris) or simply displaying the leaf level tag (#Paris) but still keeping the internal representation hidden. This could even be an option of preference for each user.

But I agree with you (and I think all others in this conversation do too) that we should be able to associate tags to a given node level if we want to make sure that they are local to a particular node (document).

Jorge

ghuth Besides even with all these previous considerations, anybody that doesn’t need to use the tag hierarchy wouldn’t be forced to. They could just continue using a single level of tags just as they are now, so I don’t see you losing anything of what you have now.

ghuth

Jorge I am certainly making some assumptions based on the fact that design/development is not completed.

Perhaps “must” was too strong, but in that example of club member names I would either have to leave them at level 1 OR put them in a hierarchy. Leaving them at level 1 would be unwieldy, so I would consider it a must to use the hierarchy if we lost the document distinction entirely. One of my assumptions is that if I personally wish to distinguish clubname.clubmember.personname in categories because it would be unwieldy for ME to to have them at the first level… then that will impose my hierarchy on any other users of that document.

The answer to that question might be linked to the following - it has to be considered if the tag shows in its entirety at the document level in the text - DOES it always show #france.paris ?

If yes, that’s going to blow out the length of my task and project names. Yuck - that leads to way more wrapping and less readable lists.
If no, then how do I make sure that the tags for #france.paris and #idaho.paris EXIST?

Currently, the app creates the list of tags within the document automatically. For that to happen, I think the document would always have to show the full tag name. The only alternative I could see was that we had to now manage tags in some separate tag management list. If it requires such a management screen, then for your example we would have to create four #paris tags - one under each of france, texas, idaho and illinois. that’s 8 tags instead of 5 and that issue would be exponential.

But I agree with you (and I think all others in this conversation do too) that we should be able to associate tags to a given node level if we want to make sure that they are local to a particular node (document).

I’m really glad to hear this and I hope it’s the ultimate solution. I did my best to pick up where things were at from this long conversation and was just left with some pretty big alarm bells I felt I had to raise.

ghuth

Jorge

Besides even with all these previous considerations, anybody that doesn’t need to use the tag hierarchy wouldn’t be forced to. They could just continue using a single level of tags just as they are now, so I don’t see you losing anything of what you have now.

It sounded like (initially) documents were all simply going to be mushed into one. It was pointed out that this would combine tags and they might be unwieldy in one big list of (now) unrelated tags. Tag hierarchy was proposed as the only solution to this list overwhelm, correct?

I maintain that I would be “forced” to use hierarchy if there was no alternative way to show only those related to the “document” - I like the freedom to use tags differently in each documents and a single list will be much less preferable.

Ultimately I’ll be happiest if the new behavior closely equates to the current system. I feel the negatives will significantly outweigh the positives if we rely on hierarchies alone to resolve the combination of tags from multiple documents.

Jorge

ghuth

ghuth If yes, that’s going to blow out the length of my task and project names. Yuck - that leads to way more wrapping and less readable lists.

That’s why I said that there should be an option whether the tags would show up with their full path or just the leaf in the outline items. If you set the option to Full path the tag would show #France.Paris in your entry (e.g. [] Have lunch at Le Gardines at #France.Paris). If you set the option to leaf only your entry would look [] Have lunch at Le Gardines at #Paris.

ghuth If no, then how do I make sure that the tags for #france.paris and #idaho.paris EXIST?

So when you are typing #Paris a list would come up showing the hierarchy something like this:

Idaho
- Paris
Texas
- Paris
France
- Paris

You would simply select which one you want, and then depending on the option above the tag would display accordingly in your entry.

ghuth

Jorge

That’s why I said that there should be an option whether the tags would show up with their full path or just the leaf in the outline items

OK that’s fair - the app could cleverly display only #paris whilst maintaining the distinction of which paris you had chosen…. but is it really better to have the 6 tags you’ve shown instead of the 4 we’d currently have? I’m not sure that it is…

Let’s consider an example where I wanted to do a task that was related to both personal AND work. Say it was about my wages.

I would now have to choose to tag this item either #personal.finance OR #work.finance, when simply tagging #finance alone would be best. Or if I tagged both, I would have to choose between showing the entire structure of “#personal.finance #work.finance” in my task name or end up simply showing “#finance #finance”. Yuck to both.

Isn’t “#personal #work #finance” simply better?

By nature I’m a problem solver - I hate to simply raise problems without solutions… but in this cause I’m concerned the potential problems with tag hierarchies could significantly outweigh the benefits and I think we really need to consider if we’re moving forward by implementing them.

« Previous Page Next Page »