What "Joomla native" means to us
Joomla provides a set of rules and tools for developing extensions. If these rules and tools are largely ignored, the extension is technically not very "native". The problem, or the reason why developers do this (knowingly), is because the existing tools do not meet the requirements of what they are trying to achieve. So they move on to create their own custom code and then end up with a weird mishmash of Joomla native and custom code, usually causing all kind of negative side-effects.
The reason why I'm explaining this to you is because even today, with Joomla 1.7, Projectfork 4.0 will require its own custom tools. However, instead of deviating from the Joomla framework, Joomla provides rules for developing custom tools and code which effectively help keeping everything "native".
In a nutshell: Projectfork 4.0 will use the existing Joomla framework as much as possible and extend on it accordingly if necessary.
Some features will be left behind
We went through our list of Projectfork 3.0 features and discussed the pros and cons of their current implementation and we even went so far to question the existence of some. In the end we've decided to entirely remove the discussion board and the calendar in Projectfork 4.0.
The discussion board may have its uses, and some companies or organizations appreciate it, but we think that it is not the best tool to communicate and share project-wide information. There are better and faster tools such as phones, Skype, or even Email. And besides, our implementation was simple at best. If you really need a discussion board, there are way better solutions out there and we might even get to a point where we can offer a direct integration with Projectfork.
The same goes for the calendar. Our implementation was too simple and there are way more sophisticated solutions out there for which we can provide integrations in the future. However, we will keep the "mini calendar" on the dashboard and improve its usefulness so that you still have a good overview of all your projects and tasks.
New concepts and ideas
The biggest challenge for us, when thinking about creating Projectfork as a native Joomla component, was to figure out a way how to take full advantage of the Joomla ACL system in a way it would be easy to pick up and to maintain over time. Projectfork relies so heavily on flexible and custom permissions that we've spent most of our time brainstorming and debating the pros and cons of various approaches. Since we're leaving our own framework and ACL system behind, we can't jump in and change the Joomla ACL to our liking. So we have to get it right on the first try.
Luckily we've met Alper from BAS Graphics & Design at the Joomla Day Austin who is using Projectfork for himself and his company since 2006. He helped us a great deal in figuring out how to handle the whole ACL aspect and we came to the following solution:
The "system admin(s)" or "website owner(s)" create companies. These companies are essentially empty Joomla user groups and serve as container for the Company departments within. Company departments are child-groups of the main company group to which you can assign both, users and permissions. When creating a new company, a "default" department is created automatically.
The final part of the ACL comes to play when creating a new project. Each project automatically generates a unique Joomla viewing access level (think menu items). You can then assign companies to have this viewing level so that all the underlying departments of these companies can "view" the project. However, in order create or manipulate project data, the user must have the proper permissions which he has previously inherited from his company department(s).
Speaking in non-technical terms, it would work like this:
You create a company with all its departments. Then you assign users and permissions to the departments. Next you create a project and assign the companies that should work on it. That's it.
Setting up the company and the departments is a one-time step only. You can re-use the same company setup for any other project.
Concerning tasks
We've also spent a lot of time thinking about how to improve task related features:
We intend to add task and milestone dependencies, so that you can have a clear project workflow and an order in which the tasks need to be completed. Furthermore, we're adding "task lists". Task lists let you group tasks into categories, for example: Design tasks and Programming tasks. So far, milestones pretty much had this extra role of categorization. In Projectfork 4.0, milestones will be on a completely separate page to offer a better overview on the progress of the project, but you can still filter your task list by different milestones.
Another thing we're going to add is the ability to quickly add tasks, lists and milestones from the overview pages, so you don't have to load the entire form for every single item you want to add.
The Dashboard
In Projectfork 3.0, that dashboard is just an empty page with a fixed layout and panel positions. That makes the dashboard "just" a collection of panels which show different kinds of information. You can add and replace panels at any time. We're taking the the same concept to Projectfork 4.0, only that the "panels" will be replaced by regular Joomla modules (which you could also display anywhere else on your website).
Furthermore, we've decided to remove the "Project details" page that we have in Projectfork 3.0, and let the Dashboard be exactly that: A summary page of all the relevant project information including project description, progress and more.
Joomla features out of the box
As mentioned, we're trying to take full advantage of the Joomla framework which gives us a number of features almost "out of the box" such as: Caching and SEO, Menu item system, plugins and modules, API capabilities, remote updates etc.
<kyle>
Moving from Projectfork Themes to Joomla Templates
Currently Projectfork (v3) uses its own theme engine to theme the component inside the existing Joomla template, Joomla admin, and on the frontend with no Joomla template wrapper. Themeing for these 3 scenarios is far from ideal and riddled with compatibility and usability issues.
Since we're getting back to being native Joomla (where components don't and shouldn't control the themeing), Projectfork themes as we know them will go away. The current premium themes (Carbon, MyProject & Goggles) will be converted into regular Joomla templates. This is actually more valuable since you'll get the style of those templates for your Projectfork intranet, and the rest of your Joomla site so everything matches! Alternatively if you have an existing site template and just want the intranet look for Projectfork, you can simply assign the template to only Projectfork menu items.
The administrator backend portion of Projectfork however will be flipped to standard/native Joomla admin administrative views, which will feel exactly like other Joomla component admin views, but for managing Projectfork data (instead of Article Manager think Task Manager).
</kyle>
Code contributions
So far it was very difficult for us to let you - the community - contribute directly to the project in the form of code improvements and new features due to the nature of SVN. Reviewing and merging code changes in SVN is atrocious and can easily delay the whole development process. And the reality is that a lot of people want to contribute but they lack the proper skills or knowledge to make a worthwhile and functional contribution.
Kyle and I always wanted Projectfork to be in an open development environment where people from around the world could make a contribution just like that. But the proper infrastructure was missing. And with SVN system we would have risked to lower the quality of the project.
With Git and Github, we think we just have found the solution for exactly those problems. From now on, Github will serve as our code HQ and everyone is invited to watch, fork and contribute!
Closing words
The roadmap does not include every little detail, but it gives you a good overview of what's to come in about 6 months from now. Projectfork 4.0 is more than just a "change of code", it is an evolutionary step forward to embrace the future of Joomla and everything around it.
Sometimes I wonder why Projectfork has undergone so many changes in the past (and now we're doing it again), whereas other projects seem to keep on the same route forever. Is it because they did everything right and there is no need for them to adapt or the need of fundamental reconstruction? Or is it because they don't dare to admit the flaws in their designs and just go with it. Or maybe they are too lazy to do what it takes to keep up with technology, or even afraid of new approaches. I don't know the answers... but I do know that I want this project to move forward into the future of Joomla and web technologies. And for that, it sometimes is necessary to think again and adapt.
I also know that Projectfork 4.0 is not going to be perfect. Nothing ever is, was or will be. The Joomla framework offers a lot and it does some things right and some things wrong. It will continue to evolve and to improve, just like Projectfork does. And that is everything that matters.
P.S.: I love cheesy blog post endings. Seriously though, I'd love to hear your thoughts and ideas about Projectfork 4 in the comments below.
