A large chunk of ORCID actually is open source: https://github.com/ORCID/ORCID-Source (though I don't necessarily agree that it should be, since ORCID is not a library or tool, but rather a service that only has real value if there's a single instance in existence).
I think there's a misunderstanding here on what ORCID is exactly. The name is an acronym for "Open Researcher and Contributor ID." It has nothing to do with publishing, but rather is being built as a central arbiter of academic identity.
Academics love to measure their importance by the papers they've authored or co-authored. Most databases currently track the names of authors associated with each published paper. But names are frustratingly ambiguous or degenerate, which makes it difficult to do things like create an auto-updated list of all the papers you've published.
ORCID is a publisher-funded non profit designed to reduce ambiguity in author identification, by simply assigning a UUID to every researcher. This is a case of publishers agreeing that collaboratively funding a single, centralized technical solution will benefit everyone much more than having a bunch of competing, siloed systems.
Have you tried actually logging in? This is not quite arxiv.org — I'd estimate that 90% of the engineering going into academia.edu has gone towards features on par with LinkedIn for their spamminess. I signed up, and was asked about 10 times to connect to Facebook, Gmail, invite my friends, etc.
They have some interesting features (such as feeds of recent articles organized by journal you can sign up for), but by far the most important feature of academia.edu is growing academia.edu.
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.
A great example of a web-friendly, interactive view of a scientific paper is the eLife Lens, example here: http://lens.elifesciences.org/#00380 . They announced the open source project back in June (blog post http://www.elifesciences.org/lens/). This is the direction that web-based paper views are moving toward, and some publishers (notably PLOS) already have quite nice interactive components.
PubMed, the government-run biomedical abstract database, also recently introduced its PubReader app for reading biomedical papers (http://www.ncbi.nlm.nih.gov/pmc/about/pubreader/). But my money's on eLife here — NCBI is better known for its databases than its user interface design (to say the least).
It would be great to see some innovation here (some publishers have absolutely awful web-based journal article views). But as the main format for paper publishing and dissemination, I think the PDF won't be going away anytime soon.
I really like plos, but one criticism I have of their interface is that the figure takes up the entire page, which destroys my easy reference to the rest of the content. e.g. at http://www.ploscompbiol.org/article/info%3Adoi%2F10.1371%2Fj... Figure 1 takes up the entire height of my screen on my laptop and then I have to scroll back to where it is in the text.
Lens reads JSON, and we convert from XML to JSON using this component: https://github.com/elifesciences/refract. We are working on updated documentation, and a getting started guide, our hope is to make the base system flexible enough to display any "component".
Using straight console.log statements seems to be non-negotiable for effective debugging, at least until a good workaround for the above is found.
For using Chrome's logging styles, we define a few short helper functions — l1(), l2(), l3(), etc. — that return predefined CSS strings, then doing our logging like
console.log("%cThis is a heading", l1())
console.log("%cLess important stuff", l2())
This means you're only adding 6 or so characters to get nice styled console messages that also maintain the nice line numbers and links to the source. Plus, it's similar enough to h1, h2, etc. that it's easy to remember.
We found that varying the font color (black vs. gray) and margin-left (2em, 4em) were most helpful in differentiating more and less important log messages.
They don't seem to be providing the actual phylogenetic tree data (there's a cryptic note "More information will be made available here with the print publication of the study"), but there is a link to a higher-resolution PDF: http://litoria.eeb.yale.edu/bird-tree/images/BirdTreeHighRes...
I think the logo clicking decision isn't crazy. My interpretation is that Google is "un-training" users from using this valuable piece of screen real estate for a useless no-op function, in anticipation of putting a more useful function in its place.
Does anyone remember a few weeks back, when Google tested a "new way to browse Google's services"? They turned the logo into a button, producing a drop-down menu of services to navigate to.
My guess is that they found the new logo-button didn't work well, mainly because so many users saw the logo as a big button which refreshed the page or went to the inbox.
At the risk of making predictions, I'd guess this recent change is a grace period, designed to get us all used to using other buttons for reaching the inbox. And once people no longer instinctively click the logo-button, they'll introduce the new navigation which makes better use of that valuable screen space.
I could very well be way off the mark here... but it seems pretty clever to me, TBH.
> My interpretation is that Google is "un-training" users from using this valuable piece of screen real estate for a useless no-op function, (...)
It's not an useless no-op function. By going to default/main page of the service it reverts you to a known state, simplifying navigation and enhancing user confidence. I personally rely on this behaviour of main logos and get terribly annoyed if someone breaks my expectation (which, rarely, happens).
One of my greatest regrets from undergrad days was having graduated a year too early to enroll in this course. Scott Strobel was something of a visionary for setting it up, and it seems to have paid off with at least one cool result -- not to mention, a handful of students who now know how it feels to find something new.
I wish more professors would actively engage their students in "real" research projects, i.e. beyond the usual cookie-cutter laboratory lessons or follow-a-grad-student internships. Sure, it's more work for everyone involved, but experiences like this are the best way to convert bright students into real scientists, IMO.
I think there's a misunderstanding here on what ORCID is exactly. The name is an acronym for "Open Researcher and Contributor ID." It has nothing to do with publishing, but rather is being built as a central arbiter of academic identity.
Academics love to measure their importance by the papers they've authored or co-authored. Most databases currently track the names of authors associated with each published paper. But names are frustratingly ambiguous or degenerate, which makes it difficult to do things like create an auto-updated list of all the papers you've published.
ORCID is a publisher-funded non profit designed to reduce ambiguity in author identification, by simply assigning a UUID to every researcher. This is a case of publishers agreeing that collaboratively funding a single, centralized technical solution will benefit everyone much more than having a bunch of competing, siloed systems.