Hey all, I’m new here and figured I’d be super annoying right off the bat! Haha
So, I’m trying to learn Twine and it’s being quite an experience so far. It’s both very impressive and very frustrating at the same time, mainly because learning syntax is a pain in the butt. However one thing I’m really struggling to wrap my brain around is the lack of a normal Save As/Load system. For 50 years basically all software used a save/load system and it has worked exceedingly well. So why would this software abandon that? For backup purposes I try to keep a fairly organized file system and without a normal save/load system that becomes a cumbersome process. Sure, Publish to file and Import works well enough, unless you’re working in two different locations on two (or more) different computers in which case you now run the risk of accidentally wiping out a version with a single ill timed click (as I did last night).
So, can someone help me understand the reasoning for abandoning a perfectly acceptable, tried and true process?
While Chris Klimas (@klembot) is the only person who can really answer questions about the design decisions that went in to the making of the Twine 2.x application, as they are the one who made them, I believe that some of the motivations for this specific design choice are:
This application was initially released in only a web-browser based edition, so it would work on any Operating System that had a JavaScript enabled web-browser, and the downloadable copy of this edition would be easier to “install” locally than the Twine 1.x application was.
The User Interface of the web-browser release was designed to be more useable on a Tablet, thus the big buttons and the menu being placed in the lower section of the screen so they are “thumb” accessible.
One thing users of the Twine 1.x application complained about was the lack of “autosave”.
Applications designed for Tablet generally don’t have the same Save/Load design philosophy as a Desktop application does, as they need to allow for the ‘network’ dropping out without notice. Users of mobile devices have become used to relying on its general “autosave” philosophy (1).
(1) so much so they often forget to “save” in Desktop applications that require manual saving, thus forcing some of those Desktop applications to switch to autosave systems that journal the changes made over time, so they undo the changes the end-user didn’t mean to persist.
Interesting. Thanks for that. That explains a lot. Are there really many people who work far more on mobile and have had very little, or no, exposure to desktop software? I’ve tried working with a tablet a bunch of times, have owned four different ones and almost never touched any of them because they’re too awkward for me.
A key thing I believe is that Twine’s home is the web. The things it makes were web native from the very beginning, and the editor became a web app with version 2. Not everyone agreed with that decision, but apart from philosophical considerations, it made Twine more accessible to people who could not install a desktop app (e.g. schools with locked-down computers), and it ensured that Twine could be on as many platforms as possible. Sometimes people forget, I think, there was no version of Twine 1 for Linux unless you were willing to compile from source. (Which, admittedly, Linux people often are.)
I added a desktop version of Twine 2 later because people asked for it, but to have two versions of the UI would’ve fractured the community and made documentation difficult to maintain. So the desktop app is intentionally as similar to the web app as possible.
While some web apps do have a Save button, it’s not the norm in my opinion. A couple examples that come to mind from apps I use regularly: Google Docs, Figma, Trello, Miro. To me, it feels natural on the web for changes to save automatically–but I get that it can feel strange in the desktop world.
But it’s not entirely without precedent. HyperCard, my favorite software of all time, didn’t have a Save menu item.
This is a difficult question to factually answer, and any statistics you find relating to the matter are generally limited in their scope, for instance take this article I found after a quick google search.
When they collate internet traffic data do they include countries like China, India, or Africa? All of which generally had/have a low personal computer usage due to the costs involved in buying and running one, yet they are known to have a high Mobile device uptake.
Thanks for the reply and the info. I didn’t know it started as a web app so all the info from both you and Greyelf is great. The biggest thing I’m wanting to do is to be able to work on the exact same project on both my home and work computers. Is there an easy way to do this using OneDrive or something? Currently the only way I can see is to publish to file from one computer and import from file on the other, which is mildly cumbersome.
I am also just learning Twine and figuring this out as well. I actually did this with AXMA because I would work on it from multiple computers and it worked well in that case - you let your current release version live on the cloud drive, then just embrace that every work session no matter where you are means importing from the cloud drive at the start and publishing back to it at the end. Saving and loading is cumbersome which is part of the reason it’s sort of handled automatically in Twine.
But actually from experience it’s much better to get used to saving your work in the cloud because you never know when your gonna drop the laptop off a cliff. It also makes sure the most recent version is redundantly backed up in 2 of 3 locations on a regular basis.
And it’s nice because the current version is already set up if you want to connect to it and playtest on phones or other computers or anywhere as necessary.