@Ali@cassie@Fox I think you definitely need to make some changes like that. I’m pretty sure I’ve mentioned this before, but there is absolutely nothing in the subject, from, or initial body of the email that references Open edX or Core Contributors at all! I wouldn’t be surprised if people ignore this. I also personally find it annoyingly difficult to tell the difference between the OpenCraft sprint listaflow emails and the Open edX CC sprint listaflow emails.
For now, we can immediately rename the checklist and it would be a massive improvement, since that would put “Open edX” in the subject line and the text of the email.
I would not recommend adding in the logo. The reason for this is a few fold:
Just reread your reply and noted that you suggested at least having Listaflow in the footnotes. Maybe! But I like the idea of it being prominent. The following points mostly make sense still:
We want Listaflow to be well-recognized as the tool providing these notifications (and perhaps later, the reports). If it’s a useful tool, we want our users to know how it’s helping them.
If we did include the Open edX logo, it would probably be better not to replace the Listaflow logo, but rather add in the Open edX logo via use of something like a ‘team avatar’ somewhere in the design. Then both can be seen.
We would want to think about how team avatars display and how they would be shown elsewhere in the design-- that has a few other subtle implications. We could just put a file field on the teams and upload the image on the backend and template it out and call it a day, though.
Basically, let’s find a sensible way to incorporate the identifying info without making Listaflow less prominent to start, then we can balance more out from there on customization per-team.
@Fox Is there a reason why we can’t have an even lower step, with a pre-populated demo/sandbox instance of Listaflow that people could use to get an idea? Even if the install is simple, having to install anything is already a pretty big step.
As far as not allowing people to directly join the proper prod instance, this is because we are missing proper permissions and admin interface, correct?
@Fox In the email we should focus on the main goal: increasing the checklist completion ratio. That should be the highest priority goal of the changes we make there (and elsewhere). If the user clicks, they will definitely see that they are using Listaflow - but that shouldn’t be taking headspace while they are deciding whether to go fill the list or not. We need to convince them to use it first, otherwise the fact that the mail had a Listaflow logo or not isn’t going to matter much for their familiarity with the software.
While we are looking at changing the emails, I think we need to make them more personable. The more automatic it looks, the more automatic the answer of the reader - yet another spam/notification that can be ignored. If, on the other side, the email originates from a real person, like Fox, me or Dean, then that’s more likely to be considered. It’s not just a machine being ignored.
Yes. Too many features currently depend on there being an administrator with administrative access to configure things that ‘sign up and try’ would provide a very poor experience. We might be able to cobble together a ‘demo mode’ but it will require special coding and deployment. For much of the useful functionality that can be run without admin access, you need to be in a team, and there needs to be a checklist the team uses, and that team has to submit their own responses (that way you can see reports). It might require doing things like auto-creating filled in checklists so there’s data to run reports on, that kind of thing. It’s messy. Adding some code to join users to a default team when they register wouldn’t be hard, though. It also wouldn’t let you get the full experience of recurring checklists specifically, but that’s probably not a huge deal if the rest of it works and you can run reports.
What we’ve talked about doing for now is creating a demonstration video that shows how it works so people get an idea of the subjective experience. It’s something that is fairly straightforward and doesn’t require a ton of additional coding/design work.
I don’t disagree, but I’m somewhat skeptical that this will work for long, since an automated email is still an automated email, even if it’s composed to look like a personalized text one. Eventually it will still get ignored. There will probably need to be manual pinging functionality which would be separate from this if our methodology is going to be notification-based. However I’m willing to give it a try, and it doesn’t take much-- the code already exists to allow us to override the template to try stuff out, so we don’t even have to redeploy to make changes to the emails.
@Fox How about duplicating the data we have in our prod database, and using it for the demo? The Open edX checkins are already public data.
That’s good too - but imho a video doesn’t replace the ability to interact with the interface oneself - especially given how good our interface is to interact with, we are missing out on a key selling point imho.
Possibly! But it would be good to see if it has any effect, and how it does fade on the longer term. We’ll likely learn from that, and that knowledge might be useful for the manual pings.
This would make a good base of data, but we’d want to make a handful of small changes for this to be practical. Namely:
Make it possible to retroactively add someone to a sprint. This way demo users would be able to participate in a sprint round despite just joining
Make sure we’re only moving data to staging which it’s OK to move. If we onboard other clients to Listaflow, we don’t want that to go onto the demo environment.
Number 1 isn’t so hard. Number 2 is tricky.
I think it might be easier and safer to, say, create a post-registration hook that can be set up and which will create a demo team and list for the registrant as well as creating some bogus historical data that is set up for the last few sprints. This could be enabled only on the demo site as some side-package.
I’ll set this up. In the meantime, I’ve renamed the checklist to add ‘Open edX’ to the front of the name, so it’s clearer what it’s for.
@Fox That’s more fancy than what I had in mind :) I wouldn’t even necessarily allow people to create an account - for a demo imho just having an existing demo/demo account you can connect to, and a DB that resets every hour to a static/unchanging SQL file can do the job? At least until we have better things in place to support proper account & lists creation.
If we prefabricate a database, with a guest account users can log into, and then have some script that reloads the DB periodically, yes, that could work. The only issue I’d see with this is that the data would age out reporting-wise-- that is, if the user runs a report, they’ll have to go further and further back as time passes to find anything.
That would be a bit awkward but it’s probably OK for a first run.
Sure thing-- I’m actually updating the email going out today to be text based. I was hoping to sign the email as by Dean, but he hasn’t gotten back to me with approval yet. The ticket for this update is here. There’s not a public ticket since it’s not involving any code or implementation details, just an update to the configuration in the admin. I’m forwarding the resulting notifications to you-- would either you or @Ali (or maybe @sarina ?) be willing to have your name sign it instead?
If not I’ll have it sent by me, but I figure it’d be better if it were sent by a CC.
New year, new budget! Yay! We’re going to move a bit of dev forward and also spend up to 10 hours on initial blog work.
After completing the paused dev tickets, we’ll schedule setting up a demo with prefabricated DB. That may be next month, depending on how the budget pans out for these tickets we’ve just thawed.
We discussed the CC notification emails, and some improvements to these.
Now that we’re redoing pages to incorperate more features we need to re-visit them from the mobile side, as the initial designs assumed all users will be on desktop. For the current audience, that’s likely true, but it’s likely that we’ll see more people using mobile (or at least, trying to) moving forward, especially as we onboard new teams. We’ll be doing this piecemeal as we go along with the new page implementations.
That’s a follow-up task that @cassie will be checking on. Matomo should have the data and if it doesn’t, we need to add it to the relevant pages. It should give us an idea what amount of people are coming by on mobile. This will give us some idea of the prioritization of the designs-- how much time we should spend refining it. Of course, this will only tell us who is using it on mobile now– it wouldn’t tell us who is using it on mobile in the future, or who has given up using it on mobile already because it failed for them.
I’ve definitely tried to fill out part of my checklist once or twice on mobile and found it more frustrating than I’d expected. In those cases I wanted to look through and remind myself what needed doing after clearing stuff I’d already done. This would have helped me plan out my day before getting to my machine when I was on the go.
Of course, if we expect anyone to use it on mobile it should at least work on mobile. And also mobile-first design is best practice these days, and all the CSS frameworks (including the ones we use) are designed to be used that way, reflowing content as the viewport gets bigger, and we’re not taking advantage of that, and are losing some of the advantages of using frameworks like Bootstrap. We make the website more brittle by not deliberately thinking about mobile when doing the design, and especially when doing the markup.
Yep! I did miss it. I’ve pinged you on the Listaflow epic with links to the credentials. Let me know if it works for you there, or else we’ll diagnose it from that point.
@Fox Sounds good! I would want to see either usage data or recurring feedback before spending too much time on it, but if there are low hanging fruits we can consider it. The important criteria would be whether this is the most important thing to do to drive adoption and response/reporting ratios - we can only focus on so many things at once.
Here is a list software solving similar problems for users as Listaflow, ordered by the volume of search for “alternative to”, “open source alternative”, etc. with the Google estimated avg. monthly volume beside each:
Notion ~9500
Trello ~7500
Monday ~2600
Clickup ~2100
Todoist ~2100
Asana ~1500
Wrike ~500
Basecamp ~500
Process Street ~500
Meistertask ~200
Teamwork ~100
Friday App ~50
While Notion is maybe not the best one-for-one alternative, it has the greatest amount of search volume. Maybe we don’t start there, but I think the site would eventually benefit from articles for at least the top 6 here. Which do you think we should start with?
