Thread

If you do need Tagging, Solspace makes an excellent Tagging module.

Before anyone else feels the need to vote on how necessary tagging is, that wasn’t the point of my comment.

I simply offered one example of how a common web function found in major (and often free) CMS applications “out of the box” had seemingly been handed over to a third party. In this case, one that charges a fee (and no, this is not a slam against third parties charging for modules - they do great work).

Regardless of how many individuals on this thread have “never used” tagging, it is a popular function for blogs, news, social networks and a growing number of business sites. Several people have mentioned how they’ve never used the Gallery module (I’m another one who hasn’t). But voting on which modules you use isn’t the point of this thread.

We all know that the EE developers have - and continue to - put a ton of work into this application; one everyone here loves. However, occasionally users feel there can be improvements to the product. Whether our suggestions are feasible or not is up for discussion. But it would be nice to have those discussions on this forum without responses becoming dismissive.

I think the most logical way of handling this would be like how a vast majority of the features that have been put into EE have been handled.  Place a feature request in the feature request forum.  If others find its something they think is a good feature/idea, they can throw in their two cents.  As the developers are working on things they do pay attention to the feature request areas, as it’s been noted in previous release announcements highlighting how many of the new features were feature requests.

Just my two cents.

Here’s my take on things…

Part of the power of ExpressionEngine IS the fact that I can create or use custom modules that extend the core. Exactly the thing that you see as dross, I see as a treasure. That ability (and, in fact, those modules) is part of what has built such a vibrant community of developers up around the software. If EllisLab started building in all the (allegedly) core features that are currently supported by third-party modules, it would chill further third-party efforts, and a lot of developers would look elsewhere, to systems that actually allow them to carve out a niche and/or solve problems in unique ways.

The thing that makes third-party modules interesting is that you aren’t locked in to one way of doing things. The tag module is an excellent example: Solspace’s tag module is great. I use it on my site and the site I do for work… But there is at least one other keyword module out there I know of, and it’s just as usable, if you either don’t have the money for the Solspace version or simply don’t gel with Mitchell’s design philosophy. If we had tagging built-in, who’s to say it would work the way you want, or I want?

I have more to say, but I need caffeine, because it’s not making sense in my head. ;P

I definitely agree with Chronistin but it looks like the EE2 screencast previews are making configurability of the publish/edit screen a priority. It may be the single most powerful constraint against deploying EE in organizations. A publish/edit screen needs to be used by people who did not develop the site. It needs to be as flexible and configurable as the templates at the front of the site, arguably more so because it’s in constant use.

Place a feature request in the feature request forum.

Feature request forums are great to hash out ideas and gain a general understanding of what folks want, but they don’t go nearly far enough towards helping us all understand and reach consensus.

What EE (and probably every other organization) needs, is a quick and easy way to compare relative, ongoing demand for a given feature/bug fix request (called ‘requests’ from here on out).

So, right now, if I have 10 votes towards requests, and I can allocate them in any way I wish, I’d send them all towards one feature request that I currently want - Feature B. I should be able to reallocate them at any time to whatever requests I want. Everyone else can do the same. At any point in time, EE developers and managers and biz dev and exec staff and investors and customers will have much better insight into what the customer base wants, and the intensity with which they want it.

We might end up with a bar chart of relative demand for various requests. Armed with that easily-digestable information, EE can make more-informed decisions about demand and cost/benefit analysis, etc. - and that leads to a more effective organization, happier and less-frustrated customers, higher profits, etc.

Number        |                 :blush:                                    
of Votes      |                 :blush:                                    
              |                 :blush:                                    
(i.e.         |                 :blush:                                    
relative      |                 :blush:                     :blush:      
customer      |     :blush:         :blush:                     :blush:      
demand)       |     :blush:         :blush:                     :blush:      
              |     :blush:         :blush:          :blush:        :blush:      
              |     :blush:         :blush:          :blush:        :blush:      
              |     :blush:         :blush:          :blush:        :blush:      :blush:      :blush:
              |------------------------------------------------------------------

                 Feature A    Feature B    Feature C    Bug 1    Bug 2    Bug 3

Looks like embedded rich text editor with easy image upload and manipulation it is!

:cheese:

Feature requests are not necessarily implemented on the strength of a vote.

I do agree that it would be nice to at least see if a feature has been requested though.

Feature request forums are great to hash out ideas and gain a general understanding of what folks want, but they don’t go nearly far enough towards helping us all understand and reach consensus.

To be honest, I don’t think there is much of a consensus to be reached? It’s not that those features with the most votes get automatically implemented, and vice versa. For a developer’s take on things, I recommend this blog article.

And I agree completely. The above article is needed here.
After all, this isn’t a “business as a democaracy”
it’s like most good businesses, a benevolent dictatorship 😉

And that’s a good thing.

I wonder how this old post was dragged to the light again?

And I agree completely. The above article is needed here.
After all, this isn’t a “business as a democaracy”
it’s like most good businesses, a benevolent dictatorship 😉

And that’s a good thing.

As I see it, a business is a business is a business - and not some kind of political system. (And btw, even if wildly off-topic, there cannot be such thing as a “benevolent” dictatorship. Ever. It’s just a contradiction in itself.)

The article linked above does a very good job in explaining why not every feature request will be answered and implemented. That’s fine (and not surprising). It does not say “we do not want to hear your ideas”. Feedback is a valuable help in any quality development process, and I’m sure the EE powers know that. 😊 Looking forward to V2.0.

Feedback is a valuable help in any quality development process, and I’m sure the EE powers know that. 😊

Yes we do 😊

Feature requests are not necessarily implemented on the strength of a vote.

True, but often they are, as I would argue they should be.

And the concept of a ‘vote’ need not be over-simplified. It’s one of the reasons I suggested an allotment of votes (say, 10) and talked about ‘relative demand’. My view is that customers should have a vote, and of course, they do - whether it’s formalized in a bar chart or not. Others should have a vote, too—potential customers, former customers, developers, employees, investors, etc. How those ‘votes’ are distributed is up to the company, its employees, and really all stakeholders who can and do exert any influence on the company. This voting happens all day every day at every company around the world the world - explicitly and implicitly. I would argue that companies with more effective feedback mechanisms represent a real competitive advantage.

I’m not suggesting that voting is the solution to all the world’s problems, but I do know that various forms of voting are used to choose the person who will occupy the most powerful position on earth for a four-year stretch at a time, so I think it’s possible that a software company might employ a similar strategy to help them decide on what software feature to include in an upcoming release. Makes a bit of sense, right?

All I was suggesting is that better information leads to better decision-making. Customers voting for feature requests could be a good idea. It could be a bad idea. Based on my experience, I would think ‘good’, but I’m open to being convinced otherwise and/or proven wrong.

To be honest, I don’t think there is much of a consensus to be reached?

That might just be philosophy. I try to operate on a consensus basis, personally and professionally, but we all differ. EE has their own philosophy. Consensus doesn’t have to mean absolute agreement on everything all the time - it could mean agreement about the way we’ll conduct business, treat each other, etc.

For a developer’s take on things, I recommend this blog article.

I had a tough time taking away much of a message from that blog article because of its heavy condescending tone, but that’s probably just me being oversensitive again. That article talks about customer ‘tricks’ and things like that. How much do you have to hate your customers to write something like that? I’ve done years of development and support, and I would never have thought to write a screed at my customers - telling them to stop trying to trick me, to stop using ‘+1’ syntax, etc. Kinda shocking, really.

this isn’t a “business as a democaracy”

ah, if only…  :D

Feedback is a valuable help in any quality development process, and I’m sure the EE powers know that.

and that was the gist of my post - specifically, the quality of the feedback can have a positive impact on the quality of the development process, the company’s bottom lines, etc.

As the author of the linked post, let me just say, I love our customers, and like most here at EllisLab, started as one of them.  The intent is to encourage users to make well thought out feature requests, not to stop giving feedback.  You’re saying the same thing I did (emphasis mine):

the quality of the feedback can have a positive impact on the quality of the development process, the company’s bottom lines, etc.

except you are drawing a different conclusion about whether or not polling/voting is of qualitative value rather than simply quantitative to help me and the rest of the dev team make a decision.  It’s not.  If it helps you understand it this way, pretend that anytime someone posts a feature request, we view it as a “vote” from every single user.  We don’t think “this one person wants X”, we approach it as “our customers have mentioned that they’d like X”.  And hopefully you take me at my word that we are a sharp crew that do not need a feature repeated to us in a mantra-like fashion to get our attention.

Others should have a vote, too—potential customers, former customers, developers, employees, investors, etc.

And this exemplifies why +1’s in the forums, or vote-to-the-top methods, or anything else that would be implemented by a type of measurement of forum activity, would be a poor representative sample.  Of even current and loyal customers, it’s only a small percentage that are active in the forums, and a small percentage of those that post feature requests.  Those that are active in the forums would see these numbers (as they do now to an extent with post count) and attempt to extrapolate that it is representative of all users.  It’s false reasoning, and by adding or condoning visual emphasis, as humans, the developers themselves could also be fooled into this reasoning, and lose focus of the needs of the entire userbase and begin developing an app that only had niche appeal.

but I do know that various forms of voting are used to choose the person who will occupy the most powerful position on earth for a four-year stretch at a time, so I think it’s possible that a software company might employ a similar strategy

Oh dear, may that never be our model for our software.  :-D Seriously, though, even that process is not one of popular vote, as at both the party and national level, there are still representatives that may or may not vote with the will of those who are vocal and engaging themselves fully in the process.  And interestingly enough, in that case as well, the vocal participants are the minority compared to the people as a whole.

Are we a benevolent dictatorship?  No.  Are we a democracy?  No.  We’re not nor are we comparable to a government of any sort.  We are a passionate group of people who love making software that people love to use.  Whatever ethical methods that need to be employed to continue that course will be used, and at least for the time being, that absolutely includes soliciting feedback and incorporating user suggestions, but doesn’t include voting/polling on feature requests.

+1 to what Derek said.

Can we get off the voting meme, it ain’t gonna happen, end of story 😊