Live data from Hacker News

Show HN: Gingko, a tree-document editor

gingkoapp.com

121–130 of 141 posts

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

#121
post #75

Earlier quoted context omitted.

seems nice, but I have a question: can it import - export to other formats? Latex, markdown, csv ....

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.

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

#122

Earlier quoted context omitted.

For three levels deep, no we don't need a new standard. Larger trees, linked together will probably need something new.

Why does it matter how many levels there are?

He's probably talking about many-to-many relationships that he has planned.

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

#123
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…

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.

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

#124
post #116
post #113

Earlier quoted context omitted.

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

That said, my being in the wrong place doesn't change the fact that startups and capitalism are both lame and evil and retarded. I think you should still consider and perhaps respond to the point instead of just discounting it because its out of place.

You might benefit from reading this: http://www.theobjectivestandard.com/issues/2008-summer/stand...

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

#125
post #6

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.

Have you seen eLife's Lens reader? Example article is at http://lens.elifesciences.org/#00772 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.

Wow, this is so much nicer than PDFs. Thanks for the example.

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

#126
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…

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

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.

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

#127
post #73

Earlier quoted context omitted.

> 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 not be sufficient?

For three levels deep, no we don't need a new standard. Larger trees, linked together will probably need something new.

Larger trees are fine with , and linking together is already defined with .

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

#128
I want the tool you're building! It's got huge overlap with a project I was just in the planning phase of, a cloud-ified FreeMind.

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.

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

#129
post #27

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…

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

Hi Adrioano,

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?

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

#130
post #126

Earlier quoted context omitted.

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…

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

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

https://gist.github.com/IanCal/6398286

Post reply on HN