search

ooni / explorer

OONI Explorer: uncover evidence of internet censorship worldwide
https://explorer.ooni.org
BSD 3-Clause "New" or "Revised" License
74 stars 38 forks source link

Country pages: websites - UI adjustments #173

Closed holantonela-zz closed 5 years ago

holantonela-zz commented 5 years ago

Since https://github.com/ooni/api/issues/85 is still in progress, for the stable release we should make some tweaks to have a useful UI:

hellais commented 5 years ago

Could we show a top 8 or 6 measured websites defined by the websites with more "blocked/anomaly" results and more qty of measurements?

How do you define this exactly?

What if a site has more anomalies (because it's tested more times), yet another has some confirmed which we have a higher level of confidence about?

Also keep in mind that we show measurements inside of the listing only of the AS (network) that the user has selected.

The sorting of the websites in the list is actually that we will first show sites that have confirmed measurements and then we sort them by measurement count.

However we sort the networks in the listing by absolute measurement count (indepedently from if they have anomalies or not).

If we do decide to change the sorting of the networks we should at the very least expose the metric that we are sorting by inside of the listing (we currently only show the absolute measurement count) to convey to the user what it is that we are sorting by. However I am not sure what metric we should use there. Do we use the number of site that we have confirmed to be blocked? Do we use the number of measurements that show confirmed? Do we use anomalies, etc.

I think the current approach of using the absolute measurement count is pretty reasonable and I would suggest we first go with this one (it's also going to be more work on the backend to implement these other strategies) and only change it once we get some feedback from users that we should go in another direction.

We should display a bigger time lapse to have a non-empty graph. Maybe all time?

Currently all the metrics related to websites, for performance reasons, are limited to only 30 days. We can change this, but we have opted for not doing it at this stage as it would be a non-trivial change.

The pager at inner sections is bad for various reasons:

Are you referring to the pagination of the websites charts? I think we should keep it, because the plan is to eventually add support for filtering websites by keyword, but we are missing that feature in the API, see: https://github.com/ooni/api/issues/86

The ASN selector and the n of tested websites should live in the same line, using 50% width per element.

👍

holantonela-zz commented 5 years ago

I think the current approach of using the absolute measurement count is pretty reasonable and I would suggest we first go with this one (it's also going to be more work on the backend to implement these other strategies) and only change it once we get some feedback from users that we should go in another direction.

Agreed. I'm trying to have a less empty graph that also can allow a further exploration at the search results page.

Currently all the metrics related to websites, for performance reasons, are limited to only 30 days. We can change this, but we have opted for not doing it at this stage as it would be a non-trivial change.

I see.

Are you referring to the pagination of the websites charts? I think we should keep it, because the plan is to eventually add support for filtering websites by keyword, but we are missing that feature in the API, see: ooni/api#86

Yes. I'd remove it and eventually when you support filtering per keyword then you can have a navigation there, even if that pattern is quite glitchy.

sarathms commented 5 years ago

Yes. I'd remove it and eventually when you support filtering per keyword then you can have a navigation there, even if that pattern is quite glitchy.

By removal, you mean that we point to the search page for users to explore that data from there.

It seems like it reduces the perceived capabilities of the country profile page. We also have pagination in another section (Networks) where we just append the new results to the bottom of the list. Would that feel different here given it is not the end of the page?

hellais commented 5 years ago

Yeah I also think that dropping the pagination in the websites section is going to make the page not as useful (especially since we don't support filtering by URL at the moment).

I think we should convert this issue into adding support for filtering by search and drop the pagination once we do that.

holantonela-zz commented 5 years ago

Yeah I also think that dropping the pagination in the websites section is going to make the page not as useful (especially since we don't support filtering by URL at the moment).

Yep. The problem is how the content jump when users go to the next page. Maybe, we can fix the container's height to avoid the weird jump. Even better, we can use/implement a lazy loading pattern for the graphs. Seems like there is a workaround for our charts library.

hellais commented 5 years ago

The problem is how the content jump when users go to the next page. Maybe, we can fix the container's height to avoid the weird jump.

Yeah this I think should be easy. @sarathms can you fix the height of the container when it's loading? I think it would be even better if we showed five loading bars of the height of the content.

Even better, we can use/implement a lazy loading pattern for the graphs. Seems like there is a workaround for our charts library.

I am not sure how lazy loading is going to improve the experience while loading. Another option could be to use https://github.com/danilowoz/react-content-loader (which we already use in the landing page though it doesn't appear to be working on the currently deployed master cc @sarathms).

I would suggest, however, to defer this to future work and document it as a separate issue.

BTW our charting library is actually Victory Charts

holantonela-zz commented 5 years ago

I would suggest, however, to defer this to future work and document it as a separate issue.

Gotcha. Done #250

hellais commented 5 years ago

Ok let's close this issue then