Live data from Hacker News

Show HN: Gingko, a tree-document editor

gingkoapp.com

101–110 of 141 posts

Re: Show HN: Gingko, a tree-document editor

#101
post #88

I don't want to have to think when I read a book. The author has to lead me through and follow a path. The auther has to make sure I get a decent introduction and he should make every sentence count. 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.

The same criticism applies to wikis and their nonlinear way of presenting information. Despite that, people find wikis tremendously valuable, and a big part of it is the ability to jump around, following your own path through the information.

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.

Re: Show HN: Gingko, a tree-document editor

#102

Earlier quoted context omitted.

It's great to have a film insider's take on this. 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…

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 .…

I see. Again, thanks for the insider info.

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.

Re: Show HN: Gingko, a tree-document editor

#103

Interesting. This is actually close to the original idea of hypertext (Ted Nelson's vision: "documents - side by side"). I would really turn down the tone. Let the reader decide how important he thinks the idea is.

Most of the site is much more toned down, but I thought I'd share what I believe about Gingko's potential.

I respect Nelson, but his intensity is off-putting... don't want to make the same mistake.

Re: Show HN: Gingko, a tree-document editor

#104

I'm sorry if I'm rude, but the more I think of if it, the less I see the point. 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 us…

> that sometimes, the tree is more like a graph

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.

Re: Show HN: Gingko, a tree-document editor

#105

Earlier quoted context omitted.

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. Any other ideas?

I think you may be overthinking it. 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…

I love overthinking things!

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:

    A  A.1
       A.2
    B
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... ?

Re: Show HN: Gingko, a tree-document editor

#106
post #59

Hopefully this criticism is helpful. 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 stu…

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…

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.

Why will it change my world?

Re: Show HN: Gingko, a tree-document editor

#107
Gingko is intimidating. It looks like a neat way to work

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.

Re: Show HN: Gingko, a tree-document editor

#108
post #15

Reminds me of Ted Nelson's Zigzag, only he had N dimensions and a cell structure. http://xanadu.com/zigzag/

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 :-/

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

Re: Show HN: Gingko, a tree-document editor

#109
First of all, congratulation for pulling off a new and experimental user interface!

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.

Post reply on HN