Jump to content

Rob Freundlich

Level 3
  • Content Count

    106
  • Joined

  • Last visited

  • Days Won

    2

Rob Freundlich last won the day on May 10 2016

Rob Freundlich had the most liked content!

Community Reputation

109 Awesome

2 Followers

About Rob Freundlich

Profile Information

  • Subscription
    PREMIUM

Recent Profile Visitors

1,826 profile views
  1. TIL that Ctrl+1 through Ctrl+9 open the shortcut notes. Thank you!
  2. I've got the same problem. Tables are just plain useful, and I've got lots of notes that use them to hold lists of information. When I'm in my kitchen updating my grocery list, or at the doctor's office browsing the web while I want for an appointment and see something I want to tack onto the end of a list, I'm not at my desk: I'm on my phone or my tablet. So I want to add a row to a table right there, right now. I was very excited when table became useful in EN, and IIRC, around the same time, there was talk of "one common editor" for all platforms. That would certainly help here. /sigh
  3. 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.
  4. 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.
  5. 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.
  6. 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: 7.10.1.1-5ba38a4 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)
  7. 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.
  8. 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 :-)
  9. 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.
  10. @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!
  11. The cynic in me wants to say "Clueless". <grin, duck, and run>
  12. 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
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...