[ux] OONI Explorer Revamp Mockups - Measurement Pages

Thu Nov 15 16:15:16 UTC 2018

Hi  Antonela,

Thanks for getting back! Addressing your points:

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.
>

Very true. We are waiting for real data to populate the country page and
iterate on that. The measurements pages are more of a priority though right
now. They are based on real data however (apart the performance tests).

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.

Which pages are you referring to? I'm not a fan of having 1 full width
block for the measurement pages as there is a lot of information we need to
accommodate and that would end up with a lot of vertical white space due to
the nature of the blocks. Isn't that a very mobile-first approach to take?
Explorer will be Desktop focused for now as well.

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.

Again, is this about the Country page or the Measurement pages? Currently,
with a 2 column view, Measurement pages don't offer much to scroll as far
as I'm concerned. I don't think there is much need for sub-nagivation
unless the measurement pages get significantly longer.

Why don't we have here a top header color based on the results of the
measure as we have on Probe now?

The use case of Explorer is different from Probe so we had in mind that it
was important to let the user know in which test environment they are in.
Would you suggest to use the color of the result instead similar to Probe?
That would make it however harder for people to see at the first glance
what type of test they are looking at.

> 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.

TBH we haven't worked too much on these graphs yet as I'd probably be a bit
restricted on this depending on the dataviz library we will use and see how
it plays out with real data. Those are great points though and having
Upload and Download graphs in one graph is also a good solution (why didn't
I come up with that myself? I guess that's why one should ask for feedback
:) )

On Thu, Nov 15, 2018 at 3:51 PM 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?
>
> 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.
>
> 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.
>
> 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.
>
> *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?
>
> *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.
>
> I made a rough wireframe to show what I'm thinking of
> https://share.riseup.net/#q84X6Qr_puDOkLeJXem45Q
>
> Let me know what do you think!
>
>
> A
>
> On 11/12/18 5:26 PM, Elio Qoshi wrote:
>
> As a little side note: Feedback on layout, structure and readability are
> most helpful at this point! Thanks again!
>
> On Mon, Nov 12, 2018 at 7:37 PM Elio Qoshi <elio at openobservatory.org> <elio at openobservatory.org> wrote:
>
>
> Hi there!
>
> At OONI we are currently shifting focus to the development of the revamped
> OONI Explorer as the mobile apps are currently being polished for a release
> soon.
>
> I'd like to invite you to have a look at the current mockups with a
> special focus on the Measurement Pages at the bottom:
> https://design.ooni.io/mockups/explorer
>
> Your feedback is highly appreciated and will help us move forward with the
> next iteration. It would be even greater if you could send us your feedback
> by the next UX Meeting tomorrow! You can comment as a guest on pages
> similarly to Marvel. You also don't need to sign in for that.
>
> Thanks in advance!
>
>
>
>
> _______________________________________________
> UX mailing listUX at lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/ux
>
>
> _______________________________________________
> UX mailing list
> UX at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/ux
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/ux/attachments/20181115/22218bb9/attachment-0001.html>