Site Development Notification and Feedback Thread

@byte[]  
I feel this is more a communication issue than a documentation issue - a feature on the site that has worked in an extremely consistent way for probably seven and a half years was just changed without any warning, any request for feedback or comment, etc. All to make it “better” to a small subset of users.
 
Why not just have both - a “search by name” field that works the old way for people who are just looking for tags or checking their spelling without having to know that they have to include wildcards, and an “advanced search” option that uses the categories?
 
@LightningBolt  
I’m more illustrating a point - the fact that this is being touted as “better” despite very minimal documentation shows that this change was implemented to appease people who are intimately familiar with the tagging system.
 
My concern here is that we’re forgetting that people like you and I do not represent the average user of this site. We are both are extremely familiar with how searching works. We both know every syntax operator there is, we know all the little hidden “secrets” of how searching works, all the tips and tricks, how to make searches work exactly the way we want, how to narrow and broaden results, etc.
 
Most people don’t.

@Joey  

 
How would you have searched for fan category tags before the change? That seems entirely unrelated.

@Zeb  
How would you search for them now? The functionality technically does exist now while it hasn’t in the past, yes, but since it was implemented without any documentation or explanation other than “you can search by category, one of them is named ‘origin’”, it’s not really usable for 99.9% of the users.
 
Here’s the list of categories that exist in the system:
 

@Joey  
Maybe I’m thrown off by the choice of example you used.
 
You brought up searching for tag categories as if this update has now made that more difficult. When this update introduced that functionality.  

 
Making it seem like this update now made it so someone has to do that for tag categories, when they didn’t have to in the past.
 
Likely me miss-understanding something obvious. If so: Sorry. My bad.
 
As for searching results like “oc:”  
Right now the tag page’s search bar operates the same as the regular search bar. Anyone who was casually using the site beforehand would have been using the regular search bar first to find images.  
So they would be moving from one search bar’s function, to another identical one. Though maybe including a small icon for “Search syntax help” next to it like the main search bar has could help people discover things easier.
 
 
From what I can tell. This change has done a trade-off of: Only being able to find tag names that contained exactly what you typed in some form somewhere in the tag. Example: LightningBolt’s Wing search  
To one where you can now specify more details in what you’re seeking. Which is helpful if you remember more about the tag you’re trying to find. Example: You know that the tag you’re looking for Started with the word “wing” instead of just having it elsewhere in the tag. The results just dropped to 353 from the 2,513 you had before.
 
In essence: It’s a trade off of:  
Not having to use any extra syntax: Get every possible result that contained what you typed.  
To:  
Having to add extra ** syntax for that result. But you’re also able to search tags with even greater specifics if you know more details about what you’re looking for.
 
Yes, there’s an added complexity. But that complexity appears to be extremely minor for the greater control people have now in finding what they want.
 
If you’re worried about no one knowing they have to use wildcard, maybe some tiny text just below the search bar that says ^{”use * for wildcards”} could serve to let people know.

@byte[]  
Nice. Thanks! I’ve wanted all that stuff for years now.

@Zeb  
The example I used was to just supplement my point - it wasn’t the point itself. But I’m probably not communicating it well either.
 
Basically, what I’m getting at is that this change feels like it was made primarily to benefit site staff and power-users who do a lot of work involving tagging. And don’t get me wrong - I’m 100% in favor of giving such people tools and functionality to make tagging easier/faster/more fun, etc.
 
However, at the same time, those people do not represent the average user of this site who’s just here to browse pictures of cute ponies (or humans, birds, dragons, etc). I feel that this change makes searching for/finding specific tags more difficult for those people, as the average user is not likely to know that they can wildcards. Even if we add documentation to that effect, who’s gonna read it?
 
And yes, you and LB do raise a very fair point that some queries will return a massive amount of results. But looking at it from the perspective of an average, everyday user who’s not gonna know how to manipulate searches, a query that used to return 500 results is now going to return 0-1 results and not show them what they’re looking for, and probably no clue how to get to those 500 results.
 
It’s a double-edged sword. And the problem is there was no discussion or request for feedback/input, no option to use the old style of searching, none of that. Basically, I feel this change likely just made searching for tags more difficult for the majority of people who are not power-searches/power-taggers.

@Joey  
Basically, I think a better approach is to make the “better” search optional. Like have a “preform advanced search” checkbox on that field. If checked, it searches using the new logic which includes all the operators and stuff. If unchecked, it uses the old logic.
 
Or even simpler, if unchecked, it just transforms the entered query into “name:*(query)*” so it behaves like the old logic, even though it’d be using the new logic on the backend. That way power-users who find value in this change will have it, but the average user who’s just trying to figure out “what the #&!$#@# is that tag called” can just type in some random phrase and get results without having to learn search operators and wildcards.

Wait so y’all fucked up the damn search system? Come on, guys. Not having to get the exact name of something is a godsend, especially for things like comic: why me?!, which I always get the interrobang wrong and couldn’t find it now if I wanted to. Seriously change it back, please.

@GenericArchangel  
You can still not have to get the exact name right. It’s exactly the same as before if you add * to both sides.

@Zeb  
But I don’t want to have to do that, or remember to have to. Why not just add an option to turn on the advanced search, or to use the old way? We had working code for that, and adding a switch between the two would please everyone.

@GenericArchangel  
I asked the same thing over in bug reports. It seems a sane and reasonable solution, but if they’re considering it, they aren’t acting like they are.

Wait, people used the Tags page?
 
Huh…

A common argument I’m seeing is “it’s not that complicated to add asterisks around your search term for the old functionality”. But - to some people, it is! Not everybody finds that sort of thing simple or intuitive, even if it’s explained to them. Nor is everybody willing to put effort into learning how to use something, especially if that thing is is something that was previously much simpler to use, and then suddenly changed.
 
I definitely don’t think it should be reverted; I think making the tag search more powerful is an excellent idea. I like the checkbox idea, possibly adding something to the settings that lets you change your default setting on it (so people who want the advanced search don’t have to click the checkbox every time they visit the page).
 
Also, making the documentation for the tag search syntax more obvious and comprehensive would go a long way, since right now the page looks identical to how it did before unless you scroll all the way to the bottom, and there’s nothing on the page that suggests that you can use stuff like wildcards now.

Big ol’ announcement box on the tags page then?  
 
@Joey  

My question is, why is this not listed anywhere? I would think a couple of pages that would show the color codes would be the Tags and Tag Guidelines pages.
 
 
@Zeb  

I used a similar example in the bug thread, and it’s exactly why I say this is an improvement. Don’t remember how many times I’d hoped for this fix.
 
@Joey  
I made the same suggestion in the bug thread, but in the opposite direction. Your suggestion sounds better though.

Why not just put two search boxes, one right above the other, for “partial tag search” (implied wildcards) and “power search” (no implied wildcards)?
 
Also some specific examples of using multiple power search terms at the bottom of the page would help a lot.

Default search field is now an NLP-analyzed version of the name, so you don’t need to explicitly wildcard anything to use it. Example.

@byte[]  
A step in the right direction, but not good enough. Users still can’t get searches back that include “wing” if it’s not at the start of the tag.
 
If this wasn’t already made clear, you’re asking too much of the average user the second you include a manual with a search bar for something so basic.

@Background Pony #EF5A  
What are you talking about? I get results with wing anywhere in the tag name.
 

@byte[]  
NLP also gives you the ability to do ASCII folding, so you can search for pokemon and get results for pokémon:
 

@byte[]  
I’m having difficulty properly linking this as the hanging asterisk keeps breaking things, but what I means is your given example is missing numerous results.
 
Typing *wing* instead returns the same results the search would have come back with two days ago before it was altered.

@Background Pony #EF5A
 
Yes, it’s missing results that do not contain the word wing in some form of its stem. Chances are when you search for wing you expect it to return results about wings, not something entirely unrelated like wingding eyes. If you want the old behavior, then you can still get it with name:*wing*, but chances are you probably didn’t intend this.

@byte[]  
Actually I do, but thinking on it, I concede that probably makes more sense this way. That said this could make searching for artist names a bit of a pain in the rear.
 
I do have one more question though; an asterisk is auto filled in when accessing the tags page, but deleting it then searching for a word without it seems to return the same result as leaving it there, so why is it there at all?

@Background Pony #EF5A  
It was asked that it be added to show that wildcarding is supported.
 
Also, the index page actually does a search for ‘*’ if the query parameter is blank. So it reflects what happens on the backend.

@byte[]  
Thank you! Sorry if we were a little rude about this whole thing.

Well now it seems like the way it worked yesterday isn’t exact. So can I no longer specify how I want searches to go with exact *s anymore? Or did I miss something changing now?