Mobile Interface

[GoogleCodeExporter]

We have an iPhone-specific interface, but it would be really slick if we
could generalize it to work on all mobile devices. It would be even slicker
if it could make use of the current OO view classes rather than standing alone.

It could, perhaps, take advantage of some slick HTML 5 features for modern
mobile devices that support them.

Original issue reported on code.google.com by ian.gree...@gmail.com on 6 Apr 2010 at 10:57

[GoogleCodeExporter]

Original comment by ian.gree...@gmail.com on 6 Apr 2010 at 11:51

[GoogleCodeExporter]

Add some thoughts on mobile. Hoping to spark a bit of conversation.

(Do we have any data about current mobile usage on plans?)

There are many directions to go.
1) There could be an app.
2) There could be mobile styles.
3) There could be responsive styles.
4) And there's http://grinnellplans.com/iphone/ which doesn't work at all on my 
android device.

Looking at these options:
a) An app seems like a lot of work.
b) I think it's unreasonable to ask stylesheet authors to make every theme 
responsive.
c) I think it would suck to force people to use particular themes on a desktop 
just to have a nice mobile style.

So that leaves me thinking that having an official plans mobile stylesheet (at 
least for a while) makes a lot of sense. Maybe it would be opt-in or maybe 
there would be a separate "custom mobile style" preference that would override 
the default style? (With that preference, people could put a responsivee 
stylesheet in both the custom style and custom mobile style preferences.) I'm 
all about flexibility, but it seems like under the current set of 
circumstances, it will be hard to give a majority of people a good mobile 
experience without forcing some kind of new default setting.

What do other people think about this? I'm fairly comfortable on how the 
HTML/CSS portion of this would work, but I don't know what would be required to 
get this working on the current or future ruby-based versions.

Original comment by rootwi...@gmail.com on 20 Dec 2011 at 2:08

[GoogleCodeExporter]

I think this is a good idea. At least for the PHP version, it wouldn't be hard 
to detect when someone is using a mobile device, and send a different 
stylesheet to them; we could use a cookie or a database flag to allow people to 
opt out (e.g. if they've selected a responsive stylesheet)

Other considerations: we may want to override the edit box size on mobile 
devices to ensure it's not ridiculously huge. 

Original comment by a...@alexcohn.com on 20 Dec 2011 at 2:20

[GoogleCodeExporter]

+1 for just making a good responsive stylesheet and always serving that to 
mobile clients. Usability is so much more important than chrome once you're on 
a small screen, I doubt anyone will be seriously unhappy. The good news is that 
Plans is so lightweight, we probably won't need to change much else about what 
we're serving up besides the CSS.

And yeah, HTML is definitely the way to go. I'd like to provide a full-featured 
API, and if people want to build (and maintain) device-specific clients they're 
certainly welcome to. But Plans "core" can provide a good experience to ~all 
devices by only maintaining an HTML5 interface, so I think that's the clear 
winner.

Original comment by ian.gree...@gmail.com on 20 Dec 2011 at 3:25

[GoogleCodeExporter]

I think it would be great to (for now?) add a mobile stylesheet option to the 
settings. Then, we have authors note whether or not the theme has a mobile 
version.

I agree with [rootwile] on points a, b, and c, though an app could be cool.

Original comment by dsdobrzy...@gmail.com on 20 Dec 2011 at 4:27

[GoogleCodeExporter]

Ok. Well in that case, maybe this will become my winter break project. I might 
have comps and be looking for feedback in a week or two. I have this idea for a 
sweet mobile stylesheet I've been wanting to try, and plans would be perfect 
for it.

I'm also hoping to recruit [kellylor] (she doesn't know this yet) to help with 
the UX portion because she's a professional.

Original comment by rootwi...@gmail.com on 20 Dec 2011 at 7:19

[GoogleCodeExporter]

mobile stylesheet++, with a suggestion to the implementors to allow the user to 
see the standard site (a "Full Site" link at the bottom, for example). 
Detection isn't perfect, and sometimes it sucks to be on a tablet forced to a 
mobile stylesheet.

Mark, if kellylor doesn't bite, you should reach out to 
[erbveron]/@verbistheword. She's also a UX professional. 

Original comment by eryn.oneil@gmail.com on 20 Dec 2011 at 10:11

[GoogleCodeExporter]

[kellylor] and I met to discuss plans mobile with [breenpet] as a 
more-than-able peanut gallery...I mean one-man focus group.

We talked about a lot of stuff and here are some highlights.
* Thinking that we should leave iPads/tablets with desktop styles if possible.
* People should always be able to quickly jump from the plan body to both their 
autoread list and the menu. (Exposing the edit plan link might also be good and 
encourage people to post more to plans from mobile.)
* To do this, every option we came up with needs to have `position: fixed;` 
elements attached to the viewport (probably the top).
* Sadly, on mobile fixed positioning is going to require javascript and a lot 
of testing.
* Lorelei's working on sketches, but our basic thought right now is to keep 
things simple: just have Heading, Plan Body, Autoread, Menu going straight down 
the page and then using targets/anchors (possibly with animated scrolling) to 
get there. (I had played with some fancier, slide-y, scroll-y, crap but they 
all just didn't feel good.)
* It may be best to expose all three levels of autoread at once, but we can 
discuss that more.
* For many reasons, we thought that it might be worth not supporting Notes on 
mobile, at least for the first release.
* For plan updating, it would be really nice to have a buttons that inserted 
the most common tags ([date],<hr>,,<i>) as they're a pain to type. As far as I 
know, keyboard customization isn't really where it needs to be for that to be 
an option.

Original comment by rootwi...@gmail.com on 21 Jan 2012 at 1:36

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Disregard my original comment; I hadn't carefully read this ticket.

It'd be amazing if a mobile stylesheet can make Plans more usable on mobile 
browsers.

Original comment by thatha7777 on 21 Jan 2012 at 1:56

[GoogleCodeExporter]

I've attached some wireframes of the main interface ideas [rootwile] and I 
discussed, with some relatively minor adjustments, mainly the autoread lists in 
columns and the "back to top" buttons. We could have people toggle the autoread 
lists open/closed on mobile the way they are on the desktop interface, but I 
think they should stay in columns either way, to minimize screen jumping. Let 
us know what you think! 

Original comment by otc.iele...@gmail.com on 26 Jan 2012 at 12:29

Attachments:

• mobile-plans-2.png
• mobile-plans.png
• mobile-plans-3.png

[GoogleCodeExporter]

Lorelei, these look great!

A few questions/thoughts/ideas:
* Did you consider have a fixed "back to top" button in the lower right corner? 
Could be nice.
* I worry whether we can get three columns of easily clickable links, but we 
should try it. That would be very nice and compact if possible.

I'm still digging the idea of targets/anchors for implementing this, but it 
just occurred to me that we'll probably want to prevent the hash-extensions on 
URLs so that the back button doesn't get hijacked. Does that sound right to 
other people?

This is a great start. Unless someone else wants to do it, I'll probably try to 
throw together a desktop prototype in the next week or two.

I also think if people have particular ideas for graphic styles, this is a good 
time to get them out there. I'm leaning toward minimal, high contrast, low 
colors, etc.

Original comment by j...@unsectored.net on 26 Jan 2012 at 4:21

[GoogleCodeExporter]

This looks great! And (I'm guessing you thought about this) doable with a few 
very minor HTML changes.

Jeff, I'm not sure what you mean about hijacking the Back button. It seems like 
hitting Back after visiting autoread should return you to your previous 
position in the page, which AFAIK is the default behavior with targets.

Lorelei, are those buttons along the bottom just the defaul iPhone browser 
buttons?

Original comment by ian.gree...@gmail.com on 26 Jan 2012 at 6:49

[GoogleCodeExporter]

Wow. That was odd. Let it be know that jeff@unsectored.net was Mark Root-Wiley, 
who usually logs in as rootwiley@gmail.com. The fun of having access to 
multiple google accounts...

Ian, regarding the back button, I was thinking about a scenario it which 
someone might click "autoread," "back to top," "menu," "back to top" or 
something like that. At that point, it would take hitting the back button 5 
times to get to the previous page. Is that really what we want. (Yes, that is 
the default behavior, I'm just not sure it's right in this case.)

Original comment by rootwi...@gmail.com on 26 Jan 2012 at 7:06

[GoogleCodeExporter]

Hmmm, I can see that being undesired. OTOH, I'm imagining this scenario: I'm 
reading someone's plan. Suddenly, I want to see if someone else has updated, so 
I hit "autoread" and check. No new updates, so I want to go back to reading, so 
I hit the back button.

I'm drawing parallels in my mind between this behavior and what the Back button 
does in native Android apps (I have little experience with iOS). If I open up a 
preferences menu in Adnroid, then hit Back, I get returned to whatever screen I 
was on when I opened the menu.

Original comment by ian.gree...@gmail.com on 26 Jan 2012 at 9:09

[GoogleCodeExporter]

Yes. I'm very torn (which probably pushes me toward leaving the default).  BUT! 
One more point/question/idea:

Not to get too abstract, but I think this kind of comes down to what mental 
model we have of this. Is it a multi-screen app that's built in a browser or is 
it just a single web page with targets?

I think the multi-screen app approach means we'd leave targets in the history. 
But the single page would suggest we strip them out.

One idea I had had was to use javascript smooth scrolling so that it would make 
it clear to people that they were staying on a single page and just moving up 
and down. Lorelei and I both agreed that this would help teach people that if 
they want, they can just scroll to the bottom of the page to access autoread 
and menu. So if there's a back to top link (that replaces the use of the back 
button in your hypothetical), does that remove the need for the back button or 
should we provide redundant functionality (maybe we should)?

Original comment by rootwi...@gmail.com on 26 Jan 2012 at 9:53

[GoogleCodeExporter]

I really like the idea of using JS for smooth scrolling. Overall, I really like 
the design. Unfortunately, I'm not a smart phone user, so can't say much to 
that aspect. :(

Original comment by dsdobrzy...@gmail.com on 27 Jan 2012 at 5:09

[GoogleCodeExporter]

This looks really great!

The only thing I have an immediate opinion on is fixing the top header, my vote 
is to set it to fixed in CSS and forgo javascript attempts. iOS supports fixed 
now and newer versions of android too (http://caniuse.com/css-fixed). 
Basically, I don't like the experience of the javascript fixes where it trails 
and then catches up when you stop scrolling -- I would prefer no fixed position 
at all to that. If you can implement javascript that really fixes it then go 
for it, but if it's nasty I say stick to the standard CSS. Just my opinion. 
Excited for this to be out!

Original comment by GrantCus...@gmail.com on 27 Jan 2012 at 5:33

[GoogleCodeExporter]

Grant, I can only speak for myself, but I'm with you completely. When I talk 
about using JS for fixed, I intend it _only_ in the "polyfill" sense, trying to 
make up for bad browser support.

Original comment by rootwi...@gmail.com on 27 Jan 2012 at 5:57

[GoogleCodeExporter]

Hey everyone, thanks for the feedback! 

Mark:
- I'm wary of putting fixed buttons on the bottom because they'd be stacking on 
top of built-in buttons. It might be nice to have as a 4th button along the 
top, but I think on the whole people expect and are comfortable with large 
amounts of vertical scrolling on smartphones. This is total gut feeling though, 
I've been focused on native apps and haven't really looked for research on 
mobile web use patterns. My general preference is, the fewer fixed elements the 
better, but if we try this out and scrolling to the top of long plans is an 
issue, I think moving the in-page buttons to the top would work well.

Ian 
- Yes, the buttons along the bottom are standard mobile Safari buttons
- One wrinkle in the autoread/back button scenario you pose, at least with a 
design that exposes all the autoread levels at once, I don't think hitting the 
autoread button alone will reload the page. Maybe that's tangential to the 
question of targets in history, but I think it's a part of the mental model 
question Mark brings up. If we want people to think of this as a multipage 
"app," the autoread button should refresh to check for new updates, but if we 
want to emphasize the single-page model, it will be up to users to refresh the 
page manually. I'm also torn, because I tend to want webpages to act like 
webpages, but auto-refreshing would be more consistent with what happens right 
now on plans. 

For that decision what I'd really like is to sit some people down with a test 
version of the stylesheet and see what their expectations are, coming into it 
for the first time. Have we got some plans-using friends with smartphones who 
haven't been paying attention to this conversation? Peter's a contaminated 
sample at this point.

Grant, I'm with Mark - pure CSS would be ideal. But support for the ideal 
solution is...not ideal. Google came up with a javascript solution for gmail, 
though it's a lot more involved than the delayed-scroll js: 
http://code.google.com/mobile/articles/webapp_fixed_ui.html

Original comment by otc.iele...@gmail.com on 28 Jan 2012 at 12:27

[niqjohnson]

Nothing like reviving an eight-year-old issue, but here goes!

Like I ([johnsonn]) mentioned on Plans, I'm going to take a shot at creating a default mobile style for Plans. I know other people have been thinking about this, so I wanted to use this issue as a place for folks to discuss and keep an eye on progress.

Here's my rough plan for how to make this happen.

The first step is easy: add the missing <meta name="viewport"> element to make Plans responsive. I've already done that in views/templates/tableless/PlansPage.tpl.php on my fork. I'm not even going to deal with the legacy table design. One note here: adding that element will probably mess up existing custom stylesheets that people may be using on mobile, so we'll probably want to give folks a heads up that they may need to update their CSS if they want to keep using it after these changes launch.

Second, I want to add an option to the custom stylesheet preferences that's something like "Also use the custom stylesheet on mobile." The idea here is that, if you don't check that box, you'll get the default mobile style on screens smaller than a certain width. If you're happy with the responsiveness of your custom stylesheet, though, you can check that box, and we won't give you the default mobile styles. I've already put some of that infrastructure in place with changes in views/templates/tableless/PlansPage.tpl.php and functions-display.php. I'll work on adding the option to the models and the custom stylesheet form later.

Finally—and most importantly—I want to take another crack at designing a really great mobile interface. I hacked together something that was at least passable on small screens a few years ago in niqjohnson/plans-styles, but I don't love it. For one thing, I threw it together pretty quickly and didn't get to a lot of refinements I wanted to make. For another, I'm a better designer than I was three years ago, so I need to redeem myself. For another another, since that was a custom user stylesheet, I had to try to do everything in CSS, which made some things just not possible. My goal with these default styles is to make no markup changes and keep Javascript to a bare minimum, but I am planning to use at least a little JS to do some things that can't be done in pure CSS (like a good nav menu). For now, I added my old mobile styles in styles/mobile.css so I had something to start with, but I expect the final design to look almost nothing like that.

So that's the plan. I have zero timeline for carrying out the plan. I'm going to try to chip away at things over the next few weeks, and I'll post updates here if anyone wants to take a look. Please please please don't be shy about giving feedback; I'm a designer in my day job, too, and I much prefer collaboration to designing in isolation.

Here's what the mobile interface looks like with the changes I currently have in the mobile-styles branch of my fork:

I like almost nothing about this other than the big ol' button in the bottom right that takes you to the next plan on your autoread list, so a LOT is going to change.

[niqjohnson]

Progress! I started redesigning the mobile style from scratch with the reading a plan view. Here's what it looks like right now on my iPhone Xs:

Next up:

• Making some typography enhancements (like changing link colors from the default)
• Adding links to check quicklove and edit your plan to the sticky header
• Adding a hamburger menu to get to the rest of the nav links
• Adding the button to jump to the next plan in your auto-read list

[niqjohnson]

Whew, been a while since I gave an update. Mostly that's because I redesigned the stupid mobile menu like 900 times. Here's what I've done since last time:

• A mobile menu that I'm reasonably happy with; still a lot of tweaks to do there, but it's getting closer
• Refined the typography everywhere
• Designed the edit page

Here's what it's looking like now:

Still a ways to go, but I'm pretty happy with the progress so far. Here's what's next on my list:

• Make the icons. Right now the icons in the interface are just basic unicode symbols. I'd like to spruce those up substantially.
• Design the other screens. Quicklove/plans search and preferences are at the top of my list.
• Add the preference to use your custom stylesheet on mobile instead of the default mobile styles. I'm toying with the idea of also using that preference as a way to beta test the mobile styles at first, but I need to think about that more.

[iangreenleaf]

This is looking so good!

Thinking about integration… what sort of effect does <meta name="viewport"> have on existing stylesheets?

[niqjohnson]

Major breakthrough thanks to CSS pointer events and counters—the little button in the lower right that will jump you to the next plan in your autoread list now shows the name of the next plan and a count of how many unread plans you have in your list:

For real this time, I'm stopping on the mobile menu and moving on to styling some of the other screens. This is very exciting, though.

@iangreenleaf, that's a good question about what <meta name="viewport" content="width=device-width, initial-scale=1"> will do. On desktop-sized screens, it shouldn't do anything. Desktop browsers already set the viewport to the size of the browser window, so things will continue to work as they always have there. On mobile, though, this might affect folks who have a current custom stylesheet they like to use on their phone. Basically, without that property, mobile browsers will set the viewport width to somewhere between 800 and 1024 px and scale the page to fit in that viewport. With that property, mobile browsers will set the viewport to the actual width of the device, so screen size media queries in the CSS will kick in. That all means that someone who has a custom stylesheet that's working for them on mobile might have to make some updates to keep it working on mobile if they want to stick with it. But basically every site that's been touched since 2010 sets that property, so this should not be an unexpected change, and it's a change that's absolutely necessary to get good default mobile styles working. Given all that, it seems like a fair tradeoff to me.

[iangreenleaf]

@niqjohnson that sounds like an acceptable downside to me. The few stylesheets that do provide an acceptable mobile experience should be updateable to handle that change, and we'll mostly be serving this new style to mobile users anyways, so it shouldn't cause too much breakage.

[iangreenleaf]

Also, I love that little jump button.

[mrwweb]

I'm working on a new stylesheet and want it to work on my phone! Can we add <meta name="viewport" content="width=device-width, initial-scale=1">?

I have never actually contributed to Plans, but I'd be thrilled to figure out the pull request. Any objections or words of advice/caution before I start?

[acohn]

@mrwweb This shouldn't be a super difficult change, but I'm a bit concerned about breaking existing stylesheets. How do the built-in stylesheets handle it?

Because Plans has multiple interfaces, this change would need to be made in both /views/templates/tableless/PlansPage.tpl.php and /views/templates/legacy/PlansPage.tpl.php. I could make a case for only modifying the former file ("tableless"); anyone who's serious about a CSS stylesheet should be using that interface.

It could be possible to make this opt-in per stylesheet - maybe a string in the stylesheet URL that signifies "please send the meta name="viewport" header"? I don't know if that's a great idea, but thought I'd throw it out there as a way to minimize breakage.

[mrwweb]

@acohn I'll try to run some tests soon with a few default stylesheets. I like the idea of only serving that with the "tableless" interface which seems like a good compromise. If I had to guess the styles will go from "hard to use" to "hard to use, but different".

It could be possible to make this opt-in per stylesheet - maybe a string in the stylesheet URL that signifies "please send the meta name="viewport" header"? I don't know if that's a great idea, but thought I'd throw it out there as a way to minimize breakage.

My gut says that it makes sense to keep this as simple as possible. Having recently tried a few stylesheets on my phone, the experience is bad enough that I doubt this would actually be breaking much for anyone. But if we have any real stats on that, I'd love to know.

[iangreenleaf]

My vote is to set it on the tableless interface and just bite the bullet. I don't think we're doing ourselves any favors by leaving this out for a fairly tenuous backwards compatibility, and if any stylesheets do have issues, the folks on this thread can probably help figure out a fix.

[mrwweb]

I just did a bit of testing and I'm even more bullish on making this change now.

I think the worst case scenario is "broken in a new way but at least I can read it", while both Pastel Hell and Terminal get better on mobile with this change (all with the Postmodern interface).

I really can't imagine anyone is using plans in any meaningful way with the current lack of the meta tag. This seems to make it suddenly possible with the right stylesheets.

Pastel Hell

Before

After

Terminal

Before

After

Libre

Before

After

[niqjohnson]

@mrwweb, one other stylesheet you might want to check out is the responsive one I hacked together that a lot of people ended up using, https://niqjohnson.github.io/plans-styles/mobile/css/mobile.css. I was too lazy to introduce the viewport tag when I was slapping that together years ago, so I just worked around the lack of one. The easiest way turned out to be sizing almost everything with viewport units (e.g. --body-text-size: 4.5vmin;), which means the rendered size of almost everything will change once a viewport tag is present. I'm actually pretty impressed with my use of variables in the stylesheet, so in theory getting it looking good with a viewport tag shouldn't take much work, but just wanted to give you a heads up of something else that would be affected.

[mrwweb]

@niqjohnson Thanks for flagging that. I had missed that one. (You should add it to [css]!)

Test looks good! All my tests are in Firefox with device mode and just looking at the Styles page. It's very possible I missed some stuff, but I'm pretty sure this should be representative of real-life.

"Mobile"

Before

After

Plans Login Screen (for kicks)

Before

After

After with one CSS fix

img { max-width: 100%; }

[mrwweb]

New pull request with this change is now available.

Let me know if there's anything else I can do to get this ready for deployment.

[mrwweb]

Two notes on this ticket:

1. Should we close this issue?
   • Reason to close: the addition of the new meta attribute allows stylesheets to basically handle this
   • Reason to leave open: Any sort of normal interactions like drawers/toggles/etc. are CSS hacks which have to be re-invented for each stylesheet and are generally not accessible to screen readers / keyboard users. A new interface could come with JS for handling these things in a standard way and let stylesheets focus on styling rather than interactions.
2. I just opened Improve icons and add manifest to improve installing/mobile experience #299 which is primarily relevant to mobile so folks might have thoughts. Share them on that issue.

[iangreenleaf]

I think closing this makes sense. At this juncture, I doubt that adding another interface is really going to be the best solution, and we'd probably be better served figuring out how to integrate any further improvements into the existing postmodern interface.