PROBLEM
Documents like recipes, schedules, and budgets aren’t expressed effectively as outlines. Data structures for nesting data are great for visualizing relationships between descendants or types - but not so great for visualizing relationships between categories of attributes. Outline “hacks” like markdown or nesting are a workaround.
For example, it’s a lot easier to scan a daily agenda in a table because the columns neatly align times and event names. In an outline you have to force either the time or event name into a parent/child relationship.
FEATURE REQUEST
Tables! Would love the ability to structure data as a relational table within outlines. For example:
THANKS!!
My profession is user experience, happy to suggest a few design approaches. No idea how much dev effort it would take to implement a lightweight-UI but I can definitely think of a few ideas to test out.
But they might also break the Dynalist philosophy?!
I don’t know exactly what the Dynalist philosophy is, but I know I moved to Dynalist from Ever Note because EN was a lot more than what I needed. Dynalist is not as powerful but it’s perfect for what I need.
If Dynalist becomes EN it needs to do so in a way that doesn’t compromise the speed and simplicity that makes it so attractive.
Personally, when I need a nicely formatted document I use Google Docs. But there are a lot of alternatives.
I second this idea. I think the ability to show/hide any columns (from a potentially global set) on a per-document basis would be great for more structured data. I currently put name/value pairs into the notes of items (e.g: “Cover: Paperback”), but expanding this to show as columns would be great. Ultimately, columns could be of different types (currency, date, list, number, etc.), you could search and filter by column value, etc., and you move toward a lightweight database.
This combination of outliner plus columns is almost perfectly expressed in the old Windows software Ecco (which can still be run today, even though it ceased development in 1997, I think). The combination of the two approaches is powerful.
If column display is totally optional, this wouldn’t interfere with anyone who wants to only use the outliner paradigm.
@Schultzter I think Dynalist could implement @Jonathan_Cohen’s request not only without compromising on its philosophy but actively achieving it.
@Erica will have good ideas about how to do this, but I think even just this should work: Have the raw data still in an outline format like this:
Name
Age
Sex
John
20
M
Marie
21
F
Then just have “table mode” akin to article mode which just adds some fancy UI to display everything in a table format. Cells could be editable too.
I like that idea, I would even take it one step further and have the entire table under a Title item, like this:
Title of table
Name
Age
Sex
John
20
Etc…
That way the item menu on the Title item can have a Display as Table choice (and keyboard short-cut) that will convert everything under the Title item into a table. Not sure how to render the Title though, I guess it would have to remain a regular item so that you use it to go back to the regular outline display.
Or would you zoom in on the Title item and then have a choice to display all the contents as a table? But display as an outline when zoomed out?
Given the way I use Dynalist (as a GTD system where each document is a context or a reference material) I would prefer to have tables as subsidiary objects not as a document view.
However the way Dynalist works, where every item can be zoomed in and even the top-level (the document title) is an item, I think if you wanted the entire document to be a table then you would be able to do that.
Hmm, agreed- it seems “un-dynalist” to have any item that can’t be zoomed in upon or made top-level. Even a cell in a table. But what would even happen if you tried to zoom in on a cell in a table? How could its hierarchy and “cellness” be represented in the breadcrumbs? Yikes.
Just like you can add a note or an image to an item, perhaps you could add a table. Might be simpler than trying to retrofit the outlining model.
Yeah, allowing inline tables is the easiest thing to do. But I guess that doesn’t give the benefits described here, like being able to sort by an attribute or filter by an attribute.
Well, if inline tables are treated as an object attached to but not descended from a bullet - like an image or note - could you carry over those benefits? Imagine a context menu for bullets with attached tables. Sorting by column names and perhaps even filtering might plug in there. Scale what you’ve got!
While I love Dynalist, this is a problem for certain types of data. recently I started using Notion S.O. https://www.notion.so/ for data like this, because you can easily drag and drop content and create columns like Trello. While you can nest items in in Notion, its nowhere near as fast or as intuitive as Dynalist when it comes to outlining or brainstorming, I still plan to use both going forward to be as productive as possible.
As another potential avenue, are there any existing web based spreadsheet/table applications that could be embedded as an item or a separate document in Dynalist? One issue I see with that is that the data would probably not be searchable within the native Dynalist search function. But it could be a good stop gap until another solution is found.
Regarding an idea of using one of the Java script modifiers to create tables using markdown or what not, there are some Java scripts available (specifically for Workflowy and one for the iOS counterpart Handyflowy (and this one only in Japanese)), which I’m assuming could be repurposed for Dynalist, but they are very clunky and defeat the purpose a bit.
I am personally fine with storing that kind of information (tables and other structured documents) on other platforms, with links.
I do not intend to try to force DL to be everything for me. I don’t believe I can achieve that with any tool without compromising/sacrificing in a lot of other ways.
(I tried at first with Evernote - storage, task management, place to write content etc. but it became way too clunky).
Though a lot of tools overlap today (just look how many non-numbers things spreadsheets are used for today), there will always be tools that are best for their specific jobs.
As long as they can link well, that’s the most important.
One thing that could be considered though, if a lot of users like to have stuff like tables, spreadsheets etc. inside their DL landscape is to make it easier to IMBED such things.
Ie. just set up your sheets, tables, graphs etc. in your other tools and imbed them in a bullet so you and view and manipulate them.
Our view is pretty similar to yours. Embed sounds like the best solution, but it might make the web load a lot slower, as each embed is basically a web page within a web page. It could hog tons of resources too.
For that reason, good old links is a great way for now, until we figure out how to properly embed things (most likely after WYISWYG).
maybe the table be displayed like a set thing with no zooming…
this could be awesome…
because many info exist in tables…and I cant transfer that info easily unto dynalist…
this is the last step for me to migrate completely from OneNote to here.
Please please consider this. even if its simple (say… only 2 or 3 columns max for each table) it could be very very useful in a great way.
In wiki you only need to separate them with a straight bar \ in the code and in the view form you see the table
so maybe it could be possible something like …
(bullet 1) $$$ Name $
(bullet 2) $ Lastname $$$(end of first row)
(bullet 3) $ John $
(bullet 4) $ Smith $
to see something like
