Web page in Draft folder

Scrivener
, ,
1

Hello,

I can add a web page to the research folder, but Skrivener refuses when I try to drag it to my drafts folder. I want to do this because it is the text of a scene in a cloud-based document service where shared editing across devices is convenient.

Is there no workaround for this? I understand that it is inaccessible for compilation, but Skrivener could ignore it for that purpose; it would be my responsibility to paste it into a conventional scene document when I’m ready for compilation. This feature could be turned off by default.

Before anyone suggests it, I’m not interested in using dropbox as an alternative.

Thanks

2

Drag you Research file to Document Bookmarks (if it relates to a single scene) or Project Bookmarks (if it relates to your entire Project) and click on the content from the Bookmarks tab in Inspector without leaving your WIP in the Editor.
It can open as a side-by-side window split or a Quick Reference Panel, dependant on how you’ve set your Bookmarks to open.
Web pages aren’t text and are not supported in the draft.

2 Likes
3

Thanks but I don’t see how that solves my problem, which is to utilise the draft structuring features of skrivener and at the same time take advantage of the cloud-based document editor I want to use. As far as I can see, the bookmarks are just a list which is independent of my draft structure. Am I missing something?

4

If you need to utilise the cloud-based editor, then do a direct bookmark to the web content by adding an external link.
Click on the ellipses in Bookmarks and select Add External Bookmark. Then add the URL to the field that pops up and give your Bookmark an ease-of-use name. This way you can have Scrivener and the web editor open at the same time, side by side or on separate screens but as distinct entities.

2 Likes
5

There is not a process that would work for precisely what you want. Broadly, if you want to bring web content into the Draft you can duplicate the import and then use Documents ▸ Convert ▸ Web Page to Text, which will at that point become a regular editable text section. So that is sufficient for most purposes, but it won’t be useful if you wish to somehow interact with the archived page (and you should feel lucky that even works at all, since the web import feature is meant to archive a page in its current state forever, not offer a live portal to the Web).

As for why the Draft folder excludes content it cannot compile, that is an overarching design decision to reduce confusion as people would almost certainly expect that if you put something in there it will compile, no matter how impossible (or difficult beyond practical application) that may be. You can search the forum and find requests for allowing and making videos and PDFs integrate with the compiled output in Draft, if you don’t believe me. If we get people asking for it to work, then making it possible to put stuff in there even though it wouldn’t, would heavily imply it could compile.

Overall I think the suggestion to use a bookmark or internal hyperlink in the main text body for placeholder content is sufficient. You are marking the place of where the final content should be in the outline, have a handy thing to click on to load the page in the main editor (or however you have configured Bookmarks/links to load), so it is still readily accessible. Meanwhile it plays well with features that couldn’t support it otherwise, like Scrivenings view. For that latter reason, I would prefer a link in the main editor for something like this. You could be reading down a chapter’s sections, and see “This is a placeholder for [scene name].” and know to click on the link to load it up in the other split maybe, and reference the work in progress along with the “fixed” content around where it will go.

2 Likes
6

Thanks. I hadn’t realised that there were per-document (scene) bookmarks. This seems like the best I could do with Skrivener.

7

Thanks. I still think that the ability to bind any document within my book to an external (editable) page would be very useful; a feature which only those of us who understand the implications could switch on as an “Advanced” facility. Manipulating bookmarks is, for me, a bit of a kludge.

BTW it’s a google drive document I’m trying to link to. Viewing it in Skrivener is a bit clunky because it says the browser view you’re using needs to be updated (even though it appears to work). Also, when I followed your suggestion to convert it to text, I get no feedback after clicking “OK” - the dialogue just hangs there for a long while until it has finished, and then the result is empty. It’s a straightforward text document with no embedded objects.

8

Yes, I should have mentioned that any page that does not truly archive in the first place would struggle to convert properly to text, for the same reason it bypasses the archival aspects of the feature in the first place. Basically what is happening is it is only archiving the container code for the site, or what causes the site to download the necessary content to create the “web app”, and then within that, your content. The conversion to text is in most cases going to be blind to any of that, and try only to convert the container itself, which will be empty. In other words, while it may look like it, Google Docs is very far away from a straightforward text document.

But in this case, with Google Docs, you will get a superior result by exporting from it to .docx or .rtf, and importing that into Scrivener. That should preserve styles like proper headings, and other special formatting features such as footnotes and comments, whereas a raw HTML conversion would be at best a visual copy of what those things look like (and even then often only roughly, as Scrivener’s text editor is nowhere near as flexible as HTML/CSS layout).

If you try it on a more traditional page, like a Wikipedia article, you would see better results. And in that case it would be a true archive, in that if the article is subsequently deleted you will not lose your copy of it.

1 Like
9

And I should reiterate: that this is working at all for you is a bit of a lucky thing. Last I heard Google Docs didn’t boot properly out of a .WebArchive file, so they must have changed something on their end—and who knows for how long that will work. In most cases these kinds of sites don’t work at all (we used to get a lot of people trying to use Evernote from in their binder, back when people still used that).

In other words, by all means take advantage of the rare eclipse between Apple and Alphabet here, but I wouldn’t expect it to work forever. You might have to use a URL bookmark some day, which loads the section up in a browser.

This instability does make implementing this as an “official” ability, even if hidden as an advanced feature, less enticing. For that to be done properly, it would be a much bigger feature request: i.e. to build a full-strength browser into the software, and all of the network of dependencies that would entail, such as security and privacy features, malware protection, cookie handling, etc. All of the stuff a browser does for you behind the scenes is a lot to ask of a program that has nothing to do with web browsing, but that’s the only way a capability like this could be made reliable and worth having as a feature.

1 Like
10

If you don’t care about compiling, why do you even need to drag the file into the Draft folder? All of Scrivener’s outlining and metadata capabilities are available throughout the project.

11

Thanks. I make software myself, and appreciate the challenges you face. Android & iOS come with fully functional WebView components which take care of everything their respective native browsers do per web page (modulo a few ancillary classes). I’m not familiar with MacOS SDKs; I’m surprised but in a way not surprised that it doesn’t supply something similar.

Anyway, it sounds like the bookmark solution is the only one I can use. The functionality in Skrivener I like is the ability to re-/structure my book, and the ability to compile into multiple formats. Not so much the native editing facility. That’s why I’m pursuing these possibilities.

12

Oh it has the same kind of thing you’re talking about (more so, I would suspect, than mobile environments), I did not mean to imply we would have to reinvent the entire technology stack from the ground up, rendering HTML from scratch, opening TCP/IP sockets to servers… We already do use the Mac’s WebKit in the Bookmark sidebar on-demand for stored URLs, and with the option to redirect clicks from .webarchives back into the frame rather than to a browser, as well as of course displaying the .webarchive itself in the first place.

What I’m getting at is more the principle of whether or not one should, just because they can in theory. There is a big difference in support and ongoing maintenance between saying: “if it works, go ahead and use it”—and “yes! Scrivener fully supports integration with Google Docs and hundreds of other websites from directly within your manuscript as though it were a section of text”. Especially so when, unless you’re talking way more work, this wouldn’t really do anything other than let you put an outline node in a different place of the outline (never mind how confusing I feel that would be to most people, that don’t understand how hard it would be to make that and a hundred other websites compile).

…The functionality in Skrivener I like is the ability to re-/structure my book, and the ability to compile into multiple formats. Not so much the native editing facility. That’s why I’m pursuing these possibilities.

Speaking of which, and perhaps taking multitasking to a more unusual level, but however still directly to the point of what you’re looking to do with a bit less clicking around:

This is how I often start out new projects. Like you I have less of a need for Scrivener’s text editor, but for different reasons. I use Scrivener to create Markdown content, for which it is merely adequate as a text editor. On the left we have a pared down Scrivener window showing nothing but an Outliner view, even the binder is closed. Here I can develop the outline, move things around, change the heading structure, run searches, assign metadata, run test compiles on the live content, and all of the other good things Scrivener does that are so rare to find in writing tools.

On the right side we have Sublime Text, with which you are probably familiar, being in development. It’s a pretty good folder-is-project Markdown editor as well, with the right plug-ins. As for what folder it is using, that would be the one Scrivener is generating and syncing with via its external folder sync feature. As I write in a full Markdown environment on the right, I can periodically update the content in the outline with a punch of a key in Scrivener on the left, that simultaneous updates Sublime’s folder listing with any new entries I’ve added, renamed, content edits I’ve made, etc.

If I need more Scrivener, I can raise it to the foreground, switch Layouts and go ham. Use the inspector, freeform corkboard and so on. Sublime is meanwhile an IDE, so it is no slouch at rapidly opening files from within a project folder, splitting the window into multiple editors (as shown) and so on.

It’s not a way of working I use forever, and for everything—at some point it starts making more sense to do everything in Scrivener. But like you, I think, early on it’s way more efficient to use the best tool for the job when you’re typing, and that’s again what multitasking is all about. What I like about it though is that it has fewer decision points than what you’re describing. I might gradually stop using this workflow for everything, but I can easily quick-fix something I’ve “moved on from” in the past because its .md file is still right there. Maybe I’ve mostly moved on and rarely work this way, but I come across a code block I’d like to tidy up. Scrivener is horrible for composing and editing code blocks, as are most word processor oriented editors, so I hit the sync button and double-click the .sublime-project file from the Project Bookmarks list to fire it up, fix it, sync and move on. There is very little by way of barrier between the two.

The folder sync feature also supports scriptwriters (via FDX) and word processing (via RTF), so this isn’t just for Markdown-based authors. There are Windows users that use this approach with Word to manage tables and lists, which even more so than the Mac version, the text engine leaves an awful lot to be desired for. Same idea, different tool set.

The tech was originally designed for iOS and Android users, as a folder full of loose files is an ideal medium when paired with any sync service of choice. Edit your files on the go with X app, and all your edits are merged in when you get back home. But it works so well for that, the idea is natural on the local device as well.

It’s another possibility anyway, and one that to me seems more natural than editing in a stripped down WebKit frame, but to each there own!

3 Likes