I was hoping that you were referring to mobile jQuery when I read the announcement :-) It would make a lot of sense to target that. Perhaps keep the textual mobile interface as a fallback for other browsers (especially if jQuery mobile has some sort of agent detection).
Reinier > -----Oorspronkelijk bericht----- > Van: [email protected] [mailto:[email protected]] Namens Luis Villa > Verzonden: maandag 16 augustus 2010 14:18 > Aan: Reinier Balt > CC: Tim Madden; track-discuss > Onderwerp: Re: [Tracks-discuss] Re: Future of the "mobile" interface > > 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
