Blog

We blog about ExpressionEngine, CodeIgniter, and web design. And children's birthday parties.

Subscribe to Our Feed Follow Us on Twitter

Our Favorite Blogs

Categories

7 Features It Would Be Nice If MojoMotor Had

by Adam Fairholm | October 29, 2010, 10:11am | 3 Comments

In the past few weeks, there has been a lot of talk about ExpressionEngine and CodeIgniter - two Ellislab products. Although starting a fire like those probably isn’t possible with MojoMotor - still a young product - we went ahead and titled this post to be as non-confrontational possible. Now, let’s get on with it.

MojoMotor, for those who don’t know, is a niftily little edit-in-place CMS from Ellislab. It was released 6 months ago, and since then has gone from 1.0 to 1.0.7 with some bug fixes and enhancements here and there.

But what about the future? Is MojoMotor fine the way it is, or does it need to innovate? Here’s our take.

Let’s think about MojoMotor’s main customer base. I’d venture to say that they are, like, ExpressionEngine’s customer base, smaller design companies. However, the emphasis is on design. They are companies that make small sites for smaller clients with limited functionality. These companies maybe didn’t start with web stuff - they maybe started with print design and moved into web. The sites MM should power are frequently described as “brochure sites”, and the companies that make these types of sites are the ones that should be the perfect fit for MojoMotor.

In short, they aren’t developers and developing isn’t high on their priority list. They need a CMS that is simple for clients and also simple to implement simple functionality. The simple part is key.

These smaller shops have a lot of choice when it comes to a CMS. Large ones like ExpressioneEngine or ModX have too much complexity for their needs, but ones like Wordpress and Concrete5 are geared more towards them.

Why? Wordpress has a litany of functionality and even though it requires some PHP know how, it is a plugin /cut and paste CMS at its core. Concrete5 is on the list because it’s the closest cousin to MojoMotor due to its in-page editing interface, similar to MojoMotor’s. It may be geared more towards developers in its promotion, but for designers who want in-page editing, it is a viable option.

MojoMotor’s strength lies in the fact you never have to touch PHP to make things work. Concrete5 and Wordpress means slogging through PHP - with MojoMotor you use Ellislab’s ever-present tag system. Add in the in-place editing and the lack of a full page control panel, and you have the basics of a very tempting system.

So why would anyone go with Wordpress or Concrete5 instead of MojoMotor if given the choice? Because, in our view, MojoMotor lacks some functionality that would otherwise sway a design firm towards paying the $50 price tag. For a small project, a designer may be willing to slog through PHP to save the cash.

We think the key to MojoMotor taking off is understanding the needs of the small site and attacking it with some key features (some unique, some not). Here’s our list of what we see as the top ones.

1. Embeddable Layouts

This is one that has been discussed since day one, and for good reason: even the least savvy designer gets DRY on some level. There are currently several resources available to be able to do this, but this one definitely should come with MojoMotor.

2. Simple Social Media Functionality

Even the smallest of the small clients now has a Twitter account, and they inevitably will want to put the last tweet on the page. To be able to do this out of the box would be a nice selling point.

3. No “pages” in the URL

Some clients don’t care, but some will wonder why “pages” is in there. It can be fixed, but there are several places in MM where “pages” is expected to be there. Removing this isn’t a selling point, but should be done for aesthetic reasons.

4. Very Basic Channel Functionality

Right now, MojoMotor is best suited to creating repeating content types for things like news sections. This makes sense. Instead of adding a new News item to a back end panel somewhere, the client can just create a new page and add the news item as it would be displayed anyways.

However, even in basic sites there are items that would be better put into simple lists that can be organized and edited by clients. If these can be worked into the page list, that would be ideal, since clients could see where those items went.

For example: you’ve got a board page with a list of people. You don’t want a different page for each person - just a blurb for each one. A nice solution would be to set up a channel with a title and a text box and give site admins a tag to display those the way they want.

5. External CSS Option

Right now MojoMotor puts the CSS right there on the page. This may be more of a personal preference, but it would be nice to be able to have that CSS be external as a choice.

6. More System Hooks for Developers

While building MojoBlocks, it became apparent that piggybacking on different systems within MojoMotor on both the PHP side and the jQuery side was simple and effective. However, there is certain functionality that is closed off to developers, like being able to make their add-on portable to EE2 through the export feature. A few system hooks would give developers the chance to plug into some important MM processes.

7. More Robust Native Contact Form

A large amount of the feature requests on the MojoMotor forums are about contact forms. The current one is pretty limited, so a few little tweaks here and there (including Captcha) would go a long way.

That’s it - some large, some small, but this is what we’d like to see in MojoMotor’s future.

In the mean time, buy our addon! Do it! You know you want to.

 

Filed Under: MojoMotor


Comments (3)


Excellent points Adam. 

One that could be added here is to have a built in image gallery.  That is one of a very commonly requested items.  And as of yet, I haven’t really seen a good solution!

By Jesse on October 29 2010 10:56am

I think some of these should be in the core (embeddable layouts, no “pages”, and a better contact form), but the others I think are better served by add-ons (not sure about #6 as I’m not an advanced dev).  In my opinion there shouldn’t even be a CSS layout type as that’s better served by an external linked file.

I would add that the mojo:site:page_list tag needs some better options and that an auto-updater would be very nice.

By Aaron on October 29 2010 11:22am

Another level of authenticated “User” who has “sub-region” edit rights.

For example,

Admin and Editors can create Tables and Column descriptors (fields).
Users would be able to create an additional row, edit the row and delete it.

This could be done through Forms—-> database——> report that is visible in the Editor’s edit region.  Editor being able to select which columns “public” can view (hidden, unhidden)

Or it could be in Table Form, with an Add Row button showing when a “User” is logged in.  There would also be a button for Users to log in of course.

Seems to me this is pretty basic.

By Rick Gleason on October 31 2010 3:19pm
Commenting is not available in this channel entry.