Now we've launched, what next?

Q & A
#1

Hi,

I partly know the answer to this question already, having been part of the beta testing cohort it was discussed during that phase, but I think it is worth asking the question again now we have a new forum and new users – what can we expect to see in the coming months in terms of development?

The simple answer is any necessary bug fixes and of course, new features. But in reality the answer is somewhat more complicated.

I requested a number of features which I would find invaluable for the way I work in Aeon, and only one of those feature requests is currently shown on the website. @matt mentioned that the current list of requested features is extensive, and contains requests held over from version 2, as well as all requests submitted during the beta phase, and I am sure that this list is growing even more now. So I understand why not all requests are shown on the website. However, an interesting question is – what qualifies a feature request to make it onto the website list?

However, my point isn’t really about my feature requests not showing. It is more about how users can gain some insight into, and potentially influence the road map moving forward? I know there is a voting system on the website but as not all feature requests are shown there this renders that voting system largely redundant. One of my most urgent feature requests is the ability to tweak the sync mechanism per Relationship type to allow syncing either to keywords in Ulysses or to Ulysses notes, rather than a blanket setting. This is in fact a huge one for me, but all I know is that it is in a big bucket of feature requests somewhere.

Will it come down to how many people ask for the same feature? But if not everyone has thought of a feature they would find useful how can they add their voice to it? And if the majority of users use Scrivener and not Ulysses does that put Ulysses users at a disadvantage? Part of the issue will be whether a feature can even be developed technically. And how long it will take. On the website this kind of information is visible, but only for those feature requests shown.

I just think that with the new licensing model and active development now being the way forward, users will want to know the answers to these tricky questions. After all, everyone thinks their feature request is the most important.

Andrew

1 Like
Still no updates?
#2

Not me. I can be safely ignored. I don’t have the brain space to monitor this type of thing. I’ll make an observation or request and then regard it as transferred: someone else’s problem (or not as the case may be :slight_smile: ). My problem is only what best to do now.

I’m also not sure of best approach to roadmap. Most programs only list major targets. Github frequently has ad infinitum lists impossible to parse. Obsidian has a like button for requests made on forum - but that’s just popularity not implementation queue. New requests seem to get lost in Plottr because, being new, they are by definition not amongst the most popular. I’m pretty much against any approach that’s time consuming (for developers or users).

1 Like
#3

I can really understand the choice to keep control over that list and only put stuff in there that the developer deems possible and reasonable. If users can put requests there themselves and upvote them, it can easily happen that requests get a lot of attention which are either hard to realize or not in the spirit of the app. Users would get frustrated if such a request looks like a high priority because it’s in the top of the list, but never gets realized.

2 Likes
#4

Hi Andrew,

Now we’ve launched, what next?

My current answer to this is sleep, which has been in short supply over the last few days! :sweat:

Immediate term
There will be one bug fix release coming out as soon as Apple gives it the stamp of approval, and I am sure there will be a few more over the next couple of weeks as we iron out a few teething issues.

Overall things have run pretty well, but there are those performance issues reported in the forums here, and one or two rare crashes that we want to get to the bottom of, so now is a good time to look into those issues so that we can reach the most stable base possible moving forward.

Scope of the problem
To help explain why I don’t have all the answers for how we will proceed just yet, it may help to provide a few metrics for you:

  • I have just fixed an issue which will be released in the coming days. That was Task #2720.
  • When we declared feature freeze during the beta, we created a bucket labelled “3.1.0” for things we ideally wanted to include in 3.0.0, but we felt had to be squeezed out. That bucket now has 59 items in it.
  • Our backlog as a whole contains more than 500 items in it, but that includes tasks that might take 3-6 month, where each of those tasks would be broken down into dozens of items each.

So the reality is that we are always going to be picking and choosing what to prioritise based on a range of factors, including:

  1. size of impact/benefit for an individual user
  2. the number of users it will benefit
  3. target markets we want to expand into
  4. the amount of effort involved
  5. are there already other ways to achieve the same thing
  6. do we have a coherent design that fits this into the app as a whole; and
  7. when we get the luxury, will it be fun to work on?

The feature voting mechanism is a useful piece of this puzzle for us, when we want a better understanding of #2. But some ideas will be ruled out by #4 or #6, or ruled in by #1, #3 or #7, before #2 is even relevant.

So I disagree with you that the voting system is largely redundant because not everything is listed there. And I don’t think throwing another 50 or 100 or 500 items into the voting system would make it more useful. It is always going to need to be a curated list (and a curated app design).

We haven’t had a chance to sit down as a team and discuss some of these issues and work out the approach we will try to take. It will also, in part, be something that changes over time as we work out what rhythm works best. We may de-emphasize the voting over time if it doesn’t work, and instead use it as more of a published roadmap. Right now it is a mix of both.

Matt

3 Likes
#5

I’m fine with a centrally administered system. That isn’t the issue for me. Rather, I was trying to make a point about what is best, both for developers and users.

I am rapidly coming round to the viewpoint that the feature request section of the website is bound to cause more problems than it solves.

As an example, the developer of Scrivener is totally against discussing future plans. He develops his software as he wishes and if people don’t like the direction of his software then that is too bad. However, his business model is different to Aeon’s. Ulysses’ devs also don’t publish a roadmap, they just respond with a blanket thanks for your request we will consider it. And they are on a subs basis.

There is most likely good reason why they don’t publish their development plans.

But really, I was hoping to bring about a discussion about the best way forward.

#6

Thanks Matt. That is helpful. I won’t bring it up again.

#7

Thanks Matt. That is helpful. I won’t bring it up again.

On the contrary, I welcome the discussion.

It will be trial and error as we learn what works and what doesn’t, and feedback is an important part of that process.

If discussion leads to a better process that suits both us and our users, then that can only be a good thing.

2 Likes