Dynamic / Mobile Friendly UI (Manage Posts)

[JohnONolan]

User story: https://github.com/TryGhost/Ghost/wiki/Manage-Posts-%28Mobile%29

If you go to the posts overview screen and resize your browser to about 600px wide - media queries will kick in and give you a mobile/tablet view of the page.

At the moment this is just done with CSS, and it doesn't actually work if you subsequently click on anything. What should happen is an iOS style animation: you tap one of the posts in the list and the whole list panel slides off to the left, and the post slides in from the right.

Should we use backbone for this? Or something like Ratchet?

We need to create a basic model here that can be re-used in various places. I've included some designs below for reference.

/cc @tgriesser @ricardobeat

[JohnONolan]

@matthojo - The tap based stuff is all very good, we don't need any of the swipe based stuff (shouldn't be adding swipe interactions "just cos we can") so that should all come out.

Can you look at adding in the "back" button in place of the menu button - per the designs above?

[ErisDS]

I've assigned this to @sethvincent now that the interactions are cleaned up as he is interested in helping us improve the mobile UI.

The next step is adding the "back" button in place of the menu as shown in the designs.

[M165437]

@JohnONolan - To warm up I worked on the settings forms yesterday, the mobile friendly version. I have some questions though.

First a general one: How autonomic am I about decisions regarding my changes/additions? Would you like to be involved in every plan on how I'm going to solve the issues? I imagine you're busy with your own tasks, at the same time I don't have a feeling yet about how strict of a plan you guys have for the code.

For example, the already defined breakpoints don't fit well for the forms. I'd like to keep the desktop design for tablets (labels on the left) and switch to the mobile design (labels on top) when the width falls below the desktop’s form width (around 550px vs. the mobile breakpoint at 400px). Is it ok to add another breakpoint or should I stick to the ones defined? Of course it doesn't need to be a centrally defined breakpoint (mixins.scss) but could be one "on the fly" too: @include breakpoint(550px).

Another one: As it is now, at the mobile breakpoint the padding around the white content section disappears. In your designs the mobile version keeps this padding. A bug or a conscious decision to get rid of the padding? What about the darker field titles in your mobile designs? Am I too picky here? :-)

Appreciate your help.

[JohnONolan]

Hello!

How autonomic am I about decisions regarding my changes/additions?

I guess the best approach is to start somewhere with a PR and we can discuss from there. It's easier to discuss code once you've had a go at something than conceptually before you write it. Generally speaking though, you can see what's there / what style it's written in - and from you comment above it sounds like the approach you're thinking about is spot on.

Of course it doesn't need to be a centrally defined breakpoint (mixins.scss) but could be one "on the fly" too: @include breakpoint(550px).

Exactly what I was going to suggest, so, yep, +1

As it is now, at the mobile breakpoint the padding around the white content section disappears. In your designs the mobile version keeps this padding. A bug or a conscious decision to get rid of the padding?

Definitely not too picky. I dropped the padding primarily for the editor screen - where it makes sense - but I didn't even really start to properly look at or test the settings screens. If it feels like it works - I'd rather keep a bit of padding. One of those things where it needs to be tested on the actual device to see if it feels right.

[nicoburns]

Question: which mobile browsers are we supporting?

I can probably help with some of this, but the above makes a big difference to how it's approached.

[JohnONolan]

Current -1 for every vendor.

So, IE9+

[nicoburns]

Makes sense, but how does this work with regard to android? Do we support 4.3 and 4.2 (the latest 2 android versions) or 4.x and 3.x (as 4.x all share the same browser), or 4.x and 2.3 (as 3.x has virtually 0 market share while 2.3 has quite a lot).

[nicoburns]

Or are we just expecting android users to use Chrome or Firefox?

[JohnONolan]

@nicoburns we'll play it by ear - at the moment the focus is on getting Ghost out the door.