Trails is a process.

11 days ago I broke my Trails account. I immediately created a new account and have been using that until Remy or Dmitry get around to fixing mine.

My broken account had at least 100 tasks. The size and length of my list made me realize that after a year of use, users might have thousands of tasks. How will we manage them? – especially the completed ones …

Completed tasks give us insights into our work habits, they are valuable, and over time I will have to find a way of displaying these tasks and lists in a useful way, allowing for many tasks to be viewed at once. Allowing us to peer through a lens and analyze how we work.

For now, we just need to get the app working.

What an ugly sight a 500 error page is.

Things break. They do, they do, they do.

P.S. – indeed, we are behind on the launch of the Alpha site, too …

Look, its a lil' Alpha signup page!

Primarily to: Remy

Secondarily to: Dmitry & Evan

Remy, I’m bringing two new gentlemen on board. One will help as we get closer to launching, or shortly thereafter, while the other will be helping out immediately. The former is Evan, and the latter is Dmitry.

Dmitry has a good eye and will help with much of the front-end implementation, making sure the app looks exactly like my mockups; he is also entirely capable of any Rails work you need help with. I’ll leave the details to you two. What do you need help with, Remy?

My main concern is the aesthetic side of the app; it is integral to my vision of how the finished product will work act and think, and integral to the stories it tells, along with the stories we tell about it. This is why I’ve welcomed Dmitry to the team.

This document will be forever evolving until we launch, but here’s a start:

Immediate goals:

Already in its infancy and eager to grow, we have a tool who’s usefulness has been clearly proven. Who’s talents are ready to shine.

As I sit on this cloudy but pleasant Sunday afternoon, tracking my time, the path I see ahead is ever-so-clear.

Trails is 90% there. The last 10% will make it or break it.

My list of tasks is massive in size – we must be able to accommodate hundreds of tasks (thousands if you include the completed ones), if necessary, therefore a separate view for completed tasks must exist, along with functionality to hide completed tasks. The UI needs countless refinements; a settings pop-up needs to come into play, and the JavaScript code needs to be optimized quite a bit.

Users should be able to check off task lists, not just tasks. And they should have the freedom to expand/contract task lists so that a list with 20 tasks doesn’t have to get in the way if its not used often.

We’re getting there, though. A website for the Alpha will be up shortly, and we’ll have a finished app in a few months.

The details of what launching requires on the business end will be disseminated in the next day or so.

This is Trails at 90 percent.

We progress; ever so slowly.

The “pay what you want” pricing model has always fascinated me.

Why hasn’t it been applied to the web? The risk? The technical hurdles that need conquering? Has anyone even considered it?

Value is relative and constantly in flux. When I first became a Basecamp customer my account went unused much of the time. I was a young freelance designer with a minimal amount of work. $12 per month was so often a terrible investment on my part, but I stuck it out and kept my account.

Trails is intended to be an extremely valuable tool – something that should be used every working day, throughout the day. A critical app to any business.

Yet I understand that while it will be valuable and used often, the exact value might very from person to person, from month to month.

So, I’m tooling with this idea:

You sign up for Trails, and regardless of who you are or what you do or how much money you have, you get a 30 day free trial.

After your trial is up, you decide what you think the next month of the app is worth and pay us accordingly.

$1, $10, $20 – pay what you think its worth!

It’s as simple as that. The technicalities can be worked out.

Fear of failure has never done anyone any good – mistakes can be beautiful things – if this turns into a thing of beauty that teaches a great lesson that only failure can offer, so be it. If it succeeds: rad.

I am happy to say that things have been moving along pretty quickly these last days. The new features required a new layout scheme in order to work properly. in my previous post I said that I would start moving away from a Table layout in favor of Lists and Divs because of some DnD issues with Tables. However, I quickly realized that It was going to take me way too much time to convert everything to divs without screwing up the graphical interface. I then opted for a UL and Table mix which seemed to be a good compromise.

After countless hours working with CSS and Javascript, I finally managed to re-enable already implemented features that were broken by my layout changes.  As of today I have also written and tested the following features:

• Drag and Drop *
• Duration bar grows as duration increases
• Duration Clock ticks while task is active
• TaskList duration and earnings updated when a task is moved to a different list
• Tasks updates every minute

*Tasks can be assigned to other task lists. Tasks can also be reordered.

The existing JS code had to be partly re-written, however I was able to make good use of existing objects after extending them. This part did not go as quickly as expected due to highly abstracted objects and lack of comments. Although, once understood the code was quite helpful to use.

I ran into many obscure issues. One of which is extremely annoying. In development mode, rails refuses to process two Ajax requests if they are sent too close to each other. The problem is actually more complex than that. I will write a post dedicated to this issue later. For now, I have been forced to use Production mode for some of the features (like Drag and Drop) to work.

Tomorrow, I will write about additional features that should soon be finished.