would love to see a self hosted ginko. It used to be that there was a lot of self hosted project, now everyone wants to keep you data... I wonder if the trend will change again.
I'd like to try it, but I'm also not going to sign up for an online note/research app to use seriously. I want assurances that my notes are on my devices, read only by me, and, after a shitty experience with Notes.app this week, I'm going to be refusing any app that silos data and/or uses an unpublished nonstandard format.
Understood. We're planning on adding offline support, and a "Chrome Packaged App" version, so you could use Gingko offline entirely, and our servers will never touch your data.
As for the format, we simply export to flat Markdown. We will be supporting other formats (including XML, and the OPML standard for hierarchical/outline text).
I have always felt PDF is outdated for research papers. We need some kind of interactive paper format; yet universal, open specs, look the same and usable across platforms.
You might have heard of this World Wide Web thing. It works pretty well at CERN. We just just have to switch the academic publishing industry to HTML now.
They took a fresh, web-centric look at how to interactively display research papers. It's being used — right now — to display all of the new articles from a major biology journal.
Dear authors, my screen has hundreds of pixels vertically, I would like to be able to read more than 15 lines at once. The font size is insanely huge. It made me close the tab.
Screenwriting was one of the initial inspirations for the UI, because screenplays are naturally hierarchical (logline > Acts > Sequences > Scenes > Beats).
Questionable. I work in the film trade, and while people may consider a logline or a one-sheet, when some reads a script they sit down and read it start to finish, like a book. It's going to play in linear form on the screen, so it has to be read that way as well.
What authors usually do is is knock out a freeform treatment where the story is described in prose, which is then broken down into scenes. It is helpful to have the overview in mind during the writing process, but existing tools such as Final Draft provide a plethora of writing aids for that, from virtual index cards to graphical character timelines.
Bear in mind that when you work with finished scripts like the Alien example, you've got a survivor bias problem, because almost any story that makes it through the screen has been through multiple drafts and hundreds or thousands of mini-edits. So while it seems very natural to lay that out in a neat hierarchy, that doesn't really reflect the writing environment, which is a lot more messy.
As for keeping track of story context, this is job one for the writer - you can beef up the dialog or whatever later, but writers, directors and other keys need to be able to keep the entire story in their head at once and know what the inputs and and outputs of any given scene are, not least because 99.9% of films are shot out of chronological sequence and so being able to keep a handle on that story context is essential for guiding the actors. Obviously you don't try to remember every last little thing at once, that's why we use storyboards and breakdown sheets, but you do need to be able to articulate the whole story off the cuff at the drop of a hat.
I do think this would very useful for film students doing analysis, but I can't really see myself writing a script in it, although I'll try doing some treatments with it.
BTW I also feel that if you offer people the opportunity to try it, you should let them try it, not switch to asking for a signup. That really annoyed me.
The screenplay examples do only go up to the "scene card" level, but we plan to have more columns so you could add the script there as well. That way you could go start-to-finish, or have overviews as well.
> I do think this would very useful for film students doing analysis.
Interesting, thanks.
A question: would this be useful for pitching a film? Say if there were concept art sections, character descriptions, and additional notes, as well as the script itself (from logline down to linear form) ??
> BTW I also feel that if you offer people the opportunity to try it, you should let them try it
Again, sorry about this. It's what we've got, and we're trying to make the best of it.
Somewhat. A fully developed proposal will have a book with all that stuff, but OTOH it's a fact of life in Hollywood that you shouldn't spend too much money on that stuff before you go into production, for 2 reasons. One, it's a fast way to go broke. Two, you wouldn't have all that stuff to hand if you were trying to turn your friend onto a great film that you had seen and thought your friend should watch right now. Studio execs don't want to be distracted by eye candy or character sheets, they want to hear something that fires their imagination.
I didn't consider that presenting too much concept art & story details might detract from the experience of letting the concept blossom in the studio exec's own mind.
I'll have to sit down with some screenwriters again, and see if Gingko is something that they'd be able to use or not.
Have you thought about allowing for the creation of arbitrarily deep trees? That's one of the features I like most about workflowy. This looks really cool, though!
Do you have a newsletter or other way I could sign up to be notified of updates?
This hits a lot of points that I've been looking for in an app/service. So much so that I was ready to sign up for the paid plan after trying this out for a couples minute, because I'm sure I'd use it enough to be worth it. But I didn't realize the three-levels limitation, and that prevents this from being useful enough to me to start using it.
I'd love to check it out again when you do add infinite nesting.
Yes, Ted Nelson has some similar work in this line. But I think he went too far with the N dimensions... Text is linear, Gingko text is 2-dimensional.
With it, we can represent more than two dimensions, by simply "slicing" along any two we choose (e.g. text & comments)... not sure I'm explaining this properly :-/
I think Nelson's use of a more general graph has some value. I could see an encyclopedia or a program being edited/viewed in Gingko with circular references. With some tweaks on the UI (being able to put more emphasis on the card currently viewed, maybe by partially sliding out of view the parent cards or shrinking them when they're not focused).
I think this project is pretty cool and the idea is awesome. It would make a lot of sense on a tablet/phone and as a generalized editor.
Zig Zag was meant to represent a very general set of data structures, if you're interested in documents then you, probably, would have a more specific interest in his (very long running) Xanadu project - https://en.wikipedia.org/wiki/Project_Xanadu - which in some ways is very similar to OP's stuff - http://youtu.be/En_2T7KH6RA?t=3m27s
I like how it organizes information spatially, like WorkFlowy. I much prefer this visual organization to tags, for example. That said, I found it hard to understand what it was, even though I'm a long-time WorkFlowy user and am very interested in this kind of thing. I wrote a post where I talked about organizing information visually in more depth here: http://colemanfoley.quora.com/Mind-Mapping-with-WorkFlowy (Registration NOT required to read).
I'm a big user of Workflowy and I felt the same about Gingko at first. The keyboard shortcuts help a lot though because I can get my thoughts down on paper much more quickly.
Ontology/taxonomy/classification are seriously difficult things. If not semantic web would have ruled the world by now.
Structural hierarchies (chapter/section etc) may be easy to get for everyone but a navigation side panel would work too. If you build a semantic hierarchy, new users may not know how to find things; yet repeat users may be frustrated by having to go through the layers to access the items they are looking for.
The research manuscript example is exciting. It would be great if authors could link directly to the part of a paper that they are citing and be able to open that up if you want to dive deeper. Linking methods to results to discussion for specific experiments would make reading through dense papers a lot easier, and maybe have a notation/jargon definition section open at the same time. It's almost like a tiling window manager for reading.
I'm a little bit concerned about how it looks on smaller screens. It looks fine on my work monitor but I only have a netbook at home right now and a lot of websites have overlapping elements that keep me from reading articles. I haven't looked at this from that computer yet though. Maybe it would help to have collapsible columns if there are issues.
Good luck, I'm looking forward to seeing where this goes!
Yes, the idea of simply embedding parts of other people's papers right there, instead of citations, is something I'm excited about.
Literature review is such a pain, and could be a lot better.
As for smaller screens, we have plans for allowing this to be read on mobile, by collapsing columns and letting you scroll left-right to navigate the tree.
I'm certainly drawn to the idea and am inclined positively towards it. I'm even willing to overlook the ridiculous hubris of "This new medium will be the way most text is read and written in the future."
However, there are many confusing things to me as a person who arrived at the site through HN. Since one of the developers is promoting the "app" here, it might be useful to hear from him on these points:
1. Is this an input format or is it a publication format, or is it a viewer? Does it rely on a time-tested plaintext markup format like LaTeX or markdown? Perhaps it is a HTML viewer for a LaTeX markup document with special structure, rather than an actual typset web publication format.
2. What is the conceptual structure of the document system? Giving me a screenshot does not show me anything about the way you are conceptualizing your document. Is there a separation of content and output, output and viewer?
3. Is any part of this open source? Are you incorporating any other major technologies which have already been developed?
I apologize if any of the above seems harsh, but this is an important topic and I have become slightly tired of seeing flashy presentations about poorly-thought out "revolutionary" new document formats/tools/whatnot.
The hubris of the statement is not lost on me, but what should a founder be but delusional and optimistic :)
1. It's both a viewer and a word processor. It relies on Markdown (and LaTeX through extensions). We export to Md, but will be adding more import/export options in the future. We hope to create a publication standard for it.
2. The structure of the document is an "outline of index cards". Each card can have one or more children. Source content (in markdown) is edited by toggling edit mode on that card.
3. Yes, we are extracting parts of this as open-source. The rest remains proprietary (for now, at least).
> I apologize if any of the above seems harsh
No need to apologize. Thoughtful criticism is what we need.
> It relies on Markdown (and LaTeX through extensions). We export to Md, but will be adding more import/export options in the future. We hope to create a publication standard for it.
Do we need a new standard for structured documents? Would a <section> not be sufficient?
I've been working on a relatively similar, but much larger and very complex project (AI/Maths) for some years now. It makes me really happy to see people coming up with the vision of a "hypertext" perspective shift.
Do you mind explaining why your surname is Ferrari?
"Hypertext" perspective shift... I like that.
What's your project called? Can I see it?
PS: My ancestry goes: Italian > Argentinian > born in Kuwait > living in Canada. "Ferrari" means iron-worker in Italian, so it's not a rare surname in Italy.
"It's like a spreadsheet, immediately familiar, but much more suitable for complex data because it's hierarchical.
It's like a mind mapper, but more organized and compact.
It's like an outliner, but in more than one dimension.
It's like a text editor, but with structure. "
You can nest spreadsheet-like cells within cells within cells within cells.. and zoom in and out between the various levels of nesting.
For Windows and Ubuntu, with a beta for Mac OS X available.
You can export/import views as XML or CSV. The generated XML is UTF-8 encoded and it only has three element types in total for the cells and rows so the structure of the file isn't complicated at all.
Treesheets is an awesome way of structuring ideas and materials. As Matti said, the XML output from TreeSheets is easy to parse and convert for other uses. Basic HTML export is also provided as a simple means of sharing sheet data. Since TreeSheets is an open source project - it is possible to extend these areas of functionality to meet your own workflow needs and the code is easy to follow and fun to work with.
One of the virtues of Evernote is that you are not stuck in a hierarchy if you don't want to be. I find Clay Shirky's well-known criticisms of pervasive hierarchies to be quite persuasive. I'm looking for something that doesn't paint me into an hierarchical corner. Evernote is certainly a step in the right direction, and the IHMC concept mapping software can work very well too.
We have the ability to filter, using the Search feature. You can just type @tags, and searching them will hide all cards that don't containt that text.
Let me know if you have any other questions or suggestions.
Interesting idea. Can you make it so that when I click in the card it automatically goes into edit mode? Having to click an "edit" button really slows things down.
With better support mobile devices (including eReaders and whatever comes after them), we hope it'll be less of an issue as time goes on.
Right now, we simply export the Markdown to flat text (breadth-first). But we will be adding PDF export options, for exporting the whole document, or one column.
That way, you can still end up with a traditional document at the end, if you want.
Have the breadth as a summary page perhaps? Like when you open a book and it's effectively the list of chapters. Then have the 2l tiers as your chapters and the 3l tiers as the subheadings in those chapters?
Don't know whether that's what you're doing at the moment :)
If you just created a document with each hierarchy organized properly, I think you should be fine.
E.g. you create say 3 heading sizes in Word. 24px, 20px, 16px.
Then for the main point, i.e. the content in the left-most column, you put those under a heading that is under the 24px - then any sub content from the 2nd column would go under a 20px heading that is under the first 24px heading and so on.
So there is a chronological order of the content.
I think that's all you need. Proper placement of the content under the right headings, make the headings different sizes and you make sure it flows like the author intended (which I think you can ensure by using the order they setup on your site).
I can't just scroll through or scan read, and I'm met with a variety of different things all at once. Everything's always visible, so I don't know what I'm looking at. I've scrolled down on the lowest level, and read a bit but have no understanding of the context. Clicking on it makes me realise where I am but I've skipped over a load of stuff in the middle so I'm scrolling back up that to find where I left off... I think this is a visual thing though rather than a major issue with the idea. Fiddling a bit I've only just found that not every node has children, but this this is only indicated by nothing happening (which is identical to something that should happen but doesn't)
This is really a different formatter for the same structure of text we've already been using, so the hyperbole is a bit of a turnoff for me.
\section{some title}
Explanatory text
\subsection{subsection title}
Sub text
Why do we need something new? What's being added? What couldn't I do before that's now possible? These are the things I want to know when you tell me you've got a new hierarchical document. Can I already read these well with a screen-reader? The ordering in the source would (I think) read each column individually, which wouldn't make sense. Try loading your viewer without CSS. Imagine a screenreader hitting the massive block of JSON at the bottom of the page. Why is that in the body?
I agree, the UI needs improvement. No one feels the gaps more than I do. But they say, "launch before you're ready!" ;)
For one thing, scrolling on its own (with mouse scroll), doesn't automatically highlight whichever card is now centered. So it breaks the flow. Clicking, or scrolling with keyboard are the only way right now to keep the context clear.
> the hyperbole is a bit of a turnoff for me.
I know, it's a big claim, and I don't expect anyone else to believe it. I thought about not including it, but it's honestly what I believe. Delusional founder? Check.
> This is really a different formatter for the same structure of text we've already been using
That's true, more or less. Table of contents, chapter & subsection breaks, etc, are all attempts to make the structure clearer.
However, once we go beyond 3 levels deep, this has significant advantages.
One can get an overview of a text by reading column 1, but can drill deeper and deeper into specific sections, and even into other trees that are embedded (or "transcluded") into this one. We could have all of physics, or comp-sci, in one tree, and the reader will always be able to drill in for more, or zoom out for overview.
> Why do we need something new? What's being added? What couldn't I do before that's now possible?
There are great benefits for writing this way, for one. Rearranging entire sections or subsections is just a drag and drop. Working collaboratively is also easier, because each person can focus on their particular strengths
> Hopefully this criticism is helpful.
It is, thank you. All criticism forces us to reevaluate our approach, again and again.
It's cool you believe in your product and its potential. At a first glance, I'm really interested in trying it out, but yeah "This is gonna change the world" kind of mantra really isn't what I need to see from and center. I don't know who you are, so unfortunately it comes off as pitchy. Tell me how this will help me convey and consume content.
I think what you've done is pretty cool. Obviously it's not going to be everyone's cup of tea, but for me, I think it's more useful than those "distraction free" writing tools that are so popular today. My challenge when writing long documents isn't the noise around the screen, it's simultaneously managing a whole pile of thoughts related to the structure.
I really like the simple approach you've taken to the UI, but that's subjective. My main criticism about the app would be that I'd rather pay $20-$30 for a native app than subscribe to a web app.
In any case, good luck, I hope your app is successful.
Here's an idea: How about you create a read-only view where all the elements are inlined, just like in a 'normal' document? As I see it, right now it's useful for creators to organize their thoughts, but there is no way for consumers of your thoughts to grasp them in an easy manner, they basically first need to learn the structure of the thought in order to navigate it. This is why we create linear documents, where everything is put down im some sort of coherent order one can follow. We basically apply a sorting algorithm to our content - the difference is that with your new tool you can try to automate that sorting while enabling the creators to follow their thoughts in their own preferred structure.
> agree, the UI needs improvement. No one feels the gaps more than I do. But they say, "launch before you're ready!" ;)
Oh I fully agree, I'm also sure that things I don't like are points of joy for others :) Launching like this is important, it helps you focus on things that people find rather than things you think they'll find.
> For one thing, scrolling on its own (with mouse scroll), doesn't automatically highlight whichever card is now centered. So it breaks the flow.
Yeah, I was going to try and suggest something but I'm not sure what'd be better (I make terrible UIs). The problem is the alternative is while you're scrolling automatically making other columns move which could be jarring. Your approach might be better and I might be 'using it wrong' because I'm trying to read it like a normal doc.
> That's true, more or less. Table of contents, chapter & subsection breaks, etc, are all attempts to make the structure clearer.
But you have the same structure, internally. That was rather my point. It's an editor and a viewer, not a new structure, which is why I would heavily suggest you use standards rather than writing your own.
This is covered by already existing standards, which will play nice with accessibility devices too. If I was a company, I could be held liable if I release something which is unusable to the blind because of the way I'd mixed the content.
> We could have all of physics, or comp-sci, in one tree, and the reader will always be able to drill in for more, or zoom out for overview.
I hate to be a downer on this, but a tree won't describe these things well, there isn't an exact hierarchy. So you improve it incrementally like so:
* Make it a DAG
* Realise there can be cyclic references, make it a graph
* See that the graph looks like trees with links but with links in between them
* Represent it as a series of distinct trees with links and anchor points
* Make it lazy loading
* Define a way of allowing people to link between different trees stored anywhere
* Realise that's the internet
While that's a bit of an annoying thing to say, it's actually nice :) Lots of stuff that'd be a great boon already exists. If you can use existing HTML standards then you get lots of functionality for free.
> Working collaboratively is also easier, because each person can focus on their particular strengths
Yes, it will really help this, having embeddable nested trees works wonderfully, it's why latex is nice for collaborative work. Although I'd like the nesting to be arbitrary (maybe there's a way of doing this, but I don't think so). It's also why the web works so well.
What I'd suggest is this:
* Use HTML sections.
* Write a bit of js to load in specific nodes from other documents lazily. The semantics for linking already exist.
* Keep the sexy visuals :)
You'll have properly marked up, parseable documents. They'll link together or be embeddable (depending only on the renderer, the semantics are the same) and you can represent any graph with it, but still have a focus on trees, and render graphs as trees. You'll get more and have to build less yourself.
I'm not sure why, but I can't edit this reply, but here's a link to a simple gist that shows a simple inclusion technique that keeps the semantics and degrades nicely if you don't have JS (you're left with anchored links).
140 comments
[ 4.3 ms ] story [ 264 ms ] threadAs for the format, we simply export to flat Markdown. We will be supporting other formats (including XML, and the OPML standard for hierarchical/outline text).
Thanks for your feedback!
Me: Cool, a demo! [click]
Web: But first, you must Sign Up...[trollface]
Me: Nope nope nope...
Might do in the future, but for now, that's what we have.
They took a fresh, web-centric look at how to interactively display research papers. It's being used — right now — to display all of the new articles from a major biology journal.
I think it's quite nice.
Personally, I think that things like this Lens reader are evolutionary advances, but science communication needs a revolutionary change.
I don't expect actual journals to be using Gingko any time soon, but there are already grad students collaborating on research papers right now :)
Browser sadly zoom the whole page nowadays, not just the text. So that is not a good solution.
https://gingkoapp.com/Alien-1979
Screenwriting was one of the initial inspirations for the UI, because screenplays are naturally hierarchical (logline > Acts > Sequences > Scenes > Beats).
What authors usually do is is knock out a freeform treatment where the story is described in prose, which is then broken down into scenes. It is helpful to have the overview in mind during the writing process, but existing tools such as Final Draft provide a plethora of writing aids for that, from virtual index cards to graphical character timelines.
Bear in mind that when you work with finished scripts like the Alien example, you've got a survivor bias problem, because almost any story that makes it through the screen has been through multiple drafts and hundreds or thousands of mini-edits. So while it seems very natural to lay that out in a neat hierarchy, that doesn't really reflect the writing environment, which is a lot more messy.
As for keeping track of story context, this is job one for the writer - you can beef up the dialog or whatever later, but writers, directors and other keys need to be able to keep the entire story in their head at once and know what the inputs and and outputs of any given scene are, not least because 99.9% of films are shot out of chronological sequence and so being able to keep a handle on that story context is essential for guiding the actors. Obviously you don't try to remember every last little thing at once, that's why we use storyboards and breakdown sheets, but you do need to be able to articulate the whole story off the cuff at the drop of a hat.
I do think this would very useful for film students doing analysis, but I can't really see myself writing a script in it, although I'll try doing some treatments with it.
BTW I also feel that if you offer people the opportunity to try it, you should let them try it, not switch to asking for a signup. That really annoyed me.
The screenplay examples do only go up to the "scene card" level, but we plan to have more columns so you could add the script there as well. That way you could go start-to-finish, or have overviews as well.
> I do think this would very useful for film students doing analysis.
Interesting, thanks.
A question: would this be useful for pitching a film? Say if there were concept art sections, character descriptions, and additional notes, as well as the script itself (from logline down to linear form) ??
> BTW I also feel that if you offer people the opportunity to try it, you should let them try it
Again, sorry about this. It's what we've got, and we're trying to make the best of it.
I didn't consider that presenting too much concept art & story details might detract from the experience of letting the concept blossom in the studio exec's own mind.
I'll have to sit down with some screenwriters again, and see if Gingko is something that they'd be able to use or not.
Infinite depth is coming (as well as other exciting features).
This hits a lot of points that I've been looking for in an app/service. So much so that I was ready to sign up for the paid plan after trying this out for a couples minute, because I'm sure I'd use it enough to be worth it. But I didn't realize the three-levels limitation, and that prevents this from being useful enough to me to start using it.
I'd love to check it out again when you do add infinite nesting.
Glad to hear that, Jeremy.
I've tagged you with "infinite-columns" in Intercom, so I can update you when we add that feature.
> That prevents this from being useful enough to me to start using it.
I agree, I struggle with this limit too, and it's my #1 most desired feature too... we're working on it!
Let me know if you have any other questions or comments.
With it, we can represent more than two dimensions, by simply "slicing" along any two we choose (e.g. text & comments)... not sure I'm explaining this properly :-/
I think this project is pretty cool and the idea is awesome. It would make a lot of sense on a tablet/phone and as a generalized editor.
Structural hierarchies (chapter/section etc) may be easy to get for everyone but a navigation side panel would work too. If you build a semantic hierarchy, new users may not know how to find things; yet repeat users may be frustrated by having to go through the layers to access the items they are looking for.
The research manuscript example is exciting. It would be great if authors could link directly to the part of a paper that they are citing and be able to open that up if you want to dive deeper. Linking methods to results to discussion for specific experiments would make reading through dense papers a lot easier, and maybe have a notation/jargon definition section open at the same time. It's almost like a tiling window manager for reading.
I'm a little bit concerned about how it looks on smaller screens. It looks fine on my work monitor but I only have a netbook at home right now and a lot of websites have overlapping elements that keep me from reading articles. I haven't looked at this from that computer yet though. Maybe it would help to have collapsible columns if there are issues.
Good luck, I'm looking forward to seeing where this goes!
Yes, the idea of simply embedding parts of other people's papers right there, instead of citations, is something I'm excited about.
Literature review is such a pain, and could be a lot better.
As for smaller screens, we have plans for allowing this to be read on mobile, by collapsing columns and letting you scroll left-right to navigate the tree.
However, there are many confusing things to me as a person who arrived at the site through HN. Since one of the developers is promoting the "app" here, it might be useful to hear from him on these points:
1. Is this an input format or is it a publication format, or is it a viewer? Does it rely on a time-tested plaintext markup format like LaTeX or markdown? Perhaps it is a HTML viewer for a LaTeX markup document with special structure, rather than an actual typset web publication format.
2. What is the conceptual structure of the document system? Giving me a screenshot does not show me anything about the way you are conceptualizing your document. Is there a separation of content and output, output and viewer?
3. Is any part of this open source? Are you incorporating any other major technologies which have already been developed?
I apologize if any of the above seems harsh, but this is an important topic and I have become slightly tired of seeing flashy presentations about poorly-thought out "revolutionary" new document formats/tools/whatnot.
1. It's both a viewer and a word processor. It relies on Markdown (and LaTeX through extensions). We export to Md, but will be adding more import/export options in the future. We hope to create a publication standard for it.
2. The structure of the document is an "outline of index cards". Each card can have one or more children. Source content (in markdown) is edited by toggling edit mode on that card.
3. Yes, we are extracting parts of this as open-source. The rest remains proprietary (for now, at least).
> I apologize if any of the above seems harsh
No need to apologize. Thoughtful criticism is what we need.
Thanks!
Do we need a new standard for structured documents? Would a <section> not be sufficient?
I've been working on a relatively similar, but much larger and very complex project (AI/Maths) for some years now. It makes me really happy to see people coming up with the vision of a "hypertext" perspective shift.
Do you mind explaining why your surname is Ferrari?
PS: My ancestry goes: Italian > Argentinian > born in Kuwait > living in Canada. "Ferrari" means iron-worker in Italian, so it's not a rare surname in Italy.
PS: Very interesting ancestry, wish I had more knowledge into my own. It led me to think that you might be related to the Ferrari Company somehow.
PS: Very interesting ancestry, wish I had more knowledge into my own. It led me to think that you might be related to the Ferrari Company somehow.
"It's like a spreadsheet, immediately familiar, but much more suitable for complex data because it's hierarchical. It's like a mind mapper, but more organized and compact. It's like an outliner, but in more than one dimension. It's like a text editor, but with structure. "
You can nest spreadsheet-like cells within cells within cells within cells.. and zoom in and out between the various levels of nesting.
For Windows and Ubuntu, with a beta for Mac OS X available.
An in-browser, collaborative version would be a serious killer app.
I've tried WorkFlowy but I didn't like the presentation. I prefer cards and in Gingko's case you get the added benefit of having a great overview.
I should have used "Evernote + Workflowy" in the title, since that seems to be what people immediately understand about Gingko.
Get in touch if you ever have any thoughts or questions.
I've even been testing it on my Kindle this morning, and was surprised to see it (almost) works there too!
Improvement: Allow to filter and color cards. So you can walk through all cards of a given type.
We have the ability to filter, using the Search feature. You can just type @tags, and searching them will hide all cards that don't containt that text.
Let me know if you have any other questions or suggestions.
Another point: Make cards collapsible/expandable to get a quicker overview about topics. (It is also an aid to the process of memorizing cards)
Collapsing to "header only" is something we might have to add, after we implement infinite columns (so we can get a quicker overview of large trees).
Thanks for the feedback.
That will let you write a group of cards as one flow, and it'll split it into individual cards once you leave fullscreen.
Single click would be easier, but since we have drag-and-drop, and sometimes use clicking just for navigation, we have to use double-click to edit.
(unless you have a better approach in mind?)
PS: Also, once you get used to them, the keyboard shortcuts lets you navigate & edit pretty quickly.
Also, just now I was seeing other people's cards showing up in my tree. When I switched trees, it corrected itself.
Can it be exported to PDF or be printed or something?
When you print it, how does it look?
Right now, we simply export the Markdown to flat text (breadth-first). But we will be adding PDF export options, for exporting the whole document, or one column.
That way, you can still end up with a traditional document at the end, if you want.
Any other ideas?
Don't know whether that's what you're doing at the moment :)
If you just created a document with each hierarchy organized properly, I think you should be fine.
E.g. you create say 3 heading sizes in Word. 24px, 20px, 16px.
Then for the main point, i.e. the content in the left-most column, you put those under a heading that is under the 24px - then any sub content from the 2nd column would go under a 20px heading that is under the first 24px heading and so on.
So there is a chronological order of the content.
I think that's all you need. Proper placement of the content under the right headings, make the headings different sizes and you make sure it flows like the author intended (which I think you can ensure by using the order they setup on your site).
That's just my $0.02.
It's true that if every card had a title, then import and export while maintaining the tree structure would be easy.
But as it stands, if you have the following cards:
this approach wouldn't be able to maintain the structure if the cards didn't have titles (it would just list all these as A, A.1, A.2, B).It's for this reason alone that we've considered making titles required for at least the first card in a group.
Or am I overthinking again... ?
But I don't think you NEED to.
I would assume that the way you know the order of the cards, is that you have some unique ID on the flow of the cards, no?
E.g. You know that A is first, then A.1, then A.2, then B.
So all you do is when you are exporting to PDF, you put the sections/cards in that order.
I think that should suffice, or am I missing something?
I find this really hard to read, sorry.
I can't just scroll through or scan read, and I'm met with a variety of different things all at once. Everything's always visible, so I don't know what I'm looking at. I've scrolled down on the lowest level, and read a bit but have no understanding of the context. Clicking on it makes me realise where I am but I've skipped over a load of stuff in the middle so I'm scrolling back up that to find where I left off... I think this is a visual thing though rather than a major issue with the idea. Fiddling a bit I've only just found that not every node has children, but this this is only indicated by nothing happening (which is identical to something that should happen but doesn't)
This is really a different formatter for the same structure of text we've already been using, so the hyperbole is a bit of a turnoff for me.
etc.Or
Why do we need something new? What's being added? What couldn't I do before that's now possible? These are the things I want to know when you tell me you've got a new hierarchical document. Can I already read these well with a screen-reader? The ordering in the source would (I think) read each column individually, which wouldn't make sense. Try loading your viewer without CSS. Imagine a screenreader hitting the massive block of JSON at the bottom of the page. Why is that in the body?For one thing, scrolling on its own (with mouse scroll), doesn't automatically highlight whichever card is now centered. So it breaks the flow. Clicking, or scrolling with keyboard are the only way right now to keep the context clear.
> the hyperbole is a bit of a turnoff for me.
I know, it's a big claim, and I don't expect anyone else to believe it. I thought about not including it, but it's honestly what I believe. Delusional founder? Check.
> This is really a different formatter for the same structure of text we've already been using
That's true, more or less. Table of contents, chapter & subsection breaks, etc, are all attempts to make the structure clearer.
However, once we go beyond 3 levels deep, this has significant advantages.
One can get an overview of a text by reading column 1, but can drill deeper and deeper into specific sections, and even into other trees that are embedded (or "transcluded") into this one. We could have all of physics, or comp-sci, in one tree, and the reader will always be able to drill in for more, or zoom out for overview.
> Why do we need something new? What's being added? What couldn't I do before that's now possible?
There are great benefits for writing this way, for one. Rearranging entire sections or subsections is just a drag and drop. Working collaboratively is also easier, because each person can focus on their particular strengths
> Hopefully this criticism is helpful.
It is, thank you. All criticism forces us to reevaluate our approach, again and again.
Why will it change my world?
I really like the simple approach you've taken to the UI, but that's subjective. My main criticism about the app would be that I'd rather pay $20-$30 for a native app than subscribe to a web app.
In any case, good luck, I hope your app is successful.
Oh I fully agree, I'm also sure that things I don't like are points of joy for others :) Launching like this is important, it helps you focus on things that people find rather than things you think they'll find.
> For one thing, scrolling on its own (with mouse scroll), doesn't automatically highlight whichever card is now centered. So it breaks the flow.
Yeah, I was going to try and suggest something but I'm not sure what'd be better (I make terrible UIs). The problem is the alternative is while you're scrolling automatically making other columns move which could be jarring. Your approach might be better and I might be 'using it wrong' because I'm trying to read it like a normal doc.
> That's true, more or less. Table of contents, chapter & subsection breaks, etc, are all attempts to make the structure clearer.
But you have the same structure, internally. That was rather my point. It's an editor and a viewer, not a new structure, which is why I would heavily suggest you use standards rather than writing your own.
The structure is this
This is covered by already existing standards, which will play nice with accessibility devices too. If I was a company, I could be held liable if I release something which is unusable to the blind because of the way I'd mixed the content.> We could have all of physics, or comp-sci, in one tree, and the reader will always be able to drill in for more, or zoom out for overview.
I hate to be a downer on this, but a tree won't describe these things well, there isn't an exact hierarchy. So you improve it incrementally like so:
* Make it a DAG
* Realise there can be cyclic references, make it a graph
* See that the graph looks like trees with links but with links in between them
* Represent it as a series of distinct trees with links and anchor points
* Make it lazy loading
* Define a way of allowing people to link between different trees stored anywhere
* Realise that's the internet
While that's a bit of an annoying thing to say, it's actually nice :) Lots of stuff that'd be a great boon already exists. If you can use existing HTML standards then you get lots of functionality for free.
> Working collaboratively is also easier, because each person can focus on their particular strengths
Yes, it will really help this, having embeddable nested trees works wonderfully, it's why latex is nice for collaborative work. Although I'd like the nesting to be arbitrary (maybe there's a way of doing this, but I don't think so). It's also why the web works so well.
What I'd suggest is this:
* Use HTML sections.
* Write a bit of js to load in specific nodes from other documents lazily. The semantics for linking already exist.
* Keep the sexy visuals :)
You'll have properly marked up, parseable documents. They'll link together or be embeddable (depending only on the renderer, the semantics are the same) and you can represent any graph with it, but still have a focus on trees, and render graphs as trees. You'll get more and have to build less yourself.
https://gist.github.com/IanCal/6398286