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
