Tim, I totally agree with you. I've found myself using the desktop Tracks interface on my iPhone for everything but adding tasks. That's even on a crappy 2G wireless connection. I've wanted to do something with the mobile interface at some point, but I haven't found the time to make it happen. I'm happy to do what I can to support you on bringing a better mobile interface to fruition.
As for how to get there, I think the current mobile interface is probably throw-away if we want a real, rich, mobile interface. I'd take the desktop interface and throw some stylesheets at it to avoid forking code as much as possible. This could be our chance to get real graceful degradation in all of Tracks, not just the mobile interface. Now that I've cleaned up the JavaScript code (and put it all in application.js), the way is open to fix up a lot of the view templates, and in doing so we should be able to isolate things into partials such that the mobile interface is just a re-combination of those same partials with a different set of JavaScript and CSS. I'd be interested in going through the view layer with you over Skype or something to see how feasible this is. I'm excited! -Eric On Sat, Mar 20, 2010 at 9:58 PM, Tim Madden <[email protected]> wrote: > I wanted to start a discussion about the future of our mobile interface > with the group and solicit some feedback. > > First, the mobile version is a great asset to have. The interface is super > lightweight, clean and works universally (more or less). However, the > mobiles that are in the pockets of many tracks users today, likely most, > have browsers capable of much more. Every "smartphone" and many > non-"smartphones" support some level of javascript. However, if you visit > the mainline tracks interface on your smartphone, the experience is > comprised. I happen to use a blackberry (and we used to have an ipod touch, > but the kids fried it) and it works but much of the javascript goodies are > lost and this actually limits the interface's usefulness. For example, > autocomplete and javascript powered drop down menus among others (at least > on my blackberry) do not work. > > So my thought is we need some happy medium between the two. Something with > some basic javascript for things like ticking off completed actions while > respecting the expected screen resolution of ~320px wide. It should avoid > drop down menus and the add and edit form probably need to be left to a > separate page instead of region of the page or an overlay on the existing > page. > > The question I have is what path offers the least resistance to achieve > this goal? (We must be realistic. This is an open source project after all. > We may have big dreams, but we also have small time budgets to contribute!) > One path would be to take the existing mobile interface and layer in some of > the important javascript goodness we want... Alternatively, we could clone > the rich interface and dumb down the javascript to the essentials and slim > the width of the interface to an arbitrary goal ( say 320px)? Maybe there > are tools to use I am unaware of?? > > Let me know if you have input on the idea. I am willing to take a run at a > development branch, but wanted to gather some opinion first, > > Thanks, Tim > > _______________________________________________ > Tracks-discuss mailing list > [email protected] > http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss > >
_______________________________________________ Tracks-discuss mailing list [email protected] http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
