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.
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
