Drop down menu - content does not fit on small screen

[nemback]

Our standard drop down component does not fit the content when using native.

Below is an example from our ongoing project Extra amortizing.

When long account names are used or the amount is very high the content does not fit. So at no point the user can see the entire account information.

We use a component that relies on the current operating system. So iOS opens its native menu (Safari) and Android (Google) its native and so on. The functionality will first be implemented in the app and then on iBP. This is built like a web component inside the app shell.

We are thinking on having a smaller font size on smaller screens, but there is a limit to how small we can go of course.

[ulde01]

We didn't have time to discuss this today so I am adding a few people here, that might have a point of view to share? @splashdust @hjalmers @henrikhoglundseb @conandx @didzis

[ghost]

@nemback Not sure I understand what you mean. Our standard vs native dropdown, is there a difference in space for text? Or is your question if it is ok to use a smaller size on the text?

[mzemlickis]

Could we have another shorter copy/text for mobile? Numbers could be shortened, as you see very start is same for all three dropdown items.

[nemback]

I think the main question is this:

When we use native, unstyled drop downs we will have situations where the content will not fit into the selector.

We used a code snippet called and a variable called text-size-adjust to lower the font size when the menu is opened. This happened after I posted the original.

Is the solution to not use unstyled, native drop downs?

For the situation posted above, the three alternatives have the same wording in the beginning. This is probably due to test data. The actual content is more diverse. If we are going to start removing, shortening and manipulating the content then we need research to know which parts in the content is most important for recognition.

Attached is the current opened menu selector on iOS.

This is not an actual account name but a test with long names.

[ulde01]

@didzisspruds do you have any input? Thanks!

[conandx]

Just a quick thought... If we are making custom built dropdowns and not using native... could we perhaps use double-rows and multiple columns in the content...?

Sort of like this: (ugly axure-sketch)

This way we can maintain full controll and shorten data where it suits us in each case.

[henrikhoglundseb]

I think its fine with smaller text on the native picker. As long as the hitaria is the same. In this example is there 573 milion kronor, a long accountname and the account number. I would see that the less info if possible in the picker.

But in "normal" instances will it be fine since this is a nichecase

I would still use the native picker when building a hybrid native app.

[ghost]

@nemback Let’s talk IRL Maybe a slot in the Coaching? Or just invite to a small talk! Who wants to join?

[axelgarciahenriksson]

I guess we will continue to run into this problem a lot.

Have we considered using the same design pattern as we do in the private app for choosing accounts (at least when registering a payment)? So - on small screens, do not use the native picker, do not use a drop down, but use a screen-wide list of accounts. Then, in extreme cases these list items can be made in several rows like Conny’s sketch.

In private web for mobile, making payments mixes two patterns: to show a custom list, from show a native picker.

Do we have test data showing which pattern customers prefer?

Axel

---

Axel Garcia Henriksson Customer Experience Designer +46 70 762 10 35

31 jan. 2019 kl. 12:14 skrev Henrik Höglund notifications@github.com<mailto:notifications@github.com>:

I think its fine with smaller text on the native picker. As long as the hitaria is the same. In this example is there 573 milion kronor, a long accountname and the account number. I would see that the less info if possible in the picker.

But in "normal" instances will it be fine since this is a nichecase

I would still use the native picker when building a hybrid native app.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/sebgroup/design-library/issues/28#issuecomment-459307243, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AihS80G54X5DuPMQRUVZnyEIZUuBad5Kks5vItACgaJpZM4aVy4h.

[hjalmers]

Since the behaviour of native selects on mobile devices (like in web browsers) is a bit inconsistent across devices and browsers we've previously opted against using them as we can't really control how they behave or work. We often prefer native to be consistent with other user interfaces running on iOS and Android respectively, but if you look at most modern web apps/sites today (airbnb, momondo, paypal, apple.com etc. just to mention a few) none of them use native selects for selecting options in a list, dates etc. I would assume one of the main reasons being the lack of control these elements provide. Take for instance the possibility to provide typeahead together with an account list. It would probably make sense to let to user type either the account name or account number to filter the list of available accounts. We've actually implemented this for our FX application when dealing with currencies, the user could either select a currency from the dropdown or start typing to filter the list in realtime, pretty much like this example (just took the first example found on google). The benefit is that it's really easy to customize the behaviour and optimize it for specific use cases. Like with accounts where you probably want to do something like @conandx proposed https://github.com/sebgroup/design-library/issues/28#issuecomment-459282435, account name on one row and the number on the next perhaps?

We used to have more examples on the link below including typeahead etc. https://sebgroup.github.io/bootstrap/dropdowns (they have a custom behaviour on small screens i.e. smartphones). I'll see if I can't add some more examples including one for accounts leveraging multiple rows and typeahead which I think would be useful too:)

Since you're using react you'd have to come up with something similar yourselves I'm afraid. Might be that Mohsen has created something similar in his react library otherwise it would probably be pretty easy to just to create a custom theme for some other library (like we do with bootstrap). Another option would also be to use web components as angular now has built in support to convert angular components into pure web components. We're using the later approach for the Arena Shell, where your app eventually will end up too I hope:)

[ghost]

@nemback Are you ok with the answers you got? We will close this for now. So come back to us irl 😄if you need to talk more! /Jes.

[hjalmers]

So what's our standpoint, native or not?

[ghost]

@henrikhoglundseb Can you answer?

[nemback]

Thanks for all the interesting viewpoints!

We will keep it native for now but might change it later when we have a styled option.

[henrikhoglundseb]

I would recomend to keep it native in this context. I don’t see a problem with a native picker in the native app.

Sent from my iPhone

On 7 Feb 2019, at 08:59, nemback notifications@github.com<mailto:notifications@github.com> wrote:

Thanks for all the interesting viewpoints!

We will keep it native for now but might change it later when we have a styled option.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/sebgroup/design-library/issues/28#issuecomment-461321061, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AscDj7COM_0qYwsRAY5YWn1wqo-DSXCnks5vK9z2gaJpZM4aVy4h.