search

npdoty / planworld

Automatically exported from code.google.com/p/planworld
GNU General Public License v2.0
3 stars 1 forks source link

mobile interface #5

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Planworld interface doesn't work particularly well on the iPhone or Blackberry 
or other mobile 
phones.  We might be able to take advantage of the planwatch.org interface, 
which has options for 
the iPhone.

jwmanly: I'd also like to put in a plug at some point for someone to produce a
CSS or other interface to Planworld to make it more usable for us
Blackberry users.  The main problem is that the Planwatch list precedes
every display of a plan, which (if you have a long planwatch list) can
mean a lot of scrolling.  It would be way better if there were a way to
have the Planwatch list appear at the bottom of the page rather than the
top.

Original issue reported on code.google.com by npdoty on 25 Feb 2008 at 11:45

GoogleCodeExporter commented 9 years ago 
The Version 3 API will support additional front ends and cross / node logins, 
both of
which will solve this issue.

So, the answer to this is: Functionality does not exist in version 2 but will be
coming in version 3.

Original comment by jlodo...@gmail.com on 14 Feb 2010 at 4:12

npdoty commented 5 years ago

I still think this is relevant and accessible for planworld's current architecture. As a starting point, could we just adjust the CSS to include media queries such that the layout works more reasonably on a mobile device? Like putting the list of plans as full-width but after the main content?

And then in the longer term, it would be interesting to have a service worker and some basic app-like functionality so you could add planworld to your homescreen. There could be offline support where we pre-cache plans, although that would have some tricky impacts on snitch functionality.

npdoty commented 5 years ago

@lebaer suggests that media queries are unlikely to work until we've migrated the HTML to something more modern, semantic and not based on HTML tables. I think we should prioritize trying to develop a separate layout using HTML5 and fitting the semantic mockup.

@jlodom previously worked on a mobile interface that itself used HTML tables, meta viewport values and a separate authentication system, with code shared on planworld.

npdoty commented 5 years ago

Some notes to myself as I look at how feasible this would be:

I think we would want to make a new "skin" for a new HTML5 layout. This could be deployed in parallel, so that all older code would continue to run by default without any changes. The user's skin is currently accessed through the User object throughout the codebase, it's just that currently the skin is only the default value. We could change User to check whether a separate preference value has been set for skin during the load() function (this is how timezones work now), and eventually change the prefs page (on both the old and new skins) to allow users to change their skin between 1 and 5. That would not require touching the users table in the database, only the preferences table. Once 5 is preferred, we could easily change the default without any database changes.

With a new skin in place, we can duplicate most of the .inc files in /layout/1/ but make changes as necessary to move away from a table-based layout. That would most prominently require rewriting outline.tpl navbar.inc planwatch.inc trailer.inc and edit.tpl, perhaps with a few others, but that would mostly just be HTML editing, with some occasional PHP. It would be a good time to clean up / change wording and formatting throughout, but generally try to create a new HTML5 layout with the same basic look, except with a responsive design.

Themes are currently skin-specific, but once we've tested them, we could either create new themes that work with the new skin's HTML, or, if all of that CSS/imagery is backwards-compatible, we could make the theme PHP code look for any 1- or 5-skin compatible themes.

A little bit of functionality has been written that currently avoids/duplicates the skin code altogether at the moment, including look.php (that might be the only thing?) and I would suggest that we not try to migrate that. Also, send.php is currently not using skins at all (it opens in a separate window that doesn't have any of that surrounding chrome); it would continue to work as-is, but we'd probably want to re-write that into a better layout that would also work on mobile. As no one especially likes how send looks/works at the moment, I think it's alright if that switch doesn't have parallel deployment.

Alternatively, we could keep everything in the default 1 skin and just work on the layouts on the test deployment on krypton until we're ready for a switchover for everyone on the production neon server. That would be all the same work on rewriting layouts, but no handling of the skin preference. However, we couldn't get any opt-in dogfood testing from users which I think might be important for something like this; we'd just have to do browser testing on the krypton environment and then switch everyone and hope it didn't break anyone's browser configuration.