Jump to content

Rob Freundlich

Level 3
  • Content Count

  • Joined

  • Last visited

  • Days Won


Rob Freundlich last won the day on May 10 2016

Rob Freundlich had the most liked content!

Community Reputation

108 Awesome


About Rob Freundlich

Profile Information

  • Subscription

Recent Profile Visitors

1,741 profile views
  1. True, although the Shift thing isn't very discoverable - I've been using Evernote for 11 years and I am only just now learning about it. Having the options on the right-click menu would be nice. And then, once they're their, having them available and in the right-click menu in Tags view would be an obvious, usable, extension of that.
  2. That's a decent workaround, but it's still a workaround. It'd still be better if the application offered "expand/collapse children" at each level, and "expand/collapse all" at the top - that's a pretty standard thing for tree/hierarchical UI's.
  3. The problem with this workaround is that it requires using the mouse. If you're a user who prefers the keyboard, this interrupts your flow.
  4. Like the title says - sometimes when I try to use the Web Clipper to capture a message in GMail in Chrome, it just doesn't start up. No message, no error, nothing. It doesn't matter whether I'm using the keyboard shortcut or clicking the icon in the Chrome toolbar. When I go to the Extension and click "background page" in "Inspect views", it opens the Chrome debugger (nice!). Hitting the shortcut key gives me this: I've seen this for a while, so I don't think it's version specific, but just in case: Chrome Version: Version 74.0.3729.131 (Official Build) (64-bit) Web Clipper Version: Version: Anyone else having this problem? (I've just submitted this to EN Help as well as posting here, so I'll let y'all know what I hear)
  5. So, I just played around with changing some of my delimited tags into non-delimited, and learned that the tag hierarchy isn't a true hierarchy in a couple of other ways. Suppose I've got a hierarchy like this: foo foo.bar foo.bar.baz test test.something test.something.baz If I search for tag:foo*, I find all notes tagged with foo, foo.bar, and foo.bar.baz. That's really nice, and it's akin to searching a file system for all files in directory foo (including subdirectories). I decided to simplify my naming scheme to see how it would work without the dots, since they aren't required by EN, and immediately realized a limitation. It wouldn't let me do this: foo bar baz test something baz The problem is that there can't be two tags named baz, even though, hierarchically, they are different. In a true hierarchy, like a file system, this would be just fine. I can certainly have README.txt in two different directories - the unique identifier for a file is its full path, not its filename. So I worked around it and did this: foo bar baz test something baz2 But then when I tried to search for tag:foo*, only notes tagged with foo were found; notes tagged with bar and baz were not. It was akin to doing a directory listing of only directory foo (which I would have expected to be a search for tag:foo), not the full search of directory foo and its subdirectories. If my proposal is implemented, this is all solved: A tag can be uniquely identified by its fully delimited path, allowing multiple tags with the same atomic name A search syntax can be added to differentiate between "search for notes only with this tag and tags like it" (i.e. "directory listing of directories whose names match foo*") and "search for notes whose fully delimited paths match this sequence (i.e "find files in directories whose names match foo* and their subdirectories"). I'd suggest tag:foo* for the first and tag:foo*.* (or whatever the user's delimiter is), or maybe tag:foo** for the second one.
  6. I get that it's got parent/child relationships, but I feel like without the notation, it isn't really a true hierarchy. Probably me being pedantic. I'm good at that :-)
  7. It's great that tags can now be nested in other tags. But the only way to create a tag hierarchy is by going to the tags list, right-clicking a tag, and selecting "Create tag in this tag's name" or by dragging a tag into another tag. In other applications, hierarchies are represented by delimited sequences of names. In programming, we have object.property.subproperty; in file systems, we have folder/subfolder/subsubfolder. I propose an option in settings that lets the user specify the tag hierarchy delimiter, so that if s/he types a tag containing that delimiter, a set of nested tags is automatically created. So, for example, if my delimiter is period ("."), then when I tag a note with financial.receipt.medical, EN would look for a tag called medical in a tag called receipt in a tag called financial, creating the hierarchy if necessary. It would be as though I created a tag called financial, right clicked it and said "Create tag in financial" and called it receipt, and then repeated that to create medical, only about a zillion times easier. The full name of this tag should be financial.receipt.medical, but I should be able to find it in all searches by simply typing medical - that is, all tag searches should be infix searches.
  8. @jefito You make good points all around. Sounds like we're in similar places - our customers have very hard problems to solve, and they want something that gets the job done. For years, our software was incredibly utilitarian, and was used by only the most technical users at the customer sites. More recently, our customers have had more of a need for the less techie people to be able to use our stuff. Functional, Fast, and Cheap are still hyper-critical for the runtime software, but we've had to bring in Friendly and Usable on the UI side. That's been a huge bonus for me, because even though I do have a background in comp sci, the really hairy computational stuff doesn't really float my boat - UI is where it's at!
  9. The cynic in me wants to say "Clueless". <grin, duck, and run>
  10. You're a lot less cynical than I am - I've never seen the a branding change that made a difference, and was anything other than a pain in the <insert body part here> for the developers. ROFL! True. But a smart company listens to its employees and its users as well as "the market", or whatever drives rebrandings. And I'll play my part - I'll do the rebranding work when it comes up. I'll do whatever work the company tells me to do. But part of my part, as a very senior developer/programmer/engineer/whatever the heck we're calling ourselves this decade, is to tell management when I think a mistake is being made. Particularly since (a) my focus is user interface, so I'm thinking about the users all the time, and (b) my current company, the one I've been at for 10 years, has a very customer-centric view of the world. Because of that, I'm expected to speak my mind if something isn't right for the customers/end users - we all are. Maybe that skews my perspective as a user of other products, but TBH, I think it's the right thing for all employees in product-based businesses. Existing customers are what it's all about. In a well-designed system, where everyone who worked on it at all levels was smart and had the authority to make decisions, you're absolutely right. And as long as I'm dreaming, I'd like a pony. But yeah, I agree with you. And the stuff I'm working on now is a far cry better from that perspective than the stuff I was working on when I went through rebranding h*ll in the past. If my company handed down a decree from above tomorrow that we had to rebrand things (which, in spite of what I said above about everyone being expected to speak up, could still happen), it wouldn't be nearly as painful as my past experiences. But I'd still wonder, loudly, why we were doing it. Well, yeah, I mean, who am I to argue with Spock? ;-b
  11. It definitely matters to investors, because they don't care about the things that really matter. Maybe it matters to new customers, although I've never looked at a product that rebranded itself and said "oh, hey, now that they have a new logo and colors, I'll try it, even though I never did before!" But speaking as a software developer who has been at companies that did a rebranding, I can tell you with absolute certainty that there is at least one group of people who works there to whom the rebranding matters not one bit. Well, that's not quite true. It matters a lot, in that they had to put in a hell of a lot of time and effort to change their code in ways that had zero practical effect, and if they're like every other software developer I've ever worked with, they're not happy about it. So it matters, but not in a positive way.
  12. No, actually, we aren't. We can be satisfied by a product that does what we need it to do, efficiently and in which bugs and design flaws are addressed instead of remaining in the product for years. We can be satisfied by seeing the company put its resources into addressing those problems instead of into marketing fluff that appears, from the outside, to be intended to impress investors or attract new users, when the existing users are increasingly unhappy. Many existing users are not looking for significant enhancements to the product, we are looking for stabilization, bug fixes, and the correction of design flaws. In fact, many of the "significant enhancements" (for example, the recent emphasis on collaboration and other business features) did make the product more complicated and were unwanted by many of the existing users. Yes, that's exactly what they did. And before that, they decided "now" was the time to appeal to the masses by adding new features that many existing users didn't want, leaving the existing bugs and design flaws in place. It's a poor decision, to always look forward at what you don't have and never look at what you already do have.
  13. They clearly spent a lot of time on the rebranding. I hope that doesn't mean that rebranding matters the most to them. As opposed to, say, fixing all of the little things that have been bugging us users for years.
  14. I didn't catch on to that before. Interesting. It does pretty much invalidate my reverse-engineered design. I'm still baffled, though, as to why the actual implementation I saw in the database would get funneled down to any kind of slots for syncing. The notebooks and tags literally each have their own color and font attribute information attached to them in the database. If I were designing a sync protocol for that, I'd just have it send each notebook or tag's color/font attribute information with each notebook or tag so it gets compared/conflict-resolved like any other field. It seems like trying to turn them into some sort of named/slotted things that get synced separately would be an awful lot of extra complexity. Not saying that this is it, but on a casual inspection, it's fairly lading... That's note-specific, not notebook- or tag-related, so I doubt styles live there. Plus it's a 4K limit, which doesn't seem to relate to a 250-style limit, unless they're allocating a specific amount of memory per style and leaving room for other things.
  15. I find this whole 250-style limit to be very bizarre. I'm a software developer, so I'm going to take that one data point and reverse-engineer the most likely design from it, laying out my logic along the way. Point 1: There's a style limit. From this, I will draw the following conclusions about the design: 1. There is an entity in the Evernote system called a Style 2. A Style describes color, font attributes (bold, italic, etc) and has a unique identifier 3. Style entities are stored in a separate file or table from other entities 4. An entity that can be styled, such as a notebook or tag, has a reference to its Style entity - most likely the Style entity's unique identifier. Point 2: The limit on styles is 250. From this, I will draw the following conclusions about the design: 5. 250 is very close to 255, which is the number of unique things that can be identified by a 1-byte value. Therefore it is very likely that the unique identifier for a Style entity is a 1-byte value. 6. The file or table storing Style entities is, for some reason, limited to 250 (or, more likely, 255) entries. These aren't the only possibly conclusions, but they are logical, and fit the facts we have been provided with. Also, they are pretty minimal and simple, and in general, simple and minimal are often (but not always) the best. Based on these conclusions, plus the fact that Evernote is known to be built on SQL database technology, I will now sketch out what I'd expect to find in the database. #1: A table called something like STYLES, with an identifier column called something like ID, of type CHAR(1) (which is a single byte type), and columns for color and font attributes. For some reason, this table will have a maximum number of rows set to 250, if that is even possible. I don't know enough about databases to say whether it is. #2: A table called something like NOTEBOOKS, with, among other things, a column named something like STYLE_ID, which is an ID value from the STYLES table. #3: A table called something like TAGS, with, among other things, a column named something like STYLE_ID, which is an ID value from the STYLES table. Again, not the only possible implementation, but it's logical and fits the conclusions. Also again, they are simple and minimal, which often are the best. So now I'll close Evernote, fire up my DBBrowser for SQLite, and take a look at the Evernote database structure to see how I did with my reverse engineering. Here's what I actually find: 1. NO styles table at all. 2. A table called notebook_attr that pretty clearly contains all of my notebooks. Interestingly, it includes a column called item_color and another called item_style. For notebooks I haven't assigned a color to, item_color is -1 For notebooks that I have assigned a color to, item_color is the decimal value of the color's hex value For notebooks I haven't set any font attributes for, item_style is null (the SQL equivalent of "no value") For notebooks I have set any font attributes for, item_style is a decimal value 3. A table called tag_attr that pretty clearly contains all of my tags. Interestingly, it includes a column called item_color and another called item_style, whose values are similar to the values in notebook_attr (although the "no font attributes" value for item_style here is 0 rather than null. Interesting. The color and font information are stored with each notebook and tag, not in a separate table. So from a data storage perspective, there is no reason whatsoever for there to be a limit on styles. So where does this limit come from? Are they somehow condensing the styles into a structure like I reverse-designed as part of the sync process? If so, what on earth for?!?!? Why not just sync the information as-is? I'm baffled. And frustrated.
  • Create New...