Tablet/landscape support

[tsiemens]

We are currently locked to portrait. Layouts need to be modified so they display correctly in wider views.

Extra tablet layouts should be added in some cases, to make better use of space such as

• Most list rows should be extended to either show more per row
• Add info to fill space, like the first line of item/spell/feat descriptions

[samcorcoran]

I added a line to allow auto-rotation based on orientation, and initiated a pull-request for it (#22) before I remembered that there were other changes necessary for landscape support (adjusting aesthetics to cope with wider rows etc). You are welcome to ignore/decline the pull request if you feel auto-rotation should not be included until these aesthetic changes have been made.

Did you intend for 'tablet layouts' to be a selectable option somewhere within the application ('Settings'?), or a process that automatically detects the width of the screen (due to landscape view, or larger devices) and alters layouts accordingly?

[samcorcoran]

Some notes on problems and changes for various UIs that may be necessary for comfortable navigation on landscape screens. I compiled this list while viewing the existing UI rotated to landscape orientation on a Nexus 10.

Characters>Combat Stats:

• Problem: Fields (e.g. modifier fields) are closely spaced to fit them on small screens. On wide screens they are bunched up, with lots of wasted space to the right.
• Solution: Spreading fields out over entire width would look bad, but increasing the spacing between fields may be better. This spacing could be made to range, from its current narrow spacing to some desirable maximum, based on screen width.
• Side-note: Contents of fields (e.g. modifier fields) could be centred within that field for better visual balance.

Characters>Abilities:

• Problem: Column names of variable fields (e.g. Score and Temp Bonus) are aligned centrally, but the contents of those fields are left-aligned. On large/landscape screens this creates a large x-dimension difference between these values and their column name, which makes them hard to read.
• Solution: Centre-align editable fields.

Characters>Skills:

• Problem: 'Ability Mod' field contains relevant Ability (e.g. DEX) and the modifier given by the character's ability score (e.g. 4), each of which is left and right aligned respectively within the column. On wide screens and landscape views this creates a large space between the two which ensures neither line up with the column name.
• Solution: Right-align ability name and left-align ability mod.

Characters>Weapons/Armor:

• Problem: On wide or landscape screens, properties do spread out to fill horizontal space as their fields take up a proportion of the screen width. However, for particularly wide screens (e.g. landscape tablets) there is plenty of space to place more properties on each row.
• Solution: Perhaps arrange fields into columns (enforcing vertical alignment to keep properties neater than current layout), with the number of columns being determined by screen width divided by a fixed column width.
• Note: Columns to enforce vertical alignment may be tidier anyway, however if a screen is wide enough to warrant three properties on a single row then it probably is large enough not to desperately need vertical screen real-estate either, so making each set of properties more compact may not be important. Additionally, changing the relative order/layout of properties may make it less easy for users to read quickly.

Characters>Feats/Spells:

• Problem: Both feats and spells have description sections which may contain a lot of information, but are hidden due to lack of space on small screens. On wide/landscape tablet screens the short names of the spells/feats take up little room, leaving vast empty space on right side which could be used.
• Solution: If screen width exceeds a threshold, give name column a maximum width (names which exceed this will become multi-line, as they currently do on small screens), and user remainder of line as a 'short description' field. This could be populated with a) the first line of the description field or b) contents of a separate, short, fixed length "Brief description" field which users could specifically use to give themselves quick, condensed reminders of the feat/spells effects

Initiative Tracker>Party Member Editor:

• Problem: Field names are short and left aligned, which field values are short and right aligned, causing both to be very far away from each other. (Same problem as with Characters>Fluff page). This can be hard to read and creates a lot of unattractive empty space in centre of screen (or rather, majority of it).
• Solution: Field values could be left-aligned (which may just create excessive empty space on right hand side...) or centre-aligned. Either way, all values should be vertically aligned with each other (i.e. not pulled out of alignment according to the length of their field names).
• Solution 2: Alternatively, multiple fields could be displayed per-row, using a columnar layout. This would need to be fixed per device, though, as rotating the device from portrait to landscape shouldn't not re-order fields as this could be confusing (as was mentioned as a downside for weapon/armor properties with variable column numbers). If calculation for number of columns was performed using the width of the shorted dimension (i.e. portrait width) then only devices wide enough to accommodate multiple columns in either orientation would do so. This would remove the discontinuity users would experience when rotating their devices (though there would still be discontinuity between devices of different sizes).

Party Skill Checker:

• Problem: If names are short, loads of empty space is left on the right.
• Solution: For particularly wide screens, this space could be populated with character information relevant to the character (e.g. perception skill, disguise skill etc.). To avoid discontinuity, decision to display such information should be based on shortest dimension (i.e. portait width) to ensure that it can be displayed at either orientation.
• Solution 2: Some other information about the character could be displayed. This may be a good idea if the Party character system is merged with the general Character system, as details such as 'class' could be shown here.

Party Manager:

• Problem: When names are short, lots of space is left on the right-hand side.
• Solution: If screen is detected as large, this could be filled with some useful information. As mentioned in above note about Party Skill Checker, if Party representation of character is merged with general Character representation then this area could display some useful information about the character, such as class.

Pointbuy Calculator:

• Problem: On small screens, "+" and "-" buttons are small and square, but on large/landscape tablet screens they stretch horizontally while all other fields (i.e. ability, score, racial mod, final score and mod columns) remain the same width (only as wide as their contents). This horizontal stretching of buttons (combined with the vertical stretching that also occurs) the buttons look quite silly and the information is hard to read.
• Solution: Place a maximum width on buttons, possibly equal to their height. Maybe include a maximum height (even if the row stretches to be taller than it). Allow other columns to stretch horizontally/spread out to fill the space the smaller buttons will create.
• Problem: Race selection field is expanded to be extremely large (full row height, full device width) when viewed on a large screen.
• Solution: Apply a maximum width (and maybe height also). Field should perhaps be vertically centred. Moving it to to top of the screen may help it be obvious (and may be a more logical place for it anyway, considering that it has an effect on the values displayed elsewhere on the page).

[samcorcoran]

Of the above, alignment changes for "Characters>Abilities" and "Characters>Skills" are quite important for readability, as is the button size issue on the "Pointbuy Calculator".

Spacing changes for "Characters>Combat Stats" would make for a more comfortable experience on wider screens.

These are probably quite important to provide for tablet users, but will be especially important for any release that allows screen rotation from device orientation.

[samcorcoran]

tsiemens, I wanted to make the spinners on the "Abilities" page center their content by setting their gravity to "center", but it turns out they already contain that. The entries are aligned to the left, despite this.

Any idea what can be changed to fix the gravity and line the spinner text up with the columns?

[tsiemens]

You'll need to make a new layout, which is based off android.R.layout.simple_spinner_item (currently being used there). There is probably an android attribute you will need to use as the base style. See spinner_plain.xml as an example.

[samcorcoran]

Thanks for the tip!

My repo's branch "issue7_tabletLandscapeSupport" now contains changes that:

• Enables view rotation with device orientation (through layout changes)
• Gives Characters>Skills ability type and mod a smaller distance between them
• Prevents point buy calculator +/- button widths expanding too much
• Centers text in spinners on abilities view so they align with columns better
• Centers text in pointbuy calculator race selector to make spinner more obvious on large screens
• Misc Fix: Inventory items names constrained to being singleLine (as inventory is only displaying first line of name anyway)
• Misc Fix: Centred combat stats values within their textviews for better visual balance
• Misc Fix: Added (more) top padding for combat stats +,- and / symbols, to align them with the values of their corresponding text fields

I wanted to increase the width of the combat stats page '+' symbols, conditional on screen size. From what I understand, the right way to handle this would be to have a separate tablet-friendly character_combat_stats_fragment.xml, placed in res/layout-large/ directory.

Does this mean that the whole layout file would have to be duplicated just to add some tablet-specific tweaks? Because that seems excessive. Perhaps there is a route that involves more layout code re-use?

[tsiemens]

You can avoid duplicating layouts by using attributes and dimensions. See http://developer.android.com/guide/topics/resources/providing-resources.html for how to make files for different screen sizes.

[samcorcoran]

In regards to tablet layout (such as adding brief/summary information next to spell names in the spell ui), would the preferred condition to use perhaps be:

A) availableWidth: rotating the device to landscape will make the conditional fields appear B) smallestWidth: device must be large enough to accomomdate fields in portrait mode in order to make conditional fields appear C) Something else?

Option A might allow larger phones to make use of the additional information when in landscape, and reduce the amount of vacant screen space they display. However it also means that fields would be appearing and disappearing as a user re-orients their device, which could be frustrating/confusing ("Where have my spell notes gone - they were there just a moment ago!") which would be avoided by Option B.

Thoughts?

Also, do you think having a separate 'brief description' (single line, character limited) is a useful addition to spells and feats - to be used in this instance of displaying on the main spell ui, but also just as a place to write a very compact note on how to use the spell? Players might think to use the first line of the description for that sort of thing, but a 'brief description' field would make it more explicit.

If they don't fill in the 'brief description' field then the first line of the full description could be used for the tablet ui note instead.

[tsiemens]

For now, I think it should be fine to keep it simple and go for smallest width. Optional fields can maybe be introduced in a later iteration if requested.

[samcorcoran]

My branch issue7_tabletlandscapeIssues now also contains changes which:

• Screen width dependent horizontal spacing on combat stats page (3 graduations)
• Added selectAllOnFocus on EditText fields throughout app (combat stats, arm or and weapon editors) for easier touch screen interaction
• Fluff page appends values to edit dialogue fields instead of setting them to place cursor at end of content instead of beginning
• Added vertical spacing to multiple editor fragments (spell, feat, item, weapon, armor) to space out cramped elements on all screens (but improving large screens particularly)
• Armour weight can now be a decimal
• Reworked armor and weapon editor layouts to make labels and fields meet at exactly halfway, as previous design was drifting fields too far right which was particularly apparent on wide screens
• Added a centred spinner layout and used it throughout the app
• Added description fields to spell book and feat list rows for large screens (sw720) which occupy a max 50% of width and display as much of the first line of the spell/feat description field as will fit

This concludes the tablet/landscape changes I wanted to make (and I fitted in your suggestions too, tsiemens)

Some of the changes bundled in here are general aesthetic changes which seemed generally sensible while I was trying to consider what would improve the tablet experience. Hopefully you'll agree with them.

Unless you have any further suggestions I would consider this branch and work finished and ready for merging. Take a look and see what you think!

[samcorcoran]

Forgot to mention another change:

• Tidied layouts for weapon and armour fields in list view so they more cleanly separate into columns