Place API: ordering... Food for thought.

[AleziaKurdis]

This is not a bug or a feature request, but more explanations about the design of the list in the Places app., that could be interesting to know for the re-design of the sorting/ordering/filtering on the server side.

So these are the how and why, as food for thought for an eventual redesign on server side.

---

Problems needed to be address:

• Don't show me places where I can't even go.
  The old explore app was displaying places running under a protocol different than what the user have.
  The result was a very frustrating rate of failure to navigate. New comers who were trying to explore were exposed to failure up to 30%, seeding in their mind a very bad image of the whole thing.

  To address this, the place with a different protocol were just excluded (client side). (which can be do on server side by passing the client protocol version in parameter to the server)
  There is also a mecanism that checks the percentage of excluded place.
  Over a certain percent of exclusion, a warning is shown to inform the user that he is running a protocol version that is no more used by the majority.

• Lack of equity, avoid the cheating schemes, places that every body know.
  Originally, the main list (the one people see opening the app) was sorted by number of people present in a domain, and then secondly by no specific order.
  So you had in top of the list the places where people are, which seems at first sight a good idea. But the reality was a lot more clunky.
  If there was 2 places in a domain, those places where displaying the same number (because the count is for the domain) It was giving impression of more people than the reality.
  The "administrative" places (arrival hub, community meeting) where also systematically in top of the list, while those are the place that people have all already visited, pushing deeper in the list the places of interest.
  Since there was no other ordering key after the number of people, some places were eternally stuck very deep in the list.
  Even if we had added the alphabetical order as a second ordering key, (thing that human being seems to always do), this was still discriminating places based of the the name. Condemning the Z to the end of the list and have a poor visibility forever.
  This system based on the number of visitor, and on the alphabetical order was also exposing the list to the very annoying phenomena of the cheating, as observed in other platforms (ex: Second Life).
  Owners started to put "AAA" or "!!!aaa" before their place name to be in top of the list, and some started to add bots in their domain to fake a higher count to be in top of the list.
  Since we are not google and do not aim to monetize the top of the list, it made sense to find a counter to this.

  To address this, the places list (the one see at the opening of the app) has not been sorted by user count, There is a present of people indicator, but it is not used as order key.
  As last order key, with objective to give equally the chance to every place to be at the top, a random number has been assigned for that purpose.
  But it couldn't be a pure random, which would have caused another problem. If the list ordering changes each time you open the app, it's annoying. Something interesting you would have noticed while you were exploring that list would be lost in that same list at your next use.
  It needed that we could ensure a minimal stability for at least the time of the user session (ideally for at least current day.)
  This is why it uses a seeded random (a randomization that is always the same for a specific seed (key)) And this seed is based on time and made to change on a cycle of 5 days.
  By doing this, every place has a specific rank in the list and this rank is kept for 5 days. Every place has its chance to be in the top, in the middle, or at the end, and it leaves no way to cheat that artificially.

"Public places" versus "Public places with something to visit".
Set an image on a place name versus not set any image, seems to be a clear indicator that the owner express the idea that there is something specific to visit.
If the owner provides no clue to the visitor about the content to be visited make this less interesting for the user to jump into that world.
With objective to provide the best user experience as possible to the visitor it make sense to promote the places with a picture at the top of the list. It also ensure that the app will display a better visual and avoid to have everywhere a collection of placeholders that tell nothing.

Local Content fist.
In a federation logic, when you are on a domain of a specific Directory Server, it would make sense to promote the local content (domains of the current Directory Server)
A bit like when you visit a country, you might be more interested to discover the cities of that country in priority.
Such a prioritization generates a regionalization that could be interesting for the explorer.
In the priority order, you would have then:
- Local (Places from the current Directory Servers)
- Federated (Places from Directory Servers that are part of the Federation)
- External (Places from Directory Servers that are not part of the Federation)

Places list (default tab):
Here how the list is then organized in the Places app.:

1- With Photo - Local DS (ordered by a seeded random sequence that is persistent and for each cycle of 5 days)
2- With Photo - Federation DS (ordered by a seeded random sequence that is persistent and for each cycle of 5 days)
3- With Photo - External DS (ordered by a seeded random sequence that is persistent and for each cycle of 5 days)
4- Without photo - Local DS (ordered by a seeded random sequence that is persistent and for each cycle of 5 days)
5- Without photo - Federation DS (ordered by a seeded random sequence that is persistent and for each cycle of 5 days)
6- Without photo - External DS (ordered by a seeded random sequence that is persistent and for each cycle of 5 days)
7- Beacons (old deprecated system) (ordered by a seeded random sequence that is persistent and for each cycle of 5 days)
8- Utilities (tutorial and Localhost)

Domains list:
Here how the list is then organized in the Places app.:
1- List of places of the domain (alphabetically) Grouped by Domain (ordered by number of user, then alphabetically) with the user count displayed (on the domain group).
2- Utilities (tutorial and Localhost)

---

All this was the result of a long thought. I wanted to expose those concepts and problem that it tries to solve, hoping it can help for a new design of a server side solution.