Hi Tim,
I believe we had a discussion on a smarter mobile interface a while back. When I updated the mobile interface to the current one, I had a non-javascript phone in mind (i.e. my ipaq with windows mobile :-)). I do not know how much people are still bound to these old generation phones/pda's. I personally moved to an android phone and I just bought an ipad, so personally I love to make this move :-) I hoped we can have the current mobile interface alongside a new one that uses more modern javascript techniques . We need agent detection code for that. I also like the screenshots of itracks (http://ibetatest.com/iphone/controllers/apps/?appId=165). We could go for something similar. The mobile google reader is also a good example I think of good mobile interaction. Anyone here experienced in mobile development? Are there 'profiles' or something of javascript that is or is not supported by the majority of mobile devices? Reinier Van: [email protected] [mailto:[email protected]] Namens Tim Madden Verzonden: zondag 25 juli 2010 1:15 Aan: track-discuss Onderwerp: [Tracks-discuss] Re: Future of the "mobile" interface Hi, the edit mobile form was missing a %> and so was broken. Just pushed a fix into github. If you cloned my branch, you need to fetch the update to be able to use it. Tim On 07/23/2010 12:01 PM, Tim Madden wrote: Hello all, Well, while some great ideas were discussed following my March (can't believe that it was back it March! arggg, where does the time go!), I made zero progress for most of the period. Eric and I had a chat on the phone and we discussed how we might go about making the main interface with all of its goodness work on mobiles, I just have not been able to carve out the time to make it happen. Additionally, the bit of research I did found significant variance in the level of support for javascript across the various mobile browsers. Not to mention, I am really still a novice in terms of ruby on rails. So, finally last week, I let go of the idea, for now, of bending the main interface and decided to scratch a few of the biggest itches that I saw in the current mobile interface. Here is a quick list of the changes I made to my branch: * On the mobile home page, I made the context name in the <h2> header a link to the context. That way if I want to zoom in on a context, it's right there! easy peasy, love it. * I removed the numbers off the header and footer links that reference the keyboard shortcuts. They don't work on my blackberry and I suspect this might be true in other phones. The shortcuts are still there, I just changed the labels. * I added a mobile.js file to the javascript directory and so far have just one function. maybe we can add more later as they are developed. as this is an interface for constrained devices, in principle, I would like to stay light on the js. * The one function is that when you load the _edit_mobile form, your cursor is automatically focused on the description field. This way you can start typing without having to select it. If I am adding a new todo, this is where I want to be and if I am editing an existing, this is a good as any place to start. * I rearranged the order of the edit form. 1. Moved the submit to the top where it handy to click. 2. Floated the Done? to its right (actually the button is floated left...) 3. Dropped the notes down below the tags. It takes a big chunk of space an I don't use most times. This puts, at least on my phone's display the submit, done, description, context, projects, and tags fields all on the screen without having to scroll. Love it. While I still have a couple more ideas to go, these were the low hanging fruit as they say and felt I was ready to share with the community. If you would like to try it out, I have pushed this mobile branch to my github account here: http://github.com/maddentim/tracks/tree/mobile I would appreciate it if some of you could test it out. It seems to work fine for me, but I would like to be sure I am not mucking things up. I will send a second email shortly discussing some of the things I would like to work on next. - Tim 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
