Modelling accounts

July 31, 2009 — Damian Jakusz-Gostomski

How accounts will be modelled in the system is something which needs to be decided on early in the process, as everything else will build on this. Unlike linking users and accounts, this will be transparent to the end user, as it’s just the internal modelling which is affected.

There are 2 types of accounts, which will be referred to as company accounts and client accounts. A company account is what is created for you when you first sign up, if you’re invited into the system, you join the company account of the person who added you. In the context of a project, the company account is the one delivering the project and the client account is the one who the project is being done for. The complexity arises from the fact that a company account can also be a client account, but at the same time, they each have distinct roles and attributes, which gives the following options for modelling the relationships.

Separate accounts for companies and clients

In this case, there would be a separate table for company account and a separate table for client accounts. The benefit of this is there is a clear distinction between the 2 account types and you can have a different set of users depending on the role of that account. The downside is there is a lot of data duplication. The account would have 2 instances, and there would be 2 sets of account/user relations. Also, as the accounts are stored as 2 separate entities, they could have different identifiers, such as names, IDs etc which makes it harder to know if they’re the same account.

Company and Client extend Account

This “simplifies” the previous case, by introducing an extra table. By adding an accounts table, which companies and clients can extend, we no longer have the need for duplicated data. All common data between the 2 account types would be stored in the accounts table and all users will be linked to this table, instead of the company or client account, and then any unique data would be linked to the appropriate account. This would simplify the database side, but could unnecessarily complicate the application.

Company extends Client

This is an extension of the previous idea, but without adding the extra table. Every account will always be either a company or client account, so why not make the base account either company or client, and make the other one extend it. It would make sense to have the base account the client account, as company accounts will need to have extra meta data, as they actually manage the projects.

One account to rule them all

In this case, there would be just one table storing account data, and there would be no differentiation between company and client accounts. The account type will only be distinguished at run time in the application based on the context. This provides the most flexibility, as it would be possible to switch between account types on the fly.

Due to the added flexibility of the last method, this is the method I will be using. It also has the benefit of requiring the least storage in the database as accounts and relations are not duplicated.

Posted in Accounts. No Comments »

Design 2

July 30, 2009 — Damian Jakusz-Gostomski

So here’s the next potential design for the application. This one is intentionally completely different from first one and has a much more contrasting colour scheme. It is also built using the 960 grid system CSS framework, so can easily be adopted to have the same structure as the variations shown in design 1.

Even though there’s more colours and more ‘going on’ it doesn’t seem to distract from the main content, as it’s nicely separated from the rest of the UI by the bold colour differences.

So what are your thoughts on this one compared to the previous one?

Posted in User Interface. 2 Comments »

Design 1

July 19, 2009 — Damian Jakusz-Gostomski

So I spent a little bit of time today coming up with a set of ideas for the main UI. In total there are 5 versions of the design, each with a small tweak for the layout of the main part of the page. The general design was built using the 960 grid system, which makes making CSS layouts much easier by imposing a few rules. I went for a very clean and minimalistic design, so that it wouldn’t get in the way of the content, using several shades of grey to differentiate elements such as the main navigation. The design is in no way a final design, but just focuses on the layout options. All variations of this design have the standard horizontal navigation at the top where users expect to find it. All designs are a fixed width of 960 pixels and centred in the page.

Clicking on the screenshot will take you to the live preview of that design

This is the first variation of the design has the sidebar on the left of the main content. This is a pretty standard layout and something most users will be familiar with.
The only difference between the first and second design is that the sidebar has been moved to the right of the page.

Although a small change, it means the main content comes first as users scan left to right.
This is very similar to the above, but there are now 2 smaller side columns on the right. They only take up 80 pixels more room but allow for much more secondary data to be displayed along side the main content
Same as above, but this time we have a column either side of the main content. This has 2 benefits, it keeps the main content centred and also allows the 2 side columns to serve different purposes. The one on the left can be a standard sidebar, but the one on the right can contain meta data and actions on the specific content displayed in the main view
This is probably the most different of these designs and it has 2 equal sized columns. The idea is that the left pane has various actions and items, and the right pane would display the item/action. This lets you get more items in a single page while only seeing the one you’re interested in.
Update
By popular demand, here’s the same design but with some added colour. The structure is the same as the first design, but the grey navigation and footer has been replaced with a bold blue. The background colour has also been changed to a very subtle blue and the headings have been changed to match.

These are very small changes but they make a big difference.

So what are your thoughts? Which is your favourite and why? I’ll try get another (completely different) design with several variations up in the next few days to compare the two. It is also important to remember that each page will actually look different as the various content elements have not yet been styles yet.

Posted in User Interface. 5 Comments »

Forum Feedback Summary

July 17, 2009 — Damian Jakusz-Gostomski

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

Posted in User Input. 2 Comments »

Linking users and accounts

July 16, 2009 — Damian Jakusz-Gostomski

There are many ways to handle user authentication with the system. The authentication can take place at a per project, per company/client account or at a user account level. The pros and cons of each method will be discussed below.

One account per project

In this scenario, every time you want to create a project, you need to enter a new set of credentials. Although you may use the same combination of email/username and password for each one, you will also need a unique way to link these to the project, which means you need to remember the project ID or some vanity URL. The advantage of this is you can keep separate projects totally isolated from each other, so work and personal projects do not get in the way of each other.

Even if you had a nice, easy to remember vanity URL, as soon as you have more then one or two projects, keeping track of all the URLs would not be easy, so you’d have to bookmark them, which results in a loss of portability in most cases, which is one of the key benefits of a web app. On the plus side, as you can have a separate set of credentials for each project, you can have notifications from different projects going to different email addresses.

On the whole, this method seems to be more hassle then it’s worth, and it’s possible to get the same benefits to an extent with the following method.

One account per company/client

In this scenario, you will have one or more accounts, which can have the same set of credentials or different. So you may have an account for work which groups all your work related projects together, then you may have a personal account which groups all your personal projects together and so on. This greatly reduces the number of accounts in total, which makes it much more feasible to have vanity URLs. You still have the clear divide between work projects and personal projects. The one downside is if you end up with a large number of accounts, your resources get spread across multiple accounts, which makes finding what you need a little more effort.

One global account

In this scenario, you only have a single account which houses all your projects. This has the benefit of everything being in one place and only one set of login credentials to remember. It also removes the need to remember any special URLs. Even with this method, there is still the need to have company/client accounts, but it would be possible to select which one you want once you login to your master account. It would also make it much easier to switch between ‘accounts’ as they’re all in one place.

Conclusion

The benefits of the 3rd method exceed those of the first 2 and it still provides the separation of accounts within the master account. The master account is just an entry point into the system, as oppose to a replacement for multiple company/client accounts.

Posted in Users. 1 Comment »

Development Process

July 16, 2009 — Damian Jakusz-Gostomski

Although I won’t be using a formal, rigid development process, there are several clearly defined stages, but within each stage, the order of execution will be flexible. The following is subject to change. User feedback will take place at all stages, and there will be iterative changes throughout.

Requirement gathering

This stage is about defining what the application needs to do. This will be based on my own thoughts, existing solutions and user input. User input is crucial to the success of any project, as if you don’t create something which is needed by real users, it’s worthless, no matter how well it’s implemented. Despite this, it’s very important to avoid design by committee, which is where you add everything anyone wants, which results in a large, bloated product that is of use to no one.

I will then build up a basic feature list, divided by section. This will be a very high level overview, and will be expanded on as I begin each section. I just need to know enough at this point to figure out how everything will fit together when making the system architecture.

UI Design

This part will involve coming up with a design for all the common UI elements, such as header, navigation and footer. The exact design for the main content will vary with each section/page, and to a lesser extent, so will any secondary content, such as a sidebar, although they will be influenced by the overall style. This part could be done at any time, although it’s good to have it fairly early on, as it will be influence the design of each page.

This process will start with some hand drawn wireframes/computer generated wireframes, which will then lead to a more polished set of design elements. User feedback

Architecture overview

This stage involves coming up with a very high level overview of the implementation. It needs to think about how the data will be stored in the database, how these tables link together. What models, views and controllers I will need as well as additional libraries and helpers. At this stage, it will focus more on what the various classes need to do, instead of how they do it, which will happen in the next stage.

I will also plan some of the key use cases at this stage, which will be a starting point for the implementation.

Implementation

This is where the actual coding takes place. For each area of functionality, I will take the relevant use cases defined earlier and expand on them. I will then create the relevant database schema to accommodate this functionality

So by this point, I have an idea of the functionality required for the given section, and some of the key use cases. For each use case, I need to simultaneously tweak the use case and the UI, as they are both dependant on one another. The use case will specify what should happen, and the UI will be what dictates how it actually happens. Once this has been decided I can move onto the database schema. I already have a basic idea of how all the core object will interact with each other, but need to start thinking about all the attributes. I can then implement the required methods in the controllers, libraries, models etc and make the corresponding views.

Testing

This will cover both functional testing and user testing. User testing is the key point I want to focus on at this stage. This will involve getting real users to use the system, provide feedback on how to improve it, report any bugs etc. Although I will need to be confident most of the bugs have been resolved before launching the user testing, it is much more efficient to allow a large set of users to identify bugs in the system from real word usage then for me to find bugs in my own code. The user feedback process will involve some structured questions but will mostly be free form, so the users can use it as they want, and give back any information they want. All user feedback will then feed into the next development cycle.

Posted in About. No Comments »

Users Intro

July 16, 2009 — Damian Jakusz-Gostomski

Users, along with accounts is an area of functionality which isn’t very exciting, but is still needed. The reason it’s needed is because each user of the system needs to authenticate with the system before they can access information relevant to their projects. Without user separation, everyone would be able to see everything, which might work in a small, open environment, but would never work on something the scale of the internet, as most project information is confidential, and kept between the people involved on the project.

The above requirements mean we need to make it possible for users to login and out of the system, as well as the ability to add new users.

Posted in Users. Tags: , . No Comments »

Accounts Intro

July 16, 2009 — Damian Jakusz-Gostomski

Accounts are another section which is an important part of the architecture, but doesn’t seem very exciting. An account groups a collection of users together. It could be a company, an organization, team etc. As with users, we need to be able to control who can access these accounts, as they are an entry point into the rest of the system. Linking users to accounts presents some interesting architectural challenges, such as how to link users to accounts.

Posted in Accounts. Tags: , . No Comments »

Feature Requests

July 15, 2009 — Damian Jakusz-Gostomski

As I’ve mentioned previously, user input is vital for a successful project, which is why I aim to get as much user input as early on as possible. So what do you want to see in a web based project management system? Or if you currently use a project management system, what would you say its ‘killer’ feature is?

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).

Posted in User Input. 4 Comments »

Overview

July 15, 2009 — Damian Jakusz-Gostomski

The following is a very high level overview of the functionality in the project management system. This list is likely to change based on user input and feedback, as well as the natural evolution process as the application is built and used. Any major changes to what is outlined here will be written up in a separate post with the reasons for the change.

Users

Users obviously need some way to access the system to view their projects and accompanying information. There are a number of ways this could be handled, and will be discussed in a future post.

Accounts

An account is a way of grouping users together. An account can be for a company, a group of users, a charity or any collection of users with a common interest. Then there are 2 types of accounts, company and client accounts, but they’re interchangeable, based on the current context within the application (you can even be both at the same time)

Projects

This is the whole purpose of a project management system, to manage projects. Each project has a company and a client, the company is the account doing the project, and the client is the account the project is being done for. These can both be the same account if it’s an internal project. A project is simple a collection of related items, including the ones outlined below. You can specify who has access to which projects instead of everyone in that project having access to every project (default).

Communication

Communication is the key to the success of any project. In most cases, this will take place via email, which means that not everyone is on the same page in terms of what’s going on. It also means there are numerous simultaneous ‘threads’ of communication, which are not easily searchable as they’re distributed. By using the PMS for all communication related to the project, it’s in a single location, making it easily searchable, and everyone knows what’s going on. For the times you need to communicate internally, you can send internal messages which the client won’t see.

Task management

It is important to know what needs to be done and by whom. Tasks and milestones help you to achieve this. Tasks tell you what needs to be done, and can optionally be assigned to a single user or group of users and milestones are dates by which point a set action needs to be done or something needs to be achieved by. It would also be possible to set internal milestones, which only the company sees. This is useful if the client only sets a final deadline, but you want to have internal deadlines to ensure the project executes on time.

File management

Most projects involve some sort of (electronic) documents. These can be office documents, images, archives or any other type (apart from executables or scripts). This will act as a central repository for all the documents. As well as just storing all the documents, it will also version them, meaning when you upload the same document again with some changes, instead of overwriting the file, it will keep both, but the new upload becomes the master copy, with the old being kept in case you need to revert back/see changes.

Time tracking

This is useful in projects which are billed hourly and fixed price projects. With billed hourly projects, you need an accurate breakdown of how much time was spent where, and with fixed price projects, you want to keep the total amount of hours down as much as possible, so with this you can see where you can improve efficiency. How this will be implemented is yet undecided, but it needs to be as streamlined as possible to encourage use.

Dashboard

This is the landing page in the application and it shows a summary of everything that is going on. It will be different for each user, based on the projects they’re part of. It will also be possible to focus the dashboard on a single project as well as all the users projects.

Posted in About. No Comments »
« Older posts