I'd put in a very strong vote against pure rich text editing support (in the sense of purely presentational formatting), and strongly support instead some sort of simple wiki-like semantic markup.
I think the ideal would be to do what the major blog programs/CMSs today do, which is to allow the option of working in either rich text or markup. That way if I want to cut-and-paste from a wysiwyg editor, the formatting is not lost.
I would also like to see rich text (at least italics) on book/article titles. I have a lot of titles with foreign terms that are italicized. I'm thinking of at least trying to hack the import/export filters I commonly use so they'll convert italics to and from underscores. I'm not much of a hacker though.
Another vote for wiki-like semantic markup! (along with a vote for either some kind of two-tab wysiwyg/markup interface for getting it in.) I couldn't bear to keep my notes in a purely presentational system. I want to know that if I ever need to leave zotero, or export my notes to some other format to make use of them in some way, I'm not stuck with presentation-only markup. I need to be able to make use of the structure of my notes whatever system I use. It's why I stopped using MS OneNote, despite the fact that it has many great features and I own a licence. Developers can say, "Let's just make our software so go there will never be a reason to leave it." But that's not good enough. Platforms change, people move on, funding dwindles, markets change and more. Give me a system that I can feel good about investing in: one that I can get out of if I need it.
On formatting: I have put an embarrassing amount of thought into what kind of formatting I need for academic and personal notes, and come to the conclusion that a standard wiki-set is about perfect for me. It has structure (heading levels), looks (emphasis/italics, verbatim, etc.), paragraph formatting (block quotes, including quotes with manual linebreaks for poetry), lists (numbered, un-numbered, nested), and linking (intra-note, local files, and web links). If the implementation has unicode support, (as zotero already does) I have nearly everything I need.
What I would add: (1) right-to-left support for embedding Hebrew in notes. Probably not in wildly high demand, and perhaps difficult to implement. I can live without it.
(2) it'd be very nice if you could manage an easy way to enter outlines (and to deal with the requirements of nesting various levels of numbered lists. Some people find it a very useful way to think. Doing it well within notes would be a big plus.
I wish you (developers) well at implementing this. A design which enables you to really like and use the notes you take (if it were possible within your time and budget constraints) could help zotero take over the market of the note-takers (Evernote, OneNote, personal wikis, etc), and certainly take over from the non-functional note holding capabilities of Endnote-and-friends.
Wiki languagess do support everything that scot asks for, including nested lists.
The one thing they don't typically support is citations for quotes and such. I talked about this with the author of PyTextile, and he suggested an easy enough solution: something like ``my excerpt''@doe99#page=11. So you append the "doe..." bit to the end of a quote.
The challenge with this is really the interface (because a lot of users don't want to be bothered), and the best place to look is at CMS systems that allow you use either WYSIWYG or straight markup.
Would love to seee support for straight markup first of course (it's easy) :-)
While we're on the topic of markup/rich text and notes, I think it would be nice if the notes had some of Tomboy's features, including internal/external links, incremental search on a page internally (with the same incremental search bar used in searching web pages in Firefox). One nice thing about Tomboy is that if you write a plain-text link or the name of another note, it automatically acts as a link. It also has things like "What links here" and "Export to HTML." For me, more fine-grained linking and searching are among the most important features of a good note-taking system.
Ability to add bold, underlining, italics is badly needed. If I type in a quote, where the original has formatting, I need to use text to indicate where the formatting should go. This is time-consuming and can lead to errors.
raf: small caps? Are you serious? That's advanced typography. For what real purpose?
The more complex a note-taking system is, the more it treads into the realm of a word-processor, and the less effective it is at its task.
I dunno: I suppose a CSS class-based system would still allow funky stuff like small caps (CSS does allow for small caps), but keep the focus on a nice, simple, clean and semantic interface.
Yes, please let's keep whatever formatting there is going to be available absolutely as simple as possible. And have it emphasize structure over visual style. Headings, lists, emphasis, quotes and links are all needed.
Also, I don't know if anyone's requested maths notation support. That's a whole new can of worms, but lots of scientists would need something in that direction for Zotero's notes to be useful. Perhaps outsourcing via LaTeX integration for specified regions of text?
Well, I was sort of serious: in the sources I read small caps are not only used for Roman Numerals in dates etc., but also place names are often printed in small capitals.
This is, of course, not an essential feature: at the moment I just use normal capitals, which is fine as well. But given the fact that I like to represent the extracts as accurate as possible, I thought I could mention it.
I do agree that everything should be kept as simple as possible and I would very much like to see the possibility for headings, lists, quotes, etc. in the not too distant future -- Zotero is the only thing I use at the moment.
But I also have to have admit that my knowledge of these things is limited, and I am curious to learn why a note-take system looses its effectiveness the more it treads in the realm of word-processor.
Well, I was sort of serious: in the sources I read small caps are not only used for Roman Numerals in dates etc., but also place names are often printed in small capitals.
So what in fact is essential is the fact that they dates or place names. That they are rendered in small caps is secondary, in the same way that the particular font family used in the text is secondary (well, tertiary!).
This is, of course, not an essential feature: at the moment I just use normal capitals, which is fine as well. But given the fact that I like to represent the extracts as accurate as possible, I thought I could mention it.
This issue keeps coming up: representing extracts accurately. I certainly understand the importance of this in fields where quoting of extracts is common (mine included). But perhaps we ought to be careful to identify the goals here; it might allow for better solutions.
As CB mentions, math people care about math representation. They couldn't care less about extracts (they never quote). Things could get really ugly if the Zotero guys aren't careful to precisely define the scope, goals and requirements of note enhancements.
... I am curious to learn why a note-take system looses its effectiveness the more it treads in the realm of word-processor.
Every single new feature means more UI complexity. And in particular when you design a system that is focused on how things looks (old-style word-processors), rather than what they mean (using concept-based styles, contemporary web design, etc.), it gets in the way of what I take to be the focus on note-taking systems: to take notes; e.g. jot down ideas, rather free form, without too much concern for how things look.
Might it be possible to agree on a very minimal set of what is needed in notes, and have the zotero guys endorse a temporary standard for marking these up? Then, when some kind of richer note feature is available, any notes using this markup could be automatically converted to the new format.
The trouble for me at the moment is that whilst we're waiting, an awful lot of unstructured notes are being taken.
I know that there are big differences between people on GUI vs markup and semantics vs visual layout issues, but I would think we could probably agree on some very basic things that we want notes to contain (as a ferinstance: headings/sections, emphasis, lists, some kind of link or citation). At least being able to get some of that stuff in there would make me feel better about the future usefulness of what I'm typing into my Zotero db.
I'd suggest choosing a markup with decent visual legibility, more like reStructured text or Markdown than Textile, for example.
I don't think you can really go wrong with Markdown: it's simple, clear, and widely supported. Textile is similar in scope.
RT is more complex, and not as widely supported (though really well supported in Python of course).
I think it would be useful to document somewhere (the wiki?) examples of how you might incorporate this in note-taking. There are some potentially innovate possibilities.
Markdown seems as good as any to me, though I haven't thought very deeply about the differences.
I'd be happy with any, but what I would really like to see is the endorsement, in the hope that zotero would automatically convert notes using this markup once a richer notes environment was available. Second-best would be enough of an endorsement or consensus to make it likely that a kind 3rd party would develop a tool to convert notes once the new facility is available. Either way, I mean just an agreement; something that needs no extra development now, but promises that markup used now won't become redundant.
Just headings, lists, emph and blockquotes would do. But I'd like also to have the ability to co-opt eg. Markdown's links to be able to point to other items within zotero (by analogy with the 'related' tab). I imagine though that's tricky, as there's no way that I know, that's transparent to the user, of finding a zotero item ID.
@CB: I like the idea very much. Your list is a good start: headings, lists, emphasis and blockquotes. The ability to "reference" a database item (either a top-level bibliographic item, or another note, wiki-style) would be a boon. External links URLS should be easy enough to implement.
I understand that Zotero was originally created for use in the humanities, but I think it would be great if it would work for scientists like myself. For it to be at all useful, we would need access to at least italics, and several other character sets (like Greek characters, super and subscripts). Not just in the notes, but in all fields. The other issue is that by importing through BibTex, all that formatting that is already in my EndNote file gets lost during import.
Zotero is damn handy, and I would be willing to add all of this formatting by hand to my library, but it currently isn't available. It sounds like this sort of stuff is in the works, and I am all for it! Keep up the good work.
Zotero supports greek letters and numeric super/sub- script in all fields, as they are UTF-8 characters.
Are the formatted fields actually in the BibTeX file? Endnote used to not be able to do that & I thought that even now, TeXers were encouraged to export to their (app-specific & ugly) XML format & to convert that in a third party program.
Zotero can import many non-latin characters from TeX-encoded bibtex files.
Italics aren't yet supported. You'd have to manually mark up an exported BibTeX file or would have to edit references in OO.o Writer or MS Word. You can use a lightweight markup language so that it will be easier to find what text needs to be changed until official support is implemented+released.
First, thanks for the excellent product. Coming at this from the physical sciences side, it seems to be almost complete. There is one thing that is puzzling me though, and searching for the key terms (bibtex export greek) yields only two threads - this being one of them.
noksagt, you said Greek letters are supported, to which I agree(meaning they show up in all fields, etc.) However, BibTeX export support seems to be lacking. An example can be found here:
http://www.iop.org/EJ/abstract/0038-5670/10/4/R04
First, it didn't import 100% correctly (epsilon is displayed as the LaTeX string $\epsilon$ in the title field). But let's ignore that, since the title needs some cleaning up anyway (removing the all-caps).
If I replace $\epsilon$ with the UTF-8 character, say, from charmap in Windows... (and μ, just to be certain it's properly encoded), the title field in Zotero looks great: "The electrodynamics of substances with simultaneously negative values of ε and μ"
But upon export to BibTeX:
title = {The electrodynamics of substances with simultaneously negative values of ? and ?},
So, is this a bug, a new feature request, or is there a trick for including Greek characters in Zotero that I haven't figured out yet? Thanks in advance to any responses, and apologies in advance if this has been covered somewhere else and I missed it.
dietlein: This isn't really related to this thread, but an updated version of the BibTeX translator is now available. The "$\epsilon$" is from the site itself—look at the page title. Post on the other thread or start a new one with additional questions.
I have to ask again a question concerning a feature that is really important for me:
is the support for italics in the titles going to be implemented sooner or later?
This is vitally important for me. As a biologist, almost 50% of the papers I deal with have some italics in their title (scientific name of species).
Since my library is pretty large, and I work both with a standard office suite and LaTeX, thinking of manually editing the reference list in the former and the bibtex-exported file EVERY time is out of question.
I think this issue prevents most biologists from adopting it - not a big deal for windows users, but a HUGE deal for linux users, since there is no valid alternative to this excellent software on this OS. In a research group with mixed OS, this might really be the definitive solution.
Keep up the good work!
PS. A minor idea: is there a chance to "lock" the fields of a reference, or a whole reference? I find it easy to change a field by mistake...
Upgrade Storage
I would also like to see rich text (at least italics) on book/article titles. I have a lot of titles with foreign terms that are italicized. I'm thinking of at least trying to hack the import/export filters I commonly use so they'll convert italics to and from underscores. I'm not much of a hacker though.
On formatting: I have put an embarrassing amount of thought into what kind of formatting I need for academic and personal notes, and come to the conclusion that a standard wiki-set is about perfect for me. It has structure (heading levels), looks (emphasis/italics, verbatim, etc.), paragraph formatting (block quotes, including quotes with manual linebreaks for poetry), lists (numbered, un-numbered, nested), and linking (intra-note, local files, and web links). If the implementation has unicode support, (as zotero already does) I have nearly everything I need.
What I would add: (1) right-to-left support for embedding Hebrew in notes. Probably not in wildly high demand, and perhaps difficult to implement. I can live without it.
(2) it'd be very nice if you could manage an easy way to enter outlines (and to deal with the requirements of nesting various levels of numbered lists. Some people find it a very useful way to think. Doing it well within notes would be a big plus.
I wish you (developers) well at implementing this. A design which enables you to really like and use the notes you take (if it were possible within your time and budget constraints) could help zotero take over the market of the note-takers (Evernote, OneNote, personal wikis, etc), and certainly take over from the non-functional note holding capabilities of Endnote-and-friends.
The one thing they don't typically support is citations for quotes and such. I talked about this with the author of PyTextile, and he suggested an easy enough solution: something like ``my excerpt''@doe99#page=11. So you append the "doe..." bit to the end of a quote.
The challenge with this is really the interface (because a lot of users don't want to be bothered), and the best place to look is at CMS systems that allow you use either WYSIWYG or straight markup.
Would love to seee support for straight markup first of course (it's easy) :-)
Works for me, but obviously, more than that would be great.
The more complex a note-taking system is, the more it treads into the realm of a word-processor, and the less effective it is at its task.
I dunno: I suppose a CSS class-based system would still allow funky stuff like small caps (CSS does allow for small caps), but keep the focus on a nice, simple, clean and semantic interface.
Also, I don't know if anyone's requested maths notation support. That's a whole new can of worms, but lots of scientists would need something in that direction for Zotero's notes to be useful. Perhaps outsourcing via LaTeX integration for specified regions of text?
This is, of course, not an essential feature: at the moment I just use normal capitals, which is fine as well. But given the fact that I like to represent the extracts as accurate as possible, I thought I could mention it.
I do agree that everything should be kept as simple as possible and I would very much like to see the possibility for headings, lists, quotes, etc. in the not too distant future -- Zotero is the only thing I use at the moment.
But I also have to have admit that my knowledge of these things is limited, and I am curious to learn why a note-take system looses its effectiveness the more it treads in the realm of word-processor.
As CB mentions, math people care about math representation. They couldn't care less about extracts (they never quote). Things could get really ugly if the Zotero guys aren't careful to precisely define the scope, goals and requirements of note enhancements. Every single new feature means more UI complexity. And in particular when you design a system that is focused on how things looks (old-style word-processors), rather than what they mean (using concept-based styles, contemporary web design, etc.), it gets in the way of what I take to be the focus on note-taking systems: to take notes; e.g. jot down ideas, rather free form, without too much concern for how things look.
The trouble for me at the moment is that whilst we're waiting, an awful lot of unstructured notes are being taken.
I know that there are big differences between people on GUI vs markup and semantics vs visual layout issues, but I would think we could probably agree on some very basic things that we want notes to contain (as a ferinstance: headings/sections, emphasis, lists, some kind of link or citation). At least being able to get some of that stuff in there would make me feel better about the future usefulness of what I'm typing into my Zotero db.
I'd suggest choosing a markup with decent visual legibility, more like reStructured text or Markdown than Textile, for example.
RT is more complex, and not as widely supported (though really well supported in Python of course).
I think it would be useful to document somewhere (the wiki?) examples of how you might incorporate this in note-taking. There are some potentially innovate possibilities.
I'd be happy with any, but what I would really like to see is the endorsement, in the hope that zotero would automatically convert notes using this markup once a richer notes environment was available. Second-best would be enough of an endorsement or consensus to make it likely that a kind 3rd party would develop a tool to convert notes once the new facility is available. Either way, I mean just an agreement; something that needs no extra development now, but promises that markup used now won't become redundant.
Just headings, lists, emph and blockquotes would do. But I'd like also to have the ability to co-opt eg. Markdown's links to be able to point to other items within zotero (by analogy with the 'related' tab). I imagine though that's tricky, as there's no way that I know, that's transparent to the user, of finding a zotero item ID.
Zotero is damn handy, and I would be willing to add all of this formatting by hand to my library, but it currently isn't available. It sounds like this sort of stuff is in the works, and I am all for it! Keep up the good work.
Are the formatted fields actually in the BibTeX file? Endnote used to not be able to do that & I thought that even now, TeXers were encouraged to export to their (app-specific & ugly) XML format & to convert that in a third party program.
Zotero can import many non-latin characters from TeX-encoded bibtex files.
noksagt, you said Greek letters are supported, to which I agree(meaning they show up in all fields, etc.) However, BibTeX export support seems to be lacking. An example can be found here:
http://www.iop.org/EJ/abstract/0038-5670/10/4/R04
First, it didn't import 100% correctly (epsilon is displayed as the LaTeX string $\epsilon$ in the title field). But let's ignore that, since the title needs some cleaning up anyway (removing the all-caps).
If I replace $\epsilon$ with the UTF-8 character, say, from charmap in Windows... (and μ, just to be certain it's properly encoded), the title field in Zotero looks great: "The electrodynamics of substances with simultaneously negative values of ε and μ"
But upon export to BibTeX:
title = {The electrodynamics of substances with simultaneously negative values of ? and ?},
So, is this a bug, a new feature request, or is there a trick for including Greek characters in Zotero that I haven't figured out yet? Thanks in advance to any responses, and apologies in advance if this has been covered somewhere else and I missed it.
is the support for italics in the titles going to be implemented sooner or later?
This is vitally important for me. As a biologist, almost 50% of the papers I deal with have some italics in their title (scientific name of species).
Since my library is pretty large, and I work both with a standard office suite and LaTeX, thinking of manually editing the reference list in the former and the bibtex-exported file EVERY time is out of question.
I think this issue prevents most biologists from adopting it - not a big deal for windows users, but a HUGE deal for linux users, since there is no valid alternative to this excellent software on this OS. In a research group with mixed OS, this might really be the definitive solution.
Keep up the good work!
PS. A minor idea: is there a chance to "lock" the fields of a reference, or a whole reference? I find it easy to change a field by mistake...
http://bitbucket.org/fbennett/citeproc-js/src/tip/tests/std/humans/flipflop_ItalicsSimple.txt
Inclusion of this facility is planned for Zotero version 2.1, which should start appearing early next year.