So Resourcer is currently in a live prototype state. This means that we’ve moved past the basic HTML+CSS design stage, and are now linking various parts of the website to a MySQL database. Of course this means that various parts of the site are up and down at any one stage, but we’re getting there slowly. A roadmap from here is:
- Finish linking core application functionality with database.
- Gather requirements and building secondary application functionality.
- Finish information type pages.
- Tidy pages, do quality assurance, move project into Beta stage and open logins to other people.
- Move application onto framework, either Seagull or Silverstripe.
- Tidy pages, do quality assurance, move project and beta data/logins onto Gold release.
- Publish API.
Also, I’ve noticed an awful lot of time tracking applications on the web, like Harvest, Tick, 88 Miles, and 14 Dayz (seriously, a Z on the end?). They’re all sexy web 2.0 applications that focus on the hastle that is Time Management. Where does the time go? I’d never noticed this applications until I started working myself in this space, and then saw all the other people who were there, hence my sand in the desert headline. But there’s a bit of a difference between Resourcer and time tracking applications:
- Resourcer tracks the time between each status update. There’s no timers, no punch in and punch outs. Managers can see how much time was taken between status updates, but that doesn’t imply the amount of time spent on a particular task.
- Resourcer focuses on a higher level than tracking time taken to do a particular task. Your status update could be about one or many or no tasks. Instead Resourcer is at heart a communications application across large enterprises.
- Where we improve on basic collaboration tools (like email and instant messaging) is our reporting tools for Managers to see snapshots of workforce utilization and to dice that information into project, or manager, or business unit specific reports.
- Where we improve on complex collaboration tools (like portals) is ease of use across multiple GUIs and multiple devices using our simple API, and ease of use to end customers. We want to be as simple as Twitter, but a lot more powerful to business.