product design thoughts

This page lists ideas about the product design of jobsworth, mainly on how to make a SAAS out of it.

What makes jobsworth different?

There're many successful softwares related to 'project management', but each with different focus.

What makes jobsworth special? Personally, I think the biggest feature of jobsworth is the integration of project management with customer support.

Most project management tools are only used internally within an organization, without the concept of customer. Customers' direct participation in the system enhances communication and facilitates fulfilling tasks. This feature makes jobsworth very suitable for those service-providing companies.

Other jobsworth specific features:

• comprehensive company wide address book
• replaces email for customer support and dev processes
• tracking the application of SLAs
• billing

There are more developer specific systems (eg. Jira) or helpdesk specific systems (eg. Zendesk) or pure project management (Liquidplanner). But jobsworth sits across all those areas.

Remove features

I think following list can be removed in the SAAS version:

• news item
• custom scripts
• triggers
• wiki
• gantt chart

Make project an important context in interaction design

Context will help simplify the interaction. Just as we have current working directory in OS, we can have current working project.

Is it a good thing to enforce users to work in specific project context? Yes, it's not such flexible as what we have currently, but most of the time, most of people will think and work that way.

A user may sometimes care about all tasks related to him in all projects. That can be shown in his personal page.

Admin may care statistics & reports across projects. That's on the admin page.

Sometimes, admin may want to make an advanced query regardless of projects, we can provide that in advanced search. But project-context based interaction is the way we think the system should be used most of the time by most people.

Make time tracking an option of project instead of user

When user creates a new project, he specifies whether the project will track time or not. If later we introduce new features, it's better to make that an option of project as well. For example, if we have implemented project wiki feature, we can make 'wiki' an option of project.

Project is the suitable level that features diverge. We can even have different kind of project, such as code dev project, which may have completely different task UI.

Can we remove the concept 'company'?

Perhaps we can go even far away, to remove the concept 'company' in the SAAS version.

We can tie projects to project owners instead of a company. This will encourage more people to use the SAAS service, as he can create his own project and invite people to join the project as long as he has an account. And the invited user can do the same.

This will allow people to participate projects across company boundaries. Suppose a customer working with two company which are both using the SAAS.(NOTE: this can be achieved with the concept 'company' as well)

Each user can manage a list of customers, just as he has a list of projects.

Or, if we can't remove the concept, we can make 'company' dependant on user, instead of user dependant on company. This allows projects wihout company(think about github organization).

Simplify authorization

Currently, jobsworth authorization mechanism is powerful, but complicated. Most of the time, we don't need such fine-tuned control(note we have change logs). I think a project role based authorization mechanism is better. At least, we have following roles on a project: project admin, customer person, project member. We can prefine access rights for each role and base authorization on these roles. This will make things much simpler and useful for end-users.