Jump to content


Level 2
  • Content Count

  • Joined

  • Last visited

Community Reputation

4 Neutral

1 Follower

About mtanne

Recent Profile Visitors

296 profile views
  1. I agree with you generally, I also think in terms of 3NF, and after many years of work in search and tagging, I generally think in terms of graphs more than hierarchies. And I generally search rather than navigate. However, we're talking about a decade of users making the point that they need to organize information in a way they are not being offered. And EN either not hearing, not caring, disagreeing, or inadequately explaining the solution. To say "works for me" is the ultimate dismissal in any software discussion. Either EN users are not very smart, and don't know how they should organization their information in all the myriad domains in which they use the product, or they have a valid point that there are valid ways to visualize information. Folders vs. Tags is one. (Gmail has an elegant solution of the two coexisting - EN could try that) The underlying problem I see isn't necessarily one implementation, but anytime a software company, and its paying customers (its lifeblood) are at odds over a major feature request for so many years running.
  2. Stacks were a huge step forward. I separate projects into stacks. Groups might be a bit more formalized or isolated - for example different levels of access, like with Google Drive or DropBox. Use cases such as: work (which may have confidential info) and personal files (which may have medical info) in the same screen. Obviously could be different accounts, or other solutions. There are other features more important to me. Visualizing Folders The key is an abstraction layer between the underlying implementation and the visual layer. Underlying implementation: a well-structured formal information architecture is what's needed. hierarchy/file system = TREE labels/tags = GRAPH. Graphs are more flexible. So it should be a graph. Probably is a graph. Gmail is a good example of a folder hierarchy implemented as labels. Abstraction: visual representation is independent of underlying structure. Changes to the visual representation DO NOT require changes to code by the back end team who are preoccupied with data integrity, account security, back-up, redundancy, scaling, etc. Visual representation: Yes. WIN/Mac platforms address folders well, they've had decades to get there. Apple experimented with stacks and drawers and piles during the years of Pink and Taligent and OS7 (?), but ended up right back to folders. Millions of users voices being heard I suppose. There are SO many variants to look at out there now: Box, DropBox, Gmail, Google Drive, Spotify, to name a few. Most have drag and drop, view as list/grid, folders down the left side, preview in the main pane, view by tag, search, sort, etc. THE KEY is the ABSTRACTION LAYER and API which would allow 3rd party developers to try domain-specific visualizations. The EN UX team could do low cost beta experiments without risking core data integrity because they'd only be fiddling with visual code. Take accessibility as a major area most people forget. Blind users cannot "Visualize" the information structure the same way as most other users. Usually once you've solved for 2 or 3 special cases, you find you've been forced into something of a workable generalization. But you need a sound information architecture underlying the whole thing. A deficit here is what plagues many Dev teams nowadays, and is what prevents them from ever solving what seem like they should be simple UX changes. (I sound like one of those guys: "when I was young we had to code in -20 weather, and had to compile uphill..." lol.
  3. True. The fundamental problem is a failure to see the abstraction between information organization and information representation. As @DTLow and @JMichaelTX and others have pointed out, the underlying implementation of any organizational mechanism is labeled objects. A Directory is set of labels to files, and if the structure of the labels allows only one parent, it is a TREE. If the structure allows more than one parent it is a GRAPH. Period. That's it. It's that simple. First year CS class teaches you this. Without an abstraction between the underlying implementation and the way information is presented, we all get stuck in this unresolvable vortex of ideas. WITH an abstraction, the implementation can focus on data integrity, back-up, performance, security (still an important matter - I don't want MY tagged notes showing up in YOUR tag search). And the presentation layer can be anything people need. You can change the UI without calling on the back-end developers, whose jobs are overwhelmed solving those much harder problems. Third parties can change the representation layer. So we can have folders, hierarchical folders, colored folders, tags, stacks, notebooks, nested notebooks, or whatever kind of representation works for all the people who, as you've rightly pointed out, think differently. I used to work in accessibility. Try thinking of all the problems we've discussed about Evernote, from the perspective of a blind user who's SOLE interface is to the have the title of each notebook read to them, and then either enter or move to the next, and you will appreciate that YES people have DIFFERENT NEEDS.
  4. Good points. An intentional stance that has note changed since 2008? There are four factors at play here. 1. Information Structure and Organization. gmail is an excellent example showing that "labels" and "folders" are one and the same. In fact, technically, any filesystem is simply a set of labels (tags) in a directory. The only difference is that tags allow multiple membership, which is a more flexible structure than a directory. I'd argue that EN users have a higher requirement for organizing active information than an email app, which is ultimately about Inbox Zero and an archive. This is the actual nature of the technical problem at the root of everyone's frustration. 2. User Stories / Usage Cases. Some people think in terms of folders. Some think in terms of tags. Some prefer search. Some problems (archival) favor folders and hierarchy. Some problems (research) favor jumping to a tag. Some (quick answers) favor a search. Take a simple example from Spotify, who has essentially solved this problem: Playlist: My Deep House Playlist - a list of songs I MUST have together in a specific order (they can also be in other playlists) Hierarchical Playlists: Electronic > House > Deep House; Electronic > DownTempo; Electronic > Dubstep; etc. Tag: Artist names, albums, genres are all forms of tags: Metalcore, punk, Prince, JustinBieber, Search: "Free bir..." 3. User Perception. The fact that this is an ongoing debate 10 years later, means customer expectations are NOT being met. Perhaps Evernote Team don't understand what the users are asking for. Perhaps they do understand but are dismissive. Perhaps no one with formal training in ontologies and information structure is even looking at the problem, so EVERYONE is confused both Evernote and Customers. But regardless, the fact that users aren't free to organize thousands of notes in a way that works for them, and the company and the users are talking past each other for 10 years running? Obviously a communication problem. Poor @engberg left alone to defend the company's position without reinforcements. 4. Technical Deficit. Evernote has been running a technical Deficit since the beginning. I'm a champion, and supporter and really WANT them to succeed. And they've managed to keep advancing the product so many of us rely on. But the reality of over-stretched technical teams, is long stand-up meetings with long lists of unresolved bugs. And the lists keep getting longer. If the technical deficit is never addressed, often by biting the bullet and focusing on refactoring ancient code, the problems compound, it shows up in quality, and it shows up in subscription renewals, and those paying customers are the lifeblood of the company. All it takes is a freshly funded Y-Combinator team who are super smart and super motivated to solve the problem in a cleaner way. Then when Sequoia backs that team, it will be able to hire the best engineers who've been slaving away to maintain the EN code base for a decade, and the rest is a story told a thousand times in Silicon Valley. So, hopefully, this one widely desired and poorly understood aspect of information organization can be resolved AND communicated sometime soon.
  5. Agreed. Technically as you've described a "pseudo notebook" is simply a label. In fact, technically, any folder hierarchy is simply a set of labels in a directory. The only difference is that labels/tags permit multiple membership. so in the end Tags is a much more flexible mechanism. You can "move" a whole set of notes to a different notebook by retagging them, OR have them show up in a different notebook by adding a new tag. Some people visualize best as folders others prefer to search for a tag. I do both. See ALL the notes in a category and know it's all of them (archival) Fastest path to my note on a topic. (targeted search) Gmail is an excellent and widely understood implementation of "folders as labels" that demonstrates these principles well, and has implemented search, folders and tagging quite effectively.
  6. You're pointing out an important difference in the way people use folders vs. tags. Some like to search tags others like to navigate folders. In truth, Tags and Notebooks (folders) are technically just two ways to visualize the same underlying organization structure, with one difference: tags allow multiple membership and folders permit one. If the fundamental underlying structure was sorted out, users and app developers could search and navigate their notes however they wanted to. One of the best examples of this is gmail, in which you can clearly see "folders implemented via labels". i.e. If you have 4 Note books "Blue Notes" "Red Notes" "Short Notes" "Long Notes" and a short blue note called "My short blue note" was tagged tag:Blue tag:Short Then you can search for the tag Blue , the tag Short or both short, blue, OR: you can navigate Blue Notes > Short Notes > "My Short Blue Note" Evernote just needs to tackle this problem. In the meantime we have notebooks filling with hundreds or thousands of notes that will only sort by date, can't pin to top, and can sub-categorize.
  7. Evernote started as a simple app to keep some notes. But its now used to track many projects, draft presentations, clip large volumes of information, and often for mixed use personal and professional. Many users have thousands of Notes (I have 2,076) I agree we are LONG overdue for: Sections within Notes - I have very long notes that are quite hard to navigate. Every PDF, Word and HTML document in the world has sections to aid this long standing and very well understood problem. Notebook Groups - simplest: Work . Personal. Nested Notebooks - Of course. We've been asking for this for years. these forums are filled with this request. I have one notebook with 595 Notes in it. Spotify allows nested Playlist folders. This is such a fundamental principle to managing information, it's stunning that it's never been address.
  8. Several ongoing editing bugs stem from one more fundamental problem I believe. Each has been discussed separately, but never fully resolved, so I'm making one post to draw attention to the bigger problem. Here are a few examples I've experienced for years: The "Quantum cursor" - cursor location after a paste is randomly above or below the inserted content Bullet list start/stop - item in a bullet list may include 0, 1 or 2 LF, sometimes you can end a list with 2 CR, sometimes it just keeps making more bullets Paste w/o formatting, sometimes you get the formatting of the line above, sometimes below removing formatting - sometimes it's impossible to remove formatting of a section of text, it's like tar stuck to your cursor, and every line it touches gets infected by it I've come to accept Evernote's core line editor is just 'quirky'. Apparently, so have others, since no one's screaming about it, and as basic as it is, release after release it just NEVER gets fixed. My Theory: The core line editor functionality isn't based on a solid, adequately formalized and characterized design. It was probably hacked as one of the first bits of code at the very beginning and it is long overdue refactoring. Normal issue when developing a complex codebase. e.g. Paste. Insert XYZ into the sequence of characters ABC\rDEF<cursor>GHI\n at the cursor. do you get ABC\rDEFXYZ<cursor>GHI\n or ABC\rDEF<cursor>XYZGHI\n. This is a problem addressed since the very earliest line editors from IBM ed, Edlin, Wordstar, WordPerfect, vi, Emacs, and implemented in the editor used by this very forum. The other issues listed, and several more not listed, suffer from the same lack of formal definition. Perhaps, when moving the cursor, we are inadvertently placing it before or after hidden format markers, and sometimes invalid or inadequately terminated formatting, leaving dangling bits: <b>this text is bold \r is this text still bold? If this is an accurate conclusion what the editor needs is a fomal definition: for all editing function: character entry, cut, copy, paste, delete, (including the more complex ones: image paste, table paste, Web clipping, etc.) cursor location, rules for CR and LF, formatting start/stop, does the end of the line include or not include the CF (e.g. in MSWord moving cursor to left margin guarantees you're selecting the entire line including LF or CR) Proper Bracket Matching on formatting markers. e.g. HTML editor or Web browser parses nested formatting: <li><b>text</b></li>. A helpful workaround would be "View Formatting" that exposed the underlying formatting structure so we could delete extraneous LF, CR, or unterminated formatting.
  9. There have always been quirks in the placement of the cursor, which seem to have improved or been resolved (for years, when you pasted text, the cursor wasn't necessarily at the end of the text afterward, so if you just started typing, you be typing in the wrong place, and checkbox lists were pretty wacky, often typing before the checkbox, or on the next line, or the previous line.) But there's a new bug: when you click somewhere to place the cursor, and begin to type, the text is entered at the previous cursor position. (Evernote 6.5, Mac OS 10.9.5) 1. Cursor is in position A (say, line 6, character 22) 2. Click to place cursor in position B (say, like 18, character 0) 3. Press a key to start typing (say, "Hello World") 4. The text "Hello World" will be entered at position A. The current workaround seems to be to click the cursor twice. (I'm betting, that the code that places text is referencing the previous cursor position, while the code displaying the cursor is referencing the current cursor position). So clicking twice, makes both the current cursor and the previous cursor the same. However this is a pretty fundamental bug - not being able to type where the cursor is.
  10. This would be helpful in so many situations. I'm even reluctant to add content clipped from the Web to my notes, because it can carry so much heavy formatting. In MacOS, there's a simple way to paste unformatted, text: shift + option + command + v That sometimes helps. But it loses ALL formatting so, if there's a table or list, they become an unformatted block of text. Three possible features would solve this: 1. paste and match like in word, as described by the OP 2. Make "simple" text, instead of plain text (keep tables, lists, divs, but strip color, font, images, anything else). There are a set of text 'structures' that are not formatting - similar to wiki text. When you edit a wiki you specify lists, tables, and other structures, but the formatting is defined by the template. 3. allow toggle of individual formatting, but this is already complex with the existing formatting toggles, so this would only get more cluttered, and you may have to click 4 or 5 of them.
  • Create New...