Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve our search results #1081

Closed
connyduck opened this issue Feb 26, 2019 · 7 comments
Closed

Improve our search results #1081

connyduck opened this issue Feb 26, 2019 · 7 comments

Comments

@connyduck
Copy link
Collaborator

The Mastodon search can now do a lot more things than previously: mastodon/mastodon#10091

We should definitely take advantage of that, and, for example, present our search results in three (posts, users, hashtags) infinitely scrolling tabs. Or present the results as we do now, but with a "more" button for each section of the results.

Of course we need to wait until the majority of instances run this feature.

@pandasoft0
Copy link
Contributor

I checked the search APIv2.

  1. What is prefer solution:
    a) show first 5 items per category (statuses, accounts, hashtags) with "more" button below each category. On More click replace this summary fragment with category fragment and show infinite scroll list with items of selected category only;
    b) show 3 tabs at top, and show infinite scroll lists per tab.
    JFYI: in APIv2 we can't select what items to load. We can specify limit and offset, but anyway - it will load items for all 3 categories: accounts, statuses, hashtags.

  2. Should i use the exists fragment and adapter to show statuses or create a new adapter in the same way i did for report's statuses? Should i implement all features of exists statuses adapter at the new?

  3. Should i update exists activity+fragment code or create a new activity with fragments according to selected solution at p.1?

@connyduck
Copy link
Collaborator Author

I prefer solution B. Only showing results of one type after "more" clicked is a bad user experience.

I think the 3 tabs and the search bar should belong to the activity, and the tab contents are three different fragments. They should all share one ViewModel probably.
The ViewHolders we have for statuses and accounts should definitely be reused, other than that you can decide.

@pandasoft0
Copy link
Contributor

@connyduck I am trying to use v2/search at mastodon.social but result looks strange.
So, first request. I want to get first 10 items per category:

https://mastodon.social/api/v2/search?q=test&resolve=true&limit=10&offset=0&following=false 
{
  "accounts": [
    {
      "id": "963"
    },
    {
      "id": "179860"
    },
    {
      "id": "1184"
    },
    {
      "id": "179862"
    },
    {
      "id": "820018"
    },
    {
      "id": "248304"
    },
    {
      "id": "725124"
    },
    {
      "id": "298091"
    },
    {
      "id": "217924"
    },
    {
      "id": "61339"
    }
  ],
  "statuses": [
    {
      "id": "102115228601373686"
    },
    {
      "id": "102146124881012866"
    },
    {
      "id": "102143335650922023"
    },
    {
      "id": "102246304503430384"
    },
    {
      "id": "102100944210578451"
    },
    {
      "id": "101836442594147121"
    },
    {
      "id": "102116886680668226"
    },
    {
      "id": "102117212948319447"
    },
    {
      "id": "102117313703633435"
    }
  ],
  "hashtags": [
    {
      "name": "test"
    },
    {
      "name": "test좋아"
    },
    {
      "name": "testてすと"
    },
    {
      "name": "testテスト"
    },
    {
      "name": "testちんぽっボロンッ"
    },
    {
      "name": "test1"
    },
    {
      "name": "test_1"
    },
    {
      "name": "test_111"
    },
    {
      "name": "test12"
    },
    {
      "name": "test123"
    }
  ]
}

I removed all fields except ids.
It returns 10 accounts, 10 hashtags and 9 statuses.
Ok, i want to load 5 items since 9 (PositionalDataSource behaviour)

https://mastodon.social/api/v2/search?q=test&resolve=true&limit=5&offset=9&following=false
{
  "accounts": [
    {
      "id": "963"
    },
    {
      "id": "179860"
    },
    {
      "id": "179862"
    },
    {
      "id": "1184"
    },
    {
      "id": "725124"
    }
  ],
  "statuses": [
    {
      "id": "102115228601373686"
    },
    {
      "id": "102146124881012866"
    },
    {
      "id": "102143335650922023"
    },
    {
      "id": "102246304503430384"
    },
    {
      "id": "102100944210578451"
    }
  ],
  "hashtags": [
    {
      "name": "test"
    },
    {
      "name": "test좋아"
    },
    {
      "name": "testてすと"
    },
    {
      "name": "testテスト"
    },
    {
      "name": "testちんぽっボロン"
    }
  ]
}

It returns some of items from the first request, but at the different order. looks like it ignores the offset and has no order... I don't know how to use it for infinite scroll. Have you ideas what i am doing wrong?

@pandasoft0
Copy link
Contributor

pandasoft0 commented Jun 14, 2019

Hm... Looks like search endpoint has an undocumented parameter "type"="statuses|accounts|hashtags" code and it works more accuracy if this parameter specified.

@connyduck
Copy link
Collaborator Author

Its probably fine to send three search requests, one for each tab? You could also look how Fedilab handles this, it has almost the same setup.

@pandasoft0
Copy link
Contributor

@connyduck Yes, i started to work on the task. But i will need to change the adapter for statuses. It uses PagedList Adapter, but i want to change it to simple Adapter to support changes of statuses.
I will try to do that on this week.

@connyduck
Copy link
Collaborator Author

#1327

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants