In this post I will summarise all the feature requests and input I’ve received from the great guys over in the CodeIgniter forums. This post covers all input in that forum between the 19th of May and the 5th of June. You can see the thread in full here. The format for this post will be a sub section for each of the main ideas where I summarise all the user input and then give my thoughts. Now in no particular order of important (this is the order they came up in).
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
Sounds like you have gotten some good input from the guys over at CI forums. Sorry I haven’t made any contributions until now.
I’m going to break my response down into categories similar to yours.
Task Management:
Custom task priority names are just extra little features. I would put those on the back burner and only pursue that if extra time becomes available.
Task Timing:
Users are definitely not going to want to fill out time sheets. They will forget to fill them out and then several days later, attempt to remember how many hours they spent on a particular task.
Getting exact measurements of time are always going to be challenging when depending on others to accurately report them. Make it as easy for the users that are filling in the time as absolutely possible. It’s always nice to wish that the user’s will be responsible and do things like they are supposed to, but it doesn’t always happen that way. My personal suggestion would be to provide a button to start timing the task, and then another to end timing (similar to a stop watch like you mentioned). Of course this still relies on the user going to the page and stopping the timer. I would also suggest if the user log’s in and a particular task is running, and has been running for an extended amount of time, notify them. Ask the user if the task really has been actively worked on for that amount of time. If not, allow them to specify a time that it should have stopped. (Good example, if they left at the end of the day and forgot to stop it, allow them to specify that it should have stopped yesterday at 5pm).
Schedule Management:
Recurring events would be a good idea, and won’t be hard to implement. You say that you don’t want to turn this into a calendaring application but that is a big role in project management. Scheduling tasks, keeping them on schedule, allocating resources, etc and ensuring that everything works out so that the project finishes on time is what it’s all about.
Scheduling tasks and such by the hour is important. Many projects are estimated to require a certain number of man hours to complete, and then billed based on this hour estimate. This being said, if you want to accurately track your efficiency, you need to track by the hour. Otherwise, you won’t be able to know exactly where you are falling behind in the overall project.
iCal integration would be a really neat addition but not something I would really focus on. Being able to see all of your tasks, milestones, etc is the purpose of building this tool.
Tickets:
Good idea but obviously should not be visible to the other users, only the PM. The customer shouldn’t be able to just throw something new in. It should be communicated to the PM and then pending the PM’s approval, the PM can add the needed tasks. The customer throwing a new requirement in can create a new for new resources, require additional funding, adjust the schedule, or adjust the scope of the overall project.
Time Tracking:
You are correct in the fact that users should not be able to see the amount of time that others are spending on their tasks. They should be able to view their own time and that’s it. The PM should be the only user allowed to view the amount of time spent per user per task.
You definitely should allow the time estimations. Being able to accurately estimate how long a task should take obviously requires prior knowledge or previous measurements of some kind, but otherwise, without estimates, how would you know whether or not tasks are falling behind schedule. That have to have an estimated length to complete.
Notepad/Scratchpad:
Interesting thought. This could provide useful. On the other hand something similar to a personal to-do list may also prove useful.
People:
Showing the number of users online and who they are is completely useless. There is no need for this. If you a user if worried about who else is online, they obvious have nothing else to do and need something else to tasked to them
Journal/Log:
I don’t see where there would be much need for this if the scratch pad were made available as they would probably serve the same purpose. This would be useful though, if it were appended to a weekly (or whatever schedule decided upon) status report. Status reports could be generated automatically via cron job, showing the tasks that the user had marked as completed that week, and the tasks that had been worked on by that user that week. These reports could be generated and presented to the user toward the end of the work week, and allow the user to add comments to the end of the status report before it was submitted to the PM.
UI:
Simple and elegant are nice, but when you have a lot of data to provide, it doesn’t always work out as nice as you would like. Bells and whistles aren’t overkill as long as things are displayed in an effective manner. If you cram too much information in a small space and it becomes cluttered, then you have a problem. Including needed information in an effective way makes the site more efficient.
Hope all this helps
Thanks for the comprehensive feedback David
Just a couple of thoughts in reply.
The custom task priorities is more then just about pretty names, as you can add extra types with a numerical value (the higher the number the more important). Although as you say, it’s defiantly not the most important thing right now.
The issue of starting the timer and forgetting about it was discussed in the forum thread, and there will be a timeout/alert mechanism in place. I was also thinking maybe having the currently active task in the sidebar, in the hope you don’t forget about it.
I know basic date stuff such as recurring events is easy, if you want something to occur every week, just keep adding 604800 seconds (1 week) to the original timestamp, but there are always complications with dates, such as bank holidays, dates such as the 30th of February etc.
Tickets, yes obviously they will only be visible to the PM (I need to really keep asking myself the question “Does everyone need to see this, or just the PM” more often). There will also then we shortcuts to create a set of tasks, milestones etc to achieve the objective of the ticket in a seamless manor.
I don’t think I was clear on the subject of time estimates. I still intend to allow and encourage the PM/users to enter time estimates them selves, but I don’t intend to do this automatically on their behalf. And they can also have all their previous estimates/actual times available to them when making new estimates should they wish.
Notepad/scratchpad/personal to-do list: The reason I was thinking of a scratchpad over something like a personal to-do list, is that you’re a lot more restricted with a to-do list, where as you can use the scratchpad as a personal to-to list of you want, but you’re not limited to using it in that way.
I think that’s a fantastic idea about the auto generated report each week where the user then adds their own comments along side what they’ve been working on that week. That little personal account there could completely remove the need for the logbook.
As for the UI, we shall have to wait and see… I plan on making a few mock ups in the coming weeks and posting them here to get some more (excellent) user feedback.
Thanks for all your input, really helpful