Thread

No, I really do! I’ve been using EE for 3 years and 2 months (had to look that one up 😊 ) now for my own site as well as clients sites, and when asked for the best system, most times it’s EE that I recommend. Still, when confronted with new needs for new projects, I often end up surprised how easy things get done with EE. So, please bear with me when I point out where EE could do even better - or where, in fact, I’m afraid development is moving in the wrong direction.

EE is taking one huge step after the other, and while new features are always appreciated, the first focus should be to consolidate and integrate existing features. This is often overlooked in development, but all the new gimmicks don’t make up for lack of usability with the existing ones.

Examples:
- Please stop referring users to 3rd party modules for vital or frequently needed features. Call me a coward, but here’s why I use a commercial cms in the first place (and not drupal, or mambo, or…): Because I can be reasonably sure that all known features will be available in future versions, too. Without twisting, bending or self php programming. That’s one of the main reasons I spend my project money here time and time again!

- EE really needs that “Stand alone edit form” in addition to the “Stand alone entry form” - without any third party modules (which might be forgotten, abandoned or become obsolete). In fact, it shouldn’t be necessary to code 2 forms - the saef should create a new entry when no entry_id is specified and edit an entry if there is an entry_id in the url. (Now I know enough about programming to understand that this isn’t an easy one, but it would be logical in coding - and coding logic should be the main focus in development!)

Alright, there’s form helper. 3rd party module, see above - although it has helped me a lot in the past. But form helper doesn’t handle related fields - because it’s development has stopped long ago (see?).

And the SAEF functionality should allow fields to be rearranged without php coding - as that’s the main - no really, the only! - reason I use stand alone forms: because as soon as you rely heavily on custom fields, the CP entry form is getting ugly and awkward to use.

Why do I try to keep my users from the CP Publish Form?
- Save/Preview Buttons should be below everything else. (Even with the 3 default entry fields, when showing a new user how to do it, they enter their data and then look around confused. Even if they have seen the buttons upon entering the page, after entering the data, they need a pointer. I need to tell them time & time again: “HERE is the Save-Button”. This could be avoided.
- A custom field with max-length of 10 characters is still displayed as a whole line in the publish form. Ever had to explain to a new user why the field does not accept any more characters although it stretches across the whole screen?
- Dates, Categories and Options all have their own “tab”. Now this is a hard one, as I, being used to the way EE works, really like it that way (and I guess others do, too). However, each and every new user keeps forgetting about the tabs. Not only the first time they’re using it, but also when using it again after some time.
- TAB overflow. You have tabs within the publish form, tabs to navigate the admin interface, tabs to sub-navigate within the publish interface. Again, I’m fine with it, but tired of explaining it to others. TAB-Customization is a help, but it doesn’t go far enough. (Even if I provide a “new tab” for features the users really need, I cannot get rid of the “modules”-tab - confusing!)

- Image handling. I often end up using a gallery for images, as this is the only way to generate thumbnails without further user input (without using 3rd party code; see above). It feels absolutely logical to me, but needs a lot of explaining to new users. Especially if you’re trying to provide a stand alone edit form, which (see above) cannot handle related entries without extended php coding (which again might be unusable or need to be reprogrammed for future versions.).

- File upload. When a File upload is needed, there should be an option for the user to just “upload” and “add” a file - without chosing directory, deciding between “add link” and “add file”, and having to look at the confusing “view” options. Again, there are modules/plugins/extensions for that purpose, but… see above. Again, it’s fine and easy for me - but not for people who don’t do internet publishing every day.

[eta] So, if I had a free wish, I would wish for the team to attend to the topics that are asked again and again in the forums - without a real satisfying solution. I’ve been part of a development team, too (although not in php), and I know that it’s more interesting to explore new fields than looking at all those old issues again (yawn) and again (double yawn). But, please, dear EE developers, think about it.

Not knowing what’s in store for EE-2.0 but hoping for a lot…that said, I do agree with several points you’ve made chronistin, especially the file upload (and image manipulation), that’s been a thorn for quite some time, and the SAEFs, they come up as a recommendation so often (daily?), probably more than the file upload, that they should probably be core by now.

Like you, I love EE and wouldn’t switch but some things could just be easier or core. As far as stepping on 3rd parties, I would think it should be understood that obvious additions or key useful features will be made core even if it steps on a 3rd party. I think most 3rd parties understand that and have developed things just to temporarily solve a problem until the core can do it.

I can certainly appreciate your thoughts, but I’m not sure I agree all that much and there in lies the issue with developing a CMS…  It simply cannot be a silver bullet for everyone.

For instance, IF Ellis Lab chose to include a bunch of modules as part of the core system, we would end up with a bloated application.  I don’t want that!  And many EE users don’t want that.  EE has always been intended to be a flexible, yet extendable system and Ellis Lab continues to achieve that.  Why not create a custom installation with all the bells and whistles you want and just duplicate that installation for new installs?

As for explaining things time and time again to clients… I doubt there is a solution to that.  It’s just part of it.  Apple products, notorious for good usability, still have a learning curve.  Harder for some 😏 .  EE is still in it’s infancy and overall it is pretty well laid out and logical.  I’m sure it will have vast improvements in EE 2.0 too.

Still, when confronted with new needs for new projects, I often end up surprised how easy things get done with EE. So, please bear with me when I point out where EE could do even better - or where, in fact, I’m afraid development is moving in the wrong direction.

I certainly appreciate Ellis Lab’s attempt to keep things minimalistic.  All too often applications evolve into bloated messes.  I believe EE is evolving without excess bloat which leads me to believe it’s moving in the right direction…

Sorry for disagreeing (respectfully) with you here.  My intent is to share my vantage point which may be in opposition of yours.  I have confidence Ellis Lab will figure it out.

Thanks chronistin for writing this post. It’s rare someone can write any sort of criticism on a forum without getting the obligatory “if you don’t like it use something else” response.

I don’t want to use anything else because like most of us here, I love EE; that’s why I’m registered in the forums. Each incremental upgrade gets better, IMO. However, I do agree with some of the points made regarding SAEF and the reliance on modules for frequently needed features.

One example is the ability to add tags to entries. Tagging is a common, expected function on the web and yet, EE does not have tagging as a core function. There is the Solspace module of course. But I’m annoyed at the idea of paying for such a common function as tagging. In addition, the current version of the Solspace tag module has disappeared from their site and the “2.0” version has been in development since May 2007.

I was hoping tagging would be introduced in 1.6 but it appears that functionality has been left to Solspace. I think this speaks to Victor G‘s point about the relationship between third party modules and core EE development.

It simply cannot be a silver bullet for everyone.

True, but that’s not the point exactly, it’s making the most often used/requested part of core.

we would end up with a bloated application.  I don’t want that!  And many EE users don’t want that.

If the feature/function/plugin/module (SAEF for instance) is constantly being used, adding it isn’t bloat.

As for explaining things time and time again to clients… I doubt there is a solution to that.  It’s just part of it.

Agree with you there as there isn’t one way that will be clear to “all”.

I believe EE is evolving without excess bloat which leads me to believe it’s moving in the right direction

For me, the Gallery is bloat as I never use it, just build them with the weblog module. One mans/womans bloat is not anothers.

Thank you all for thinking with me. Some interesting input. I too, am hoping for EE2.0. (Feels like waiting for christmas 😊 )

Victor G: 1. You are right on usability standpoint and there is always room for improvements. (but look at the *other* they are much much worse)

I definitely agree. That’s why I took the time to write my experiences down - with EE, it can be done (in fact, we’re almost there), while most of the others are hopeless when it comes to customization.

2. the modules part, i agree too, but you must understand that Ellislab cannot easy build-in modules that are available from third-party people (the commercial ones) that would hinder future developments from those people.

That’s a thought I don’t like at all. Don’t get me wrong, and with all due respect to the third party people (who do great work, too, and should be able to make some money with that!) - but things that people expect as basic functionality should not come from the outside, and shouldn’t have to be paid for extra. Now to define what’s “basic functionality” - I would say the features that get asked for with a certain frequency.

stephenslater: As for explaining things time and time again to clients… I doubt there is a solution to that.  It’s just part of it.

Explaining IS a part of it, but there’s a difference in how often and how much. I attached to files from a recent project, field names blurred out, but I think you can see the difference between a form that needs a lot of explaining and a form that needs just a little explaining.

Sorry for disagreeing (respectfully) with you here.  My intent is to share my vantage point which may be in opposition of yours.  I have confidence Ellis Lab will figure it out.

No problem, in fact I agree that the core system should not get bloated. But as PXlated says,

If the feature/function/plugin/module (SAEF for instance) is constantly being used, adding it isn’t bloat.

j. brotherlove: One example is the ability to add tags to entries.

Personally I never missed those, as you can “fake” tag functionality quite well with the flexible category system. Needs a little more work on the author’s side, though.

Off to get some work done 😉

One example is the ability to add tags to entries. Tagging is a common, expected function on the web and yet, EE does not have tagging as a core function.

Just as a counterpoint—in working on 20+ EE sites I’ve yet to need tagging.

One person’s “killer feature” is another’s feature bloat.

TRackbacks ftw!! (runs and hides from Derek)

TRackbacks ftw!! (runs and hides from Derek)

How did you know I was lurking?  ::bonk::

For instance, IF Ellis Lab chose to include a bunch of modules as part of the core system, we would end up with a bloated application.  I don’t want that!  And many EE users don’t want that.

I can’t agree with that one. One of the advantages of EE lies in the fact that you do not need to install/activate modules, plugins and extension you don’t need. So, there is no “bloated application” because of this modular approach. While I do understand that the resources available for developing EE are limited and therefore additions are carefully decided, the “bloated” argument for the application itself shouldn’t be the key.

In addition, I don’t know on what foundation your statement is based that “many EE users don’t want that”. As already mentioned, I’m as well not using the gallery - no problem. I’m not using other modules as well. And I don’t use the MSM. Is all that “bloated”? I don’t think so. But as already mentioned before in another thread, I would always be happy with every addition that EllisLab chooses to implement in the basic distribution (to differ from Core). 3rd party additions are great, but there are risks incorporated when using them - and not everyone (and every customer) is willing to accept that risks or able to develop and maintain custom solutions.

That said, I really like EE and I do see the massive amount of work spend in development and support. Thanks for that, guys (and girls 😉).

-Markus

Let me clarify… If they stay “modules” as you point out, then that won’t necessarily make bloat, but if they try and make a lot of the third party modules part of the core application (which in my mind means integrating it into the system), we will indeed end up with a bloated application.

In addition, I don’t know on what foundation your statement is based that “many EE users don’t want that”.

I think my statement can be backed up based on many, many comments in these forums.  Two people have already agreed in this thread.

Explaining IS a part of it, but there’s a difference in how often and how much. I attached to files from a recent project, field names blurred out, but I think you can see the difference between a form that needs a lot of explaining and a form that needs just a little explaining.

The way EE displays custom fields inside of the Publish tab is pretty straight-forward, but probably will never achieve what is possible with custom designed forms.  Your screenshots are nice, but I’m not sure the one you say is easier to understand can be achieved with custom fields inside of a CMS…

Check the attached screenshot to see what I mean.

...although the idea of being able to have custom fieldsets is a nice idea.  I’m anticipating a lot of AJAX used in EE 2.0 CP, so I’m sure we’re in for a nice surprise.

[eta] So, if I had a free wish, I would wish for the team to attend to the topics that are asked again and again in the forums - without a real satisfying solution. I’ve been part of a development team, too (although not in php), and I know that it’s more interesting to explore new fields than looking at all those old issues again (yawn) and again (double yawn). But, please, dear EE developers, think about it.

We do, every day, usually for 12 hours, sometimes more. And that’s all I have to say about that. 😊

I say the existing modules by third parties is perfect. It answers a need and helps EE developers who have the option of usiing an existing one or paying for development for a new one that’s needed.

Avoiding bloat and an overloaded system having modules and extensions not needed is important as well.

Over a year ago I had a client who wanted a specific feature that did not exist. We had solspace make it on custom order, and got a discount by allowing it to be released as a module publically. It’s now known as Gallery Extended, and development has continued on it since then.

I have ran into having to explain many features to clients. Those which require explaining numerous times, I now make a tutorial with screenshots and refer clients to them. This is working perfectly, giving them a quick reference and saving me time going over the same things. There’s also excellent tutorials at EE 😊

.

One example is the ability to add tags to entries. Tagging is a common, expected function on the web and yet, EE does not have tagging as a core function.

Just as a counterpoint—in working on 20+ EE sites I’ve yet to need tagging.

One person’s “killer feature” is another’s feature bloat.

I’ve also never built a site with tagging.