Spencer Hill

Thanks for correcting me WPyogi, I totally didn’t see that!

leejosepho, I don’t understand what you’re saying. “until after you put something in it at the back”?

WPyogi, so I’m slightly confused now about how to achieve my goal. Here’s the lik to the page, and you’ll notice the meta information in the lower left. That should appear in the white area on the left instead.

Thanks for all your input everyone!

Thanks for the input WPyogi, but that doesn’t seem to be right because that file doesn’t exist within TwentyTwelve (by default).

Thanks for the response.

I do have a static front page set. So does that mean it will use something beside index.php then?

Bob, I hope my explanations were helpful to you. I sincerely was trying to help but I see how what I’ve said has come off arrogant and stubborn, and maybe offensive to you.

I’m passionate about successful project management and over zealous about this topic.

As a fellow user of this plugin I want my opinions to be considered in it’s development and I thought my explanations would help non-developers understand some possible reasons why the author of this plugin stated he didn’t have an ETA as to when this feature would be introduced.

Again, I’m truly sorry if I frustrated you!

Good luck whichever way you go.

Ellsweb, we’re not officially associated with the author of this plugin. We’re simply forking it (creating an alternative version of our own) with the intention of submitting a pull request that we hope the author will accept.

ellsweb, since your the second person who seems to think I’m arguing I suppose I should clarify:

1. Our fork of Propel is being merged with our fork of WPPM. So we view ourselves as a contributor, not a competitor. And that’s why I’m in this conversation.
2. I’m sincerely trying to help anyone who believes that a front end UI is necessary by advising them to rely on a platform other than WordPress (such as Drupal or Basecamp). This is because the nature of WordPress encourages users to rely on their admin UI instead of reinventing the wheel (which is why there are design standards regarding administrative UI’s nowadays).

Of course you’re all welcome to do whatever you please, you’ll probably just have better luck with existing platforms if you’re looking for a front end UI.

Since I now understand that you’re not a developer it’s clearer, to me, why we have a disconnect.

If you don’t want users to sign in or access the back end; then I would recommend you seek out a non-WordPress based application (AKA Basecamp). I think it’s uncommon, and seemingly nonsensical, for someone to view membership and WordPress’ back end as “cumbersome and wholly unnecessary”.

I can’t think of a single project management tool that doesn’t require any users to sign in before viewing the data. So even if the developer of this plugin chose to display the data on the front end it’s still most likely that users should have to sign in (even if they stay on the front end). Otherwise literally anyone can see their projects details.

Regarding your comment about being “technically an idjit” – by the way that made me laugh out loud for several reason :p – it’s assumed that whatever solution provided must be “idjit” proof. In fact, providing them with a consistent UI such as WP’s admin UI is exactly the reason why I’m advocating for it over a custom front end UI.

Lastly, controlling how the data is displayed can be done in the front end as easily as it can be on the back end (actually it’s easier). I’d love to hear some examples of what you mean (sincerely). My staff and I have forked this project already and love to hear from the people.

I hope this makes sense to you now.

Haha, I appreciate your humbleness!

Well I think that you have to rephrase your question from “How do I keep my client out of the ‘back end'” to “How do I control what aspects of my website my client see’s”. Because displaying limited data on the front end is no different than displaying it on the back end except that it requires the plugin author to do even MORE work to add all this front end support.

What we do with our clients is we installed a respected plugin called Adminimize and Role Manager (I think that’s it I’ll have to check). Role Manager allows you to create new roles and choose what privileges they have (like the ability to add, create or view post types). Adminimize allows you to choose what things they can see like navigational items, panels, etc…

They’re extremely easy to install and configure. Literally could take you five minutes and BAM. You have a new role called “Client” that limits everything they can see.

Of course, I think this should probably be integrated into this plugin, or, better yet, WordPress Core, but for now this is what we do.

I almost completely agree with that statement. To clarify; I completely agree that there needs to be a “locked down” interface for clients. But I think the argument for utilizing a front end interface for this is simply because there is an assumption that it can’t be accomplished in the backend. Does that make sense?

+1

I have to disagree with anyone on this for this reason: this is an administrative tool, not a creative project.

I’m one of the developers of Propel and we used to have front end support and eventually deprecated it because we realized that all we were trying to do was create a new version of an administrative interface that WordPress already provides. Which is one of the most valuable features WordPress provides to plugin developers.

Compare WordPress to Drupal for example. Drupal has a phenomenal platform for plugin development. But the reason WordPress has conquered them in the CMS market is because WordPress understood that you can’t leave administrative UI up to the developers and designers. If you do, you open up an endless rabbit hole of bugs that are overlooked because the interface is changing all the time.

I’d also like to pose the question of: what’s the point?

Assuming that you have created a dedicated role for your Clients to sign in with so they only see WPPM. If you don’t have that then I do understand why one might feel a need for a front end UI.

I wondered about this as well and I suggest that the list of contributors appear in the Project Info section in the upper right.

I agree with Schleicher on this. Though the occasion is rare, we have found times where a task is associated with two people. Say, for example, the two developers need to collaborate on it to complete it properly.

Although I agree that this is an important feature, I think that a higher priority (and supplemental to this feature) is filtering.

For example, if you had a filtering tool then you could create custom filters too. Say you want to see all your projects/tasks ordered by date.

Or maybe you create categories and associate a weight to each category so they automatically prioritize by that first, then by date.

Etc…

I agree that sub tasks is a necessary feature. One of the things that frustrates me about Basecamp actually.

However, it may make more sense to associate Categories with Task Lists and Tasks because they can be filtered and grouped. But that would also only be useful with a filtering tool.

My staff and I would love to contribute to this project including developing this feature. Please contact me when you’re able. Thank you!