I particularly like that they keep the metadata and the content of the note separate. This is the same thing Camlistore does, and it's nice for version control because making changes to the metadata (adding new tags or whatever) doesn't show up as a content change.
Speaking of version control, Quiver's thoughts on this are interesting:
"Since Quiver stores all the data in plain JSON files, it’s easy to put the whole library (or a specific notebook) under version control. This is another way to collaborate with your team."
Leaving version control up to the user isn't the worst, but it does mean that it won't be straightforward to put an "undo" in the GUI (if the GUI already has undo somehow I'd like to hear how they do it).
I'm also not sure whether it would be better to version the whole notebook or individual qvnotes. I have more thoughts on this (starting from a slightly different angle of how it relates to wikis) here: http://housejeffries.com/page/4.
EDIT: Something just occurred to me. If HappenApps wanted to make a machine readable schema for qvnotebook and qvnote they could use JSON Schema for the JSON part. What would they use for the directory part? Is there such a thing as a schema for directories? (e.g. this directory must contain a `content.json` file, a `meta.json` file, etc.)
The more I read about different applications, the more I think you can't understand them unless you look at the underlying data format.
"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious."
Probably not. Hell I've never even read the book. Instead I learned through experience and observation then later learning about the book and a summation of it :)
I don't know if you can compare ANYTHING to org-mode :P
But it is a small program, gtk gui (I think), it is WYSIWYG,
has lots of plugins (calendar, todo, tex equations) and it is a Wiki. Even the calendar plugin is mostly a helper to create note-pages with the date as their title.
Based on the fact that they are using ACE to edit code cells and MathJax to render Latex, I'm going to go out on a limb and guess that a large chunk of the app is written using web technologies, and porting to Windows/Linux should be relatively straight-forward.
It starts up under 50MB with the built in notebook. Scrolling around between notes (with images) and starting a new notebook, I managed to get it up to 150MB (and then back down, so no strong evidence of memory leaks).
Not a huge deal to me for an app of this functionality at this point in time. (I do remember being able to run X11 + Netscape in 16MB, though.)
That honestly isn't a small flaw if you are building a note/documentation application of any kind. The ability to share it is too valuable to use anything that can't be used on all platforms.
According to the StackOverflow survey Windows has been losing developers for the past three years (though that's obviously not a new trend). So much that those stats say that there are about 2/3rds as many developers on OSX as were on Windows 7 (I don't know when 10 came out, but it's not represented).
IME if you're on a Mac at your day-job you on-average have a lot more freedom in which tools you're using, and you're a lot more likely to spend your own money on them.
All that just to say: I'd be very surprised if releasing for OSX first wasn't the best financial move for them.
<i>I like the concept, but it's a non-starter while it's not available on... I don't know... the largest platform</i>
It is slightly unfair to complain about what platforms a developer chooses to publish his/her work on. Perhaps they have been a long term Apple user? Perhaps they don't know anything about Windows development.
Windows may be the largest, but there are so many good apps and developers making a living off the smaller platforms. This doesn't make using their apps a "non-starter".
> This doesn't make using their apps a "non-starter".
I don't think the parent meant a "non-starter" in general. This app seems really awesome, but I primarily develop on Windows, so it's a non-starter for me, which is really too bad. I was really excited looking through the page until I noticed it was only on OS X.
That and I'd prefer my electronic notebook to be available on my phone as well, so that's another reason I wouldn't use it. But if this ever comes out for Windows/Android, I'd definitely be excited to try it out.
I understand what you are saying. I re-read the parent post and it sure does seem that is exactly what the post says.
There are so many platforms available. I don't think apps would ever get released (or companies started) if for people to adopt them they had to be out for every desktop and mobile platform. That is unreasonable. Get something out there and iterate on it.
I prefer not to use my phone and tablet for stuff like this. It forces me to pay attention to it more than I wold like because I am carrying the device. I force myself to take breaks from work by not having work stuff on my phone. If one of my co-workers really wants me, they have my phone number.
This seems remarkably similar to the Jupyter (IPython) notebook format [0]. The only big difference I can see is the separate metadata file, which I'm not so sure is a plus (since it adds the complexity of needing each notebook to be a folder).
It's a tricky situation. I'm not sure which is best. The advantage of using a directory for your format is that it's easy to use preexisting tools on the contents of a note.
You can examine and modify the .tiff file using normal command line tools. This is nice!
Whether this adds to the complication of the project depends on your perspective. From the user's perspective this is simpler, they can now use normal tools to work on resources without having to manually extract and then reinsert the resource.
But from an overall perspective (which is probably more important), I think you're right that this is more complicated. Directories are higher level than JSON files -- we don't always have tools that can work with them. A JSON file has a both a single Unicode and byte representation, not so for directories. Losing this to make things easier on the user is no small deal.
Perhaps the right answer _is_ to put the whole note in a single JSON file. From there it can be transformed into directory with FUSE for modification by standard tools (or for export purposes if the user wants to move away from our note type). I'm still not sure about this though.
Right, but Jupyter lets you evaluate the code, which is much cooler than just editing it. On the other hand, Quive may have better search functionality.
> Leaving version control up to the user isn't the worst, but it does mean that it won't be straightforward to put an "undo" in the GUI (if the GUI already has undo somehow I'd like to hear how they do it).
The GUI does have an Undo, and it works exactly as you expect: it reverts changes made in the GUI app. If you have a note open and you make an external change, the app will at some point notice the change and ask you if you want to reload; if you say yes, it reloads from disk and throws away the undo history. I was able to get it to reload content without realizing it changed (by editing the note, then closing it in Quiver before it detected the change and reopening) and this didn't throw away the undo history, which seems like just a fairly simple bug.
Or to put it more generally, Undo works in Quiver pretty much the same way you'd expect it to work in any editor that can reload files that change on disk; the undo history simply doesn't concern itself with undoing changes made outside of the app, and in most cases reloading the file from disk throws away undo history.
Oh, that makes sense! So it's exactly like Vim (with noswapfile turned on) or any other program that tracks history at the application-level, but doesn't write it to the directory you're working in.
Sublime seems to work very well in the case you describe: The changes coming in from a reload are simply put into the undo history just like any other change. No need to throw anything away.
This weekend I kept thinking about wanting to make a trello like board for personal knowledge or idea tracking but keep it git version controlled, your comment reminds me that maybe others are in the same track.
Here's Quiver's: https://github.com/HappenApps/Quiver/wiki/Quiver-Data-Format
It's . . . really good. Like, _really_ good.
I particularly like that they keep the metadata and the content of the note separate. This is the same thing Camlistore does, and it's nice for version control because making changes to the metadata (adding new tags or whatever) doesn't show up as a content change.
Speaking of version control, Quiver's thoughts on this are interesting:
"Since Quiver stores all the data in plain JSON files, it’s easy to put the whole library (or a specific notebook) under version control. This is another way to collaborate with your team."
Leaving version control up to the user isn't the worst, but it does mean that it won't be straightforward to put an "undo" in the GUI (if the GUI already has undo somehow I'd like to hear how they do it).
I'm also not sure whether it would be better to version the whole notebook or individual qvnotes. I have more thoughts on this (starting from a slightly different angle of how it relates to wikis) here: http://housejeffries.com/page/4.
EDIT: Something just occurred to me. If HappenApps wanted to make a machine readable schema for qvnotebook and qvnote they could use JSON Schema for the JSON part. What would they use for the directory part? Is there such a thing as a schema for directories? (e.g. this directory must contain a `content.json` file, a `meta.json` file, etc.)