Better tables would really be useful for research.

  1. It would probably overly complicate your codebase, but the ability to use tables, ala Excel would be very useful for organizing information. Tables like Word, would be good for the presentation. There’s a happy medium there someplace.
  2. While having the ability to outline separate documents is GREAT, also enhancing the outlining capability within a document would be exceptional.

What specifically are you looking for with tables? There are several ten thousand features in between Word and Excel. :slight_smile: I can say that in general tables in Scrivener are meant to be places where you can dump data into cells for later formatting after compile. For design minimalist tables they are probably good enough without that, but heading toward presentation is a bit out of scope for what this software is all about. Presentation should be handled by pro desktop publishing tools, not a writing program—at least that is our contention, and much of the philosophy of this software’s design.

That’s perfectly fine to do if you wish, it sounds like you are used to working in a system where outlining is done entirely in text files? It’s the same idea here, but the implementation is more biased toward writers, in my opinion. I extensively outline within what one might refer to as a “document”. It’s just that in Scrivener, a document can be a thousand different pieces of text arranged into an outline. You don’t have to stop at chapters, or sections, is what I’m saying—if the section you are working on needs more outline, then break it up and outline it. Some people around here have things broken down to paragraphs. :slight_smile: It’s a totally different system than in a word processor, where the outline is embedded directly into the text as a special function of the text itself. Scrivener deliberately is not that, because it acknowledges that what an author needs for an outline often has nothing or very little to do with what is visible as text—particularly for the reader. That is nothing new of course, any author with boxes of index cards can attest to that—we’re just trying to bridge that box of index cards with the manuscript directly (and a little less messily).

Another thing to consider is that there is no stipulation that elements in the Binder must be “documents” in the traditional sense. They can merely just be entries in the Binder, outline rows if you will (if you’ve ever used a dedicated outlining program, that’s a better comparison to how Scrivener works than something like Word or even Win Explorer).

What does that mean in practice? Since everything in Scrivener is a container, that means every section of text in your book can be its own playground for outlining and forming ideas. Just hit Ctrl–3 while writing, and you’ve got an empty outline to work with, build out your idea (note that adding rows is as easy as hitting the Enter key, just like a traditional outliner—if not check the Navigation settings tab), and then Ctrl–3 back to the text. You’re just switching Outliner view on and off for the text file you are editing, nothing mysterious, and the result of your outline will be in the Binder beneath that text file. You could write into these nodes to flesh out the section, or just use it as a place to think about the bulk of the text in a more abstract sense.

1 Like

i see how you’re organizing it now. I was differentiating between the containers listed on the left and the contents, but I guess I don’t have to. a different paradigm.

I was thinking of the lists for outlining, but i guess they’re not really intended the way I was assuming.

As far as the tables go, giving them fancy formatting wasn’t really what I had in mind. It would be useful however to be able to resize them with the mouse. Or have I just not learned that yet?


The one extra feature I would like to see most for tables is to copy, paste and move a row/column of data. At the moment you can insert blank rows but you can’t move a whole row, so if your data is in the wrong order you’ve got to move everything one cell at a time.

Yes, it is a different approach, and it isn’t necessary—Scrivener works just fine with a more conservative item = file type way of working, plenty do it—but the features of the program definitely do reward a finer grained approached with greater flexibility and visibility of your own work.

Lists, as in the bullet and enumeration feature is very simple—you could try to use it for traditional outlining, but you’ll probably find it lacking for that. All of the traditional outlining style features are aimed at the binder structure itself.

Tables: yeah, making them all around better to use for their intended purpose is something we’d like to do in the future. Mouse resizing is one such thing already on the list. Moving rows and columns is a little more difficult, from what I understand, as all of the existing editing tools manage the text within the cells, not the cells.

We’re just having to reinvent our own wheel with these, so it takes a lot more work than it might if we had a table kit we could just drop into the program. Then again, we do have that on the Mac side, and its so closed off we can’t really modify it without starting over from scratch. So both ways have their pros and cons. :slight_smile:

On top of not being able to resize columns using the mouse as mentioned above, I ran into a few more frustrations with tables in SfW the other day.

I had started off with a three column table, then needed to increase to four columns just for a few rows. Scrivener refused to split the cells (the option was greyed out). After a bit of experimenting, it seems to be due to the Table Properties. Attempting to split a cell that would make that row wider than the column number in Table Properties cannot be done, whereas it should surely just raise that value automatically.

Another problem surfaced once I took a sledgehammer approach to the problem and reconfigured the entire table to be four columns (using Add Column After). There is no command to merge columns or rows, just the one to merge cells. Consequently, to restore the original section of the table to three columns, I had to do it a row at a time. This was rather time consuming, made worse by there being no option to assign key shortcuts to table commands.

A strange one that cropped up while I played with it was that after using Table Properties to increase the table size to five columns, I then used Undo to return to three. Instead of returning me to the previous state, Undo merely squeezed columns four and five to be a pixel or two wide and kept the table as five columns. I had to return to Table Properties to change it back to three.

Is there a way of importing Excel or Word tables so they become Scrivener tables once imported? Until the software is improved in this respect it would at least be a work around. Creating tables in another package then importing as images is not going to work as I will want to edit them frequently and don’t want to keep hopping in and out of different packages (they’re not used in the documents themselves, but are integral to my planning and outlining).

So my wishlist would initially be:
Adjust cell size with mouse
Split cells and adjust Table Properties if required
Have Undo work correctly for table commands
Split horizontally and split vertically commands for selected cells (to replace split cells)
Merge horizontally and merge vertically commands for selected cells (to replace merge cells)
Keyboard shortcuts

Or maybe I’ve just missed something as I’m fairly new to SfW. Do let me know if so.

There is also a bug in the Add Column command. Create a two column table then merge the top two cells to create a title cell. Now place cursor in the title cell then Add Column After. SfW crashes and quits. This happens whenever you try to add a column from a row that does not contain the maximum columns as per the Table Properties.