Anasoft

I see. I am not sure why EN would choose to confuse these two well known concepts in this way. For example, here is my folder structure: I'm sorry I can't show more to show the logic, but essentially clients are broken in countries/states/sites/projects, but clearly with the hierarchical folder limitation, this isn't possible. My Tag structure is simple as you can see from this sample: I could possibly replicate my folder structure in Tags, but why have folders? It makes no sense. As I say, these two concepts can work harmoniously, however, for reasons unknown, EN has elected to dumb down one and has promoted the bastardisation of the other to compensate. I can imagine why this has happened, but unfortunately, it is ultimately counter-productive to an awesome tool. People will go elsewhere...when this one change would have a huge impact on usability and acceptance. Trust me, I know how popular it is, and I know so many people who start and stop. There should be no reason to stop, but it is taking licence like this that drives people to it I'm afraid.

No, let me show you. These are all of my notes, shown using "Top List". Here you can see the data structure that comes along with the note itself. You'll note that the order of the data fields is "Location" and then "Tag". In fact, using tags as a proxy for hierarchy is actually not really the correct use for this kind of data, and looking at this, it appears that is reflected in this layout. Typically, folders would have pointers to each other, to effectively support the nesting that they promote, whereas tags are structurally agnostic (as they should be) in order to find content independent of structure. A mature implementation of both is a very sound outcome.

Thank you for trying to be helpful mate. Don't you find that bastardisation a little clumsy? I can see how it can be used, it just seems more like a workaround than mature solution. What is also interesting is that, when you are in something like "Side List" mode, you see the folder first ("Location") before "Tags". I know the original DMS systems tried to move away from folders to "Structured Searches" which were essentially the predecessors of Tags nowadays. They were not particularly successful in it and had to bring back folders as well. In fact, when deploying a real document/knowledge management system, this part is some of the most difficult change management for the entire project. My challenge is that I work with a number of large clients, sometimes directly, sometimes through other large companies. Within each company I have programs or projects, and within those further projects or work package, No client can see another client's work, but I may wish to see everything I have assisted with on Strategy. I would file the notes against the meeting in a work package within a project for a client, but I might also add Minutes / Strategy as tags to it. While I can see where you are going with your tag structure, I think it would become quite unwieldly for me This is such a bugger as I really like everything else about the tool... Seems like EN can't quite get there unless anyone has any other ideas?

While I could clearly be wrong, I am thinking you have never really designed complex software before if that is your response! The UI, table structures and code are related, no doubt, but should not place this kind of hard limit on a product. While I agree, it may be by design, it certainly shouldn't be a limitation - simply an architectural decision. I haven't elected to deconstruct the schema, but I am guessing (again) that this is highly unlikely a limitation, but, if it exists as you surmise, an architectural decision. Are you one of the product architects? You speak as if you have inside knowledge and seem quite fine telling others in the user community to move to a competitor... Quite strange really.

It is a pity. If there is one thing we have learned over the years looking at Data->Knowledge->Wisdom, or whatever philosophy you follow, is that everyone learns differently. In this case we have a couple of ways of organising and there are strengths and weaknesses of both. We also have the difference between "grouping" and "filtering". Often types of people see tags as "opting into a group" and a folders as "excluding things outside irrespective of tag". One sees structure and control in a nice neat hierarchy. It is how the brain organises information. It can be very effective and is typically excellent for the user, but not so good for multiple users who would have their own 'internal" hierarchy that is right for them. Sometimes, as the total number of notes grows, even the original user can struggle to find a note if they have changed the way they think about a subject over time. Tags are great for unstructured data but people who think in hierarchies really struggle with them. It also changes the amount of "organisational effort" that can go into a note. Tags require a lot of consistency, and are (again) things that change over time as you learn more about a subject or topic. This is why universal search has become almost essential in everything from Google to Outlook to tools like this one. Personally, I would like to see EN adopt Folders as well as Tags, they are not mutually exclusive, and in fact, can work really well together. It is its only weakness that I find a source of annoyance, even though I am comfortable with Tags. Both have their respective strengths and weakness.