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 :)
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.
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.
\section{some title}
Explanatory text
\subsection{subsection title}
Sub text
etc.Or
<section>
<h1>heading</h1>
<p>Text</p>
<section>
<h2>heading 2
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.
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
Section := Title, Content | Title, Content, [Section]
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 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.
Why will it change my world?
"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.
Browser sadly zoom the whole page nowadays, not just the text. So that is not a good solution.
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?
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.
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?
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.
Don't know whether that's what you're doing at the moment :)
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.
Fuck start-ups and capitalism.
Did you perchance take a wrong turn on the interweb tubes, and arrive at this website by mistake?
You are right, though; nothing proprietary and costly is ever going to 'change the world' of something so basic as reading and writing...
I think you should still consider and perhaps respond to the point instead of just discounting it because its out of place.
Every once in a while there's something important that I get from HN, which is why I've kept coming back since starting to get better. Some time ago I decided it really wasn't worth it, and I haven't yet quit because I'm just on auto-pilot and come here when I'm bored. I'll get around to quitting soon though. Thanks for the reminder.
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.
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).
Thanks for your feedback!
2) It could be nice if the sections M+1/M-1 (above/below) the selected section in column N were given a subtle distinct color, and then the appropriate sections in column N+1 that are nested in M+1/M-1 were given the same color. Does that make any sense? It would give a visual indication of which sections in column N+1 lie within sections M+1 and M-1, and also help to emphasize the tree nature of the layout. A different color could be chosen for M+/-2, +/-3, etc.
Good job! :)
Unfortunately, it got too messy, and neither of us are designers, so we had to shelve it for now.
As for scrolling, and want the mouse scrolling to work just like keyboard (selects the card at center, reorders other columns appropriately). Haven't gotten around to it yet.
Thanks for your feedback!
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.
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)
I'm worried that what I am typing into this might show up in someone else's tree.
No one can see your trees. The "bunch of text" bug has never happened before, will try to track it down.
Probably due to the flood of traffic from HN!
UPDATE from my cofounder:
"fyi: I fixed that bug weird one" - Aleksey Kulikov
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's one fatal-for-me flaw in your current implementation: only three layers deep. Deal-breaker. I'd love to hear about it if/when you change that behavior, so that I can start trying this seriously.
I saw your comment about future possible options to self-host, or offline mode, or something like that. That's definitely interesting to me. Self-hosting would be ideal, really. But I also very much like having the option to use your servers.
When you mentioned exporting to Markdown, you mentioned breadth-first. I'm not at all sure that you want breadth-first. The documents I'm imagining writing will make more sense exported depth-first.
I think it would benefit from a little visual cue to see where one card ends and the next begins, even for cards not currently selected. My first attempt would be to let the grey background show through the white cards, but whatever.
I agree that the default text size is a bit too big. Maybe some scaling could be added as an option when configuring a tree.
Yes, more than three layers deep is our highest priority, along with offline mode.
And you are right, I meant "depth-first"; makes more sense.
The initial described problem (organising ideas in a hierarchical way) has already been solved efficiently years ago with visual mind maps. They have been used successfully to not only create the hierarchy, but also to realise that sometimes, the tree is more like a graph.
As a reader, it's infuriating to have to click all the time (or use keyboard) and have this page scrolling all around. I just want to READ, not being distracted by some kind of useless parallax effect.
As a writer, moving ideas around to get them properly organised is really painful. There is no distraction-free interface neither.
If you really want to make tool for writers, I would strongly suggest you that you take a look at tools like Ulysses or Scrivener and try to understand the rationale behind the UI choice they made.
I agree, but I think it's better to start with a tree, and then add graph-like features, than to start with a graph and try to make a tree out of it. Mostly because I believe hierarchy is a more natural structure for our brains.
For reading non-fiction, yes the parallax can be distracting. But I think A) the interface can be improved. B) For non-fiction, it's outweighed by the benefit of having context & details available.
We do have plans for a distraction free mode, similar to "Zen mode" on Github. But offline & deeper trees are a priority for now.
I have studied Scrivener, but didn't know about Ulysses. Thanks for pointing it out.
I like stuff going to the web, but until that works fully offline after installation (so being able to make new projects, save them, change them, do everything except the stuff which really requires internet), I don't really have much use for productivity apps like this.
My cofounder is working on full offline support right now, as it's been a much requested feature.
Suppose my tree structure is as so:
* a
** b
*** c
* d
** e
*** f
*** g
*** h
Gingko lays it out like this: a b c
d e f
g
h
If I'm in the far right column, let's say I've highlighted item g and go up to item f. However, I hold the arrow key down a little too long and overshoot to item c. This causes everything to the left to suddenly jump around and disorient me.A related issue, the layout suggests that c-f-g-h is an intended list when it isn't. It can cause readers to become confused if they're reading normally in one column and don't fully realize they've jumped to a different branch in between c and f.
For one thing, the looping back when holding the arrow key is annoying to me too, and a simple fix we will get to.
As for the branch jumping, we tried other approaches, but haven't found one that works well in all cases.
The core of Gingko, navigating tree structures, is something we are constantly trying to improve.
Thanks for your feedback!
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.
This is nice to play. And maybe even has it's applications such as documentation where quick browsing helps. But if I had to read a thesis/book like this I'd be a very unhappy person.
This thing is confusing at first, but it looks like it could be pretty darn slick after spending a few minutes getting used to it.
1) What I miss is the possibility to attach files. This would be essential in typical collaborative environments. 2) I don't want to give you my data. So localstorage or export/import is essential.
Offline & import/export are features in the pipeline.
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.
You can check it out at http://papers.mcgillweb.com
I respect Nelson, but his intensity is off-putting... don't want to make the same mistake.
I've even been testing it on my Kindle this morning, and was surprised to see it (almost) works there too!
That will let you write a group of cards as one flow, and it'll split it into individual cards once you leave fullscreen.
However, I believe, the idea that tree- or graph-like structuring of text is beneficial for reading and writing text in general, comes close to the graphical programming fallacy. Eventually, the spatial make-up fails because of the following three reasons:
(1) The manual difficulty of navigation and the count of subconscious visual cues necessary for retrieving a passage increase exponentionally as the content grows, (2) altough thoughts do seem to come in hierarchical structures, we usually don’t think of text, code, stories, memories nor knowledge as visual graphs and (3) textual hints for emphasizing and linking text are more efficient and flexible than visual hints.
At first glance, Wikipedia seems like an affirmative example for graph-like structured text, but that structure is usually not used for primarily intended navigation. The articles are actually expected to be self-contained for readers with only a fair amount of prior knowledge.
It's more fully baked and I think has a better UI that Ginko (writing a book or long piece with 3 relatively small columns isn't ideal).
Unfortunately it is marketed poorly, so not a lot of people know about it, but I have found it very useful when doing writing for longer pieces.
but when I see a big button called "try it now" (red flag), with testimonials (big red flag), no download (small red flag), and no mention of licensing, privacy, or cost (edit: it was just hidden), or... anything (big red flag). My experience tells me to avoid it, and to council everyone else to avoid it as well.
I don't want to be gouged, aggregated, or advertised to. I would love to use your tool. I just can't be sure you wont use that desire against me. I can't find anything on your site that will assure me that wont happen.
edit: AHA. I did find your pricing.
https://gingkoapp.com/p/pricing/
So at least you're mechanism of monetization is there.
I envisioned something very different from the screenshots. I expected you to be able to expand and collapse nodes, with the collapsed nodes existing only to provide a summary of the surrounding information. I can see the appeal of having everything visible so that you can just scroll through the document as you would now, but in that case the scroll positions of the columns need to be dynamically linked and there needs to be more feedback about which nodes serve as a summary or context for which other nodes.
In general, I think the process of reading a Gingko document is not clear to a first-time reader. Fixing this will require changes to both functionality and design.
I've thought about building something like Gingko for a long time, so thanks for providing an alternative option!
Is that a bug or is that how it's supposed to work? I often scroll to the end of a short document by holding down the down arrow until things stop moving.