On Wed, Jul 28, 2010 at 3:14 AM, Luis Villa <[email protected]> wrote: > I'm told it will be publicly released Tuesday; I'll forward it then. > I'm not 100% sure it'll be what we need here but it will be a good > start.
http://jquerymobile.com/gbs/ is the chart I was referring to; take a look at the chart and note the text "jQuery core is working to support all A and B grade browsers." It might make sense to target jquerymobile when that is available late this year rather than doing much work directly in tracks? Luis > Luis > > On Wed, Jul 28, 2010 at 8:48 AM, Reinier Balt <[email protected]> wrote: >> I hope Luis can get the info on supported javascript in the common mobile >> devices… Then you can target that. >> >> >> >> Reinier >> >> >> >> Van: [email protected] >> [mailto:[email protected]] Namens Tim Madden >> Verzonden: dinsdag 27 juli 2010 16:02 >> CC: 'track-discuss' >> >> Onderwerp: [Tracks-discuss] Re: Future of the "mobile" interface >> >> >> >> See comments below... >> >> On 07/27/2010 01:42 AM, Reinier Balt wrote: >> >> When I updated the mobile interface to the current one, I had a >> non-javascript phone in mind >> >> I believe most phones sold in the last couple of years support some level of >> js. The issue is that it is all over the map. I think an important thing >> to build is a graceful fallback where if a there is no javascript at all or >> no support for a particular function. if support is not there, it needs to >> still work. The main interface is unusable without javascript. >> >> >> >> 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. >> >> This would be nice, but could be a significant effort. I know there are >> libraries out there you can hook into that provide data on what agents >> support what, but I suspect that even if we got it set up, it would require >> so ongoing care and feeding. For me, it seems like a lot less work to >> manually go to a subdirectory... >> >> >> >> 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? >> >> In the end, for me, I found the path of least resistance was upgrading some >> functionality on the mobile interface vs dumbing down the main web >> interface. There were just a lot things broken (like hover based menus, I >> don't think these work with most touchscreen based UIs, and toggling todos, >> I suspect the main culprit here might be having it disappear from one area >> (the context) and reappear in the completed area) I found it less work to >> drop in a few simple big wins (at least for me) into the current mobile. >> >> I am all for a new rich small screen interface, but just didn't see myself >> having the time or expertise to make it happen... >> >> >> >> 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. >> >> Moved the submit to the top where it handy to click. >> Floated the Done? to its right (actually the button is floated left...) >> 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 >> >> > _______________________________________________ Tracks-discuss mailing list [email protected] http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
