Develop new UI for Nearby item view pane, to include Upload option

[misaochan]

In our implementation of #252 , we need to think about where the "upload image for this item" button will be, and in the process figure out if the existing Nearby item UI needs to be overhauled.

Options:

1. We leave the current UI mostly as it is, but replace one of the two bottom navigation buttons (probably "read article") with "upload image"
2. We design a different viewpane for Nearby items (perhaps taking inspiration from @psh 's suggestions at Overhaul media details view pane #873 )
3. We keep the viewpane simple, where the user would just use that as a platform to launch a new fragment with more details and options for that Nearby item

I am personally leaning towards Option 2, but would love to get more input/suggestions.

[neslihanturan]

It seems to me like the discussion in #873 is about media detail view instead of nearby items. To apply such thing to nearby, we might need to open each items details on new screens. Since nearby items doesn't have photos to display, it would be an empty page with nearby options. Thus my vote is for option 1, partially.

I think it can be better if we protect both read article and get directions buttons and add "add photo icon" like:

What do you think?

[misaochan]

To clarify, I didn't mean that we should follow the suggestions at #873 verbatim, just that perhaps we could consider incorporating elements of the suggestions there into our design here. Alternatively, I think Google Map pins are very similar to our Nearby items, so if we study how they handle their item details pane, we could perhaps use elements of that to improve our current one.

I also think that we need to think about how the current Nearby item viewpane looks with the Nearby list (as opposed to just with the map). As seen in the screenshot above, it overlaps part of the list, which isn't a design that is commonly used - I think we might want to see if there is a way to work around that.

[misaochan]

Edit: I just did a bit of further reading, and it seems that the technically correct term for what I'm talking about is a "bottom sheet", not a "viewpane" - https://material.io/guidelines/components/bottom-sheets.html#bottom-sheets-usage

Sorry for the confusion!

[misaochan]

Oh, sorry @neslihanturan , I also realized I didn't answer your question, lol. That looks quite good if we go with Option 1. :) It would be nice to have a few different possibilities to choose from though. Not urgent, we can start the wireframes in the next phase (2 weeks from now I believe?). I'm just asking early so we can get input from others before you start wireframing.

[neslihanturan]

I prepared that wireframe just to visualise our discussion. It is not my offer, actually. I will search to find a better solution according to your comments:)

[psh]

Google maps has a lot of good content in a very small space. Comparing the non-expanded Google Maps footer with our "nearby" map, I think it's equivalent in terms of content shown:

What's nice is the FAB - a clear call to action for taking a photo in our case.

The footer is hidden until you tap on something of interest. I think that would be pretty reasonable to implement in the Commons app. What I like is the smooth expansion (fairly standard bottom sheet behavior) in Google Maps:

But the side-scrolling information cards are another nice feature. They benefit from great pictures but the floating card concept is pretty easy to implement:

Have we considered the idea of simply expanding (and collapsing) the list items in place when a user taps on them - its within the bounds of reason looking at the Material Design spec.

[neslihanturan]

I like implementing a small footer with FAB icon. But I think making map view user friendly is an easier task than list view. I prepared some screenshots from google map.

As you see, they change whole screen when list element is selected. We can use half page footers with map view as suggested above, but it doesn't seem appropriate with list view. I have two suggestions for listview:
1- Since our nearby places doesn't have images, if we change whole screen it will be a very empty screen. So, we can place to upper half of the page map view with only selected item, current position and the path between them displayed. Bottom halt of the page can display informations about page etc.
2- We can use expanded list view elements. And we can expand it on click, and display the same thing we display currently on our bottom sheet.

[psh]

It sounds like the switch between "map" and "list" is more about expanding and collapsing the map; in "list" mode its about 1/2 the screen and in "map" mode its the whole screen. Like the "fullscreen" button when watching a video online.

[misaochan]

@psh I agree, using a FAB for camera would be awesome! (I suppose in this context it would make sense to prioritize camera over gallery, gallery can go elsewhere). For the Nearby Map, the expansion of the bottom sheet (from compact to detailed) would be great, too. Definitely makes much more sense than a separate activity/fragment.

I'm not sure if the side-scrolling info cards are feasible for our scope this round, but it could be a future enhancement. :)

@neslihanturan Yeah, for the Nearby List I would personally go with Option 2 that you mentioned, expanding the list view element in place. I don't think we need to handle the list the same way Google maps does... I might suggest something like the style below, perhaps? (with material design of course, the screenshot isn't very aesthetically-pleasing, haha)

[psh]

What I think I am hearing - map mode is a map that fills the whole view, and list mode is now a hybrid 50/50 split of list items and map:

When an item is selected on the map, we show a footer (this used to be a floating bubble which covered the map display)

and if you tap on the footer, it expands to show more detail about the selected place:

The fully-expanded footer is (basically) also the view you would see if you tapped to expand an item in the list. I would expect that the back button would "close" and return you to either the map with footer or to the list of items (depending on where you were).

(Note: I might have made the FAB a little large in these mockups, but you get the idea)

[neslihanturan]

Hmm, so we should decide something:

1. Do we want to change our switching mechanism between map and list (separated screen as @psh and me mentioned above)?
   Advantages of new mechanism:

• User is able to switch between them easier and faster. Easier to see names of places by list (without clicking to map), and see distances and directions by map without switching screens.
  Disadvantages:
• I think it looks complicated when both list and detailed information comes from bottom in almost same shape.

By the way I totally agree displaying detailed information with FAB camera icon on map. However, when I think about our use case, expanding list view on list looked to me a little problematic.

1. Click on nearby activity from nav drawer
2. Look at to the list, choose rather close nearby place to go and upload photo
3. Click on list element, and see camera button before directions (you need to do one more extra click to get directions)

This UI would only work when you are in front of the nearby place. Thus, I think since nearby is one of our most important feature, its UI requires more brain storming. We can even consider a fundamental change.

[misaochan]

Hmm, so we should decide something:

Do we want to change our switching mechanism between map and list (separated screen as @psh and me mentioned above)?
Advantages of new mechanism:
User is able to switch between them easier and faster. Easier to see names of places by list (without clicking to map), and see distances and directions by map without switching screens.
Disadvantages:
I think it looks complicated when both list and detailed information comes from bottom in almost same shape.

Yeah, good question. I agree with you re: the advantages and disadvantages. Another potential disadvantage of the hybrid view is that I'm not sure how it will look like on very small and low-res screens - might be worth checking out how Google Maps handles those.

But on the other hand, another potential advantage is that it makes it simpler to do away with the map-to-list switch icon. Remember that with the new UI in #725 , Nearby will be on a tab alongside Contributions, so the current location of the icon (action bar) would likely not be appropriate anymore. If we go with the hybrid view, that solves the problem instantly. (Although then we are left with the problem of how to display the refresh option)

Would be great if others could chime in. :)

Click on list element, and see camera button before directions (you need to do one more extra click to get directions)

I think if people are using the map to find the closest place, they may not often use the "directions" option since the nearest place would be very close by. This would be especially true once we implement real-time user location on the Nearby map.

[neslihanturan]

I liked hybrid view more, when @misaochan make us remember new UI plans. It really solves one of our problem.

[neslihanturan]

According to our discussion, needs and material standards, I have prepared something. I am not sure about some points so your feedback is highly appreciated.

[misaochan]

@neslihanturan Nice! In general it looks good to me, I especially like the camera FAB and the clean look. :). For the map, I'm not sure about having "show list" on the bottom left of the bottom sheet after the item is selected though (middle right screenshot). But admittedly, without it, it would be trickier to switch between list and map. And for the expanded bottom sheet (top right screenshot), I think we could improve on the layout of the buttons, I'm not sure we want them on all 4 corners.

The list looks great to me in terms of layout, although I am not sure if the color scheme of the expanded list item (bottom right screenshot) conforms to Material standards?

Would be great to hear input from others, too.

[psh]

I am liking the direction this is going, liking it a lot. 👍

Another way to think about showing or hiding the list of items is to look at the one screen having 3 states - All Map, Hybrid (1/2 map / 1/2 list) and All List. That is, from the perspective of just the size of the map, 100% / 50% / 0%. What if we had two small buttons to "maximize" and "minimize" the map display located at the bottom right side of the map.

This feels a lot like how I interact with YouTube, where I have the video at the top with scrolling details below but there is a "full screen" button to bounce the video up to its 100% size, with a similar button to toggle back to 50% again.

Recent versions of YouTube have a nice "picture in picture" view where your currently running video is minimized but still playing while looking at other content:

I am wondering how it might look if we had a little floating map display when the map was minimized (that is, list was at 100%) If you tap the map and it restores to hybrid (50%) again.

[neslihanturan]

Hmm actually Youtube's left bottom corner generally disturbs me, but I am probably an old fashion user. I think it can be too much accessibility if we use "picture in picture" and "hybrid view" together. But we can consider using only picture in picture thing too:)

[maskaravivek]

@neslihanturan Great work with the mock up. Am very excited to imagine how our app would look after we implement this. :)
I am planning to handle the interaction once someone clicks this upload button with the proposal in #950. A common flow can handle the upload interactions in both the cases.

[misaochan]

@maskaravivek Good point. We actually do need to discuss how to handle the choice of Camera vs Gallery as well. In the UI aspect, a few of the options are:

1. Expanding the FAB to "Camera" and "Gallery" buttons when tapped, similar to the planned overhaul of ContributionsActivity at Main screen UI overhaul #725 (and if we do this, we need to figure out how to get it to work for the Nearby List as well, which doesn't have a FAB)
2. A dialog similar to the screenshot at Implement upload button to allow the user to select Camera or Gallery #950
3. Having the camera button as the FAB and the "gallery" button only in the expanded item view.

Personally, I would actually be in favour of option 3, because my thoughts were that the main purpose of direct uploads is a continuous workflow - go to the place via our map, take the item, upload it. But @nicolas-raoul and @neslihanturan brought up a good point at #591 about people wanting to take photos first and then upload later (when at home, with wifi etc), so it's possible that option 1 or 2 would be a better bet for those people.

[neslihanturan]

My vote is for option 1, and adding a gallery button to our nearby list design.

[misaochan]

My vote is for option 1, and adding a gallery button to our nearby list design.

This sounds good to me, too.

[neslihanturan]

According to feedbacks and our new needs, mockups are redesigned:

1- For listview, selected grey tone is appropriate to material specs and upload button is added:

2- Option 1 for details view,

• Flat buttons are changed icons to make them more visible.
• Upload option is added with expanded FAB button.
• An extra FAB button is added to show list.
  

3- Option 2 for details view,
-Flat buttons are changed with raised buttons to make them more visible.
-Upload option is added with expanded FAB button

• Using an extra FAB is not recommended according to material docs when they are not equally important. So we can choose SHOW LIST flat button as in first mockups, using default back button (no extra accesibility for list) or using extra FAB button no matter what docs says:)

Waiting your feedbacks.

[misaochan]

Looks great to me, @neslihanturan ! 👍 I would personally go with Option 1 for the detailed view.

Anyone else, please feel free to offer feedback/suggestions too. :) We plan to start implementation next week. @VojtechDostal @nicolas-raoul @tobias47n9e

[neslihanturan]

Hi everyone, since I am implementing our chosen design, I have some questions about best practices. Currently I am working on hybrid map-list view, colapsed nearby details view and expanded nearby details view.
I decided to use a bottom sheet to display listview so that user can expand it to whole screen or hide completely by swiping. For nearby details, I decided to use another bottom sheet.

Logically nearby details bottom sheet should be a modal bottom sheet, because it is actually a dialog. And user can hide it by clicking back button. However, modal bottom sheets get focus (since they are modal). I think semi transparent whole screen would look improper when nearby details bottom sheet is collapsed, user should be able to click other markers on the map at the same time. So there can be 2 solutions:
1- Use a bottom sheet for colapsed view, and a modal one for expanded nearby details sheet.
2- Use the same non-modal bottom sheet for both purposes (by expanding and collapsing it) and handle back button explicitly.
Which one would you prefer? My vote is for 2 by the way.

[misaochan]

Tagging @psh or anyone else familiar with Android UI development? :)

[psh]

@neslihanturan - I really like where your design is taking us!

Couple of questions about the list view -

• In your list view, is it possible to expand more than one card to show the buttons?
• What does your design look like in landscape mode or on a tablet - is the goal to take the items from "... more" and put them into the buttons?
• I'm not sure what the top and bottom shadows are trying to communicate on the expanded card. Is the idea that the buttons are in a layer "below" the cards for individual list items? What does the list item look like if the row gains elevation and the options are part of the expanded card itself?

For the detail view -

• I like the flat buttons with icons (option 1) - I like that you have a common look and feel with the list view
• Definitely go with the non-modal, persistent bottom sheet (your option 2 that you prefer) - set the peek height to be how big you want the footer, and you can register a BottomSheetCallback to have Android tell you when the sheet is expanding / collapsing to know if you should show/hide the "more info" bar (or even do something cool and tie its alpha to the slideOffset in the onSlide callback)

[neslihanturan]

Hi @psh , answers for your questions:

• No, only one card
• Yes we can fit all buttons
• Yes, I wanted to make them look like they are on below layer.

For controlling states:
Actually firstly I implemented a bottom sheet state control by using if-elses and visibilities with bottom sheet callback. However, later it seemed to me badly organised and confusing. Later, I decided to use state design pattern by defining ColapsedListView->ExpandedListView->ColapsedDetailledView->ExpandedDetailledView as nextState, and going reverse, to previous state, by back button. But, I am not sure if it simplifies the design or makes it even more complicated:) Please share your comment after my PR as a experienced developer @psh .