But what about Scrivener’s compatibility with PWA? Isn’t that L&L’s responsibility? Both vendors can’t point fingers at each other whilst their users (very many of whom use both products) sit around watching, paying, praying… for a fix…
Given above, probably best that PWA developers/executives get in touch with L&L counterparts and not try to resolve here, perhaps? Best, I think, if PWA can be specific about what changes they expect L&L to make.
L&L publishes their support contact methods:
Please do soonest as you can see from the previous posting by @kb, they are soon to take off for the upcoming holidays.
We have never claimed to be “compatible” with PWA or any other third-party application. We have frequently said that the only supported way to edit a Scrivener project is with Scrivener itself.
And yes, as @rms said, if PWA would like to request a specific change to Scrivener, they should contact us directly. (I’m not Keith, so for all I know they already have.)
3 Likes
Just to amplfy on what Katherine says and has said here:
-
PWA has been working again for a week - fixed adequately in a few days.
-
I don’t know if the functioning is exactly as it was before, but it is quite usable. Click to drop-down and see any issue, and the issue also highlights in the Scrivener editor.
-
see the attached screenshot of this working
-
If you don’t understand the software talk, it’s quite clear that Scrivener has and can have no responsibility in the PWA issue, though they have been kind enough to point out where the problem likely lies.
-
which is that a third-party library, which Scrivener uses and PWA apparently does also to layer their abilities and window on Scrivener, has changed. It’s PWA’s responsibility to keep up with vendor changes like this, and the vendor is QT Group, who you can look at on that highlighted link.
-
Then as Katherine has stated there is no Scrivener ‘API’ as someone has mistakenly assumed from the beginning here. And yes, if PwA would be interested in one, they’d have to contact Scrivener themselves and negotiate it, were @Keith to agree.
-
if there’s anything left to improve, I suspect PWA is quite capable of doing so by the method they’ve used all along, given time to accomodate the later QT release.
Here’s the screenshot (I usually have PWA come up over the Inspector, where it’s handy):
1 Like
Hi,
32 years in the software industry starting with 7 yrs. in technical support, then 3 in testing. Then I moved to program management and finally to product management and marketing user education. This gives me a broad view of some issues.
Scrivener is clearly a customer focused design. That is why it sometimes has a large learning curve it has done a great job of trying to be adaptable to a large variety of writers.
As a PWA user, I like the company because they are also very customer focused. My 19-year-old daughter is working to become a writer as a career from the start. PWA has sponsored some amazing virtual conferences for free, with a final day being for subscribers, that really helped her network and learn.
So, the clear appearance is both companies are customer motivated.
It would do Scrivner well to look at PWA and their work with Pro Writing Aid Everywhere as an asset vs a burden “It’s not our bug, we don’t say we are PWA compatible.”
What is interesting is the company I work for is ramping up a tool for creating software demos that includes writing content in onscreen boxes per-page. PWA Everywhere, just works with it. Suddenly we have a tool that adds a ton of power to our writing with almost not work. It doesn’t work in some of the places where we write Accessibility content. But we are looking at what change that would take, because we could never get this much power for our users without a significant investment and delay.
Given the nearly free power it provides Scrivener, and the likely growing list of users. I have the following suggestions:
- I would suggest that there be a basic list of PWA everywhere test cases added to your release management.
- Since both companies appear to be focused on creating customer focused software, it might be good to set up a working relationship, so you have contacts you can send issues you find and give them access to near release versions. Because if they release test for you, to make sure their customers are happy, that is a win/win.
If I were a $60 tool that suddenly got nearly free features from a $300ish tool. I would leverage the heck out of that.
Imagine if you actually worked with them so their text underlining always worked in Scrivener the way it works in Word, Microsoft Teams, etc. etc. Vs “Not our problem.”
When you release a new version that breaks a “free asset” that your users get value from and they report it. It is a bug. Bugs are either broken software that doesn’t work as the maker expects and loses data etc. or they are places where the software doesn’t work as user would expect. The later bugs can get move to a feature request list of course, but they are “design” bugs.
A great response when a valued and happy user says a release breaks an interaction with a tool they use to get more value from your product is: “Please get us info about which versions of both tools you are using and OS version, and we will take a look. Since we don’t make PWA, we can’t promise a fix, but maybe we can reach out to them.”
Scrivener to me is much more valuable tool with PWA Everywhere. It reduces the chances I start to look elsewhere, because the quality check features are less than other tools. It is a “gift” to your users, that it works usually without you having to do anything. So, when it doesn’t work, not a bad idea to do a tiny bit. 
Thanks
Wordjoy, I think your heart’s in the right place here, surely.
As perhaps an even more certiffiable ‘old hand’, would feel there’s good sense in what you say also. And, it’s Christmas, or other holiday season, which one could hope would help.
I think things might have ggone more smoothly had several person not come in here with a very demanding and ‘we’re not listenting until you fix it’ attitude. From the top, L&L has long been a group with its own very independent character, and this is not the way to speak, any more than it would be to any persons.
On the technical side, it seems pretty clear that the problem isn’t in Scrivener, but in changes made by another group that tends to act in its own fashion, the Qt library provider. Scrivener just updated to a more current version, and either ProWritingAid didn’t, or there’s something in the new mix which gets in their way.
If the second thought is true, then a fix might become somewhat involved. It might need Scrivener to invent what it doesn’t have, a connectivity (API) which would let PWA do its manipulations. With the rate of current development in Scrivener, on its backlog of desirables, it might not be too easy to provide such in what people would consider a reasonable time. Also, if Scrivener created this, they’d have to support it, where I think you’d be able to fill in the deggree of responsibilities.
On the other hand, it might just be that PWA could use a hand up in converting to the new library. I’ve talked to them in earlier days about getting some of their own issues fixed, and didn’t have the feeling they were over-provided with coding-side resources.
Could they talk together? That would be up to @Keith and whomever operates PWA, where once again experience suggests two rather independent individuals. But they could…and see where a nice path might appear.
That migth turn out to be rather welcome, by the advantaging views you’ve offered. There migth even be resources discovered for bringing in suitable help, given PWA is not shy in the marketing department, or what we might guess from that in revenue ability .
And, it’s Christmas
Followed soon by a fresh year, where hope may find its presence in new shoots, the dependably natural way.
I felt you quite well described what Scrivener really is, Wordjoy, resonance there to appreciate many things about ways it is, and that we many appreciate in it.
All the best,
Clive
2 Likes