Task management

One of the key features mentioned for task management was to do with tracking time on tasks. To not only know how long a task took to complete, but to also be able to track time on it over a period of time, instead of in just one go. I think the best way to implement this would be to use a stop clock, where the user can start and stop the timer for a task. Something like this is much more likely to be used then a traditional timesheet which will result in more accurate times. A desktop widget was suggested for this, but that’s a little beyond the scope of this project.

Another thing that came up which I’d thought of, but not as suggested in the thread was to do with task priorities. I’d initially thought of just having 3 priorities, low, medium and high. This would have the benefit of reducing clutter as there are 3, easy to understand levels of importance, but it was then suggested to allow custom priorities, such as ’show stopper’, ‘nice to have’, ‘Sev 1′ etc. This lets the users have as many as they want, but also use the terms they prefer, which allows for more consistency between this and their other applications/processes. All accounts will now start with the 3 base priorities, but you can add your own.

Schedule management

Next up we have schedule management, which covers projects, people and milestones/events. One thing I was surprised to have seen explicitly mentioned by several users was the need for concurrent project support, which seems strange as I assumed this was an obvious inclusion. One thing that came up which I hadn’t thought of was the idea of reoccurring events/milestones. So this might be something that takes place every week, every month on a set date etc. Support for this will probably be fairly basic as I don’t want to turn the main focus of this project into a calendar application, but it is important to bear in mind.

One thing that came up which I’d not previously given too much thought to was how in depth I would let the planning be. I always knew there would be planning by the day, but hadn’t thought about anything more specific then that, although there appears to be a clear demand for down to the hour planning. The problem with this is it adds a lot more clutter to the UI. It would be easy to hide this in a div, but that would require an extra click every time to display the extra input for more micro level planning. On the plus side, scheduling stuff down to the hour provides much more information to be used in reports and stuff like Gantt charts. Gantt charts where another common request, which in its simplest form shows a timelines in a graphical form. It shows resources and times, and how they fit together. This is also something which would fit nicely with the reporting, which I’ll talk about more later.

The final thing that got mentioned was iCal integration. iCal is a format which works with many desktop calendar tools, so you can integrate all time/date sensitive information from within the application with your desktop calendar application of choice.

Tickets

This is something I’d not originally thought of, but now that it’s been mentioned, it appears to have been a big omission on my part (which is why getting user input is so valuable). A ticket is similar to a task, but unlike normal tasks, a ticket is reactive. As with tasks, it was suggested that tickets can have custom priorities (should they be the same priorities as with tasks?). It should also be possible to categorize tickets.

Time tracking

One interesting point came up regarding time tracking which made me think twice about the way I planned to initially implement visibility. I’d initially thought that making everything visible (such as times) would make the process a lot more open and benefit everyone. Someone mentioned you might not want to client to see how few hours you actually spend on a project, as they would think they’re getting poor value. Also you may not want other people on the team to see your hours as they may resent that they put in more hours on a given project. As a result of these issues, I will make it so that by default only the project manager see’s all the users times for a project and they can optionally make them visible to the client for the whole project or a per milestone basis.

Another thing that came up was to do with estimations, you could measure how long you thought a task would take against how long it actually took. You could then use this to find out how accurate your estimates are, how efficient you are at meeting them etc. I initially though about using all this past data to help you estimate new tasks, but there are serious complications with this, such as comparing different tasks, which are clearly different, and as a result, will not be part of the functionality.

Projects

The concurrent projects are something I’ve already mentioned, but progress indicators for projects are something new that came up. I had an idea of health indicators which would show the risk of a project going off schedule, but this builds on that by showing how far along the project is. This is of course more complicated then just the number of completed tasks/milestones as a percentage, as it needs to take into account time estimates, efficiency of meeting these estimates, if previous milestones where met on time, early or late etc.

Reports

There are 2 types of reports which seem to be in need, management reports, which show status updates, can generate PDFs on the fly, Gantt charts etc, and lookup style user reports, where you can find all your tickets with a given priority, or all messages in a certain time frame etc.

Notepad/scratchpad

This arose from the need to just be able to get stuff into the system in an unstructured way, so it could be relevant information which doesn’t fit any of the specific modules. This could be per user, per project or per account (yet to be decided, although most likely per user per project).

Context/user aware

This is something which arose from the needs of different users types. If you’re a single user working on a project, you don’t need all the tools meant for users, and if it’s an internal project, you don’t need client facing tools.

People

This is something that came up which I’m not sure how useful it would be to the application in its current planned form. The suggestion was to show which users are currently online, although this seems redundant unless there is some sort of IM functionality (which is not planned at this stage). Also you can determine who was online based on what time they done various tasks, posted messages etc.

Developer tools

Seeing as all the user input in this post came from the CodeIgniter framework forums, it was inevitable I would get some developer specific suggestions. The main one was integration with source control systems such as SVN or Git. The files would then appear in the file repository as normal. The problem with this is it’s a lot of work for an audience specific piece of functionality. Another suggestion linked to this would be to push files which have been approved to a live server. Unfortunately this doesn’t really seem like a feasible idea as in most cases, access to the production server is very restricted. These developer tools are something which could maybe be added at a later stage.

Totally new ideas

As well as all the great ideas from various users in the CodeIgniter community, I had a few more ideas during all the talking about cool new stuff. One idea I had when discussing about the developer tools and being reluctant to go down a specific route was to build a generic core and to then add specific modules on top of it. So a developer might enable SVN integration, file moderation (for code reviews) etc, where as a photography project would need more graphic focused tools. Instead of making users choose the modules they want each time, they could be saves as profiles or bundles.

Another idea was to have a journal/log section, where you can just write daily entries. This would be useful for reviewing what you’ve done at various stages of the project from the perspective of the user, instead of just the auto generated content.

General

Some of the more general themes which emerged are that users tend to favour simple and elegant interfaces instead of something full of bells and whistles and that only the minimum amount of information should be required. This means if creating a task, there may be fields for milestones, assigning to users, priorities etc, but all you really need is the task itself. The rest is just additional information which is useful and you would get extra value out of using it, but you don’t need to enter it when creating the task, it can always be added later if needed.

Overall it was a very worthwhile process to get some user input and hopefully I’ll be getting lots more throughout the design and development process. If you think I missed anything out, just post it in the comments

This is also being discussed in the CodeIgniter forums, and can be found in this thread (you must be registered to post to the forums, but can view as a guest).