Continuing the discussion from Future of Mosaic:
@djay, @tkimnguyen, @gp54321
Spinning off a discussion on this, since it didn't feel Mosaic specific enough.
1 Like
@djay,
Your post, in the Future of Mosaic thread,
made me think of a decision making framework which presents "resources/inititatives" at the bottom and target "experiences/solutions/goals" at the top. I just "rubbed up" an example. In our case the "resource/initiatives" can be things like "on-going updates to documentation", "marketing efforts", "pastanaga UI" etc..
Whomever is willing to implement will get to dictate to a degree allowed by their willingness to ignore people shouting at them.
This is not going to change on the basic level. Please do not start building more hurdles on the road of idea -> PLIP -> development -> release branch merge.
@Rotonen I think the point here is to help inform the people who are willing to implement. Of course they can ignore community-driven advice, but hopefully they will (a) be aware of the community-driven thinking and (b) they will understand that it would probably please more people in the community (and users of Plone) if they follow a community-sourced "consensus" (I use "consensus" in a loose way, not to mean that everyone agreed, but maybe most people who care to voice an opinion and contribute to the discussion care)
I like the idea of having a more structured way of pointing out unresolved issues and having a structured discussion on each with periodic resolution steps hopefully leading to a wider agreement.
yeah that seems right. Except I would not describe the top as "solutions". To me its problems (described from a user point of view) on top and solutions on the bottom.
And actually its three layers. Over aching goals at the top layer.
- [USP/wow] [reduce support/smooth]
The problems
- [user breaks home page because don't understand display menu].
Then the sollutions
- [replace display menu/default pages with mosaic] [make display menu dialog and have preview]
and each layer is ordered based on how on what it connects to above.
You are right. The weakest point of this whole idea that highlighting what we need makes it happen. It possibly doesn't. And I suspect that people are less likely to work on other peoples ideas than their own.
On the other hand, I suspect what happens now is that there a general feeling of consensus that goes on during conferences/PLOG/FWT and it derives from those with the most merit (core developers) agreeing with each other based intuition and what is least controversial. But my suspicion is that this implicit process makes us feel like we are doing the best thing for plone but in-fact developers intuition is leading us partly astray.
So all I'm thinking is we try to balance developer intuition with some information that comes somehow from end users and marketing so they can help make better decisions on what they want to do. There is no extra hurdle I believe.
Sorry I should correct myself. It's often more about priorities. Developers often want to do whats good for the product but in the wrong order. e.g. cleaning up a code base vs refactoring a confusing UI. One helps make plone more popular quicker, the other slower but both probably need doing.
I can see 3 layers but I don't agree with the specifics of the implemenation or naming.
These are my definitions:
solutions are "paths" from "resources".
resources are what developers are building or have built.
There is an ongoing dialog between the stakeholders in the three layers (marketing, users, developers).
It's important that the bottom layer be BOTH resources and solutions, some resources already exist and can be mapped to problems.
The top can be the unique selling points (USP), the goal of this framework is to help to map, existing and emerging "resources" to user problems. Hopefully from there the gaps become evident.
Here's the updated framework with adjustments to support @djay's three layered concept BUT treating solutions as "paths".
To make it more interesting, a Unique Selling Point is derived by analysing the benefits and determining how to sell it to an audience.
I think something is getting lost in all of that.
The idea of the roadmap is to make a judgement on priorities. The idea of the 5 simple labels is catagorise the impact of fixing a particular problem to help that priortisation.
Why? Often we see a problem and think wow I can see how to solve this and I feel like I want to solve it so you go ahead and solve it. And that is often without thinking if its the best thing to solve. If it turns out to be easy and have no other implications than great but often what happens in practice is that it turns out to be harder and a lot of time is wasted or only half the solution gets implimented so perhaps its a worse product, or perhaps the end result has some technical implication or UX implication that was untended. The point is, aligning our goals means that the effort is more likely to be worth it, should it get hard.
The idea of 5 simple goals is to help make it clear when solving a problem is going to help in sales vs just help in support vs help a small number of niche cases. They don't have to be the 5 I picked but I do think it should be very simple to understand that we have collectively decided allowing users flexibility of layout for example is essential to sell the product even if its no longer a USP. Or having a solution for integrators to use plone headless so they can use JS only frontends. Does that help sell it? Is it a USP? vs is it something we want to do but in the market place of CMS's people don't care?
"Intuitive workflow management" is not a judgement or goal but rather just another way to write the UX problem "Workflow is unintuitive" but is still too general. I think from training people that plone currently has a "confusing relationship between roles, permissions, sharing and workflow that is unintuitive and requires training to explain"
The problems layer and solutions layer has to be very specific. Pastanaga is not really a single solution but a bunch of different UX ideas, each design to solve different UX problems. "Confusing UX" is not really specific enough.
Finally we can get as fancy as we want but at the end of the day I'd rather actually work out how we could have a process that works... remotely with the tools we have now.
I used trello for my roadmap for our product.
- I had one card per problem. It's title was the problem statement e.g. "hard to create custom content types". As specific as I could make it.
- Within the card I listed out the possible solutions
- if there was a preferred solution I could put that in the title e.g. "hard to create custom content types (fix via themefragments)
- I then went through the list and made the judgements on each problem by putting it in the title "[wow] [smooth] hard to create custom content types (fix via themefragments)" etc. hence the need for those simple names. but as I said before [wow] had a specific meaning for me. it meant something that would make a potential client pick us over someone else, a usp. but it because clear in this discussion is everyone considers it "their" wow, so its confusing.
- Then I kept on reordering the items giving items that had most important impact (wow) and also if it had other impacts too. for example, there might be a feature that really makes it easy to onboard people, helps reduce support costs by making things more intuitive, really helps advanced users and is also a USP and that should obviously go near the top.Trello is not perfect and could use lots of other tools.
But first I'd like to know if there is support for this kind of process? And what it would take to get buyin? This forum is wrong place as plenty of people important to plone don't read it. Perhaps some kind or roadmap temporary team could be formed with the idea that its representative of the types of companies, individuals and end users and buyers to help make these judgements more objective?
@pigeonflight @tkimnguyen Perhaps a simpler way to think of it is
Feature/Effort -> Benefit + Audience -> Sellable [1-5]
Where benefit is just the inverse of user problem. Every benefit has user group/Audience.
Sellable is a prediction and is going to depend on how in demand a benefit is, how many different types of users the benefit is for and how unfulfilled that need is currently (ie is it a USP). Things that are hard to describe are also hard to sell.
There are also high value vs low value benefits... the ability to get insights into customer engagement is probably going to be worth more than giving more control over layout to content editors. In fact the kind of customers who care about engagement are probably going to have tightly controlled themes and would lock down something like mosaic if it was available so content editor control over layout might be a negative for them.
Not sure if this is easier to write out but here is a go.
- Mosaic
- Content editors control over layout = Webmaster type sites, intranets, smaller organisations
- 2
- Easier to learn/less support (via remove default pages and display views) = Webmaster type sites, intranets, smaller organisations
- 2
- Content editors control over layout = Webmaster type sites, intranets, smaller organisations
Anyone else?
My idea is that we lead with Sellables, where my working definition for "sellable" is something that adds enough value to your organisation by either saving or earning that you'd spend money on it. If it leads to saved time or money or earned money or value it is sellable.
What are the "Sellables" today? How many of those boxes do we already tick? Whose jobs are we making easier?
Here's a checklist of possible Sellables,
some may not be true today
- Ability to measure customer engagement (don't know that we have this but marketing cares about this)
- Secure (reduce the administrative overhead, the worry and the embarrassment)
- Easy to customize (TTW, ???)
- Integration Friendly (Integrates easily with other systems and other systems can integrate easily with it)
- Easy to maintain and install
- Support - A network of experts who know and support Plone
- You can fully own the platform (being self hosted is needed by some companies)
- Extensive catalog of best of breed add-ons (what is high value here? Themes, Ecommerce, Survey type products, Photo gallery)
This is a first pass which will need to be refined, but we need to start somewhere and I believe the sellables are where we start.
I think you two are proving my point, which is that it's hard to have this type of discussion online and asynchronously. Topics are fragmenting, interest and attention are sporadic, and it's difficult to get fast enough clarification on points to make progress.
We could also chalk it up to a lack of a deadline. Face to face has a natural deadline of getting this done before the meeting adjourns. An interesting experience would be an asynchronous process with a known deadline (e.g. only running for a window of two weeks). I think the constraint would help to focus efforts and reduce the fragmentation.
I think you know how difficult it is to arrange for several people to clear their schedules to attend (in person or, say, remotely) an event and focus on it (not allow interruptions from daily life or work). But yeah, a fixed time window would help.
Additional questions that have come to me from these discussions and may be worth stating explicitly.
- How do we achieve a middle ground between in-person/synchronous and remote/asynchronous
- How do we ensure that future in-person road-mapping events (assuming we consider this is best) are "representative" of the users/administrators etc..?
- Do we even need a framework beyond the PLIP process? If we do, what added value will it bring?
- How frequently should we review the road-map?
- How do we reduce the cost of road-mapping?
Kim, I explicitly said a forum like this was the wrong way to do it. But
please do continue with your ideas. Good luck.
There has been a roadmap team before, though its most recent incarnation was really only "the people who wrote down what went into a particular discussion".
This issue is now in the "whoever makes the first move" state. What needs to happen:
- someone needs to call for membership in a new roadmap team
- someone needs to set a clear and simple objective for the team, as well as a (reasonable) deadline
- someone needs to set up a simple tool or process for documenting and working collaboratively through the discussion
- someone needs to gently encourage participation from the community (including "key" members)
- someone needs to provide a final draft / report on the outcome
Some challenges to be expected:
- Attendance and participation will be spotty
- There will be a lot of tangential and spinoff discussions and arguments
- It will be difficult to bring those discussions back on topic, summarize discussion, and form consensus
Roadmapping Plone is a big project.
I've been getting into Design Sprints and I'm wondering if it would be valuable for Plone.
see: https://sprintstories.com/ for more info.
As far as I know, if we do this, we might be the first open source community* project to adopt the methodology (I could be wrong of course).
* if you don't count open source ecology which is a maker community.
agree with all of that. But I think the #1 issue is that, would it make a difference to what gets worked on? Let's say it was representative and end user focused and all the users wanted X, but the core developers are excited on building Y, what would happen?