Tidalsand

We’re putting together our project road map at the moment. The basis of this road map is our wish list. Our wish list includes everything we think a time tracking application should be able to do and what we’d like it to do; our must-haves, should-haves, and nice-to-haves.

So what broad features must the application have?

1. It must be a joy to use.

This is a huge one. It’s a timesheet – using it is never going to be the favourite part of anyone’s day, but it should be wonderfully intuitive and look the part. You can’t get away with a ropey-looking application any more – it just has to be beautiful.

It must also fit in with whatever colour scheme and visual design standards are in play in the environment in which it’s working. This means complete CSS configurability.

2. It must work the way you want it to work.

This is a huge one. It means it pulls time tracking information from wherever you happen to put it.

It means it makes it’s own time tracking information easily available (it’s your data after all).

It means it doesn’t get in your way.

Essentially, this means having a published API so that getting information in and out can be handled by other systems, and not just by someone clicking an “Export” button.

It also means that we don’t force you to record your time in just the we think works best. We have our views and recommendations but if you already have a process up and running then we’re not going to make you do it the Tidalsand way.

3. It must be secure.

Also a huge one – are you getting the picture?

Some companies will require the application runs on their own servers on the company intranet – they want to be completely in control of everything. Other companies will be ok with having the application run outside of their company firewall but will still want to be in control – they might want the application to run in their own Amazon AWS space. Other companies will be ok with the application running as a service on hosted servers but they will clearly require complete assurance that their company data is held securely.

This implies a fair amount of architectural flexibility – we can’t force you to use Application Server X or Database Y. We just have to make it work anywhere while also providing fully packaged solutions that work right out of the box.

So that’s it really. Mote of a statement of direction than a road map but it’s a start at least.

“Our application must be a joy to use; it must work the way you want it to work; it must be secure.”

I think that covers most bases.

Over the next few posts we’ll flesh out the details behind each part of the statement and go through some of our technology choices.