Giter VIP home page Giter VIP logo

lens's Introduction

Lens

Lens provides a novel way of looking at content on the web. It is designed to make life easier for researchers, reviewers, authors and readers.

Using Lens

Lens is a stand-alone web component that can be embedded into any web page. Just take the contents from the latest distribution, then adjust the document_url parameter in index.html.

// Endpoint must have CORS enabled, or file is served from the same domain as the app
var documentURL = "https://s3.amazonaws.com/elife-cdn/elife-articles/00778/elife00778.xml";

var app = new Lens({
  document_url: documentURL
});

Lens can display any NLM XML document or, alternatively, the Lens-native JSON representation. Lens is pure client-side Javascript, so anyone (even authors) can host their own documents on a regular webspace.

Make your own Lens

Lens is meant to be extended and customized. The American Mathematical Society developed a math extension for the Lens Reader to display JATS files with Math content, i.e. environments and formulas. See the official AMS Lens repo for a complete integration example.

However, now let's look into developing our own extensions.

Prerequisites

For Lens development, you need to have Node.js >=10.x installed.

You need to repeat that install step whenever you updated the screwdriver repo.

Setup

  1. Clone the lens-starter repository
  git clone https://github.com/elifesciences/lens-starter.git
  cd lens-starter
  1. Configure System

As stated above, you'll need version 10.x of Node installed, and you'll also need version 2.7.x of Python available. You can use nvm to manage which version of node to use on a per-project basis, and PyEnv to do the same for Python. With both of these tools setup, you can...

echo "lts/dubnium" > .nvmrc
nvm install
nvm use
echo "2.7.17" > .python-version
pyenv install
pvenv local
  1. Fetch dependencies
npm install
  1. Run the server
npm start

Then navigate to http://127.0.0.1:4001/ in your web browser.

Converter

Lens can natively read the JATS (formerly NLM) format, thanks to its built-in converter. Conversion is done on the client side using the browser-native DOM Parser.

You can find the implementation of Lens Converter here. Lens Converter is meant to be customized, so publishers can develop a their own flavor easily.

Each converter must have a method test that takes the XML document as well as the document url. The method is there to tell if the converter can handle the content or not. In the case of eLife we check for the publisher-name element in the XML.

See: lens/converter/elife_converter.js

ElifeConverter.Prototype = function() {
  ...
  this.test = function(xmlDoc, documentUrl) {
    var publisherName = xmlDoc.querySelector("publisher-name").textContent;
    return publisherName === "eLife Sciences Publications, Ltd";
  };
  ...
};

A customized converter can override any method of the original LensConverter. However, we have designated some hooks that are intended to be customized. Watch for methods starting with enhance. For eLife we needed to resolve supplement urls, so we implemented an enhanceSupplement method, to resolve the supplement.url according to a fixed url scheme that eLife uses.

See: lens/converter/elife_converter.js

ElifeConverter.Prototype = function() {
  ...
  this.enhanceSupplement = function(state, node) {
    var baseURL = this.getBaseURL(state);
    if (baseURL) {
      return [baseURL, node.url].join('');
    } else {
      node.url = [
        "https://cdn.elifesciences.org/elife-articles/",
        state.doc.id,
        "/suppl/",
        node.url
      ].join('');
    }
  };
  ...
};

You can configure a chain of converters if you need to support different journals at a time for a single Lens instance.

See src/my-lens.js

LensApp.Prototype = function() {
  this.getConverters = function(converterOptions) {
    return [
      new ElifeConverter(converterOptions),
      new PLOSConverter(converterOptions),
      new LensConverter(converterOptions)
    ]
  };
  ...
};

The Converter.test method will be called on each instance with the XML document to be processed. The one that returns true first will be used. You can change the order to prioritize converters over others.

Custom Nodes

You may want to customize how information is displayed in Lens. Here's how it works.

Define node model and view

We can either define a completely new node or override an existing implementation.

The following example from the starter repo overrides the Cover node and adds a feedback link to the top.

See lens-starter/src/nodes/cover/cover_view.js

CustomCoverView.Prototype = function() {
  this.render = function() {
    CoverView.prototype.render.call(this);

    var refUrl = encodeURIComponent(window.location.href);

    // Add feeback info
    var introEl = $$('.intro.container', {
      children: [
        $$('.intro-text', {
          html: '<i class="fa fa-info"></i>&nbsp;&nbsp;<b>Lens</b> provides a novel way of viewing research'
        }),
        $$('a.send-feedback', {href: "mailto:[email protected]", text: "Send feedback", target: "_blank" })
      ]
    });

    // Prepend
    this.content.insertBefore(introEl, this.content.firstChild);
    
    return this;
  }
};

In this example only the view code is modified while the original model definition is being reused.

See lens-starter/src/nodes/cover/index.js

var LensNodes = require("lens/article/nodes");
var CoverModel = LensNodes["cover"].Model;

module.exports = {
  Model: CoverModel,
  View: require('./cover_view')
};

In order to activate in that patched node, your custom converter has to instantiate a custom Lens Article instance.

See lens-starter/src/custom_converter.js

var CustomNodeTypes = require("./nodes");

CustomConverter.Prototype = function() {
  ...
  // Override document factory so we can create a customized Lens article,
  // including overridden node types
  this.createDocument = function() {
    var doc = new LensArticle({
      nodeTypes: CustomNodeTypes
    });
    return doc;
  };
  ...

Panels

Lens can easily be extended with a customized panel. It can be used to show additional information relevant to the displayed article. A few examples of what you could do:

  • Pull in tweets that talk about the current article
  • Pull in metrics (click count, number of articles citing that article etc.)
  • Retrieve related articles dynamically (e.g. important ones that reference the existing one)

For demonstration we will look at the implementation of a simple Altmetrics panel. It will pull data asynchronously from the Altmetrics API (https://api.altmetric.com/v1/doi/10.7554/eLife.00005) and render the information in Lens.

Panel Definition

This is the main entry point for a panel.

See: lens-starter/src/panels/altmetrics/index.js

var panel = new Panel({
  name: "altmetrics",
  type: 'resource',
  title: 'Altmetrics',
  icon: 'fa-bar-chart',
});

panel.createController = function(doc) {
  return new AltmetricsController(doc, this.config);
};

Panel Controller

Our custom controller provides a getAltmetrics method, that we will use in the view to fetch data from altmetrics.com asynchronously. Using the Substance Document API we retrieve the DOI, which is stored on the publication_info node.

See: lens-starter/src/panels/altmetrics/altmetrics_controller.js

var AltmetricsController = function(document, config) {
  PanelController.call(this, document, config);
};

AltmetricsController.Prototype = function() {
  ...
  this.getAltmetrics = function(cb) {
    var doi = this.document.get('publication_info').doi;

    $.ajax({
      url: "https://api.altmetric.com/v1/doi/"+doi,
      dataType: "json",
    }).done(function(res) {
      cb(null, res);
    }).error(function(err) {
      cb(err);
    });
  };
  ...
};

Panel View

The Panel View is where you define, what should be rendered in your custom panel. Your implementation needs to inherit from Lens.PanelView and define a render method. The implementation of the altmetrics panel is pretty simple. We will show the panel (PanelView.showToggle) as soon as data from altmetric.com has arrived.

See: lens-starter/src/panels/altmetrics/index.js

var AltmetricsView = function(panelCtrl, config) {
  PanelView.call(this, panelCtrl, config);
  this.$el.addClass('altmetrics-panel');
  // Hide toggle on contruction, it will be displayed once data has arrived
  this.hideToggle();
};

AltmetricsView.Prototype = function() {
  ...
  this.render = function() {
    var self = this;
    this.el.innerHTML = '';

    this.controller.getAltmetrics(function(err, altmetrics) {
      if (!err) {
        self.renderAltmetrics(altmetrics);  
      } else {
        console.error("Could not retrieve altmetrics data:", err);
      }
    });
    return this;
  };
  ...
};

Activate Panel

Panels are enabled in the projects app.js file by manipulating the panels array.

See: lens-starter/src/app.js

var panels = Lens.getDefaultPanels();

This code adds the altmetrics panel to the next to last position (before the info panel).

var altmetricsPanel = require('./panels/altmetrics');
panels.splice(-1, 0, altmetricsPanel);

Bundling

Lens uses gulp and browserify for bundling. Just run the gulp command.

$ gulp

You can find your bundle in the dist folder.

$ cd dist
$ python -m SimpleHTTPServer

To open one of the bundled samples you need open the following URL in your browser

http://127.0.0.1:8000/

Adjust the 'url' parameter to open a different document.

A note on mobile

Mobile support has been removed with Lens 2.0 to reduce technical debt and iterate more quickly on features. Eventually the Lens team will come up with a dedicated reader for mobile. We want to solve it right, and eventually also ship native versions for iOS and Android.

Credits

Lens was developed in collaboration between UC Berkeley graduate student Ivan Grubisic and eLife. The team of Substance is helping with the technical execution.

Substantial contributions were made by HighWire, which launched Lens for a number of science journals in fall 2014 (The Journal of Biological Chemistry, The Plant Cell, Journal of Lipid Research, mBio®, and more). The American Mathematical Society (AMS) made Lens ready for advanced rendering of math articles.

Thanks go to the following people, who made Lens possible:

  • Ivan Grubisic (concept, dev)
  • Ian Mulvany (leadership)
  • Oliver Buchtala (dev)
  • Michael Aufreiter (dev)
  • Graham Nott (infrastructure)
  • Melissa Harrison (QA)
  • Rebecca Close (converter)
  • Felix Breuer (math)
  • David Jones (math)
  • Peter Krautzberger (math)
  • Samo Korošec (design)
  • Ian Hamilton (design)
  • John Sack (guidance)
  • Greg Schwartz (content variation)

lens's People

Contributors

giorgiosironi avatar gnott avatar ianmulvany avatar ivangrub avatar lsh-0 avatar michael avatar nirum avatar nuclearredeye avatar obuchtala avatar oliver7654 avatar pkra avatar thewilkybarkid avatar vectorsize avatar withanage avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

lens's Issues

Figshare widget

Would it be useful to look into utilizing the Figshare widget for displaying doc, xls and other supplement data formats within Lens instead of forcing the user into downloading them?

use of substance screwdriver

I think using usual workflow and usual tools to update, build and run the project is way better than introducing new tools. Because by experience, ease of getting started with the project causes more contribution.

For Lens, instead of using substance cli tool, we can use npm. Then we can focus on the project itself not the tools. I suggest this workflow:

  • Publish all modules required for Lens on npm.
  • Use package.json to reference modules required and their versions.
  • If Lens needs a module to change, change the module, bump the version, publish to npm, update Lens' package.json to use the newly updated module.
  • npm can run custom script in different phases ( https://npmjs.org/doc/scripts.html ). We can use start script to start the local server, update script to fetch updated dependencies, etc.

I'd like to hear your ideas on this suggestion.

panning figures

This is a great addition. The one thing that I thought would be an improvement is that multipanel figures look small, and it will often be the case that the reader wants to see a particular part of the figure enlarged, but without losing the text on the left. Currently, when the figure is enlarged, it expands to fill the entire window and the text disappears. What I have in mind is that the left and right panes would stay as is, but the cursor would turn into a magnifying glass that would allow the reader to "magnify" the right pane and then scroll around it using the mousepad. Sort of like how it works in google maps when you zoom in on an area. For example you could use "pinch zoom" to zoom in and out, or do it with keys (command + or command -). A second feature that might be nice would be to be able to control the width of the left and right panes by being able to move the divider that separates them.

Adapting Github Flow (Lens edition)

Just had another read on Scott Chacon's post on Github Flow.

http://scottchacon.com/2011/08/31/github-flow.html

In order to quickly adapt that process to Lens development I'd suggest that:

  1. from now on anything pushed to the master branch is considered 'fit for use'. I think at our current stage we don't need to consider the master branch 'deployable' as we do bigger release increments. Let's just use tags for every production release.
  2. All development is done in descriptive feature branches. My current one is modularize, which will cover CommonJS support and pluggable content types.
  3. Pull requests: Every repo (master branch) is maintained by one person. I'll take care of the lens and lens-article repositories while Ivan dictates the refract repo. Our main responsibilty will be keeping the master-branch 'fit for use'. Thus all changes to Lens and Lens Article, that are ready to be merged with master must be reviewed by a Pull Request workflow. @ivangrub Next time I make changes to the converter that are ready for master I'll send you a pull request.
  4. Dependencies between projects/branches

Many times there will be breaking changes that affect multiple modules. E.g. now that we're working on improving the Lens Article format. I'd suggest that we use the same feature-branch names across projects. I've created a modularize branch for all sub-projects.

Anyone who violates these rules shall be punished by curating a Lens JSON off an NLM-XML by hand. ;)

NLM XML front and back standard

Is there any way that publishers could agree on a standard for the tagging of an article's meta information in the front and back portions of the XML?

That is currently the only aspect that requires some potentially serious tweaking to get refract and lens working smoothly with any publisher.

Online annotation / metadata export

Would it be possible to add annotation features to lens?

More specifically, I am thinking of similar features that are already available for pdf files such as text highlighting and notes/comments.

Additionally, it would be great if those annotations could be shared with others as well as exported as plain text. Obviously it would require some sort of signup process and a personal account.

Just curious if any of this is something you are seriously considering?

Thanks!

Feature proposal: Private Notes

Something that was requested frequently by our testers was the ability to store private notes and stick them to certain text passages.

Supporting private notes would be rather cheap, compared to implementing public comments, which would require server infrastructure for storage. Also as Ian stated the public commenting features are rarely used.

Estimated development costs for a functional prototype: 1-2 weeks (depending on configuration).

Proposed Technology:

  • HTML5 localStorage API
  • A stripped down version of Substance Surface (for normalizing DOM selections into exact ranges)

PLOS specific color schemes

PLOS Comp Bio, Genetics and Biology use #16A127 (green) and #3C63AF (blue)
PLOS One uses #F8AF2D (yellow) and #3C63AF (blue)
PLOS Medicine and Neglected Tropical diseases use #891FB1 (purple) and #3C63AF (blue)

Maybe keep the publications blue and change the color for the figure annotations?

Mobile ideas

Had a look at Rebecca's experimental mobile branch of Lens. Just collecting my mobile thoughts here for later reference.

screen shot 2013-09-01 at 10 03 39 pm

  • One view at a time is key I think... no split screen for small screensizes
  • Context switches should be easy to follow for the user.
  • Context toggles (Content, Figures, References, Info) should probably sit on the bottom, always visible (cmp. iPhone Twitter App)
  • Visual Document Outline is probably too much for mobile view (interaction is supposed to be clumsy) It might make sense to make a stripped down non-interactive version of it.

Example scenario:

  • the user starts reading in the content view.. content takes the full screen space
  • User clicks on a figure reference
  • Triggers a switch to figure view and jumps (auto-scrools) to the selected figure
  • Back button is always there to quickly go back to the original reading position (problem: this is redundant with clicking the content view toggle)
  • within the figures view all other figures are visible too, users can scroll around.
  • tapping on a figure opens a fullscreen version
  • back button takes the user back to the figures view

Alternatively:

  • Home screen only shows the abstract + directions (Content, Figures, References)
  • User clicks on content and only sees the article content (no other UI elements except the back button on the top)
  • User clicks on a figure
  • Only that figure gets shown in fullscreen..
  • back button lets the user continue reading
  • click on a citation
  • same game as with the figures
  • user clicks back twice, which takes them to the home screen
  • user clicks on figures (which activates the figure centric view)
  • click on a figure opens it in fullscreen
  • back button takes you back
  • back again
  • now click on references (citations)
  • welcome to reference-centric mode
  • (not sure if there's a need for focus on one reference)
  • (... well if we have additional information on the referenced article there is a need! )

to be continued....

Infrastructure upgrade

I had to thing about our roadmap this morning and I think one important early step would be upgrading our infrastructure layer. We have a pretty minimal setup now, in fact Lens is just a static webpage. I kind of wanted to have it like that since it simplified things during the development process of the prototype. However, we might want to get things a little further so Lens becomes extensible and easier to deploy.

CommonJS modules:

There's broad consensus on using Common.js for modularizing Javascript code. We can make use of tools such as browserify to resolve dependencies and generate a dist package. We've recently moved the Substance development stack to Common.js and integrated it with our development workflow. It works pretty well.

Pretty urls

instead of the hash fragments we could use regular urls.

http://lens.elifesciences.org/#00768/toc/heading_s2-3
->
http://lens.elifesciences.org/00768/toc/heading_s2-3

Converter integration

We could integrate the converter directly into Lens, which would allow for on the fly conversion of XML files.

http://lens.elifesciences.org/convert?source=http://......doc_a.xml

Search engine optimization

A little server layer would allow us to implement Google's Ajax crawling scheme so our docs are indexed by Google. We could also make it so that we return a static version of the page when the urls like http://lens.elifesciences.org/00768/toc/heading_s2-3 are accessed by Google.

Well the overall idea is to provide a little sandbox that makes it easy for developers to collaborate on Lens. It should be easy to run the latest version of Lens locally, make changes and contribute back. Also I had in mind a simple plugin system which allows people to add new nodetypes.

Drawback of using a server: We loose the ability of deploying Lens purely statically. I don't think it's a big deal though, since data doesn't need to be proxied through the server. It also opens the door for implement user authentication etc.

Running the thing locally would be as easy as:

$ git clone https://github.com/elifesciences/lens
$ cd lens
$ npm install
$ npm start

@IanMulvany @gnott @ivangrub what are your thoughts about this? Should I start working on this next week?

@gnott Are there any difficulties in deploying node applications to an EC2 instance? Heroku would be an option too for deployment.

iPad - iOS4 problem

The front page loads, but the canvas does not scroll and none of the articles load.

support a getting started fast interface

Should either be able to drag and drop xml or json onto lens -- or point easily from the lens code to an include tag or to a source file, rather than having to unpack how lens currently creates it's list of resources to display off of AWS.

Result is different from eLife Lens website

I cloned repository, tried lens script to pull required resources and npm modules, but after launching lens locally, I couldn't get the same result as eLife Lens. I just see three articles in homepage, clicking on the third one I get this result:

substance

Is it normal? I'm confused.

add a label to the document map

Editor from science writes:

"Thanks. I just took a quick look at the site and it works quite well. As an editor, I like that you can easily find out where references are being discussed. Of course this applies to figures, too.

The video is definitely helpful (or, in my case, the fact that you introduced the map idea beforehand). Otherwise, I'm not sure I would've figured it out right away. I wonder if a label (e.g. 'ms map') would help."

Add keyword search in article view

"I've shared lens with my team here, a few of which have other halves doing PhDs - a bit of feedback I'm certain you've got on your radar is that it needs a keyword search within the paper. While the browser search obviously does the job, there's something about interface giving you all these different routes into the content that makes you forget the browser search, and look for one within the app."

Add "filter by month" on the homepage.

In a continous publication model It's hard to get a view of what was published when. May readers still like the interface of an "issue". One way to replicate this is to provide a "by-month" filter, as opposed to a "in the past month" filter.

for the elife repository, add a "back to eLife" link or affordance

We are working on putting a link to Lens from elife.elifesciences.org, but I would like users who follow this link to have some way to get back to the main journal.

Could be:

  • a back link
  • make the elife logo go to the journal, and provide a different navigation element for the lens cover page
  • could be an interactive popup with a guide on where the user is now, with an option to go back.

To be decided.

part of this story on trello https://trello.com/c/d68lsvtB/6-integrate-lens-view-into-submissions-system

Google indexing etc.

Just had an idea regarding Google indexing. What we could do quite easily is just creating a little static site generator based on the client-side renderer we already have. So instead of dynamically rendering on the client we would prerender each article as static html and host it on amazon.

For comparison (using verbose url notation)

Current

one index.html that contains templates and a renderer for clientside rendering:

http://lens.elifesciences.org/index.html#01135/publications/text_15/article_bib5

New

We get a dumb html file per article and another one for the document index.

Like so

http://lens.elifesciences.org/01135/index.html#/publications/text_15/article_bib5

http://lens.elifesciences.org/index.html

That way we have google crawlability for free and an even more pure static approach. Even better, load speed would definitely be positively affected. We wouldn't need the json file for the initial render.. only when the user does the first interaction. Essentially we would get rid of the "loading...." stage entirely.. the page gets streamed to the client as any non-interactive page on the web.

We'd need a smart build process that could be simplified to something like this:

./lens.py --bundle --source http://s3.amazonaws.com/elife-lens/xml_files.txt

Then, take the contents of the "dist" folder and dump them on S3. Done. ;)

Lens publishing for everyone.

Here's some ideas how we could encourage people (site visitors) to start publishing their own Lens documents.

Maybe on the startpage we should have a simple call to action screen.

lens-startpage

I'd like to add first-class support for libraries and collections to the user interface. It's not a big deal, it's just coming up with a proper specification for what we called the "document index" before.

So here's how I imagine it to look visually.

lens-collections

While I won't take this too far I think it's crucial to have that functionality in place, so publishing is possible without having to install Lens locally. All they need to do is hosting an index.json which references the available collections and.

Thoughts?

Decision Letter/Author's Response

Any images that are supplied in the author's response, are usually not referenced in the text and are currently appended at the end of the Figure list. Often times it does not look very good. We should come up with a more uniform presentation for them. Be it that they are implicitly linked to a section and automatically have labels if they are not provided by the authors.

There are also lots of references sometimes at the end of the author's response. These references are presented as simple paragraphs which makes adding them into the Publications pane very difficult.

Needless to say, I don't think this is the highest priority item, but would be nice to give it some thought.

Author cards are missing equal contributions

The author cards should also include information about when authors have contributed equally to the article.

The JSON representation in the person node would have the following.

person:1 : {
     "type" : "person",
     "id" : "person:1",
     "equal_contrib" : "person:2",
}

The representation the card would have:

Equally contributed with: (Name of person:2)

Zotero/Papers/Mendeley

Along with adding tags for google search, we should also make the articles identifiable by the extensions provided by existing reference managers (Zotero/Papers/Mendeley as examples).

eLife journal integration

Now that we have a client-side converter, I think it would be smart to integrate the Lens.Reader module directly into the eLife journal page. We could leave the whole article navigation part + Google indexing as is. Essentially what needs to be done is just having a copy of this page layout

http://elife.elifesciences.org/content/2/e00768

but instead of the Highwire view the Lens.Reader would be shown. See this little sketch.

screen shot 2013-09-10 at 3 23 05 pm

I'll provide a packaged .js file + css + a guide that has everything needed for integration. You can override the CSS to match the eLife journal style without messing with the Lens codebase.

Ian, how do you like that idea? What are the next steps regarding journal integration of Lens 0.2.0?

Level 4 headings are missing in TOC

article 00012. Current version has a bit of a bug with this. Will update with the newest one before the weekend so that you can see it. Had to reformat the way heading levels are determined to make it more consistent across journals.

Add ALMs to Lens

What a thing of beauty!

Enhancement request:
I'd love to see the real time ALMs for eLife papers in Lens as well as those for each of the references.

Add loading indicator

Bigger docs take a second or two to download and convert.. -> add a loading indicator to the reader, as we had it in the first version.

Bundling

Rebecca in response to the new 0.2.x build:

The first thing I notice about the changes is that there are even more javascript files for users to download. It seems like you might want to condense them all into 1 or a couple minified javascript files so that the files will be smaller and there will be fewer requests to the server. Lazy loading would be good whenever possible. Same deal with the css. Check out how bootstrap handles this situation. Choose the components (modules) you want and then you can elect to use the minified files if you want. Additionally it would be cool to either make a tool or explain in later documentation how to customize fonts/backgrounds/etc for branding or just plain viewing preference. You know how all the cool coder kids like to view things in green on black these days. :p

Good points. The current dev-stack serves the files on the fly. That's handy because in the Chrome debugger we have a 1:1 mapping to the file+line-number where the error occured. However, I'm aware we need some sort of build process to create a combined/minimized package of the JS/CSS for deployment. I'll get after this in September when we're preparing the deployment of 0.2.0.

What we will do is adding a --bundle option to the Substance screwdriver command line utility.

$ substance --bundle

It will create a dist folder within the project folder that has the combined and minimized files, ready for deployment.

Dealing with legacy browsers

Just mocked up a welcome screen that we could display if someone is running a legacy browser.

Pls help refining the message we want to display. Also let's collect some test results here.

screen shot 2013-06-04 at 11 56 13 am

Not sure if I get enough time to implement that today, but we can add that in the coming days. Shouldn't be a blocker for the release imo.

Right-hand pane: invisible information content until scrolling

When information is displayed in the right-hand pane it is currently unclear how much is there and how it is structures (at least beyond what is visible the screen). This resembles the problem on the left-hand side with the entire text. Actually, how about just getting rid of the old-fashioned slider and replacing it with the same type of structured slider you use for the text? The implementation could be simpler as there is less functionality needed (in terms of highlighting and linking).

Lens Library or introducing Lens document repositories

I think it's time to introduce the concept of a content repository to Lens. We're quite close already, since we have defined a simple index format that just provides meta information about a set of articles along with their urls.

See: http://elife-converter.herokuapp.com/documents

However currently, one would need to configure Lens to be able to access a different content repository.

Lens.ENV = 'production';

// Can optionally be an array specifying a file extension (we need that for static deployment)

Lens.API_URL_PRODUCTION = ['http://cdn.elifesciences.org/documents/elife', '.js'];
Lens.API_URL_DEV = 'http://elife-converter.herokuapp.com';

It would be nicer to do that at runtime like so:

http://lens.li/#elife/00654 - for accessing an eLife article

http://lens.li/#plos-one/0048868 - for accessing a plos one article.

(btw. the lens.li domain is free... .li like "literature" ;)

The first part of the url is an alias for the content repo, which is identified by a URL. In order to allow lens to display any document on the fly, one could also provide a url to a lens document.

E.g. if you wanted to display http://plos-converter.herokuapp.com/documents/journal_pone_0047695

you'd just have to provide the URI-encoded url

http://lens.li/#http%3A%2F%2Fplos-converter.herokuapp.com%2Fdocuments%2Fjournal_pone_0047695

Let's consider making repositories a first-class citizen and introduce the Lens Library interface. A Library conforms to the JSON serialization format we have right now.

It has an index of article records. One record looks like this:

{
      "_id": "00051",
      "published_at": "2012-12-13",
      "name": "Global divergence in critical income for adult and childhood survival: analyses of mortality using Michaelis–Menten",
      "authors": [
        "Hum",
        "Jha",
        "McGahan",
        "Cheng"
      ],
      "journal": "eLife",
      "article-type": "Research Article",
      "keywords": [
        "enzyme kinetics",
        "adult survival",
        "child survival",
        "income",
        "HIV",
        "smoking"
      ],
      "organisms": [
        "Human"
      ],
      "subjects": [
        "Human biology and medicine",
        "Microbiology and infectious disease"
      ],
      "url": "/documents/00051"
    }

Thoughts?

Reference sections (headings)

Add support for referencing sections within an article. Annotation definitions would look like so:

{
  "id": "annotation:25",
  "type": "cross_reference",
  "source": "text:25",
  "pos": [0,25],
  "target": "heading:10"
}

I think calling this "cross_reference" make sense, since we can also use it to reference any content node (like other paragraphs).

Zoom implementation

Now that we're doing a bigger refactor of the codebase I'd like to take the chance to get zooming right. We have a quick-and-dirty solution hacked into image nodes currently, I think this could need some love in terms of code modularisation and visual appearance.

I'd like to have a generic concept for zooming that scales to all node types. E.g. zooming into tables/videos would make sense.. And I have a feeling there will be new content in the future that deserves some zooming.

Budget estimation: Not more than one day for a clean rewrite.

Provide documentation on how to point lens at a user authored document

At the moment the README file instructs the user on how to launch index.html.

It would be good to explain how lens loads the current file list, and how to replace that file list with a custom file list.

It would be good to provide documentation on how to point the lens viewer at a specific json file provided by the user.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.