5 ms·

>it's been a long time I've felt such an enormous disgust at the amount of neglect and arrogance that is being displayed there. Please do not assume bad faith.

by zxzax 5y ago

>it's been a long time I've felt such an enormous disgust at the amount of neglect and arrogance that is being displayed there. Please do not assume bad faith. Type-ahead has some confusing usability issues, such as that it only matches against the beginning of the filename, which from my reading is why it probably will not be brought back. The way forward is to help get the current solution up to par. I feel your pain, but giving up and reverting to old type-ahead behavior will only ensure that the issue never gets a proper fix. It's very hard to have a conversation about this when people assert that the real cultural problem is that a particular feature they want isn't implemented. >Another point is that their Alt-Tab has a strange auto-grouping behaviour that totally breaks my workflow. Has this been reported?

jstimpfle 5y ago
I don't assume bad faith, following Hanlon's razor it's obviously stupidity and probably a culture of arrogance engrained into a larger group (I know very little about the organization there, but there has been a lot of heated debate for years about other groups connected to redhat). How can they otherwise ignore such an obvious, massive load of complaints with dismissive and side-stepping comments? > Type-ahead has some confusing usability issues, such as that it only matches against the beginning of the filename Please, explain to me, what exactly is confusing about that? That it matches precisely against the beginning of the filename? It's the exact polar opposite of confusing, and furthermore it's extremely useful in my (and many others') workflow for navigating large directory trees where I know which path I want to take in advance (obviously this is a frequent situation for all the things I'm currently working on). And I am convinced this is not a coincidence or a pecularity of my workflow, precisely because the behaviour of type ahead is simple and predictable and also matches how humans tend to remember names, which is most likely by their initial letters. This old and proven workflow reduces a lot of stress coming from increased visual-motoric interaction, compared to the search behaviour in Nautilus where the screen gets updated in unpredictable ways (both in terms of the files that are displayed, and also in the time lag to when they are displayed and interactable). We're talking multiple or many seconds of wait and stress that this behaviour can cause, even on beefy machines. Noone working in UI would disagree that operations should aim to take less than 100ms. (by the way I don't dispute that more involved navigation facilities are useful sometimes, for example I like to use glob-patterns that start with a * or something from time to time. However prefix search is clearly the most accurate and fastest tool for like 90% of my navigation needs).
- zxzax 5y ago
  >How can they otherwise ignore such an obvious, massive load of complaints with such disrespectful and dismissive comments? [...] We're talking multiple or many seconds of wait and stress that this behaviour can cause, even on beefy machines. I don't think the complaints were ignored, multiple other tickets with concrete work items were opened in response to the complaints. There is a ticket open to improve the speed. The particular suggestion for a fix was dismissed, but that's a separate thing. >Please, explain to me, what exactly is confusing about that? I personally find it confusing, in large folders I often don't remember the exact name. I don't think this behavior is particularly bad if the user knows what is going on, but going back to making it the default and de-prioritizing search can make it hard to find some files.
  - rstat1 5y ago
    You can keep the type-ahead functionality while also implementing proper full search like every other OS available does. It doesn't need to be a one or the other type deal. File Explorer in the last 4 major Windows releases has a search box in the top right of the window, while also supporting a type-ahead search as well. There's no reason why GNOME can't also do that. I don't think you'll ever be able to improve the speed of a full search to a point that it'll match the performance of a type-ahead style search.
    - zxzax 5y ago
      >It doesn't need to be a one or the other type deal. Sadly it does. Search is currently the default. If you bring back type-ahead, that will de-prioritize search. Nautilus could copy the Windows approach but that would also bring along with it all the issues of the Windows approach, where there are two similar options with subtlely different behavior of how they match against file names, with no clear explanation to the user why this is or why some files are accessible in one way but not the other. You and I may be familiar with the approach because we're used to it but other users might not. I've seen some users that have been using Windows for decades and still they have no idea what type-ahead is because they never even thought to type into the file manager. >I don't think you'll ever be able to improve the speed of a full search to a point that it'll match the performance of a type-ahead style search. Why not? I would think search would actually be faster, because that only has to show a few relevant search results, whereas type-ahead has to keep scrolling the view around and reflowing the whole folder.
dnr 5y ago
I don't even use Gnome, but the behavior in the gtk open and save dialogs changed in the same way a few years ago, so I'm going to assume it's the same issue: I hate hate hate the new search behavior, and would go back to the old ("type-ahead") behavior in a second if there was a setting I could toggle. I don't think it's "bad faith", I think it's just weird group-think and having things other than the users as priorities. The amount of condescension and misplaced confidence displayed in that thread is impressive. If you (or anyone reading this) is affiliated with the Gnome project, please reconsider how you handle and incorporate user feedback into your products.
- zxzax 5y ago
  >The amount of condescension and misplaced confidence displayed in that thread is impressive. I would say that assuming condescension is assuming bad faith. If there is a comment that is truly rude and dismissive, it should be reported as a code of conduct violation. Otherwise, please don't assume the response is trying to put you down because it's disagreeing on technical grounds. Any bug report has to go through technical review, and the developers will almost always have more information about the code than the reporter. >I hate hate hate the new search behavior, and would go back to the old ("type-ahead") behavior in a second if there was a setting I could toggle. To give another opinion, I personally don't feel the same way about this, and I don't think it would be much benefit for there to be a setting. >If you (or anyone reading this) is affiliated with the Gnome project, please reconsider how you handle and incorporate user feedback into your products. I'm not affiliated, I'm just expressing my personal opinion on this, as you are. Not all user feedback is created equal. Sometimes, the developer must firmly say no because something isn't technically viable. Users don't decide what is technically viable or not, only the developer tasked with writing the code can make that decision. Sometimes, the developer is faced with a choice between competing requirements, and it's not possible to fulfill both technically. Once the decision has been firmly made, there's little purpose to accepting further feedback after that. Committing to a solution means the developer has to accept the effects of it, losing users is always a possible effect, but so is users changing their mind.
  - dnr 5y ago

by zxzax 5y ago

jstimpfle 5y ago

I don't assume bad faith, following Hanlon's razor it's obviously stupidity and probably a culture of arrogance engrained into a larger group (I know very little about the organization there, but there has been a lot of heated debate for years about other groups connected to redhat). How can they otherwise ignore such an obvious, massive load of complaints with dismissive and side-stepping comments? > Type-ahead has some confusing usability issues, such as that it only matches against the beginning of the filename Please, explain to me, what exactly is confusing about that? That it matches precisely against the beginning of the filename? It's the exact polar opposite of confusing, and furthermore it's extremely useful in my (and many others') workflow for navigating large directory trees where I know which path I want to take in advance (obviously this is a frequent situation for all the things I'm currently working on). And I am convinced this is not a coincidence or a pecularity of my workflow, precisely because the behaviour of type ahead is simple and predictable and also matches how humans tend to remember names, which is most likely by their initial letters. This old and proven workflow reduces a lot of stress coming from increased visual-motoric interaction, compared to the search behaviour in Nautilus where the screen gets updated in unpredictable ways (both in terms of the files that are displayed, and also in the time lag to when they are displayed and interactable). We're talking multiple or many seconds of wait and stress that this behaviour can cause, even on beefy machines. Noone working in UI would disagree that operations should aim to take less than 100ms. (by the way I don't dispute that more involved navigation facilities are useful sometimes, for example I like to use glob-patterns that start with a * or something from time to time. However prefix search is clearly the most accurate and fastest tool for like 90% of my navigation needs).

zxzax 5y ago
>How can they otherwise ignore such an obvious, massive load of complaints with such disrespectful and dismissive comments? [...] We're talking multiple or many seconds of wait and stress that this behaviour can cause, even on beefy machines. I don't think the complaints were ignored, multiple other tickets with concrete work items were opened in response to the complaints. There is a ticket open to improve the speed. The particular suggestion for a fix was dismissed, but that's a separate thing. >Please, explain to me, what exactly is confusing about that? I personally find it confusing, in large folders I often don't remember the exact name. I don't think this behavior is particularly bad if the user knows what is going on, but going back to making it the default and de-prioritizing search can make it hard to find some files.
- rstat1 5y ago
  You can keep the type-ahead functionality while also implementing proper full search like every other OS available does. It doesn't need to be a one or the other type deal. File Explorer in the last 4 major Windows releases has a search box in the top right of the window, while also supporting a type-ahead search as well. There's no reason why GNOME can't also do that. I don't think you'll ever be able to improve the speed of a full search to a point that it'll match the performance of a type-ahead style search.
  - zxzax 5y ago
    >It doesn't need to be a one or the other type deal. Sadly it does. Search is currently the default. If you bring back type-ahead, that will de-prioritize search. Nautilus could copy the Windows approach but that would also bring along with it all the issues of the Windows approach, where there are two similar options with subtlely different behavior of how they match against file names, with no clear explanation to the user why this is or why some files are accessible in one way but not the other. You and I may be familiar with the approach because we're used to it but other users might not. I've seen some users that have been using Windows for decades and still they have no idea what type-ahead is because they never even thought to type into the file manager. >I don't think you'll ever be able to improve the speed of a full search to a point that it'll match the performance of a type-ahead style search. Why not? I would think search would actually be faster, because that only has to show a few relevant search results, whereas type-ahead has to keep scrolling the view around and reflowing the whole folder.

dnr 5y ago

I don't even use Gnome, but the behavior in the gtk open and save dialogs changed in the same way a few years ago, so I'm going to assume it's the same issue: I hate hate hate the new search behavior, and would go back to the old ("type-ahead") behavior in a second if there was a setting I could toggle. I don't think it's "bad faith", I think it's just weird group-think and having things other than the users as priorities. The amount of condescension and misplaced confidence displayed in that thread is impressive. If you (or anyone reading this) is affiliated with the Gnome project, please reconsider how you handle and incorporate user feedback into your products.

zxzax 5y ago
>The amount of condescension and misplaced confidence displayed in that thread is impressive. I would say that assuming condescension is assuming bad faith. If there is a comment that is truly rude and dismissive, it should be reported as a code of conduct violation. Otherwise, please don't assume the response is trying to put you down because it's disagreeing on technical grounds. Any bug report has to go through technical review, and the developers will almost always have more information about the code than the reporter. >I hate hate hate the new search behavior, and would go back to the old ("type-ahead") behavior in a second if there was a setting I could toggle. To give another opinion, I personally don't feel the same way about this, and I don't think it would be much benefit for there to be a setting. >If you (or anyone reading this) is affiliated with the Gnome project, please reconsider how you handle and incorporate user feedback into your products. I'm not affiliated, I'm just expressing my personal opinion on this, as you are. Not all user feedback is created equal. Sometimes, the developer must firmly say no because something isn't technically viable. Users don't decide what is technically viable or not, only the developer tasked with writing the code can make that decision. Sometimes, the developer is faced with a choice between competing requirements, and it's not possible to fulfill both technically. Once the decision has been firmly made, there's little purpose to accepting further feedback after that. Committing to a solution means the developer has to accept the effects of it, losing users is always a possible effect, but so is users changing their mind.
- dnr 5y ago