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."
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.
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.
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.
This looks a lot like the Jupyter/IPython Notebook, which is a free and open source "scientist's notebook". If you're interested in mixing LaTeX, Markdown, and code from almost any language (Python, R, and Julia are very well-supported but there's an open kernel spec), then this might be a more appropriate tool for you to use.
The Jupyter/IPython notebook default storage format is JSON, which makes it a little more friendly for text-based version control, and also enables a static HTML view of notebooks (http://nbviewer.jupyter.org/github/ketch/teaching-numerics-w...) on GitHub.
Helen Shen wrote up a great article for Nature (http://www.nature.com/news/interactive-notebooks-sharing-the...) on how scientists are using the notebook, but it also provides a good overview of how you might use it, as well as a free interactive demo.
The originator of the notebook UI is Mathematica if I recall correctly. You can try the web version at [1] - it doesn't quite have the elegance of the desktop one, but is a much better notebook than Jupyter in my experience.
Totally agree. Jupyter/IPython is an impressive tool.
I started to play with it recently and I am very happy with what it can do.
It's, also, very easy to install in a docker container: https://github.com/jupyter/docker-stacks
(I haven't managed to make work the persistence part when stopping the container yet, but this is due to my inexperience with docker).
That looks very good, I just wish I could buy it outside of the mac app store. I really dislike buying for the app store and much prefer buying directly from the company...
For me: If I have a copy of the software I have it forever. With the app store I only have it as long as Apple permits. Using an older version of OS X can create issues as well, if the developer decides not to support it. If for some reason they remove it from the store I have to hope the developers make it available outside that channel. It's certainly happened with iOS apps. I'm open to being proven wrong though.
Sorry hadn't seen your message earlier. Everyone pretty much covered it but basically I have multiple reasons why:
- an app on the app store can be pulled out at any moment.
- I can't backup a specific version of the software that I like (I've seen before software become overly bloated in future versions forcing me to keep using an older version)
- I do not want to support Apple's policies on the app store and do not want to ever end up having a system that's as restricted as IOS (although if that happens I'd jump ship back to Linux so I guess my non app store purchases would become useless anyway)
- my experience with ios app store reviews told me that Apple rules are idiotic, the review experience is poorly managed and they don't give a fuck about keeping developers happy now that iphones are massively successful (very different than when they were trying to court developers back in 2005ish...). I don't want my money to help finance this with the 30% cut that Apple takes.
It all really boils to control, being able to keep backup of the software I use, having access to that software even if the developer stops selling it for whatever reason. I dislike the fact that end users have less and less control over the platform they buy and I do not want to be part of that.
I'm a tad hypocritical since I use a mac and I have an iphone lying around to test and software dev on but buying on the app store is where I draw the line.
I agree. I've downloaded the trial, and if I like what I see (and, of course, the price is right) I'll buy a copy, but only if I can buy one directly from you, not via the App store. The App store has many technical limitations, and it also means the consumer is effectively just licensing software from Apple rather than owning it outright.
I like the ability to install apps from the Homebrew Cask Tap [1] to automate my laptop setup where possible. Apps that are only available in the App Store aren't usually installable this way.
The tutorial notebook is full of individual notes with multiple 'cells'. When creating my own note, it's not immediately obvious how I achieve this. Hitting ENTER just creates a new paragraph/line within the same cell. I've discovered, through trial and error, that hitting SHIFT+ENTER creates a new cell, but this should maybe be more easily discoverable.
Some of the UI elements are a bit out-of-place. I'm not sure if it's just because they're not native controls; I'm still running on Mavericks and it's quite possible these are El Capitan-style controls. Still, it's a tiny bit disconcerting.
On a more positive note, I think this is a wonderful concept which can potentially inform future tools for 'code management' (for want of a better term). I think there are plenty of ways in which the integration of code and other content can improve our discipline, so any work in this area is very interesting.
Actually, it says so right in the 1st note "Getting started":
"Click inside a new note and start typing. Press “shift+return” (⇧⏎) to create a new cell and use “backspace” to merge cells. That’s all you need to know to start using Quiver."
>When creating my own note, it's not immediately obvious how I achieve this. Hitting ENTER just creates a new paragraph/line within the same cell. I've discovered, through trial and error, that hitting SHIFT+ENTER creates a new cell, but this should maybe be more easily discoverable.
Well, from the menubar: Cell -> New Cell. Which also shows the shortcut next to the menu option.
That's great, the tutorial notebook is a nice addition. To its credit, the app is usable without wading through a manual first, as all software should be. I still feel a toolbar icon or a more obvious way to create a new cell would be beneficial.
I happily use a github repo for taking my 'programmer notes'. Advantages:
1. Goes well with my programming workflow: Change/Commit/Push
2. Allows me to use my preferred editor
3. No need to worry about backups: Git push and you're done
4. Accessible from anywhere, even if you don't have your computer
Is there anything that Quiver would offer that I wouldnt already have with a github repo?
I do the same, bitbucket allows you to group repo's by project or team (or both) so I always create a default docs repo.
For actual notes I just use org-mode since it can be read easily in nearly anything, supports all the bits I want and has nice html/pdf export if I need to send a todo/completed list out to anyone.
What's nice is I can keep my own meta-docs project which just links to each repo for each set of projects so I can jump around different projects transparently as well.
Feature-wise, it looks a lot like org-mode - hierarchical rich text notebooks with support for Markdown, LaTeX, and code samples. Advantage: pretty OS X application. Disadvantages: OS X only, not integrated with the full power of Emacs.
I still use vimwiki. It has a few warts, but since I'm comfortable with it (as in when you learn some of the leader commands, it becomes more powerful) and files are saved to Dropbox, it makes work and home note taking convenient.
It's particularly nice in that if you are already in vim; <leader>ww will open the wiki index.
I have been unable to find an advantage that vimwiki or vim outliner have over just using vim with markdown in a Dropbox directory. Folding, numbering, etc work really well for me for that. What do you like about it in particular over what I could do with markdown?
There are definite advantages to just doing what you do. I like classic markdown syntax more. Things like #foo instead of = foo =.
But I particularly like some of the ways vimwiki functions.
I like that I can type project_notes and hit <return> and it opens up a new project_notes.wiki, and then I can hit <backspace> to go back to the previous wiki.
There are more normal mode keybindings that you might find yourself using. Sometimes I remove unwanted wikis by <leader>wd, which will delete the wiki you are currently viewing (it's nice in that you can see the content then quickly delete). Renaming, too.
Maybe I can sum it up to just say I prefer the navigation and handling of new/unwanted files with vimwiki?
- Create notes as files named like tweets `my note #javascript #yolo.txt`.
- Write markdown in plain text files.
- Open the folder from your choice of editor.
- Distribute your notes folder using Git, Dropbox, Drive, etc.
- Enjoy your notes FOREVER.
Atom works great when you need your notes in a Desktop environment. The command line is wonderful when you are on a server. Byword is amazing on iPhone. Nothing great I've found for Android yet.
Readit News
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.)
"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."
— Fred Brooks, The Mythical Man-Month
I might give it a shot if they decide to support linux.
Note: I was being sarcastic when I said small.
I like the concept, but it's a non-starter while it's not available on... I don't know... the largest platform.
[0] https://ipython.org/ipython-doc/3/notebook/nbformat.html
Say your note looks like the Quiver example:
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.
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.
https://github.com/WardCunningham/Smallest-Federated-Wiki/bl...
This looks a lot like the Jupyter/IPython Notebook, which is a free and open source "scientist's notebook". If you're interested in mixing LaTeX, Markdown, and code from almost any language (Python, R, and Julia are very well-supported but there's an open kernel spec), then this might be a more appropriate tool for you to use.
The Jupyter/IPython notebook default storage format is JSON, which makes it a little more friendly for text-based version control, and also enables a static HTML view of notebooks (http://nbviewer.jupyter.org/github/ketch/teaching-numerics-w...) on GitHub.
Helen Shen wrote up a great article for Nature (http://www.nature.com/news/interactive-notebooks-sharing-the...) on how scientists are using the notebook, but it also provides a good overview of how you might use it, as well as a free interactive demo.
[1]: https://lab.open.wolframcloud.com/app/view/newNotebook?ext=n...
I started to play with it recently and I am very happy with what it can do.
It's, also, very easy to install in a docker container: https://github.com/jupyter/docker-stacks (I haven't managed to make work the persistence part when stopping the container yet, but this is due to my inexperience with docker).
For me that was allways the killer feature of Jupyter :-)
- an app on the app store can be pulled out at any moment.
- I can't backup a specific version of the software that I like (I've seen before software become overly bloated in future versions forcing me to keep using an older version)
- I do not want to support Apple's policies on the app store and do not want to ever end up having a system that's as restricted as IOS (although if that happens I'd jump ship back to Linux so I guess my non app store purchases would become useless anyway)
- my experience with ios app store reviews told me that Apple rules are idiotic, the review experience is poorly managed and they don't give a fuck about keeping developers happy now that iphones are massively successful (very different than when they were trying to court developers back in 2005ish...). I don't want my money to help finance this with the 30% cut that Apple takes.
It all really boils to control, being able to keep backup of the software I use, having access to that software even if the developer stops selling it for whatever reason. I dislike the fact that end users have less and less control over the platform they buy and I do not want to be part of that.
I'm a tad hypocritical since I use a mac and I have an iphone lying around to test and software dev on but buying on the app store is where I draw the line.
[1] https://github.com/caskroom/homebrew-cask
Some of the UI elements are a bit out-of-place. I'm not sure if it's just because they're not native controls; I'm still running on Mavericks and it's quite possible these are El Capitan-style controls. Still, it's a tiny bit disconcerting.
On a more positive note, I think this is a wonderful concept which can potentially inform future tools for 'code management' (for want of a better term). I think there are plenty of ways in which the integration of code and other content can improve our discipline, so any work in this area is very interesting.
Well, from the menubar: Cell -> New Cell. Which also shows the shortcut next to the menu option.
This is in the tutorial, Section 3 - Cell Operations.
Is there anything that Quiver would offer that I wouldnt already have with a github repo?
For actual notes I just use org-mode since it can be read easily in nearly anything, supports all the bits I want and has nice html/pdf export if I need to send a todo/completed list out to anyone.
What's nice is I can keep my own meta-docs project which just links to each repo for each set of projects so I can jump around different projects transparently as well.
It's particularly nice in that if you are already in vim; <leader>ww will open the wiki index.
https://github.com/vimwiki/vimwiki
I've also been doing some note taking with :set filetype=journal in use with junegunn's nice syntax.
https://github.com/junegunn/vim-journal
But I particularly like some of the ways vimwiki functions.
I like that I can type project_notes and hit <return> and it opens up a new project_notes.wiki, and then I can hit <backspace> to go back to the previous wiki.
There are more normal mode keybindings that you might find yourself using. Sometimes I remove unwanted wikis by <leader>wd, which will delete the wiki you are currently viewing (it's nice in that you can see the content then quickly delete). Renaming, too.
Maybe I can sum it up to just say I prefer the navigation and handling of new/unwanted files with vimwiki?
- Create a folder.
- Create notes as files named like tweets `my note #javascript #yolo.txt`.
- Write markdown in plain text files.
- Open the folder from your choice of editor.
- Distribute your notes folder using Git, Dropbox, Drive, etc.
- Enjoy your notes FOREVER.
Atom works great when you need your notes in a Desktop environment. The command line is wonderful when you are on a server. Byword is amazing on iPhone. Nothing great I've found for Android yet.