[ux] OONI Explorer Revamp Mockups - Measurement Pages

[Arturo Filastò]

On 15 November 2018 at 15:51:15, Antonela Debiasi (tor at antonela.me) wrote:
> Hello!
>  
> As we talked before, we want to have some coherence between the new
> Probe and new Explorer. The best approach for this kind of massive data
> one-page layout has the most important content in the hero zone. Then,
> it starts to expand on technical data once the user begins to scroll,
> which means that they have more interest in what they are reading. To
> find it out, let's start with two simple questions: What is the
> essential data on this page? And, what are people looking for when they
> arrive at this page?. Then, does these match?


This is a great question and good way to approach reasoning about this page.

I agree that there should be something tying the similar mobile screen to the explorer screens, yet as I will explain the way in which these screens are used is a bit different.

If you haven’t already, you should take a look at the sitemap I shared on the #ooni-design slack channel.

People will reach this page by either:

1. Clicking on a result that they found through the search page
2. Clicking on a measurement that is linked from some website (ex. an OONI research report) or shared via social media
3. They clicked on this from the OONI Probe mobile app (this is not yet implemented)

This is an important thing to keep in mind, because the context the user has about a certain measurement is different in explorer (measurements will be from all sorts of different countries around the world and they have been run at different times).


In terms of the most important information to show, I would say the following:

1. Where was the measurement run (Country, Network)
2. When was the measurement run (Date & time)
3. What was the result of the measurement (this changes depending on the sort of test)
4. How long did the measurement take to run
5. What type of result is this, yet this can often times be inferred from 3.

Moreover we have other bits of information that are not as important, yet should be included:

* The RAW measurement JSON (this is especially useful for measurement where we don’t have detailed views for them yet)
* The metadata of the probe (OS, version, etc.)
* Measurement ID (though this is inferred from the URL)


> I think that will be useful design with real data. The content must
> shape the layout. We cannot map *all* the cases (well, you can), but it
> can help on having a quick overview of how the layout gets broken when
> you have more or less content or which is the best way to approach a
> kind of data. A quick example is on the country page, where you have
> four digits measurement qty, and the real number is more close to nine
> figures. That will break your layout.
> 

Yes for sure the country pages need to be designed with real data, which is why we are now actually moving forward with implementing some of the country pages so we can start to have real data to play around with.


> In general, I would avoid the two columns. Based on the content I see at
> the mocks, is perfectly fine if we try a one full-width block per section.
> 

I think you have a good point here.

This would also allow us to be ready to port the design over to being mobile friendly with less effort, maybe?


> Another thing to consider is a sub-navigation. It will help users to
> find specific sections more accessible. With a sub-navigation, you can
> extend your data without sacrifice users time scrolling to see what they
> are looking for. A fixed left column menu or classic pill tabs at the
> top could make the work.
> 

This is a very good point. For the measurement pages I think that the only result which really could use the sub-navigation is the web_connectivity result (the others don’t really have that much information).

For the country pages, though, I think we should make the navigation system more prominent and more useful than how it’s mocked up now.

> *Web Connectivity Measurement / HTTP Invalid Request Line Measurement*
> Why don't we have here a top header color based on the results of the
> measure as we have on Probe now?
> 


In theory we could do this, though if possible I would find I way to also somehow include our brand colors in here as well (since many people will see this page and we want to establish it’s an OONI page).


> *NDT Speed Test / DASH Streaming*
> In addition to all the previous comments, I think that line graphs are
> beautiful, and you could go full-width on them. We can have the same
> line graph but different options to display, like pills filters. In this
> specific case, having upload and download lines showing at the same time
> allow users to compare both.
> 

Yeah I think maybe having them full width is better, though we have to see it with real data, though I suspect we cannot put them both in the same chart because the scales are quite different.

For example most people will have an upload speed which is even 10x less than their download speed, moreover these charts are pretty specialised charts and we will likely only implement in a future version.


> I made a rough wireframe to show what I'm thinking of
> https://share.riseup.net/#q84X6Qr_puDOkLeJXem45Q


That seems reasonable.

I think we mostly need some help in trying to re-organise and rationalise some of the information that we need to present so that we can structure it properly.

Would you be available to have a call to discuss this next week?

~ Arturo