EllisLabs, the developers of ExpressionEngine, run a sister-project named MojoMotor. Mojo is pitched as “The Publishing Engine That Does Less” - a sort of shoe-in to the ExpressionEngine way of thinking for smaller websites. Despite doing less, MojoMotor actually has a pretty nice WYSIWYG editor built in.
The MojoMotor Editor is built on CK Editor - the same open source project that powers Wygwam, the powerful editor that we use on almost all of our ExpressionEngine projects.
Having a basic WYSIWYG editor will fill a void in the basic toolset of ExpressionEngine while allowing third-parties to extend further.
Memberships, forums and wiki using the standard template system - it’s as simple as that.
One of the key usability reasons for using Assets over the default file field is the fact the developer can chose between List or Thumbnails view as a default. I’d be surprised if this wasn’t in EE3, if not a later version of EE2.
Working with Devotee, we hope to see a central application distribution mechanism in ExpressionEngine like Wordpress. Taking the concept further we’d like to see the ability to have different repositories, so a website could chose to use Devotee or something else. We’d certainly take advantage of this, running our own internal repository of our frequently used extensions which could be installed and updated with one click.
Again, Assets does this perfectly. With EllisLabs understandably not wanting to stand on the feet of their advocates this becomes a little less likely. However from a developer perspective it adds extra value to the default installation of ExpressionEngine.
Right now a channel may have any number of categories associated with it. This has proven to be really powerful but for some reason the same is not true for Channel Groups. Allowing developers to have many groups to a channel would allow for less repetition.
Perhaps the more prominent need for this feature is for Search Engine Optimisation.
At this point, we feel like this is missing for a reason and EllisLabs has little desire to add it. Gypsy used to fill the void in ExpressionEngine 1 but no real alternative is supported in EE2.
The template system in ExpressionEngine is brilliant. If you can think it, you can build it. At the moment the framework can be split into two logical layers, “Template Group” and “Templates” within it. We propose a third, higher level for “Template Sets”.
Every site would start with a “Default” set but any number of additional sets could be added. The model could embrace inheritance, where every subsequent template would inherit from default.
A template set system would ease delivery of multi-lingual sites, allow for better mobile and accessibility as well as simply offering the user a choice of how the website looks.
It would also allow for development of two designs within the same site for the smaller builds where a development server probably isn’t needed.
At Rye we go to great lengths to make the control panel as easy to use as possible. At this point it barely looks like ExpressionEngine other than generic structure. And that’s the problem, sometimes we don’t like the structure. We’ve already covered the Wiki, Forum and Member areas but this one is slightly different as it’s “behind-the-scenes”. Unfortunately it is probably a bit too difficult to expect all templates to work with all potential plugins.
As with above, it would be nice for developers to pay a little bit extra for White Label support. We wouldn’t use it, ExpressionEngine is a badge of honour for us but we certainly see a market for it.
The recently released Responsive Control Panel goes some way to solve scratch this itch, but we’ve had many clients ask if they can update their site from their phone. The current solutions are weak but frankly this is a really difficult challenge. Most EE websites rely on advance tools such as Assets, Playa and Wygwam that couldn’t be easily replicated in a native phone application.
Perhaps the best way would be for EE3 extensions to have two sets of views, “full” and “light” for desktop and other devices respectively. Likewise extensions could override rules so that a fieldtype of “Wygwam” falls back to a basic textarea and the post cannot be set as open until the formatting has been approved on a proper computer.
Realistically though, this isn’t a very scalable option and unless it’s done right it shouldn’t be done at all.
We don’t even really want this one! The commercial grade support and tight community is one of the key advantages of ExpressionEngine. Many free (more so open-source) projects fall apart under the weight of the demands from the community and we’d hate to see that happen to EE. An open-source EE inspired CodeIgniter CMS however would be very interesting.
ExpressionEngine has a bright future ahead of it. The biggest barrier of entry is the cost of the licensing from EllisLabs and third parties. Bundling more (frankly essential) features into the core distribution would allow for a much more competitive price and expand our community in a positive way.
What do you think? Are you holding out for the golden feature, strongly oppose first-party additions or couldn’t care less? Let us know in the comments below!