Based on recent experience, here’s some feedback on how I think EllisLab might better manage user expectation for the huge milestone that is EE2 PB and prevent your customers from falling in the forest of your web site (as I have recently done)...
My key point is that it’s as important for you to make clear what isn’t changed in EE2—especially those areas where users might expect change—as it is to make clear what has changed.
Here’s some background…
Lisa was kind enough to provide me with some straight answers to 5 questions I posed in the EE 2.0 PB FAQ: Additional Questions thread. I’m grateful for her answers but my issue is whether at least some of them shouldn’t have been clearer to me before I asked them!
I totally understand when she said…
[EE2 PB] was not a feature release, even though it did contain some new features. The focus of this was to get ExpressionEngine and other first-party add-ons built on CodeIgniter.
You will appreciate, however, that every experienced EE user will have a slew of features that he or she was hoping to see addressed and that there is therefore a huge pent up demand for users like me seeking those answers.
With that in mind, I do take issue somewhat with Lisa saying…
Most of [my queries] are answered by the 2.0 PB Change Log in the docs.
If I’ve simply missed your coverage of the topics I’ve asked about, then I apologise for wasting your time though why I’ve missed them should give you pause for thought. But I don’t see mention of them. If I’m right and they’re not there, then I suppose just not mentioning these aspects is a kind of answer in itself but not an adequate one.
In the change log you quite reasonably say…
Under the hood, there are too many changes to itemize!
On some level that’s clearly true, but there are some big ticket issues like relationships and querying category data that many, many users bump up against with 1.6.x and will naturally have been hoping to see something explicit said (but until Lisa’s response I just haven’t). Luminaries such as the good guys at Erskine Design are on record as saying a while ago that they hoped the handling of relationships would be better in EE2. Now, as EE2 insiders, they will have known the reality for some time, but most EE users will not.
So to sum up….
1. You can continue leaving the EE community (and newcomers) to figure out the answers to such issues by reading between the lines and posting the same questions again and again on the forums.
OR…
2. You could provide one or more articles/pages outlining much more clearly your strategy and your decisions not only as to what’s new in EE2 (which you have done), but also what isn’t and why (which you haven’t), so that customers both new and existing can make informed choices more easily. Surely such an approach has to be good for sales?
On a closing note, the above is intended as constructive marketing criticism from someone who is a staunch advocate of EE. I remain really excited about getting my hands on EE2 in the near future and seriously impressed with the clearly massive enhancements to the CP amongst many other things.
As a business user of an EE site (i.e., I work with an EE developer), I would like to vigorously SECOND the motion raised by watershed. I think this type of communication is vitally important.
From my perspective, the irony is: EE/Ellislab is the most communicative & transparent company (e.g., the customer feedback and service is second to nobody) yet there is, to my knowledge, really no insight into the product roadmap.
e.g., we rely profoundly on the forum module and I had unrealistic expectations (apparently) for the EE forum 2.0 (i.e., I think it’s basically unchanged if i try to decipher the answers to my questions). The forum is strategic for us (i.e., for other platforms, the feature set is advancing) but i have no clarity on forum 2.0 vis a vis the roadmap…I love EE and Ellislab but, since the platform is strategic to my business, I could really use some help vis a vis expectations since it impacts our planning…currently, the only default seems to be Lisa’s advice to work with what exists and, therefore, to have no expectations…
As a business user of an EE site (i.e., I work with an EE developer), I would like to vigorously SECOND the motion raised by watershed. I think this type of communication is vitally important.
Total agreement. It isn’t that EE folks are not communicative about such issues. They’re very communicative. What I’ve noticed is that there are multiple voices responding to multiple queries about this or that and the end effect is scattered and fragmented.
From my perspective, the irony is: EE/Ellislab is the most communicative & transparent company (e.g., the customer feedback and service is second to nobody) yet there is, to my knowledge, really no insight into the product roadmap.
Total agreement. I love you guys. You’re one of my all time favorite online companies. You communicate freely and take support and service seriously. And, your product affordable and trustworthy.
That said, I’d love to see more of a roadmap for planned feature implementation. I also know how difficult that can be (look what happened with EE 2.0). With EE finally up on CI, maybe now is a good time to address some of the specifics that can be developed safely within the 2010 to 2011 window.
e.g., we rely profoundly on the forum module and I had unrealistic expectations (apparently) for the EE forum 2.0 (i.e., I think it’s basically unchanged if i try to decipher the answers to my questions).
Other than a fix or two or three, I can’t see anything different in EE Forum Module 3.0 vs. 2.x. That’s a whole point change, though. Which means, if new features show up in 3.1, that a minor point update gets more features. But what kind?
...currently, the only default seems to be Lisa’s advice to work with what exists and, therefore, to have no expectations…
That’s the pragmatic response, of course. The one you expect to hear but don’t want to hear too often. I did some work with Pizza Hut corporate office many years ago. At the time, their internal motto was “Under promise, over deliver.” If I’m expecting three or four different features to show up in a year’s time, but I get seven or eight (including the originals), I’m quickly a happy camper. Surely, EE can say, “We plan to have this, this, and this by this date.” and deliver a few more, too.
My key point is that it’s as important for you to make clear what isn’t changed in EE2—especially those areas where users might expect change—as it is to make clear what has changed.
I appreciate where you’re coming from, watershed, but I ask that you consider what it would mean for us to communicate everything that isn’t changed in EE, or that didn’t make it that some user may have expected. Either document would be too large to read, and anyone looking for a specific item is not likely to read or find it, and one would even be impossible for us to write unless we were mind readers, and even in that circumstance, would also be too voluminous to be a useful resource.
There’s a reason, I think, that the standard in the software industry is to provide a Change Log vs. a Hasn’t-changed Log.
Under the hood, there are too many changes to itemize!
I understand that you feel that this is either evasive or laziness on our part, but it means just what it says. “Under the hood” changes are changes that are strictly at the code level and do not alter or add to ExpressionEngine’s features.
You can continue leaving the EE community (and newcomers) to figure out the answers to such issues by reading between the lines…
On the contrary, we don’t desire anyone to read between the lines. As an honest, straightforward, and accessible company, we desire that you read only what we have written, as we have written it.
Coming back to this I can see I was more harsh than I intended when I said…
You can continue leaving the EE community (and newcomers) to figure out the answers
That was an inaccurate caricature: EllisLab’s unfailing attentiveness is one of the many reasons I love EE and your response, Derek, proves that point.
In return, I think you misrepresent my thoughts when you say…
There’s a reason, I think, that the standard in the software industry is to provide a Change Log vs. a Hasn’t-changed Log.
A Hasn’t Changed Log wasn’t what I was suggesting—it wouldn’t be practical or even desirable. I have no illusions that one cannot second guess the myriad ways in which a feature-rich suite of products such as EE will be used. And I’m very aware that EllisLab need to tread carefully in terms of exposure to their competition.
Nonetheless, I still maintain that somewhere between the top level marketing of established features, what’s new in EE2, the minutiae of what’s in the docs and the over 100k forum threads, what gets lost is the ease with which users can find answers to very common questions and a ‘big picture’ understanding of functional scope.
I still think my example of the scope of entry relationships holds water. I presume that there are very good strategic reasons as to why relationships haven’t moved on. You might have decided (and here I’m speculating wildly) that add-ons like Playa do what they do supremely well and that the benefits of a vibrant add-on community outweigh the benefits of porting such functionality into EE natively. That would be a great story I imagine most EE users including me would be highly receptive to. Instead of which, seeded by reading the thoughts of Erskine Design and others, I feel rather flat when no mention of relationships is made until I ask and then all I get is a flat “No”.
Maybe my feeling deflated is just a fundamental reality of supporting a highly complex and malleable product, but I’m not convinced.
Nonetheless, I still maintain that somewhere between the top level marketing of established features, what’s new in EE2, the minutiae of what’s in the docs and the over 100k forum threads, what gets lost is the ease with which users can find answers to very common questions and a ‘big picture’ understanding of functional scope.
Most complex software have tech notes to address this communication need and, despite all qualities of the product, I still think that EE fall short in documentation because it lacks that crucial level of documentation.
I know it’s not a popular one in this forum but I support your view.
We actually strive in EE’s Change Log to avoid the detailed programmer-oriented change log, to keep it publicly digestible. Your request is understood, though, and highly technical users such as yourselves are less common among users, but an important group of users nonetheless.
watershed, I suppose I don’t see how the relationships thing could have been pre-empted or predicted by us when communicating 2.0’s changes. Is your comment perhaps predicated on the thought that we have a very close behind-closed-doors relationship with Erskine? I honestly have no knowledge of the comment by them that you’re referencing. There was a point during the Developer Preview that we asked them for some feedback on the changes, but we never heard back from them.
Hmm, maybe I’m presuming too much and my memory’s shot…
I have been presuming a relationship with Erskine that is maybe closer than exists because they got to do the Agile Records example site. I’m sure I recall reading one of their blog posts mentioning that they were hopeful for better relationships capability in EE2 but I’m dammed if I can find it, although I have found them saying “ExpressionEngine related entries can be prohibitive”. Maybe it was someone else.
I’m surprised if my level of technical engagement with EE is “less [than] common”, because I imagine myself to be only an accomplished front end coder and I’m often in awe of the depth of PHP, SQL and sys-admin magic of the very many people in the EE community who go way beyond those skill sets.
As to the relationships thing, it was mentioned primarily as an example to illustrate my larger point about very common questions. Putting that particular example to one side, I imagine it wouldn’t be too hard to analyse the forum threads and find the top issues/questions/requests that crop up again and again. From that one could:
1. Reasonably anticipate the kinds of features that users will be hoping to see development of but that you know not to have moved on with EE2, and thus pre-empt and better manage the expectations of your installed base of customers.
2. Identify areas where the docs in particular could augment the details of parameters and variables with more rounded illustrations of the kinds of things that are possible (and maybe those that aren’t), and thus reduce the burden on answering the same queries again and again.
I agree that this is a problem but at the same time I’m not sure how Ellis Lab should be handling it as it’s a very difficult situation.
I feel I’m in the same boat as people mentioned above where my business utilises EE for projects and in some ways we ‘sell’ it to prospective clients. My frustration comes from the fact that I have no idea where EE is heading. I know that 2.0 is an improvement in multiple areas such as File Management/Admin UI but I feel it still has a long way to go in other areas such as simple Page Management/Relationships.
If we had some sort of road-map we could at least then plan appropriately or have managed expectations. For example if the 2.2 release was scheduled to have an updated Forums module with a new skin then we know not to get our hopes up for 2.1 etc.. In fact I feel that’s probably the main issue, there’s not really any management of expectations so everyone gets ideas in their heads which aren’t actually realistic and it just sets everyone up from disappointment.
Apologies for the ramble but just thought I would share where my head space is at, which is in short:
I’m not sure where EE is heading or what to expect with it which makes me feel uneasy about projects and also makes me question if I’m using the right tool and if I’m going to get burnt in the future.
I don’t see how the relationships thing could have been pre-empted or predicted by us when communicating 2.0’s changes.
Other large projects publish a roadmap to address this need.
A well-done roadmap is a sophisticated tool, I agree, but it is a very useful one for customers when they allocate their own ressources for their own large projects
One solution that works well is to match the features to a version release, as in (and I’m making the example up):
- migration to CodeIgniter: 2.0
- custom fields for wiki: 2.1
- ignore user in forum: 2.2
- n-to-n relationship: 2.2 or 2.3
- one user in multiple group: 2.x
- subscribe to users stream: not in roadmap
The roadmap does not need to be deep, you can go only 2 versions above the current version (as that probably covers one year of development). And it can be revised and authoritative: “sorry we need to push custom fields in wiki to 2.2” is valuable information.
Also it’s a living document (so it’s probably best implemented over a channel, like the bug tracker). Things get pushed or removed but it needs to be consolidated, i.e. the up-to-date information in one place.
And let me explain why it is useful with the example of custom fields in wiki. It is a feature request that I submitted a while back. As things have progressed we have identified that it is a real need for us moving forward, one that we did not recognize when selecting the CMS. So we have a number of options:
1. my feature request has been considered worthwhile and you’ll provide the option in a future release, say within a year => put that section on hold and wait
2. other alternatives are too costly => drop our wiki altogether as the current solution is not satisfactory and focus our editorial energy on something else
3. need to develop that section => address the problem at the technical level and we have identified 3 viable solutions: develop an extension (currently the solution I favor the most), migrate the wiki to a blog with the standalone form (your suggestion in the orignal thread) or install another wiki engine.
What I would need right now is information on whether 1 is likely or not. I assume it’s not but you won’t tell. So the challenge is that I need to commit ressources for a development/migration but if you have planned it for 2.1 or 2.2, I’ll end up having wasted those ressources. That hurts our business because we don’t have that much ressources and we need to use it wisely (or as wisely as possible). If it’s not planned until 2.3, it probably does not make any different for us: we cannot wait that long so we’ll look at alternatives.
Let me give you a counter example. For awhile I counted on the much-discussed commerce module to sell some more sophisticated products. It was discussed (including by EE team) as planned 2.0 so we waited for 2.0 to implement those aspects of the site and worked on other areas in the meantime. Then somehow, in a forum discussion, I learned that it had been dropped from 2.0 roadmap and the information I had found was obsolete.
You can’t imagine how liberating it was to find that it had been dropped! Now I know that I could look at alternative solutions and it would be worth the effort. We ended up developing our own module but the point is that knowing that it is not 2.0 told us it would not be a waste of our time to implement a solution.
Maybe it will come in 2.1 or 2.2 but we figured it was not worth the wait.
I hope I have clarified the challenge we face. I understand the one you face as well but, like others in the thread it appears, I’m not sure you’re using the most efficient solution to address both our challenges.
Other large projects publish a roadmap to address this need.
Yes, and we don’t. We’ve been down that road before, numerous times in fact, explaining why we don’t think it’s a good idea. And just to manage your expectations accordingly, I don’t see that changing any time soon, sorry.
We welcome your feedback, so thanks for that. It is always read and considered.
Other large projects publish a roadmap to address this need.
Yes, and we don’t. We’ve been down that road before, numerous times in fact, explaining why we don’t think it’s a good idea. And just to manage your expectations accordingly, I don’t see that changing any time soon, sorry.
Derek could not see how to address watershed’s needs, I was merely pointing out that there is a well-known solution.
Coming at this again with regards to Derek saying…
I don’t see how the relationships thing could have been pre-empted or predicted by us when communicating 2.0’s changes
One can of course change “the relationships thing” in the above statement to any user’s feature issue, which is why I have sympathy with EllisLab’s position.
But, I wonder if…
more rounded illustrations [and synopses] of the kinds of things that are possible (and maybe those that aren’t)
...in the docs would address both our perspectives.
It begins with a nice example of why one would use relationships, it then goes straight on to tag usage details. Nowhere does it say:
* Unchanged since 1.6.8
* Scope: 1:1 and 1:n relationships
Both of these could (should?) be said at the top. Not only would this make things clearer to the newcomer but also someone like me hunting down potentially new functionality in EE2 would be able to see the wood for the trees. It would be blindingly obvious that n:n relationships aren’t covered, the onus would no longer be upon me to read the page top to bottom to see if some aspect of it has changed, and I wouldn’t lose the will/patience and then end up asking questions in the forum just to be sure!
Wouldn’t that be a win-win?
This is, of course, just 1 example from the docs.
Now, about the docs navigation and usability. Oh no, wait up, that’s another thread for another time!
For awhile I counted on the much-discussed commerce module to sell some more sophisticated products. It was discussed (including by EE team) as planned 2.0 so we waited for 2.0 to implement those aspects of the site and worked on other areas in the meantime. Then somehow, in a forum discussion, I learned that it had been dropped from 2.0 roadmap and the information I had found was obsolete.
Never ever did anyone from EllisLab indicate that commerce was going to be a part of 2.0.
hunting down potentially new functionality in EE2
Please, it’s all in one place, there’s no hunting required.
It begins with a nice example of why one would use relationships, it then goes straight on to tag usage details. Nowhere does it say:
* Unchanged since 1.6.8
Show me a software company that the documentation for each feature says “unchanged since…”
Can we just agree that you are both upset that certain changes you were hoping for didn’t make it into 2.0 and that you both would like a roadmap, and don’t like our documentation? I can respect that opinion, even if I disagree, but some of the suggestions here are just silly and evidentiary statements untruthful and full of assumptions.
Jeez, Derek, I wasn’t upset (until you said that).
I don’t dislike your documentation. There are some aspects of it that frustrate me. I think it could be better. I know I’m not alone.
I’ll leave my final word on the matter to Gerry McGovern…
Watching people try to carry out top tasks is a harsh lesson. You would be amazed at the amount of times they fail or give up or get the wrong answer, thinking it’s the right one.
We [...] don’t see our customers using our websites. We lack empathy and feeling for our customers because we’re not watching them try to do what they came to our websites to do.
Observing our customers is intrinsic to web success, and it’s so basic. We need to understand their tasks and know whether they are successful or not in completing them. What could be more basic than that?
