Future Orchard Roadmap

Several of you have asked us to provide some info about our roadmap and what we are planning for Orchard 2.0. The dust has not settled on the design board yet, but we are ready to start sharing some of that stuff. My plan for the following days/weeks is
to write a series of blog posts exposing some of the planned features and the preliminary design. The first one is Tokens and can be found here:

Autoroute: automatic generation of URLs following configurable patterns. If you want your blog post URLs to look like http://mysite.com/blog/2011/7/22/best-thing-evar,
you will be able to get exactly that, through pure configuration of the site. This feature will rely heavily on Tokens.

Projector: build arbitrary queries on your contents from the admin and construct their HTML representation on the site. We like to describe this as Lists done right.

These are some of the things we are looking at right now, but Orchard 2.0 will be more than that. We have less details available at this time about other features, but we are building around four pillars:

Turnkey: it's effortless to create, manage and deploy sites with Orchard.
This includes an install free and update free cloud-hosted service, a recipe gallery with more recipes available, more themes, and modules to address common scenarios.

Platform: Orchard delivers a production-ready platform that scales and performs to meet real-world demands.
This will include our work on Azure as well as further improvements to our shared hosting story. We will also optimize the site, module and theme development workflow overall.

Commerce: Orchard delivers a competitive solution for small and medium businesses to make money from their sites.
By the time 2.0 ships, we will have out-of-the-box scenarios enabled, probably through integration of popular third party systems, as well as a flexible foundation for building full custom commerce solutions.

Ecosystem: Orchard has a vibrant ecosystem and community, that encourages participation and contribution.
OrchardProject.net is your one-stop place that aggregates all the activity of the community. We'll add showcases for you to publish your case studies or generally share your creations in a gallery of Orchard sites, you'll see more videos and tutorials from
us and from the community. We'll also improve our gallery with reputation, profiles and stats, and with a better publication system that integrates version control. You'll have more ways to extend Orchard with recipes and translations.

And of course, I'm sure most of you are wondering when all that will be available. We are aiming at a first pre-release mid-September, and the actual 2.0 release in early Spring 2012.

Thanks for this. It's great to know the feature-level direction of the product that the core team is going in. Can you talk a bit about the team's philosophy on open source development as it relates to determining these features as well as the
division of tasks and progress towards these features? There are all sorts of open source projects: some are run in isolation with code drops every once in a while, others are completely open with a public backlog. My feeling so far is that
this project falls somewhere in between. The team does a great job interacting with the community on the forums for troubleshooting / architectural assistance, but I feel a bit out of the loop on the project management side until you drop a note like
this or official code drops. There's no right or wrong here, I'm just trying to determine the amount of transparency the team is interested in at this point.

For instance, are you driving development by
http://orchard.uservoice.com, or is this just a temperature gauge on the user base? Are there any plans to increase transparency and resolution on future planning and development, or has the open source philosophy been already firmed up and implemented
on the team? Or maybe the transparency already in place and I just haven't found it yet?

That's a fair observation. So far, we have been very focused on our vision of CMS and on delivering the base platform. Because of that, design has been so far done by the core team. Our reasoning was that a CMS project is a little different from other
types of applications because so much can be done as additional modules. We believe that most innovation will happen in the future through third-party modules, and to a lesser extent from the core. The core should just be an enabler for third-parties, and
be the materialization of the platform philosophy. Indeed, we are beginning to see some interesting stuff popping up on the gallery. The hope is that some of those modules one day join the official distributions of the application.

But even for the core, we think we are going to progressively yield more control to the community. I might as well talk about that here although we're not completely ready and are still figuring out the details. Our current idea is to have a steering
comittee of sorts, composed of key members of the community, that we would pick for the first batch, then quickly switching to a model where they are elected. This comittee would be included in key meetings way sooner than it has ever been the case so far.
In the end, it's what code gets committed that counts, but we do completely recognize the need to be more inclusive in the decisions we make. I've seen this model work well in other Open Source organizations. As for UserVoice, it's been an invaluable
tool for us to understand the priorities of our community, and we continue to use it for that.

I absolutely understand and agree that most of the future functionality gains will come from modules. From a module developer's perspective, I believe that increasing transparency and resolution on current and future work (especially in core and framework)
can help module developers work with you and accelerate the platform. When you are ready, an excellent first step would be to expose the core team's current task backlog, sprint and sprint tasks. Even if they are changing (which I'm sure they do
frequently), it would allow the community developers to keep pace, get an idea what's coming down the pike and set a better direction for their own modules. Then down the road, opening up community involvement would be awesome.

Mmmh, yeah, that's what we 're trying to do here:
http://orchardproject.net/docs/feature-roadmap.ashx, although it's not as detailed as what you're asking for. It should give you an idea of what we're doing, without having to go through dozens of work items. We do have a view of our Zen board that is available
behind a password on our site, but it's actually the first time I'm hearing a request to make it public. But if enough people really want to see how the sausage is made, well, we could I suppose remove the password in front of it.

I am for a more transparent roadmap because it has a direct impact on developers. For example, one of the projects I am working on needs a feature like Token. We had planned to implement that feature ourselves, but I am glad we may not have to (depending
on how usable the September pre-release is).

So, I would like access to this password-protected website for my own planning as well as out of curiosity for this great platform :)

On the other hand, I am a bit concerned about the negative impact this could have. We all know that software design is part science, part art. And I wouldn't want the developers to lose their focus because us developers start over-analyzing and second-guessing
every little design decision.

Let's give it a try and change strategy if things get out of control. I like the committee idea, and they could eventually be the only ones who have access to that website.

Regarding the roadmap, I am very interested in the Projector feature as well. Yet another thing I was looking into building myself. Although, I am looking more into being able to build an experience like this:

http://www.bing.com/shopping/search?q=tablet

On top of providing search, paging and sorting, it also generates "facets" to filter per category. And there is also the ability to change the view (Grid/List).

If you accept feature requests here, a core feature I would really appreciate is the ability to have the content item editing experience on the front end of the website (instead of having to go to the Dashboard). This is really important for any scenarios
where we want users to be able to contribute items (a little like how they can write comments on blog posts).
In a way, it is a generalization of this feature request: http://orchard.uservoice.com/forums/50435-general/suggestions/635753-forms
Edit: I also found this which would be a great improvement on the online content type creation story: https://github.com/botskonet/jquery.formbuilder
Demo here: http://experiments.botsko.net/tests/formbuilder/

The roadmap looks good but here are acouple areas I would like to have seen improved upon within the core..

1. A better Moderation pipeline, I think whats there at the moment is a good start, but if you look at what a news team do for example, they create a piece of content and submit to thier editor for moderation.. and then the editor would publish.. Although
you could lock down the publish to the editor role, I dont this this is enough.

2. Inline editing without having to jump to the admin page... I think this would make the page editing experiance much better.

3. A more dynamic widget view. Where I work, we have a page canvas that allows our front end developers to move modules around and see what the page looks like there and then... If you need examples I could email them to you if you want? - Im not saying
what we have is perfect, but the experiance is quite cool and one of the only features of our CMS that I actually like.

So a Layer is just a collection of widgets right? So instead of seeing a list of widgets? why not have an option to see those widgets on a page canvas view by layer?

You could expand on this... When an author is creating a 'Page' content type, they could have a view of them creating that content within a 'uneditible widget view' for example of that page canvas (not sure about the layer at this point), this allows them
to know how the page will look after it has been published, rather than just a text area and title...

Have you any ideas on how this would work? (I completely forgot about the layer scenario tbf)

I really think that there should be a more flexible experience when it comes to content item editing. Having to go to the dashboard doesn't work for any scenario where the end-user is a regular member. That's the case for any community-based website including
social network/ecommerce/forum/wiki or filling a form like survey/poll/RSVP. Going to the dashboard is too intimidating and disruptive in the user experience.

If it becomes possible to edit content items and view them in the front end, then only the admin will need to go to the dashboard (for admin stuff).

I understand that it will require some big changes in the core, but I really hope you will consider it. That's what a v2.0 is all about :)

@Jetski5822: good suggestions about the experience, specially the front-editing.

@bertrandleroy: I agree with you about the widgets/zones/layers visual interface, it can be built now with some js, and with supporting drag and drop. Also after a drop, a small menu will appear with a check-list of available layers to select the moved
widget will be displayed in the dropped-in zone for what layer.

BTW, I think the docs are very cool, but need more work and examples for advanced development situations. Is there any news about any book in the way covering the Orchard topic?

Regarding the roadmap, I was disappointed that there was no mention of enhancements to page templating. My company currently does 40-50 CMS sites a year (we use an in-house CMS), and we have been keeping Orchard on our radar since the project was in it's
infancy. We would love to move away from our proprietary system to a framework like Orchard. The reason we have not adopted it is that there is no easy way to give our clients the facility to change the layout on a per-page basis.

For example, a typical site for us will have a home page layout, a default sub-page layout, maybe a blog, and a couple of alternate views (page without/sidebar, split view etc.). One of the things that our clients love to do with a default content/sidebar
layout is type in content in a main zone, and then drop in page specific content in the sidebar. Another example might be on a contact page - in the main content zone the client might add a WYSIWYG and then drop in a contact form underneath it. And in the
sidebar, they might drop in another WYSIWYG widget with some more page specific content. The parts for something like this seem to be in place in Orchard (zones, widgets, layers etc), but as far as I can tell, it is not readily doable for a non-technical end
user.

It probably comes down to target audience. Orchard is not targeted at John Doe, the owner of the small business down the street. I understand this and have no problem with it. But I would love to find a way to use Orchard in my day-to-day business.

Also, I definitely vote for exposing the Zen board. I have always wondered why there is no link to Uservoice on the Orchard website - if it gives you lots of useful feedback, I think it might be helpful to make its existence more obvious.

I couldn't tell for sure, but I assume that you will be providing reflection out-of-the-box!?!
This would basically allow us to use tokens exactly like in Views (eg: @Model.ContentPart.Comments.Count becomes {Model.ContentPart.Comments.Count} without any extra coding).

I wish there was also some kind of auto-completion experience inside the Dashboard, but I guess that's asking for too much :)
In any case, discovering what tokens are available will be a key aspect of this feature (for the end-user). Maybe you could extend the shape tracer to provide them as well...

For security & flexibility reasons, there should be some hooks to listen into tokens being rendered with the ability to change or even veto it based on the context. This would enable permission models per content type or module or logged user. This would
be very important (esp. with reflection) avoid hacks like writing a blog post comment containing {WorkContext.CurrentSite SecretSetting} :)

@phkuate: a token provider that reflects on content types would be trivial to build, but we're not necessarily going to provide it. Discovery of available tokens is built-in the API already. I think permissions on tokens is overkill and a little misplaced:
it's probably the underlying API that a token uses that should accept to give a value or not, not the token provider. Tokens shouldn't be exposed to be written by end-users anyway.

great to see things rolling with the committee, having more of an idea of what the core team is working on could also help the collaborators getting into the groove of the project. I for once, would value all I could learn from your methodologies and work
methods.