Jump to content

donut

Member
  • Posts

    12
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

donut's Achievements

Helping Hand

Helping Hand (3/5)

1

Reputation

  1. I'm not a fan of these kinds of exchanges. We have a communication disconnect. Thanks for your help. And again, not intending to be difficult, just trying to understand and be helpful. Apologies for the frustrations I've caused.
  2. I see. So inferring, Alfred already trims the results list to 20 or 40 at search time. I'm wondering about similar situations in which any search would be polluted similarly. "ABC" having results like "A-B-C", for example. It would be tedious to prime each query if it happens a lot, but if it doesn't, this is manageable. I'll do my best. @deanishe I didn't get the impression you acknowledged it was a bug, either. The impression I got was this is normal, expected behavior. But now we've clarified. Thanks for your explanations.
  3. Sigh... Which you didn't really need to do in depth. I'm just a sole user and "can't fix" would suffice. Sorry to bother. Thanks for doing this. Thanks. I'll give this a try. I can tell I'm frustrating you both, and you're kind enough to still engage. While I now understand Alfred's model for results ordering makes filtering and additional sorting difficult and particularly performance-constrained, I still don't understand why while searching for "RTS" being polluted with results containing "RT-S" isn't considered a bug from a user and product perspective. Wouldn't you all not want "RT-S" results to show up? Isn't this undesirable? If the answer is, "Yes, that's valid, but can't fix." then that's an ok response for a frustrated customer. If not valid, I guess I'll deal with the coming frustration of bad results or worst case, find another tool, which I'd rather not do, because Alfred is great.
  4. No, it won't. I can't select the result (Yes, I read the link; selection is required according to 1 and 2.), because I can't find the results, because of the number of matches, because Alfred is not matching properly. It's a bug from a user's perspective because the matching isn't right. The returned set of results is incorrect. But I can see you've made up your minds. I thought it might be helpful to point out the results are wrong and try to work through solutions, but I don't know the implementation contraints. I'm just a random user. I'm good. Sorry to bother.
  5. I think there's a way to achieve some of these goals without changing the search, just the rendering in the ViewController. For me, the bottom line is: Alfred is returning incorrect results. This is a bug. Results for "RTS" are being polluted with "RT-S". I don't think "Well, it's the metadata server" is a good reason for why (from a user's perspective, while it might be a good root cause for the developer). Those polluted results are preventing me from finding the most obvious, most intuitive results, which to me in this use case are the highest in the folder hierarchy. There are other rubricks by which a user might consider results as intuitive. I have a workaround for 2, but I don't for 1.
  6. I don't feel we're connecting. When I said "quirks," I wasn't talking about performance characteristics, I was talking about the metadata search treating "RTS" and "RT-S" as the same, which I gleaned was a surprise, given the first response to my inquiry. I don't know the implementation costs, obviously, and I don't mean to overtrivialize, so please don't characterize me as purposefully doing so. I'm just making a user-oriented argument for why wrangling with the complexity is worth it, but as I noted before, I'll deal.
  7. I think this is a false assumption, and this part: ... is rather exactly the point. Alfred is relying on this metadata search API too much, and passing the buck, and the user experience suffers. I don't think users should have to know the underlying implementation and work around what's effectively an excuse for bad results. Really? Does the metadata search always return too many results to handle? Why put Alfred's UX at the mercy of the metadata search alone, something that clearly has shifting behaviors? In my example, it treats "RTS" and "RT-S" identically. Why would we want that as users? Products should be designed with the end users' mindsets and goals in mind, not the metadata search's quirks. Of course, I'm just one lone user, but if performance is the issue, I would make a different performance vs feature tradeoff. While it's always a careful decision to defer choices to users, does this occur enough that it's worth the feature? "Hey, we'll give you more control, but Alfred will be a bit slower." I think there are potentially low-cost ways for Alfred to take these results from the metadata search and present them in a more intuitive order by default. In the case of folders, these might work for my use case: sort them by path string exclude any path with "node_modules" anywhere in the path, treated as a string sort by the length of the path string, so shorter ones show up first sort by the number of slashes (or by depth), making "~/Documents" first, then "~/Blah/Documents" show up second These are relatively low cost ways of getting to a more intuitive set of results and would work for me.
  8. ...or with a more intuitive sorting of results. Folders like node_modules and bower_components and the like make limiting the number of folders inconvenient for developers. Alfred simply doesn’t support this use case efficiently. And it’s totally fine to limit the audience for a product. Value and implementation cost have to be balanced.
  9. Well, my example is one where a tighly focused search isn't possible, because of the explosion of results by default. So I had to remove search space by excluding an entire folder of work from the index, because Alfred defers order to the system outside of its control, rather than deploying a pattern of intuition. I've used Alfred for years, so while I'm disappointed that something so simple seems out of scope, I've got it for now. It just means Alfred can't handle the use case of having hundreds of folders and files that are intermingled with the logical results.
  10. It looks like the workflow approach is the right one, but I'm having trouble making this part of the default search behavior. For the time being, I've just excluded the parent folder from the Spotlight index, and I'll just deal. Thanks!
  11. Thanks for the reply! I familiar with most of this, except the workflows recommendation. In my case, there are so many false matches that I can't find the one I want, so I can't even select it to give it any preference (even with 40 results shown). But that's also only a solution for this particular query; I'd have to do this for nearly everything. Unlike what Alfred help page says, I don't think the default ordering is even taking hold. When I execute `mkfind`, the second result is the one I want. In Alfred, it simply doesn't show up in the first 40 hits. Also, when I set the sorting to "last modified," the results are still ordered incorrectly. I can rename the folder, then rename it back, and it's not the top hit Overall, I think Alfred should be more opinionated about how results are shown, and that's not by usage by default, in my mind. But I think I'm unique that I don't like fuzzy searches, especially if the fuzzy match is several folders deep. In my own apps, I preference search results by exact match at the start of titles, then exact matches by whole word, then go from there. Is there a way just to exclude all folders called "node_modules"? Or even simpler, just sort the results by path?
  12. I'm searching for a folder with the query "RTS", which I expect to result in "~/Dropbox/RTS". It's an exact match I'm looking for the target folder name. However, the results I get are deeply nested, dozens of matches like: "~/workspace/keyboards/qmk_firmware/lib/chibios/demos/STM32/RT-STM32F103-OLIMEX_STM32_P103" ... which is quite counterintuitive to me. In fact, most of my results are like this; deeply nested fuzzy matches ("RT-S" vs "RTS") are dominating the results in a way that I can't find the simplest matches, which I expect to be the exact matches higher in the folder hierarchy or left-most in the path. Is there a way to configure the matching to make this more of exact-match-first? Alfred 4.3 [1205] + PowerPack on macOS Big Sur, 11.1.
×
×
  • Create New...