In the search page, when we select the "profiles" tab it would be more interesting if the results were sorted by the most recent users first.
The /api/srch/profiles already has the parameter sort_by. One possible solution would be to change this line so it calls the endpoint:
https://publiclab.org/search/profiles/#{profile.username}?sort_by=recent
I'm really interested in this adjustment!
I just had an experience of searching for a community member by full name, and having the actual profile which is in the format firstnamelastname be the very last result.
Would changing the sorting as described in this issue help with this?

It looks like according to the docs here: https://github.com/publiclab/plots2/blob/master/doc/API.md#profiles
The current sorting is by user_id, which would be /roughly/ by creation date.
I think Liz's observation reflects this as philipsilva is probably a very old profile!
A few things:
recent means recently posted notes/wikis -- so sorting by whoever's posted something on the site (not comments) most recently. recently posted notes/wikis, philipsilva doesn't appear (https://publiclab.org/search/profiles/philip+silva?sort_by=recent) -- because Phil has never posted a note: https://publiclab.org/profile/philipsilvaSo, while I think this is good, it would make the default sorting exclude people who've never posted a note. So I think we may want to explore first --
A. making recent reflect... comments also? Something else? Note that philipsilva has also not posted any comments, so that wouldn't help @ebarry's search
B. any other way to sort users that WOULD help @ebarry ?
For example, @stefannibrasil @milaaraujo -- would it conceivably be helpful to add another sorting type to user.rb to sort by natural language score? This is done in node searching:
We could copy that into profile searching over here:
Although we'd have to accept more parameters, as we do in node.rb:
def self.search(query:, order: :default, type: :natural, limit: 25)
Could this be a reasonable next step? I would kind of loosely guess that philip silva would have a good match score against philipsilva -- what do you think?
hello, all! back from my vacations! hum, that's true, thanks for the details!
hum, I think that we may need to break those into two separate endpoints. The way it's now is basically used for the autocompletion feature.
I can work on this. What do you think of leaving this endpoint (rename to usernames, for example, or something) for the autocompletion and create a new one only for the search, since they are supposed to be used in different contexts? That way would be easier to search for user tags for the search feature. Let me know what do you think! @ebarry @jywarren
that would also fix #3506
Oh that makes a lot of sense. Thanks!
On Wed, Oct 10, 2018, 1:52 AM Stefanni notifications@github.com wrote:
that woudl also fix #3506
https://github.com/publiclab/plots2/issues/3506—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/publiclab/plots2/issues/3501#issuecomment-428287230,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABfJztANEB22y63f9wzzr7959O9ifEbks5ujOIkgaJpZM4W70U_
.
ok, @jywarren I'll work on this, then :+1:
hey everyone, I'm fixing this #3700 first then I'll focus on this one, hang on! xD
hi, everyone. I'm afraid I'm not gonna have the time for this, sorry about that.
@milaaraujo do you wanna move with this one? Thanks!
Yes, I can work on that.
I think using the same endpoint keeps the code more consistent. From a user perspective, it would be awkward to have two endpoints searching for profiles. Besides that adding the tag search option to the profiles endpoint is not complex.
I'm working on #3767, to solve #3506 first. Them I'll come back to this one here.
Closing as we've wrapped our search project!
Most helpful comment
Yes, I can work on that.