This situation, and the company’s response, are both highly disappointing and exasperating.
If I had an iOS app that integrated with, say, the Facebook API, and then Facebook changed their API in a way that broke my app, would I say my broken app is Facebook’s fault? NO WAY. If I make an app that integrates with the Facebook API, it is my job to update my app in line with the changes of the Facebook API. Since I chose to have my app depend on that system, that is part of my responsibility.
However, here, L&L is passing the buck to Apple.
If you make Mac software, it is your responsibility to your paying customers to keep updating the code so that the functionality persists.
Something IS lost here. The “Research” functions of Scrivener are not bells & whistles; the ability to add to and browse through research culled from the Internet in a single UI, ideally whether online or offline, is the main reason many of us keep using Scrivener. There are ample replacements out there for distraction-free writing and project organization these days.
If the tune doesn’t change here, I guess I’ll switch to one of Scrivener’s many competitors for distraction-free writing and project organization, and try building a modern cross-platform open-source research-gathering tool myself. Any other coders want to join me?
Back in March, when the issue first became clear, I think it was suggested that users try DevonThink, KeepIt and EagleFiler to see if their webarchive functionality was working.
I’ve followed the suggestion and tried all three and can save and access web archives. As far as I can see, only Scrivener is unable to display web archives as expected.
Given the caveats already discussed and considering the length of time that this has been an issue, it doesn’t seem unreasonable to expect the issue to be resolved now. Or, if that’s not going to be possible, for the web archive option to be removed from Scrivener.
I believe part of the issue has been the sudden and unexpected need to implement new licensing functionality, as discussed here: literatureandlatte.com/blog … ith-paddle
For obvious reasons, that has jumped ahead of all other Mac development on the priority list.
FWIW, there are many different ways to capture research from the Internet, and the web archive format has always been one of the least robust. It’s certainly not accurate to say that problems with that format alone mean that the Research functions of Scrivener have been “lost.”
Interesting, I wasn’t aware that Highland could load WebArchive files at all. It’s a good program though, if you only write a certain type of thing, go for it. Most software oriented toward writing will not handle bulk research either. That is one of the things that sets Scrivener apart.
Meanwhile, we’ll have the fix out for this in a matter of days, as we’re ready for the Paddle roll-over that has delayed getting it out sooner.
You might want to post to a new thread, or get in touch with our support address directly, as this particular issue that this thread is about wouldn’t cause any crashing (in fact if anything it would improve stability by being rendered inert, since the WebKit viewer is a well-known vector for instability). We may be able to help you recover your work, even though crashes can be by their nature a bit destructive.
On certain versions of macOS, there is one type of file it cannot display in the editor. It does however continue to host the files just fine, and they can be viewed using any number of workarounds described previously. There are also thousands of different types of research files it continues to display just fine. That’s a far cry from a writing program that can only host text.
If we’re going to be pedantic, at least be precise about it.
This is mostly a USER forum, which might explain the repeated sarcasm. But we don’t mind, so you can safely continue being sarcastic and to display a crappy attitude.
Translation for us non-academics: “I made a stink about particular details and overstated my case, then got schooled on those details, so now I am resorting to personal attacks instead of admitting that I might be in the minority of people who are severely affected by this issue that is of Apple’s making.”
This is wrong, from start to finish. If a company changes an API in such a way that it isn’t backwards-compatible with existing apps, the company that changed the API is at fault. It probably won’t get the blame, because the error shows up elsewhere, but they are at fault. An API should never be changed such that it breaks existing software.
I get that people are frustrated by this issue – it’s why I am here, as well – but if existing functionality is broken the fault lies with the entity who broke it, even if someone else has to fix it.
I’m hopeful that the issue can be worked around by Scrivener soon.
To Amber and the whole L&L team, thank you SO MUCH for including this fix in the latest incremental update even in the presence of “Paddle pressure.” I have confirmed that I can view my research web archives again! Woohoo!
Also, sorry for being one of the harsher squeaky wheels, but thank you to all the other squeaky wheels in this thread for helping L&L know this was an important bug to fix.
Lastly, to Deguello, you get the prize for missing the point. I was not trying to assign “fault” among two companies in an imaginary bubble. I was evaluating the response of a real-world company (L&L) with real customers (us), real competitors (too many to list), and real cooperators (e.g., Apple). L&L ended up doing the right thing here. Should they instead have, in your estimation, refused to fix this bug at all because it wasn’t their “fault” in your imaginary bubble?
Whoa, I came here to ask if this has been fixed yet, and saw the references to a recent update release. Went to Scrivener, had it search for updates, et voila.
