Web Based Version

Resurrecting an old thread (sorry)

I just wanted to say, that even though I’ve written three novels in Scrivener, I’ve drifted away from it and don’t even have it installed on any of my current computers, specifically because of its lack of web/cloud support.

Wait! Before you start responding that it does support saving to Dropbox (and MS OneDrive and Google Docs, etc.), let me qualify what I’m saying. I frequently have to work on different computers at different locations. And yeah, the license is EXTREMELY liberal (thank you), but my projects still hork all over themselves if I accidentally leave it open on one computer and then reopen the project on another computer. Suddenly I have two (or more) versions within the same project. No warnings and no easy way to recover. Yeah, I can go in, and with some amount of pain and trepidation, put things to right, but Scrivener should handle this more cleanly. Actually, it shouldn’t let it happen in the first place. ( BTW - I’d love to be told that 3.0 handles this case better, but I haven’t seen any sign of it)

The best way would be a full web version of Scrivener. A couple of years ago, when this thread was active, the world of web apps was different. In today’s world, a PWA (Progressive Web App) would be able to look and act like a native app on all platforms, including Linux, Android, and Chrome OS, along with all of the platforms currently being supported. Large amounts of the existing code base would probably be reusable and going into the future, there would only be a single code base to support, making maintenance and adding new features a one-time process.

Let a user point to his own cloud storage (or local storage if the cloud isn’t needed or desirable), and you’re good to go.

I understand if you’re not interested, but somebody will do it, and they will own the future. I know a few people that are working on PWA/cloud-based writing apps with different levels of success. In the next couple of years, somebody is going to do it right, and I would rather it be you. I’ve thought about doing it too, but not until I retire, and that’s still a couple of years away.

Currently, I’m using a web-based app that isn’t terrible, but it’s not Scrivener. It fits the completely cloud-based multi-computer work model that is becoming more and more common, but I’d rather use a web-based Scrivener.

Scrivener is the best traditional writing app, but the best app for the future is still up in the air.

This is why the autoquit feature exists.

One only needs to look at the development history of Windows Scrivener to realize that crossplatform portability of the kind you describe remains a fantasy.

Maybe if you tried it, you’d be able to accurately assess the complexity of the problem.

Katherine

One only needs to look at the development history of Windows Scrivener to realize that crossplatform portability of the kind you describe remains a fantasy.

Maybe if you tried it, you’d be able to accurately assess the complexity of the problem.
Katherine
[/quote]
On the first point, I said that much code could be re-used. Specifically, internal logic code, not UI code. For the rest, that is why I said that it only needs to be developed once. PWAs, written properly, are truly platform agnostic. There is no requirement to write platform-specific code. But, if there is a need for it, for example, to make native calls for performance, you can do so to whatever level is needed.

Perhaps you should familiarize yourself with Progressive Web Apps before making pronouncements. I currently use a number of them, with common binaries, on Windows, Chrome OS, and Android. I could also run them on Mac OS, and IOS, but haven’t needed to do so. Oh, and on each platform, they look like native apps. PWAs are a panacea for the multi-platform developer.

As far as doing it myself, I have written literally millions of lines of professional production code. I have written two PWAs for internal use at the company I work for. From a clean slate without having to worry about compatibility, it’s very doable in a reasonably short time. With the compatibility issues that you deal with, both with previous versions and with different platforms, it would be orders of magnitude greater. But if you only have to do it one time to run on all platforms, it is much more doable than maintaining the nightmare you have now. I say this as an absolute truth as someone who has supported apps that run on different platforms with identical requirements.

But I do have the skills, the experience in all parts of the process, from architecture and design, through infrastructure, implementation, test, and release management. The only thing I lack right now is the time. That isn’t to say that I’ll ever do it, but you shouldn’t assume that you are the only person or organization in the world with a specific skill set or knowledge. That’s the kind of hubris that eventually ends companies.

I made this suggestion as a path to the future, but it sounds like you are tied to your current path into the past. There isn’t any need to reply. Evidently, nothing I’ve written will make any difference moving forward.

And that’s the kind of hubris that encourages people to say sod off

L&L have explained at length why it is not for them at this time. Perhaps show minimal respect by accepting that, rather than doubling down on trying to prove you know better.

For me, and it seems from here most regular Scrivener users, the answer is ‘no, a thousand times no!’

We (mostly) love Scrivener as it is and would rather Keith and team focus on development of the current range rather than tearing the house down and starting again.

And that’s the kind of ignorance that lowers the world average IQ - Congrats on your greatest personal achievement.

They made the statement about it not being the way forward, a year ago. The software development world has changed since then, as have the problems with Scrivener development and feature parity. Perhaps now is the time to reevaluate.

The modern software industry is driven by response time for new features and maintenance. The good folks here, who have made an incredible product, have demonstrated how difficult this is with their current resources and requirements. This is an unfortunate truth, that bad grammar and feeble insults are not going to change. Someone will come out with a competing product that uses modern methods, that can be (relatively) easily modified and maintained. In the long run, it will surpass any (not just Scrivener) current monolithic platform bound apps. Based on the history of the software industry and every model for development, this is something that is absolutely true and will happen. Excuse me for wanting that product to be a modern version of Scrivener.

But I can see that the developers have no interest in long-term viability, and neither do some, at least, of the customer base. That really is a shame.

And by the way, my opinion of you expressed in the first line of this reply was serious and accurate. Civility breeds civility. People like you breed contempt. I expect to get banned soon for expressing opinions that have a glimmer of truth and knowledge, neither of which is welcome in modern discussion forums, as you so ably demonstrated.

I hope you have a nice life, wherever it is now and wherever it takes you in the future. And this is a sincere wish for you, and pretty much everyone except the current president of the United States. I have a slightly different wish for him….

Take care.

The core of Mac Scrivener is a significantly enhanced extension of the Mac OS text kit. (And similarly for iOS Scrivener.) Creating a platform-agnostic, web-based version of Scrivener would require, at a minimum, duplicating that functionality. Precisely because it’s based on an operating system resource, it can’t be reused: it’s not our code to begin with. (In fact, the need to recreate this for the Windows platform has been a significant contributor to the delays in Windows Scrivener’s release.)

Beyond that, I will simply note that “native calls for performance” is potentially quite a large fraction of the whole given that our users expect to be able to manipulate hundreds of thousands of words and hundreds of megabytes of research materials. For the same reason, cloud-only storage of projects is problematic, as no internet connection is as fast as a local SSD drive. The advantages – for both the user and the developer – of a web-based solution shrink dramatically if the application needs platform-specific calls and local storage in order to achieve acceptable performance.

Katherine

I understand your viewpoint and apologise for disturbing you.

Scrivener is a great product, but I truly fear for its future.

Regardless, I won’t bother you again. Good luck!

First, a polite reminder to everyone - on both sides of the argument - that we should all follow the forum rule of “being polite”. Let’s not impugn one another’s intelligence or business sense, or accuse one another of arrogance and ignorance, please. Everyone is allowed to express an opinion, even criticising or questioning our decisions as long as it’s done politely (it’s interesting to hear the reasons for a user moving away from Scrivener). Likewise no one should get upset if their opinion or criticisms are challenged (as long as the challenge is polite).

I think a source of the misunderstanding may be the assumption that our raison d’être is to make as much money as possible and dominate the market. It isn’t. Of course we want to continue making money and to keep our wonderful staff in employment, but our reason for being is to make software we love - and love to use ourselves. This may make terrible business sense, but that is the way it has always been - we build what we love and hope enough other users love it enough to pay for it. We don’t build apps or features based on focus groups or trends. If at some point in the future there’s no longer a market for the software we love - well, we’ll just make a lot less money. :slight_smile:

And the trouble is that I really don’t love web apps. In fact I loathe them. I’ve tried some of the competitor web apps, and clearly there’s a market for them, but I would never want to use something like that myself. Whilst web apps have clearly come some way, they still seem limited and don’t work much like a native Mac or Windows app despite claims to the contrary - they’re neither fish nor foul (in my opinion).

Of course the company doesn’t have to be entirely dictated by own inclinations, and this isn’t to say that there will never be a web app, but it’s certainly not in our plans right now. We would have to completely change our infrastructure to accommodate it - and I’m not sure the changes it would necessitate would result in the sort of company we want.

Besides, there seem to be some specious word choices here, equating “the past” with native apps and “the future” with web apps. I’m not convinced.This is just another twist on the classic “if you don’t do what I want then your business will fail” argument.

The technical challenges Katherine mentions are all there and are massive, but in some ways they are beside the point. The real point is that we’re never going to appeal to everyone or create what everyone wants - and that’s fine. If we don’t provide what someone wants, then they should of course go and use something else. And it’s also fine (and useful) to tell us why, in case it’s something we are interested in doing. However, it is important to accept that we might not have an interest in travelling in that direction, and that if our direction isn’t one you like, that does not mean that our business is in trouble.

1 Like