development priorities are a puzzle?

[project_2501]

So we've previously discussed why and how Publisher can't do the very basics like enable a workflow that allows us to work on documents of 20 pages, 200, pages, 2000 pages .. like a DTP app is supposed to? Master pages were a key focus of this discussion. 

 

We talked about the lack of an open development process that bidirectionally engages the supportive community - its the best way to derisk a technology project - start with users, and work with users as you develop iteratively. Nothing new here.

 

Today we get an email telling us of great progress. of the 3 key new features we get the ability to "apply a Master Page to a Master Page".

 

Is it just me who is wondering what Affinity's priorities are? In what way is that a higher priority than getting master pages to actually work like they are supposed to - to enable a workflow that scales with tens, hundreds, even thousands of pages. 

 

Gobsmacked is me.

 

 

https://affinityspotlight.com/article/affinity-publisher-public-beta-170162-now-available/

Edited November 9, 2018 by tariq
fix link

[fde101]

It was probably just low-hanging fruit.  People were asking for that, it may be that they were in a position to get that done quickly and check off a box.

The tasks you are talking about are probably much, much harder and they are very likely working on them behind the scenes but it is taking longer to get them done.

Sometimes there are prerequisites to certain things too that might not seem obvious from the outside looking in...

[project_2501]

8 minutes ago, fde101 said:

It was probably just low-hanging fruit.  People were asking for that, it may be that they were in a position to get that done quickly and check off a box.

The tasks you are talking about are probably much, much harder and they are very likely working on them behind the scenes but it is taking longer to get them done.

Sometimes there are prerequisites to certain things too that might not seem obvious from the outside looking in...

 

wouldn't it be so much better if the development process was open ...

[fde101]

It is far more open than most already.  This is a commercial project, not open-source.

[project_2501]

7 minutes ago, fde101 said:

It is far more open than most already.  This is a commercial project, not open-source.

 

and we've seen the problems that has led to... 

what's better?

• closed process leading to a bad product
• open process leading to a successful product

 

also, having an open process isn't the same as having your code open

 

[Old Bruce]

1 hour ago, tariq said:

We talked about the lack of an open development process that bidirectionally engages the supportive community

"bidirectionally" People asked for stuff, Affinity worked on the beta (I have to empathize this is a beta) and told the people something had been implemented. 

35 minutes ago, tariq said:

 

wouldn't it be so much better if the development process was open ...

'Tis.

Unless you mean Open Source and their required nightly builds.

I suspect there are one or two items you want to see implemented and you would like to know on a regular basis about the resources expended and progress made on said implementation. That would take resources away from development and slow the whole project down, so time is spent saying "We are still working on it" instead of working on it.

[project_2501]

2 minutes ago, Old Bruce said:

"bidirectionally" People asked for stuff, Affinity worked on the beta (I have to empathize this is a beta) and told the people something had been implemented. 

'Tis.

Unless you mean Open Source and their required nightly builds.

I suspect there are one or two items you want to see implemented and you would like to know on a regular basis about the resources expended and progress made on said implementation. That would take resources away from development and slow the whole project down, so time is spent saying "We are still working on it" instead of working on it.

 

With all due respect, this is contrary to the lessons learned by software development teams all over the world over the last 20 years or so.

Also, your understanding of what a beta is, is mistaken. Allow me to humbly clarify:

1. user research - what's the problem to be fixed, who are the users, how do they want to work, what are the actual user needs
2. alpha - user research leads to proposed ideas for solutions, these ideas are the basis for experiments to see if the proposed solutions are going to work, some do, some don't
3. beta - having found solutions that the alpha experiments suggest will work, we now refine them, focussing on testing them, to seek feedback from edge cases, scaling issues, issues we only see from wider exposure. at this stage, we are testing a solution that meets user needs.
4. live and iterate

What alpha and beta are NOT, is a list of features or a development timeline divided into two, with one called alpha and the next called beta. 

A beta is testing a solution that meets user needs. The current Publisher "beta" doesn't meet user needs. 

Again - no malice intended, just facts and wisdom. Do feel free to correct me if I'm wrong, we're all forever learning.

[fde101]

13 minutes ago, tariq said:

we've seen the problems that has led to... 

Seriously?

 

15 minutes ago, tariq said:

also, having an open process isn't the same as having your code open

It is not, but at the same time, being too open about the product would give away secrets, plans, etc. to competitors who have more resources and could get ahead of the team and marginalize the value of the product.  Being too open with a product like this would mean that the product could only hope to compete on price, when they are looking to make something that is actually worth using.

You seem to be looking for an "open process" similar to that which would be appropriate for an open source project.  It would not be appropriate for this.

[fde101]

5 minutes ago, tariq said:

•  alpha - user research leads to proposed ideas for solutions, these ideas are the basis for experiments to see if the proposed solutions are going to work, some do, some don't
•  beta - having found solutions that the alpha experiments suggest will work, we now refine them, focussing on testing them, to seek feedback from edge cases, scaling issues, issues we only see from wider exposure. at this stage, we are testing a solution that meets user needs.

By those definitions, the open beta is actually an alpha version.

Those terms are not consistent in the industry and different people define them in different ways.

I was taking the definitions in this case to be alpha = "inside the company only, before the beta release"; beta = "testing release outside the company".

If you search around you will find zillions of other variants of how those terms are defined, so I wouldn't read much into them.

 

Sometimes it is better to design a product for yourself and release it later in hope that someone else finds it useful.  Design by committee can often clutter a product and lead to something that is not as good as what a single visionary can produce.  While I don't think that is *exactly* what is happening here, the Affinity team members have said several times that they have their own vision for where this product is going.  If they already have a vision for it then user input is less essential in the early stages.

[project_2501]

4 minutes ago, fde101 said:

Seriously?

 

Seriously.

A DTP tool that can't provide a usable workflow that scales to more than about 5 pages is in serious trouble.

More detail here: https://medium.com/@postenterprise/affinity-publisher-beta-hands-on-review-4f5f05c96c02

 

Secret plans? I don't think Affinity need to worry about secret plans if they can't provide a tool that allows us to work with documents of more than 5 pages with text and images that reflow automatically according to a master page design.... again my original point.. priorities.

[project_2501]

4 minutes ago, fde101 said:

user input is less essential in the early stages.

 

What can I say? 

[Old Bruce]

4 minutes ago, tariq said:

The current Publisher "beta" doesn't meet user needs. 

I think we could both agree that All software is going to miss some users needs sometimes. And I will say that 

 

2 hours ago, tariq said:

getting master pages to actually work like they are supposed to

is right at the top of my wish list. There are things about their current implementation which means I won't be purchasing Publisher. I am however heartened to read that something I didn't ask for and probably won't use has been implemented. I am heartened because it shows that Affinity listens and does the work necessary to get that feature in so perhaps the things I want will be put in.