Some days I just don't like Endnote any more. In the past I have used a combination of Endnote and Papers2. A few years ago I wrote a review of Endnote X4 for Mac and I thought that I would go back and take a look at what I thought about that review and the new version of Endnote 8.
Keep in mind that I have over 8,500 references in my Endnote file. My biggest complaints are:
It is slow.
There still is no keyboard short cut for importing a reference.
The "detect duplicates" script does not allow one to exit successfully prior to completing all the items in your detected duplicate list. (Which for some might be very long, and cause the script to crash!)
There is no mechanism in the collections area to browse by Journal or Book series.
When looking at a reference, there is no clear way to determine if it is in one of several collections (including in the check for duplicate script).
There does not seem to be an export style for exporting to bibJSON. (I might be creating one soon).
No auto suggest for missing citation metadata.
for me, Endnote, when importing citations which contain a relative link to a PDF on my machine, does not actually import the PDF to an endnote managed folder. I want all my PDFs in one place. And if they are not in the Endnote managed folder I want a visual indication that they are outside the Endnote data folder.
These are my observations as I try and work with Endnote (and have over the last few months). For me, Papers2 (I haven't bought Papers3) nailed the interaction around PDF management and citation management, from a User Experience perspective. Papers2 just didn't have the custom Fields necessary for me.
In this post I take a look at some of the software needs of a language documentation team. One of my ongoing concerns of linguistic software development teams (like SIL International's Palaso or LSDev, or MPI's archive software group, or a host of other niche software products adapted from main stream open-source projects) is the approach they take in communicating how to use the various elements of their software together to create useful workflows for linguists participating in field research on minority languages. Many of these software development teams do not take the approach that potential software users coming to their website want to be oriented to how these software solutions work together to solve specific problems in the language documentation problem space. Now, it is true that every language documentation program is different and will have different goals and outputs, but many of these goals are the same across projects. New users to software want to know top level organizational assumptions made by software developers. That is, they want to evaluate how software will work in a given scenario (problem space) and to understand and make informed decisions based on the eco-system that the software will lead them into. This is not too unlike users asking which is better Android or iPhone, and then deciding what works not just with a given device but where they will buy their music, their digital books, and how they will get those digital assets to a new device, when the phone they are about to buy no-longer serves them. These digital consequences are not in the mind of every consumer... but they are nonetheless real consequences. Continue reading →
I often see good (maybe not sexy), software, like iBable designed on the Mac for scientific purposes. I often wonder, “Why hasn’t anyone done something for or with linguistics?” linguistics is a big field. Don’t get me wrong. It is also a field with few standardizations for data interoperability, and even fewer standards for data description and markup. Just seeing something like iBable is inspiring to want to learn Ruby and do something for linguistic data.