834147 - Optimize Marketplace Reviewer Tools for mobile

Status: RESOLVED FIXED

(Marketplace Graveyard :: Reviewer Tools, defect, P4)

Description

[Bram Pitoyo [:bram]]

This bug will contain design improvements that will optimize the reviewer tools user interface for smartphone devices.

Most of these improvements will be CSS tweaks made to the existing responsive design, but visual mockups will be uploaded.

Comment 1

[Christopher Van Wiemeersch [:cvan]]

Is this a use case: reviewers write approval and rejection messages on their smart phones?

If so, then I understand the necessity for this bug. Otherwise, we should try to harness a "send to phone" reviewer workflow (bug 833503):

1. Reviewer opens up an app in the Reviewer Tools on his/her desktop.
2. Reviewer logs in to the Marketplace app on his/her B2G/Android phone. The Marketplace app automatically notices which  app I am reviewing. Reviewer installs the app there and tests it.
3. Reviewer decides to either accept or reject the app from the comfort of his/her desktop where the explanation is written and checkboxes are checked.

Comment 2

[Bram Pitoyo [:bram]]

Attachment: reviewer tools - queue page - 01

This mockups visualizes what the queue page could look like on mobile.

Notable things:

* Current page is clearly marked (although the visual style may not yet be final). In this case, the user is currently at the ‘Queues’ page


* Search bar is moved up, so search can be performed on all tabs, not just one. Also note how the “Search” button is located to the right-side of the search field, to save vertical space.


* To toggle between tabs, user can tap on the “Apps (182)” text, or the Southeast-facing arrow, or the whole light brown area. Tapping this will trigger a menu that will let users select between tabs.

As an example, try opening up SUMO from your smartphone, on this page: https://support.mozilla.org/en-US/products/firefox/get-started — then tap the “Showing All articles” button. Toggling between tabs will have the same kind of interaction. But this interaction is not final yet. I’m just starting to think about what it could look like.


* The table does not contain a “Price” column, because the “Paid” price is already indicated by a coin icon. I’m not sure how we’re going to indicate apps with in-app payments (I’m thinking a plus ‘+’ icon?), but we should find an icon for it, so we don’t have to display the “Price” column.


* On a related note, how can we display compatible devices in a smart way, so that it’s  not overwhelming to look at?

  A couple of potential solutions:
  * Don’t display incompatible devices, so we reduce visual clutter (easy)
  * Display the device icons in a way that consumes less space
  * Find an entirely different representation of devices (hard)


* Navigational buttons (<<, previous, next, >>) look clickable, and are sized so they’re big enough as link targets.

That’s about it for today. Keep watch for more mobile mockups and screenshots when I get back from Firefox OS App Days Wellington this weekend!

Comment 3

[Wil Clouser [:clouserw]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #1)
> Is this a use case: reviewers write approval and rejection messages on their
> smart phones?

It's my understanding both scenarios are valid use cases.

Comment 4

[Bram Pitoyo [:bram]]

Attachment: reviewer tools - queue page, moderated reviews - 01

This is a mockup of the moderated review tab of the queue page.

Notable features:

* App name is made bigger (font-size: 20px) and bolder (font-weight: 700) so they’re easier to target

* (Optional) every other item in the listing has a light gray background color. This is similar to the gray shading that we have on the Apps Queue page, and will make one app distinguishable from the other.

* “Keep review”, “Delete review” and “Skip for now” radio boxes are made into tappable buttons, so they’re easier to target.

* A couple of notes about these buttons:
  * I recommend making the keep/delete actions performed on tap, and make this button perform like a button, not like a radio box item
  * For example, if a user taps on the “Delete” button, it should perform a delete action right away—perhaps with an overlay confirmation message
  * Imagine seeing this page populated by 20 apps to moderate. A user will have to scroll all the way down the page to get to the “Process Reviews” button. The biggest advantage of doing this is that we eliminate all those scrolling, because actions can be performed on individual app on the list
  * Consequently, we won’t need to have the “Process Reviews” button
  * Because of that, we also won’t need the “Skip for now” button

* CSS code values for the buttons:
  * Teal/green: #009d89 to #00c7ac
  * Red: #d93f21 to #b20000; if we already have a red button, use it
  * Gray: #fafafa to #ccc
  * All colors are taken from the Firefox OS palette
  * Button height for keep and delete: 60px
  * Button height for skip: 32px
  * Font size for skip: 13px
  * (Optional) on tap:
    * Reverse the gradient values
    * Eliminate the lighter box-shadow on the bottom of the button
    * Move the darker box-shadow to 2px on top of the button


All CSS codes are made to make your life easy and save you from using the eyedropper all the time; feel free to use your best judgment and implement something easier!

Comment 5

[Bram Pitoyo [:bram]]

Attachment: reviewer tools - app review log page, explanation - 01

This is a mockup that visualizes the mobile-optimized app review log page.

Notable features:

* Note the dark purple highlight on the “Logs” menu item of the navigation bar. This serves as a visual signpost, indicating the current page.

* The Filter form above the table has been refitted. We should have some sort of a roulette date selector (a la time selector) to make selecting for specific dates easier. Make sure that the blue value of the button style is the same as attachment 705749 [details].

* Sidebar: we seem to have two blue values for these buttons: one lighter than the other. Let’s pick one and make them the same across the site.

* the table header <thead> element is hidden.

* Every <td> element in the table has a ‘display: block;’ property. This sounds crazy, but it makes the content stacks vertically. It’s much easier to look at a long list on your smartphone when it’s ordered like this.

* App title has a font-size of 20px and font-weight of 300.

* The rest of the text has a font-size of 13px and line-height of 1.5. This is consistent to the rest of the site.

* Every odd <tr> element has a border-bottom: #d7d2c3. This will separate each table entry with a light brown border. This color value is used elsewhere on the site.

* When comment is shown, every even <tr> element has a light gray background-color: #f8f8f8, border-top: #fff, and border-bottom: #bcb6b1. Comment text has a font-size: 13px and a line-height: 1.5. This will give each comment a differentiating color, and a slightly darker brown bottom border to separate it from the next table entry.

* Finally, on the bottom of the page, you’ll see a row of <<, previous, next, >> buttons. This pagination element is exactly the same as what we had on attachment 705749 [details].

Comment 6

[Bram Pitoyo [:bram]]

Attachment: reviewer tools - navigating between queue tabs, explanation - 01

This mockup visualizes what user can do to navigate between sub-pages or tabs inside the Queues section.

The only notable thing here is the fact that user can either tap on:
* The “Queue” link on the header nav, or
* The tab title itself

This will invoke some sort of an action menu that contain links to different tabs.

Comment 7

[Bram Pitoyo [:bram]]

http://f.cl.ly/items/3W3E3100283y1S3c0g0c/reviewer-install-flow.pdf

This is a series of mockups that describes the most common “send to phone” reviewers workflow.

cvan wrote it on bug 834147 comment 1, so to quote:

> 1. Reviewer opens up an app in the Reviewer Tools on his/her desktop.
> 2. Reviewer logs in to the Marketplace app on his/her B2G/Android phone.
> The Marketplace app automatically notices which  app I am reviewing.
> Reviewer installs the app there and tests it.
> 3. Reviewer decides to either accept or reject the app from the comfort
> of his/her desktop where the explanation is written and checkboxes are
> checked.

Basically, user will have to:
1. Add an app on desktop
2. Install an app on mobile
3. Review an app on desktop


But in addition to this scenario, we should make our design fully responsive, so he will be able to access the Reviewer Tools and add, install and review apps no matter what platform he’s on at the moment. Provided that the app is made for that platform, he’ll be able to install it there.

So this install flow document also outlines an admittedly uncommon scenario, where user has to:
1. Add an app on mobile
2. Install an app on desktop
3. Review an app on mobile

Comment 8

[Andrew Williamson [:eviljeff]]

(In reply to Bram Pitoyo [:bram] from comment #4)
> * A couple of notes about these buttons:
>   * I recommend making the keep/delete actions performed on tap, and make
> this button perform like a button, not like a radio box item
>   * For example, if a user taps on the “Delete” button, it should perform a
> delete action right away—perhaps with an overlay confirmation message
>   * Imagine seeing this page populated by 20 apps to moderate. A user will
> have to scroll all the way down the page to get to the “Process Reviews”
> button. The biggest advantage of doing this is that we eliminate all those
> scrolling, because actions can be performed on individual app on the list
>   * Consequently, we won’t need to have the “Process Reviews” button
>   * Because of that, we also won’t need the “Skip for now” button

the use case for moderating reviews is doing a large number at the same time (maybe all 20) rather than a single one, so the scrolling is a reflection of the work flow.

Comment 9

[Rob Hudson [:robhudson]]

(In reply to Bram Pitoyo [:bram] from comment #7)
> http://f.cl.ly/items/3W3E3100283y1S3c0g0c/reviewer-install-flow.pdf
> 
> This is a series of mockups that describes the most common “send to phone”
> reviewers workflow.

I don't see anywhere showing how the reviewer will clear out the "My Reviewed Apps" list? The lifetime of the apps showing up on this page isn't clear to me.

Comment 10

[Christopher Van Wiemeersch [:cvan]]

(In reply to Rob Hudson [:robhudson] from comment #9)
> (In reply to Bram Pitoyo [:bram] from comment #7)
> > http://f.cl.ly/items/3W3E3100283y1S3c0g0c/reviewer-install-flow.pdf
> > 
> > This is a series of mockups that describes the most common “send to phone”
> > reviewers workflow.
> 
> I don't see anywhere showing how the reviewer will clear out the "My
> Reviewed Apps" list? The lifetime of the apps showing up on this page isn't
> clear to me.

IIUC, (a) when the app has been successfully reviewed (i.e., approved or rejected) or (b) the next time we poll and the app is no longer being viewed by the reviewer.

Comment 11

[Rob Hudson [:robhudson]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #10)
> IIUC, (a) when the app has been successfully reviewed (i.e., approved or
> rejected) or (b) the next time we poll and the app is no longer being viewed
> by the reviewer.

(a) makes sense. For (b) I didn't see any hints of polling going on in the PDF? It looked like the reviewer takes the explicit action of clicking the "Review app" button for it to show up in the "My Reviewed Apps" list?

Comment 12

[Andrew Williamson [:eviljeff]]

(In reply to Bram Pitoyo [:bram] from comment #7)
> http://f.cl.ly/items/3W3E3100283y1S3c0g0c/reviewer-install-flow.pdf
> 
> This is a series of mockups that describes the most common “send to phone”
> reviewers workflow.

some comments:

The pdf implies you have to press a button to start the review - the idea is to use the existing 'reviewing' ping so you'd be starting the review once you start the page.

'My Reviewed Apps' is be more accurately 'My Reviewing Apps' (poor grammar!) as its only the apps current under review.

The install button should always be enabled, even for platforms the developer doesn't claim they support.

Comment 13

[Bram Pitoyo [:bram]]

http://f.cl.ly/items/3E3V1Z3f1I2T3C40301k/reviewer-install-flow-v2.pdf

Thanks for all your feedbacks! The reviewer install flow has been updated with these changes:

* There’s no longer a feature to “press a button to start the review”, so it’s very similar to the way we’ve designed it originally. The moment a reviewer opens an app in a new tab, he’d be starting the review, and we’d track that app in the “My Reviewing Apps” page. No further actions needed.

* This means that, when the reviewer closes that tab, the app is gone from the listing page. A reviewer must keep a tab open for any app he wants to review. This tab could be opened on either the desktop or mobile interface, but it has to remain open.

* The name “My Reviewing Apps” still needs to be better worded. cvan wrote it best as “Apps I Have Open On My Desktop”, but the name is too long.

Does this address some of your concerns? Is there anything I missed?

Comment 14

[Andrew Williamson [:eviljeff]]

(In reply to Bram Pitoyo [:bram] from comment #13)
> http://f.cl.ly/items/3E3V1Z3f1I2T3C40301k/reviewer-install-flow-v2.pdf
> 
> * The name “My Reviewing Apps” still needs to be better worded. cvan wrote
> it best as “Apps I Have Open On My Desktop”, but the name is too long.

"Apps Under Review"?  Or "Under Review" (maybe the same page could then be used for Themes and Addons)? 

> Does this address some of your concerns? Is there anything I missed?

I think its all good now!

Comment 15

[Bram Pitoyo [:bram]]

Attachment: reviewer tools - individual app page, explanation - 01

This mockups visualizes the individual app page that’s been optimized for mobile. It’s designed so reviewers will be able to:
1. Get an at-a-glance overview without too much scrolling
2. Where appropriate, dig down into a particular section of the information
3. Accomplish the most important actions (like install) quickly


The background of the redesign was: last week, I wrote to Lisa asking about the information that most reviewers commonly look for in this page.

She wrote back:

> Most important is the download button.  Next is description, screenshots,
> and app history.  Last would be the app details (free vs paid, manifest
> url, locale, etc)...except for app status (pending approval, rejected,
> etc).  It's also important to highlight if someone else was looking at the
> page first, so the reviewer will know to check with the other person
> before making changes.

Based on this, the page has been reorganized to follow this hierarchy:

1. The top spot contains the most important items:
  * The Install button. Most reviewers will look for this
  * The View Listing button
  * App status (pending, rejected, etc.)
  * Warning if another reviewer is looking at the page

2. Up next is the Description area. It contains:
  * Screenshots
  * Summary
  * Description
  * Everything is condensed by default, expandable with a “(more…)” link

3. Next, we have the App History area that contains comments and messages associated with each version of the app. This area will contain a lot of text, scrolling is unavoidable, and there’s no way around it.

But we should expect that a user who wants to write a review or view a particular message of an app will be using the desktop interface. So then, we don’t need to worry too much about this section.

Lisa wrote it best in her email:

> I'm thinking that for this first mobilization project, the primary way of
> accessing all app info should be via Desktop.  The primary workflow for
> Mobile would be searching for and installing an app.  The rest of the info
> should be accessible on Mobile, but expect that a user will be sitting at
> a Desktop machine with the same full size page in front of them.

4. Next, we have an area for the app Details, like:
  * App type (packaged or hosted)
  * Price
  * Weekly/total downloads
  * Etc.

5. Finally, we have the area that will allow reviewers to approve, reject, escalate and comment on an app.

Comment 16

[Bram Pitoyo [:bram]]

Attachment: reviewer tools - queue page, advanced search - 01

This mockup visualizes what happens when you go to the queue page (attachment  705749 [details]) and then tap on the “Advanced search” link below the search button.

I know that advanced search is a low priority at the moment, but I thought that this would get every part of Reviewer Tools ready to implement whenever we want to develop it.

The only thing that’s notable here is the use of value selectors instead of checkboxes to select number of days, app type, device type, and premium type. This will make it easier on the small screen.

One thing that I haven’t considered is adding a second search button somewhere at the bottom of the advanced search interface, so user doesn’t have to scroll all the way up in order to execute a search.

Comment 17

[Bram Pitoyo [:bram]]

Attachment: reviewer tools - queue page, moderated reviews - 02

(In reply to Andrew Williamson [:eviljeff] from comment #8)
> the use case for moderating reviews is doing a large number at the same time
> (maybe all 20) rather than a single one, so the scrolling is a reflection of
> the work flow.

In that case, then we can revert the change so that the buttons would perform the function of a radio button, rather than being actionable on tap.

The “Skip for now” is pressed (selected) by default, and user can tap on either the “Keep” or “Reject” buttons to select that option. After done reviewing all options, user can tap on “Process Reviews” to commit all changes.

These selections should have affordance. They need to look like something that can be pressed, so user knows the what he’s supposed to do when he sees it.

Attached is the two visual styles for these: one has a sunken effect, and the other looks it’s been raised.


Bonus: CSS code, below, should we want to implement it later.

.raised {
    box-shadow: inset 0 13px 15px rgba(255,255,255,1);
    background: rgba(225,225,215,0.5);
    color: rgb(164,148,96);
}

.sunken {
    box-shadow: inset 0 0 4px rgba(215,210,195,1);
    color: rgba(0,0,0,0.35);
}

Comment 18

[Bram Pitoyo [:bram]]

(In reply to Bram Pitoyo [:bram] from comment #17)
> Created attachment 710535 [details]
> reviewer tools - queue page, moderated reviews - 02

The themes review tool is a good example of the same kind of interaction we have in the Moderated Reviews page, where user is reviewing a large number of entries at the same time, then committing the changes all at once. We might be able to adapt some of their UX for the desktop interface.

https://marketplace-dev.allizom.org/reviewers/themes/queue/

Comment 19

[Wil Clouser [:clouserw]]

Bram: Do you have anything else to attach to this bug?  If not I'll split out some tasks and close this one.

Comment 20

[Bram Pitoyo [:bram]]

I think I’m done here.

Comment 21

[Wil Clouser [:clouserw]]

(In reply to Bram Pitoyo [:bram] from comment #20)
> I think I’m done here.

Ok, thanks Bram.  Spawned out of this are bug 839539, bug 839540, bug 839541, bug 839542, bug 839543, bug 839544, bug 839545.  Closing this bug.