When writing a SMS the display does not rotate to landscape mode. This is a BIG loss of usability, because the buttons in portrait mode are to small to write SMS comfortably

this was reported by operator during IOT. Nominating it for leo?

This is by design.

@tchung : could you give any good reason for that ? People really like to type in landscape mode as they can use both hands!

Can anyone estimate how risky is to include this modification? I do think it is very important in terms of usability of messaging app.

(In reply to Beatriz Rodríguez [:brg] from comment #4) > Can anyone estimate how risky is to include this modification? I do think it > is very important in terms of usability of messaging app. It would require doing a lot of visual design rework. As seen in the app manifest, the current implementation of the SMS app is designed to only handle portrait mode. So it's probably a high risk change. Now that I rethink about this - this is a valid bug, but we cannot do this in the leo timeframe. Supporting landscape mode is at the level of a feature.

I'm not sure why this was reopened, but tchung's closing was correct: There is no wireframe, or visual spec that has ever mentioned or illustrated landscape mode.

(In reply to Rick Waldron from comment #6) > I'm not sure why this was reopened, but tchung's closing was correct: There > is no wireframe, or visual spec that has ever mentioned or illustrated > landscape mode. Because this is a feature request to support landscape mode. We just haven't created UX specs for this. I do think this is a valid feature request.

I'd vote for this feature to be added as well, I've thick fingers and landscape mode with bigger buttons is much better/precise for me... (and for many other people as well, I'm sure...)

Hi, If it's not possible to include this for leo, what about doing it at least for koi? Nominating koi? for discussion. Thanks! David

UX will check and feedback

For this bug, I propose to let the Compose area take the full available height when the on-screen keyboard is active. Keeping a “Back” button would require another bug (and a UX mock-up).

I feel like it's too late for 1.2 now.

I think this is part of the work the System FE team is doing in regard of the refactor of Building Blocks. I myself already started working in adapting the visuals to landscape, being the proposed solution to automatically decrease the height of fixed components, like headers, a 25% in order to leave enough room for the user to see messages and be able to scroll on the active area when the keyboard is displayed. But the layout of the SMS app should remain the same, no matter it's in portrait or landscape. Ismael, Arnau and Pavel are working in the BB refactor to add this behavior, so i don't know if that's a blocker in order to solve this bug? Find attached a screenshots of the SMS app in portrait and landscape.

The work that we are doing in the Building Blocks refactor includes landscape support for the components. The problem is that the refactor is not going to land Gaia in v1.2 so if this is a blocker, we may try to get an ad-hoc aproximation inside SMS app instead of relying in the Building Blocks for this issue. The code is already ready for the headers.css, so it might be only to copy+paste to the SMS app for that component.

BTW: As i've said there are some work done for the headers.css in the refactor, is just a matter to link this file[1] and re-adapt the new selectors with the ones that are in shared/style/headers.css [1] https://github.com/mozilla-b2g/Gaia-UI-Building-Blocks/blob/325f840ea213bcbb3d018ec6886211b22ec1abb1/style/headers/responsive.css

For usability we think we could move to the intermediate solution. Borja, could you take it and talk to kaze and Ismael ?

Im going to take this and try to deliver a temporal solution, because with new BB this should be fixed! I'll attach the proposal today

Comment on attachment 800039 [details] Pull request The code seems ok, but i'm worry about the !important usage, can we avoid it?

Ok, I have tested this patch and from a UX PoV unfortunately we are not in a position to implement this on the device yet. There are several concerns related to the wider environment that this functionality will be introduced into that, at the moment, make it highly undesirable: 1) Orientation of related apps / facilities I am noting that certain apps and facilities that can be launched from the message app whilst it is in landscape mode launch only in portrait mode. For example if the user selects to add an attachment to a message the Gallery opens in landscape but all other apps open in portrait. More pressingly if the user is on the new message screen in landscape mode and select to add a contact to the 'to field' from the contact list, the contact list opens in Portrait mode. This particularly is a massive UX issue. 2) Transitions The transitions within the message app as it goes between Portrait and Landscape mode (and visa versa), the transitions of the message app when it is in landscape mode and the transitions when the message app is in Landscape mode and is going to and coming from external apps which are only available in Portrait mode (such as the apps used when attaching a file to a message) are completely inadequate and make the phone seem broken. 3) Inefficient use of space It is not sufficient to simply orientate an interface designed for Portrait into Landscape or an interface designed for Landscape into Portrait. Both Landscape and Portrait afford different spacial opportunities and constraints. Therefore in order to maintain a reasonable standard of UX the layout, presentation and often presence of the components of a screen require revaluation when the screen is taken from Landscape into Portrait and visa versa. For example the new message screen is reasonably efficient in terms of UX in portrait mode, but in landscape mode the header becomes 'dumb' and eats a vast amount of real-estate on the Y axis meanwhile the message field (the most important field on the is screen) into which the user composes their message looses real estate in the Y axis and had its usability greatly handicapped, particularly when the user adds attachments. 4) no way to lock the device in portrait mode If we are going to have landscape mode functionality we absolutely need functionality to lock the phone in portrait mode and so to prevent it from going accidentally into landscape mode. Overall point 1), 2) and 3) make the message app feel extremely odd and disjointed when actively used in Landscape mode. Coupled together with the fact that the user cannot lock the phone in Portrait mode (thus blocking themselves from experiencing the problems of 1), 2) and 3)) are more than enough to advise not to land this until the environment is aligned: related apps support landscape mode (specifically contacts), transitions into and within landscape mode are correctly defined and implemented and the screen content / layout of the message app is evaluated and tuned to provide an adequate UX whilst it is in Landscape mode. The bottom line from ux pov is that the user can still send and receive messages whether the phone is in landscape or portrait. There is absolutely no added benefit of landscape except a bigger target area on the keyboard. However this sole benefit is well and truly negated by the negative points i detailed above.

I've thinking of an alternative way. Fact 1: moving to landscape/portrait using the phone orientation is annoying and frustrating, except in specific apps like Gallery, Video, and maybe Browser. (note: this is subjective) Fact 2: in apps where we need an user text input, the user triggers the landscape mode to gain screen space to compose a text input. Therefore, here is a proposal. I don't know if this doable and I'm flagging Rudy for this. * we'd have a new action on the keyboard. This action could be triggered by a new button, or by longpressing the "layouy configuration" button and displaying a menu, or whatever the UX thinks is good. * this action would trigger what I call "poor man's landscape mode". This "poor man's landscape mode" would be handled entirely by the keyboard app. * poor man's landscape mode: + the idea is to edit the currently focussed control + the keyboard app would take the whole screen, forcing landscape mode + upper part of the screen would be a textarea, with the text that is in the focussed control when the user triggered the poor man's landscape mode + lower part of the screen would be the keyboard + when the user has finished editing the control, he can press a button on the keyboard to indicate he's finished. We can imagine having also a "next" button to get the next text control in the page, if existing. We should probably send the usual events (see last point) before editing the next control though. + while the user edits text in this mode, no event will be sent to the page. Everything happens as if we're in an external editor, (and we actually are), like [1] for example. + when user exits this mode, the usual events are being sent, and the page reacts. [1] https://addons.mozilla.org/fr/firefox/addon/texto/ * advantages: + it's all in one app, there is no need to add support in all applications + all applications benefit automatically Rudy, do you think this is doable ? Ayman, what do you think of this plan ?

Sounds like an interesting proposal, and I really think this is reasonable, since I remember I have seen similar UX on Android, but not sure if that still prevail. My only concern would be how to trigger this behavior, as your mentioned: >> This action could be triggered by a new button, or by longpressing the "layout configuration" button and displaying a menu, So this button would live in each app? Right now keyboard app would be launched by clicking on an input field, so the trigger point from my point of view should live within the input field, like adding an (new) attribute to it to require the system to show the landscape keyboard for it. Or we should let Gaia system's keyboard manager to decide to show landscape keyboard when the orientation is in landscape mode. I am not sure of how Android design around this, so we might need some UX study before implementing this. Thanks.

My idea of the typical user actions: * focus the input => the keyboard is displayed in portrait mode * tap a button on the keyboard => the keyboard switches to landscape mode * the user edits the text * the user taps the "finish" button on the keyboard => the keyboard switches back to portrait mode I think moving in keyboard's landscape mode automatically depending on the orientation would be weird, because the application itself would not be in landscape mode.

hey guys from a UX pov it is undesirable to automatically switch the view to landscape based on user interaction with the keyboard or our switch to portrait based on keyboard close. I am happy to explore alternative methods of entering Landscape mode (other than orientation of phone) ..but the user has to have absolute control over it.

Ayman> but otherwise, what are your comments about comment 21 ? What is the path forward ?

This feature has been added to the comms "nice to have" list for v1.3 (Bug 920625)

Comment on attachment 800039 [details] Pull request Christmas cleaning, clearing the f? flag.

I think this should be a system-wise issue - Orientation. And should not be limited to message only.

Currently we have no guidelines for landscape building blocks. We can plan to do it in the next UX refresh.

My view here is still comment 23.

Firefox OS is not being worked on