Closed lime124 closed 6 years ago
@aminalhazwani can you please edit the first comment and post your WIP for pocket video feed. Then we can start to get people's comments and thoughts on it. Thanks! :)
Hello there! As @lime124 wrote up here I would like to share with you some explorations I've been doing for the Pocket Videos feed.
On launch, if the connection is slow, or if the API is not responding, we could show and empty/loading screen.
If there is an error with the API call we could prompt a reload button.
iiic in the first iteration we are going to have just one feed of recommendations. I initially tried a vertical feed with the video description on the side but after digging more into the returned content of the API I noticed that the descriptions are not adding value to the thumb/title so I then opted for a more simple horizontal scroll.
I tried to use already existing metaphor when possible - eg like the New Tab card - so that we bring Firefox products closer together. We could display the source of the video, the title, if it has been recently added to to the stream - i understand that a new video is pulled every two hours - and the thumbnail. a) It seems that all videos are coming from YouTube? Are there going to be other sources in the near future? If yes, I would suggest to leave the source, if not, we could display the source only when the video is focused.
When a video has been already watched we could use the icon + label at the bottom of the card to display a "Watched" signifier. b) do we know if people already watched the video? c) what happens after a user press on a video? does it open youtube? /tv o /mobile domain?
The feed highlights always the first card on the left, but I am still exploring if this is worth pursuing or if we should highlight the card in the center. When a user reaches the end of the recommendations we could use animation - eg small elastic bounce - to let users understand that they reach the end.
If the hidden content off screen is not loaded we could use the loading/empty states to let users know that something is happening.
Looking forward to hear from the team!
Thanks for the mock-ups, Amin! I like the visual design – it's clean and consistent with the platform, but also stands out (I like those colors, at least on my display :).
Here are some thoughts:
To address your specific questions:
On launch, if the connection is slow, or if the API is not responding, we could show and empty/loading screen.
fwiw, we could cache the results from the feed so that we'll only hit this the first time the screen is shown (but caching adds complexity so maybe it's not worthwhile, e.g. what happens if we display the cached data and find out later there is new data on the feed?).
It seems that all videos are coming from YouTube? Are there going to be other sources in the near future?
In theory, the Pocket API already pulls videos from everywhere – it's possible 1) Pocket is not categorizing video pages well so it is missing some that might be videos (e.g. a NY times article that is primarily a video) or 2) users are only Pocket'ing videos that are Youtube videos.
do we know if people already watched the video?
We can track that information but it'd be extra work: I'd say we leave it as a nice-to-have for 3.0 and add it in the next iteration
c) what happens after a user press on a video? does it open youtube? /tv o /mobile domain?
By default, we'll open the URL directly but I think we should try to rewrite Youtube URLs to youtube.com/tv urls if possible. Would you agree?
When a user reaches the end of the recommendations we could use animation - eg small elastic bounce - to let users understand that they reach the end.
Seems like another idea that might be better to iterate on: I'm not sure how difficult this would be. It also depends on if we use standard components (which might already have the animation) or if we have to build it ourselves.
Thanks for these mocks! I think mcomella's answered your questions above before I got a chance to :P
Here are some questions of mine (these are mostly further than v3.0):
This is great! Let's summarize the questions/feedback:
Overscan?
Good point, I changed the layout to include the 5% overscan recommendation.
I also did some research in order to understand what could be a good navigation pattern for this feed.
I presented these explorations during design critique and collected some feedback - which I will share after, I don't want to bias anyone 🙂 What's your take on that? (Read the picture per rows, so 4 rows = 4 possible approaches). @lime124 also in reply to your comment on Slack.
Awkwardly big?
On Fire TV YouTube displays 3 full thumbs and 1 very cropped thumb. On Apple TV/Android TV the YouTube app display 3 fulls thumbs plus 2 very cropped thumb on the left/right side. Seen this in context would you still find it awkward? We could also try to fit 4 full thumb and see how it looks, if there's too much space above/below the feed or if not. Actually let me try that, I will post a mock first thing tomorrow morning CEST.
Thumbnails?
I dunno how large are the thumbnails returned by the API, can we verify that? Right now the layout features a 528x296dp thumb when focused and 480x270dp when not focused.
TV-optimized website?
Since the content is and will be video-heavy I don't foresee the website going much far from this design. Similarly as streaming/videos websites I believe that we will continue to use similar patterns and components even if the technology underneath changes. @liuche did you have something different in mind?
Where videos come from?
In theory, the Pocket API already pulls videos from everywhere – it's possible 1) Pocket is not categorizing video pages well so it is missing some that might be videos (e.g. a NY times article that is primarily a video) or 2) users are only Pocket'ing videos that are Youtube videos.
Can we investigate if it's either option 1) or 2)?
Action on tile?
The current and only action is Select and if triggered it directs you to the YouTube website.
By default, we'll open the URL directly but I think we should try to rewrite YouTube URLs to youtube.com/tv urls if possible. Would you agree?
Yes, we just have to be careful that users understand that it's another website and not an app. @lime124 also in reply to your comment on Slack.
What is Pocket?
This is a very good point. It depends on how we introduce the Pocket tile in the homesceen, @lime124? I will also touch base with the New Tab folks in order to understand how they introduce Pocket recommendation in about:newtab.
I hope I didn't miss anything, if yes ping me. Thank you all for the feedback, this is really valuable and very appreciated!
Conceptually, rows 3 or 4 make the most sense to me: you see where you've been and what's in the future. This is what youtube.com/tv does. fwiw, the Fire TV homescreen does row 2.
I think it's hard to say without trying to use it, however.
I was actually concerned about it being awkwardly tall but...
On Apple TV/Android TV the YouTube app display
But it seems everyone else does this and it looks fine so wfm. 😄
Can we investigate if it's either option 1) or 2)?
I added this to our questions for Pocket, #771.
It actually looks like there's a parameter to the images. By default, they're 450px width but we can choose whatever size we want (I'll double-check this is true in the pocket questions).
@liuche and @mcomella -- I'm a bit confused, while I love the detailed video feed page, I assume we agreed last week to not ship the list view in 3.0 due to concerns about efforts and our set time frame.
Also by shipping this minimalist MVP -- do people even care clicking on this, would be absolutely enough from a product perspective.
Please let me know.
Meeting with Tif, Amin, Chenxia, Mike on April 12, we've confirmed the following
Feed List
Mike to confirm which UI/implementation is easiest after talking to Amin and will post decision here
The leanback ListRowView
widget does implementation 3/4: it starts on the left but always highlights the center view while scrolling. (I'd post a video but I can't get one on the emulator). Thus, this will be the easiest to implement.
Thanks @mcomella. So this is how it might look. From left to right: first card, second card - which is center in the screen, third card+n - centered in screen -, and last card.
How do you usually get specs/redlines? Do you and @liuche have any preference?
How do you usually get specs/redlines? Do you and @liuche have any preference?
Antlam and Bram used to do things like this: https://cloud.githubusercontent.com/assets/51007/23636057/40ddc66a-0338-11e7-95ae-ae330c77e70f.png I find it helpful because it disambiguates the provided dimensions rather than using text like, "This box should be Xdp".
That being said, I'm not not opposed to trying new things! I noticed that Sketch has a measurement tool so screenshots of a design tool are fine, or even just getting the mocks in the design tool itself (assuming there isn't a huge fee for us to use it) and letting us extract the measurements could actually be ideal.
@aminalhazwani What options do you have and how much effort is it to put them together? I've never actually had this conversation and I want to minimize the work for both of us! This seems like it might be better in a Slack/Vidyo conversation so feel free to ping me if you want to talk!
Hi there, I'm Peter Cho, the head of design at Pocket. @liuche just invited me. Great to see this work in progress and excited to see videos from Pocket getting sent to this new experience.
For reference, our coral brand color is: #EF4056, and here is the SVG for the Pocket mark. LogoPocket_96.svg.zip
A couple things I'd like to call out:
Are we settled on calling this section "Pocket Videos"? To me, it suggests that Pocket is the source/creator of the videos, and we should be clear that it's a recommendation source, not a video provider. I know it also says "Recommended" below, but I think users may still be confused. Maybe: "Popular Videos from Pocket"? Or, maybe the top says just "Pocket" and the Recommended heading says "Recommended videos." I'm sure there are other solutions out there too that could work better. I agree a 'What's this?' could be helpful.
In terms of the interaction of the selection 'window' with the sequence of items, I prefer having the window stay in the far left position, and move to the center or right only when the far right edge of the list is on the screen. I think it might be helpful to have a design principle when making decisions like this, and I think a good one would be to allow users to have as much context as possible on what else is coming in the list.
Here the link to the inspectable mocks https://firefoxux.github.io/people/aalhazwani/firefox-for-fire-tv/pocket-video-feed/index.html#artboard0, feel free to ping me if something is not clear nor possible to implement!
Edit: changed the link and using github tag for versioning instead
Thanks for the feedback, Peter!
Are we settled on calling this section "Pocket Videos"?
@aminalhazwani Have you talked to Brian about the copy on this screen?
In terms of the interaction of the selection 'window' with the sequence of items, I prefer having the window stay in the far left position, and move to the center or right only when the far right edge of the list is on the screen.
We decided that in the short-term, we're going to do the approach that centers the tile when there is content on either side due to time constraints (the built-in Android component does this by default). If this is unacceptable (or a bad decision for some reason), please let us know!
Here the link to the inspectable mocks
@aminalhazwani The values in here are specified in px, not dp (despite being labelled as such): 1080p devices are at a 2x multiplier (they're xhdpi) so all of the values in here need to be divided by 2. I'll do that locally so I can keep developing. :)
@pchocho Do you happen to have a Pocket SVG asset without built-in padding? The built-in padding makes it really hard to make the size/padding during implementation match the mocks.
@aminalhazwani as the mocks get finalized, can you post the most up-to-date version into the first comment? That way all the mocks will be at the top once development starts.
Thanks for the feedback @pchocho! I changed the header to only say "Pocket" and the label to say "Recommended videos". For the logotype I've been using Roboto. If you can share with us the Pocket logotype we can include that as well!
@mcomella yes, let me ping @BrianNJones for strings and copy review. Brian I will create a card on the UX Content Project Trello board!
Edit: Brian here the link to the Trello card https://trello.com/c/1itKe6eJ/71-strings-for-pocket-video-feed-on-fire-tv feel free to dismiss it if it's not necessary!
@mcomella I updated the pocket feed mocks. Now the specs are set by default to XHDPI, you can change the resolution by clicking the inspector in the top right corner. Changing the resolution will also change the units from sp/dp to px proportionally.
@mcomella regarding you question on the Pocket logo, let me know if this new SVG helps you: pocket-logo.svg.zip
Edit: logo and wordmark from Peter pocket_logo_wordmark.svg.zip
@liuche I update the first comment with the most recent links to mocks for both the homescreen with pocket tile and the pocket feed. fyi the homescreen includes new things I've been working on like the focus state and new button states. should I add those changes to #690 or somewhere else?
Here is the Pocket logo with wordmark (without padding). The spacing and sizing is a lockup, so please use this asset if you plan to use the the symbol and text at the top together. (Also, in case you notice, this wordmark is a new version that was redrawn in February, and we'll be rolling out replacements of the current mark in our products shortly.) Thanks!
@aminalhazwani just keeping all the deliverables in this bug is fine - that way there's only one place to look (and for UX to have to remember to update).
@pchocho Thanks for the asset. How do you typically handle localization of the wordmark? Is it always in english/latin script?
It's a brand name, and not localized, always in English/Latin script.
@aminalhazwani I noticed we're use #FFFFFF for the Pocket logo/wordmark and #F9F9FA for other white. However, Tif mentioned that we should primarily use "tv_white" instead of #FFFFFF, which is #eeeeee. Should any of these values be "tv_white" instead?
@mcomella I updated the mocks in order to remove any instance of full white #ffffff
. For small real estates I am using Grey 10 #f9f9fa
and for larger real estates Grey 20 #ededF0
. I tested on the TV here in the office and it looks good. Let me know what do you think!
Once Tif is back I am going to ask her more about the new #eeeeee
because it is very very similar to the Photon Grey 20.
hey @mcomella, after talking with @shorlander we decided to opt for a softer active card style, a focus ring instead of the white background, I updated the inspector with the latest specs https://firefoxux.github.io/people/aalhazwani/firefox-for-fire-tv/pocket-video-feed/index.html
I noticed that with the focus ring is not possible to inspect the content of an active card, for that you can use a previous version that I exported w/o the focus ring.
Edit: posting a screenshot so that also who read only the issue can see how things now look.
@aminalhazwani , following up on 3 of your string questions:
Title of the view, currently "Pocket" Concern is that users may have no context for understanding what Pocket is and why it’s showing up unbidden in their feed. Firefox for Desktop offers both a 1-sentence basic description and a link to https://help.getpocket.com/article/1142-firefox-new-tab-recommendations-faq Guessing it would adds a tremendous amount of complexity, but what similar affordances can we add to Firefox for Fire TV? The Firefox for Desktop title (“Recommended by Pocket”) at least offers a hint of context: what is this Pocket thing that’s recommending stuff?
Title of the feed, currently "Recommended videos" Don’t think we can solve this until we solve the title.
Card label, currently "New" if it's a new video pulled in the feed, or "Watched" if a video has been already watched What would you think about eliminating “Watched” and simply having “New” signal unwatched content? Let “new” signal both “seen” and “unseen” and not asking users to use a tiny fraction of cognition recognizing “new” vs. “watched.”
@aminalhazwani @BrianNJones thanks for working on the strings! So we have time to get strings localized, would it be possible to get the strings we need by the end of this week, or early next week so we can do a string export next week for the localization team? I filed #829 with a loose checklist.
@aminalhazwani fwiw, I don't know how hard the focus ring will be to implement, especially the double layer of rounded corners: I'll need to get back to you after I play around with it. fwiw, the more time we spend changing the focus style, the less time we have for other features and polish :) so let me know what your priorities are (but maybe this is my fault for implementing it so early?).
To be explicit, I don't want to make the decision just yet of, "This is too hard!" and I want us to come to a conclusion together about what is the best use of our time. :)
@BrianNJones thanks for all the feedback!
Concern is that users may have no context for understanding what Pocket is and why it’s showing up unbidden in their feed.
That was my concern too. This is why I opened #828. We can leverage the extended real estate and introduce the pocket mega tile right where and when users will see it for the first time. What do you think? For the copy we could use/modify what we already have on desktop - without the personalization aspect - and ask the pocket people to create a page for video recommendations on the Pocket FAQ that we can link to, how you see that?
What would you think about eliminating “Watched” and simply having “New” signal unwatched content?
I agree, good point! Let me update the mocks!
@mcomella
I don't know how hard the focus ring will be to implement, especially the double layer of rounded corners
If it requires more time than estimated we can add the focus ring in a later release. Since we already have the zoom, the change of the card background, the motion, and the change of the thumb and title I believe we can add the focus ring later.
Also this addition can be part of a bigger polish where we bring the same focus state across the whole app.
@bbinto @mcomella @liuche I would like to share with you a concern that I have about the homescreen. I initially polished and adapted the original mockups that were designed during the workweek.
So right now we have a row of primary and secondary buttons plus the brand. A row for the search bar, the pocket mega tile, and the default tiles.
While this might look ok at launch I noticed how it's not clear which buttons are related to the webiste (back, forward, reload, pin) and which are unrelated (settings, history, turbo mode), eg getting back to the homescreen from a website.
So I started to think how we could better layout the different functionalities so that proximity and relation can help users understand which elements are connected to which button.
In this proposal I combined the search bar with the back, forward, reload and pin button. Separated the settings from the main navigation, removed the brand and hid the turbo mode that with this approach will be moved to the settings page.
Combining the two first rows gives us more real estate and allow us to better separate the navigation from the pocket mega tile/default titles area. For future features - eg history - we could think about a bottom navigation that always lives below the default tiles. Beside that, I have some questions:
Thanks!
Thanks for surfacing this! I think separating these two out make sense and I really like it! (and makes it easier to mentally group these actions - left: navigation, right: pinning). This actually also makes it easier for us to have a single row, removing the hint, etc.
My concerns would be:
Putting Firefox on the homescreen is mainly for brand recognition
Yeah, consider that we should keep getting credit for bringing open web video to the TV. Looking how Netflix and Hulu treat their brands on Fire TV are good examples (a splash screen with a sound, persistent in the content selection screens, and in some cases, even on top of video content for shows they produce). If the logo is taking up too much 2D space, maybe we can consider overlays (like the TV network bug that appears in the lower right of video content) and/or brand appearing/disappearing based on states of the UI(?)
Combining the two first rows gives us more real estate
I really like this one, but would we have to drop the logo, too? URL field is usually way too long, and entry happens most of the time (if not always) in the keyboard overlay; users could still see the first part of the URL and then some anyway, right? Room for the Firefox logo probably wouldn't steal anything human-readable, most of the time (video IDs many times are just random characters).
@aminalhazwani To be clear, if we can't do the focus ring, you'd prefer if the highlighted card looked like this:
and not this:
My current plan is to implement it using the first implementation and filing a follow-up to manage the focus ring, if we have time (e.g. UX polish days).
To be clear, if we can't do the focus ring, you'd prefer if the highlighted card [...]
@mcomella we can opt for the dark card. The ring is an extra enhancement because when a card is highlighted we already have a change in: background, title font weight, size, and the motion that helps user understands which card is the active one.
Generally what do you think?
I like it a lot.
Is there a specific reason for having the brand on the homescreen?
Anywhere else we could put the logo? I'll leave it up to @porfitron to confirm the necessity of the logo and where.
How feasible is all of this? Yeah, what do the engineers think, @mcomella and @liuche
What are the next steps, can we agree on something?
@liuche @porfitron thank you for sharing your feedback and concerns!
I see good and valid reasons for keeping both the brand and the turbo mode, so I started to explore possible alternatives that would not affect those two elements.
We could remove the Firefox word mark and keep only the logo. This will still maintain visible space and separation between navigation features and app features.
Or with the full logo + word mark it would look like this (in the example below back/forward are inactive, reload and settings have a default state, turbo mode and pin have an active state, and the url bar is focused)
I like the wordmark with text, since it's more clear that it's there for identity, vs. a UI element that does something.
I have a feeling if it were just the icon, people might try to press it on it.
These look great! Can't wait to see these on my TV.
On Fri, Apr 20, 2018 at 6:22 AM, Amin Al Hazwani notifications@github.com wrote:
@liuche https://github.com/liuche @porfitron https://github.com/porfitron thank you for sharing your feedback and concerns!
I see good and valid reasons for keeping both the brand and the turbo mode, so I started to explore possible alternatives that would not affect those two elements.
We could remove the Firefox word mark and keep only the logo. This will still maintain visible space and separation between navigation features and app features.
[image: homescreen v5] https://user-images.githubusercontent.com/1721875/39052701-2b88f6d8-44ad-11e8-86fe-d31c0cfba975.png
Or with the full logo + word mark it would look like this (in the example below back/forward are inactive, reload and settings have a default state, turbo mode and pin have an active state, and the url bar is focused)
[image: screen shot 2018-04-20 at 3 09 47 pm] https://user-images.githubusercontent.com/1721875/39052781-6925b38c-44ad-11e8-8bdf-43fe2f1e1af7.png
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mozilla-mobile/firefox-tv/issues/759#issuecomment-383094227, or mute the thread https://github.com/notifications/unsubscribe-auth/AFe51MxYr8YNSOkWDRfGbTMjxXR7Cq7wks5tqeEigaJpZM4THgry .
-- Porfirio Landeros Director of Product Marketing Mozilla, San Francisco
FYI: I get a performance warning when using the Pocket + wordmark SVG asset (nothing is noticeable on device, however). I filed https://github.com/mozilla-mobile/firefox-tv/issues/848 to follow-up.
@aminalhazwani the #eeeeee is the android guidelines for what to replace white with. i don't have a problem using an existing photon color that's close to that (as long as it's not more white/brighter).
Regarding combining the rows... I agree with porfirio that if it were just a circle it would look too much like a button and I also agree that it's important to keep our branding here for the same reasons previously mentioned.
I do love gaining more real estate vertically and keeping all the chrome to a single row but I worry that it's starting to look a bit busy and becoming hard to parse things at a glance. I'm also unsure how this would expand to incorporate new things like "request desktop site" (a future feature that would allow people to toggle between mobile and desktop depending on what breaks and how).
If the pocket tile is removed (another future feature) it's not as clear that when I hit the down button, what tile is going to be selected.
We could potentially move settings down with history but that only gives us one "spot" back and doesn't help with the busyness. I'm also worried about how this might pan out in practice. With our 5-way nav a floating footer doesn't really work. The items would have to be appended to the underneath the last row of pinned content - which is going be off screen and hidden.
Returning to the original post from Amin and getting back to what are we trying to solve - better visual grouping to reduce confusion- the issue/confusion point I see is that the URL bar is spanning across the entire page which lends you to group settings and history with the URL bar as well as the navigational/page type items. The original intent was for the bar to NOT span the whole page but be much shorter so that history and settings visually and mentally remain separated from the other grouping.
A bit more context behind the original intent, turbo mode impacts the page, how it looks and how it loads, which is why it was grouped with other page related actions. The URL bar was placed on the 2nd row below so that it was a single click to either get to the back button or to the first row of content.
@lime124 thanks for the feedback, the rationale behind the first iteration now is much more clear. I updated the mocks to reflect what said above.
I took notes of what Tif wrote and started to explore possible future iteration of the homescreen in order to have a more cohesive experience - after v3.0 of course.
If https://github.com/mozilla-mobile/firefox-tv/issues/829#issuecomment-384679571, we started a discussion about megatile error handling.
If there's an error in the homescreen, what's missing? Only the video thumbs or the whole mega tile?
@aminalhazwani Whichever you want! Which do you prefer?
If there's an error, we just won't have thumbnails to show so we'll need a 1) loading state and 2) the error state (after some timeout – 5 seconds? 10?). Note that the way data retrieval works, if the user gets successful data once for this run of the application (we lose the data on restart), they will never see a loading or error screen again (except for the images popping in since we retrieve them independent of the pocket data).
@mcomella I did some explorations on how the loading and error handlign of the pocket mega tile might look.
On startup we could draw the pocket megatile and add loading placeholders for the pocket video thumbs. We could animate those thumbs so that we help users understand that something is happening. I was reading about animating gradients or transition drawables. This can be part of a later polish but let's talk more later today.
If we fail to retrieve the thumbs we could display a message that notifies the users that something went wrong on our end.
I understand that setting the label of the button to "Try again" is not ideal. Let's talk more later today about what our options are.
Anyhow I updated the mocks/specs linked in the first comment of this issue.
Spoke with Amin and Brian on Vidyo:
@aminalhazwani For the pocket megatile, how round should the corners be? I can't find it in the mock.
@mcomella border radius of the pocket mega tile is 32px/16dp. I found out that if you apply a border radius with a mask Sketch Measure do not output it, I filed a bug on their repo.
Animations: home screen thumbnails will fade between two gradient images and on feed, will fade between gradient cards. Amin to provide assets
@mcomella I pushed the animation assets here. I am using three images, one with a gradient left to right, one with a gradient right to left and one without gradient as a base. The animation could be even more smooth with a fourth image but I wanted to touch base first with you and hear what you think.
At the same link you also find three examples, one for the pocket mega tile placeholder thumb, one for the highlighted placeholder card, and one for the non-highlighted placeholder card.
All the images are stored here. I pasted the same links in the first comment as well.
We'll talk more next week about how to transition from "loading" states to "error" states
I don't think we need a transition nor animation here. It's an edge case that can live without a smooth change.
@aminalhazwani How should the overlay scroll when selecting multiple tiles? Currently, we do this:
But using the same method doesn't seem to work great anymore (pardon the WIP spacing):
border radius of the pocket mega tile is 32px/16dp.
@aminalhazwani What about the thumbnails? 4dp looks about right...
Information Architecture
Homescreen
Strings
Pocket Feed
Strings
Pocket assets
#ef4056
Loading Placeholders
Pocket Megatile