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.
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]
<mailto:[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]
<mailto:[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
