Web browser Text annotator to annotate documents - javascript

I thought to bounce this idea from people here:
I have to build a light-weight text annotator which will be later embedded in one of website.
The text annotator will be used to collect manual annotation for various documents from various users (i.e. human users which are logged in to that website). User will be rewarded based on their labor.
Wondering if anyone has already done similar thing or if someone has any thought on this task.
As per my research so far, somehow using CKeditor for this seems good idea.
This is totally new to me and I am also new to JavaScript (but hardcore with Java core :) ). Any assistance will be greatly appreciated.

The Firefox addon Semantic Checker retrieves semantic data such as this from websites. There are also several JavaScript libraries which facilitate creation of such metadata:
RDFaCE
createjs
annotate.js
alohaeditor with WAI plugin
vie.js with backbone.js
References
Commercial Benefits of Accessibility | CKEditor.com

Related

Is it possible to edit and save website content to server, making the change viewable by everyone?

I have created a website for a third party, who have no experience in editing HTML. However, the third party wishes to be able to edit the content on the website without having to open the files and edit it this way, they wish to do it somewhat WYSIWYG (For example, hit an "edit" button for the content they wish to edit). Is this possible to achieve? It is not an internal website, it has user tracking (this should obviously only be available to admin users).
Is there a way of making contents of a div editable, then saving the change directly to the server, so the content gets updated publicly?
I am currently researching the topic, and although I have found some indications that the solution may be a PHP script, I have yet to find any definitive solutions or examples of similar functionality.
Yes you will need a backend language or framework to archive this. Where Javascript is used to interact with the page, the actual storage of information requires a database or similar technology.
Unfortunately which backend language or framework to choose really is the million dollar question. It largely depends on exactly what you are trying to accomplish, what your client or user is comfortable with, and how much experience you have programming.
PHP is fast and time tested backend language. Node is the new kid on the block, and it very popular also. Java and dotNet are on the way out. You can dig up a bunch more including Go, Python, Haskel, Etc.
You can use a languge listed above and start scripting away, but this can be time consuming and error prone. Most people use a framework to get started, and program using that framework's tools. The most popular PHP framework is WordPress, but it is designed for blogs and might not fit your use case. I use the framework Craft CMS which is very customizable. But the way you are phrasing the question a framework might be overkill. This is really up to you to decide after doing research into the available options and comparing them to what you wish to accomplish.
For the WYSIWYG, you might want to look into the following tools for the client to edit content:
https://imperavi.com/redactor/
https://ckeditor.com/
Hopefully this provides some direction, happy coding!

Real-time collaborative rich text editing

I would like to have a real-time collaborative rich text editor for my webapp. So far i've done a LOT of research and i'm really a bit frustrated that there is nothing fitting out there.
The thing is, that every solution out there is tightly coupled to an editor (Firepad for example uses CodeMirror/ Etherpad uses Etherpad).
There are only two other solutions i found interesting:
ShareJs -> works only for plain text
Webstrate -> This was the MOST promising to me. It can handle DOM synchronization and therefore it can handle every contenteditable - great!
But the problem with Webstrate is, that it is in an alpha Version. So for me it was too buggy - didn't work out. Tried to get it working for about 2 days. The text synchronization was easy. But it didn't work with iframes or other stuff.
My claims are pretty high for a collaborative RTE - it should support:
Images
Iframes
Video
Text (of course)
While i'm searching for about 3-4 days now for a solution - maybe someone of you has a hint? Would be very gentle ;)
You can try http://swellrt.org, is a complete framework to develop real-time collaborative apps including rich-text support and an editor for Web.
It provides a JS API, analogue to GD Real-time API, plus rich-text editting.
The editor can be extended to support any attachment.
It's a fork of Apache Wave that generalizes the original code.
The closest thing I found is http://quilljs.com/ - it has an API for getting and updating text deltas and also for getting and setting multiple labeled cursors. It doesn't manage the real-time editing for you, but it gives you enough to work with (more than any other project I found). However it is not as comprehensive as other editors in formatting (for example, it doesn't support tables and nested lists). It is somewhat extensible, so you may be able to add support for additional HTML elements.
Robust collaborative rich text editors are still somewhat bleeding edge. Most web based text editors fall into of two categories.
Those that are compatible with real time collaboration but have fairly limited functionality (e.g. no tables, no nested elements, etc.).
Those that are very robust web based rich text editors, but lack that API to integrate with real time technologies.
Then there are the collaboration engines like ShareDB, Google Drive Realtime API, SwellRT, and Convergence (full disclosure I am a founder at Convergence Labs). These types of systems each have their own opinion on data models and how to mediate collaboration. It may be the case that the way your favorite rich text editor works internally is incompatible with the API of the collaboration engine.
The technologies out there that simply sync the DOM are interesting because they are often portable across editors and are less dependent on the editor API, but they tend to lack a lot of the required real time editing capabilities that are required for good collaboration (shared cursors, shared selections, etc.). This can be very hard to implement on top of a DOM syncing approach from outside of the engine itself. Unfortunately, without these features, the collaborative editing experience is not that great.
There are several projects out there that are attempting to remedy this situation. The folks at CKEditor are working on CKEditor 5 which has collaboration in mind. Also, over at Convergence we are trying to work with the authors of many of the popular editors to enable real time collaboration.
The reality is that it is still a pretty new space and evolving quickly. There is no tested, scalable, slam dunk solution that provides and out of the box fully capable, collaborative, free and open source editor. The situation looks to be improving over 2018. Hopefully in the next 12-24 months this becomes a much easier problem.

iBooks JavaScript resources

iBooks recently started supporting JavaScript inside epub. Where is this documented?
Are there any code examples to get started?
** Update, one year later : This has been now documented for several months in the official Apple Docs available on iTunes Connect
From what i've seen, you already have quoted the best known sources.
I think that it is not documented anywhere in the official docs from Apple. Here are some elements from what I've experienced.
Features supported by iBooks
A lot of things that work on Safari work on iBooks too. You already have access to HTML5 features like internal DB, canvas, etc. The biggest problems I saw were related to slowness and vertical positionning. There are problems with pagination too : if you add content, pages are not added to the end and the content can overflow.
Validation for the iBookStore
Before being published on the iBookStore, it relates entirely on Apple's arbitrary validation when it comes to Javascript. I know at least one ePub with interactive forms and DB, that they have validated.
For lack of better resources, I created a open-source example of using JQuery to show an alert. Might be helpful as a starting point.
The examples you give refer to the interactivity in the body of the books. Javascript scripting can also be used within the HTML widgets:
HTML widget boiler plate on github -- https://github.com/TrevorBurnham/iBooks-HTML-Widget-Boilerplate.
iBook Widgets with D3.js --
http://vallandingham.me/ibooks_and_d3.html
(to check the widget, click on 'download a copy of my iBook file', change the iba extension to 'zip', uncompress, navigate to vis-1.wdgt)

Pure JavaScript-based clients

I would like to know, how powerful/viable are JavaScript only clients based on say, GWT/gxt/vaadin, when compared to DHTML clients such as those made with wicket, tapestry, click etc?
My boss has insisted on using GXT (due to its nice colors and theme) on a project that will most likely become very big with lots of screens. I am against the idea of a javascript only client, especially when the javascript is generated from Java code. I have tried to advice him that we use something like wicket whereby we construct the screens with html but put in ajax where and when neccessary.
How viable is such a JavaScript client? I understand that JavaScript was intended for minor web page enhancements, and not all browsers, especially mobile devices have complete support for JavaScript.
Yes, it is viable for certain applications. Consider Gmail, Google Docs and Google Maps as typical applications where this works, and is probably the most feasible approach.
Some rich UI JavaScript frameworks, such as Ext JS also rely on this technique.
I've built javascript only web apps for ages.
First in SAP projects for big multinationals. And now on a new project:https://beebole-apps.com?demo
So yes it is powerful and viable.
Javascript-only webapp can be extremely powerful, and it's viable for certain applications, say, an Instant-Messenger webapp?
You mentioned that there are lots of screens in your web-app. One of the advantages from GWT/GXT is the fact that you can unit test your UI-layer with JUnit. This is an extra testing you can do on top of, say, Selenium. This is essential if you'd like to make UI testing a part of the continuous integration process, and, as the team grows, you'll definitely want to have tests around to make sure everything works (At least in theory.)
However, if what your boss meant to do is to build an in-house, custom Javascript engine using GWT's JavaScript Native Interface (Link), then I'm not sure...
Another advantage with GWT-like-engine over Wicket is that you can rely on HTML-code-gen to generate standard-compliant (In theory) HTML code. With framework like Wicket, it is hard to ensure every single developer on the team to author good HTML code - Especially when the team gets bigger.
Disclaimer: I'm a member of the Vaadin team.
Our Timeline demo is a good example of what can be achieved with Vaadin and GWT in client side, but I think all of the options presented in this discussions are viable given enough time.
Since you are going to start a big project you should build a simple proof-of-concept app with each of the relevant frameworks. If your PoC includes at least some of the more complex use cases you'll probably can make a pretty informed choice based on the experiences you get while building them.
I urge you to at least evaluate Vaadin. With it you write only server-side Java code and Vaadin will create a slick and professional browser UI for you. Client side can be easily extended using standard GWT (also pure Java), and there are no HTML templates, tag libraries or XML configuration involved at all. A Vaadin UI is fully Ajax'ed and lazy loading out of the box, and it easily integrates with any server side technologies, eg. Spring.
In addition to the development model advantages you get top-notch documentation, a bi-weekly update schedule, a very lively community filled with helpful experts, 100+ useful open source add-ons, and a 10 year old backing company with help on hand should you need it.

Adobe ExtendScript development - How different than regular JavaScript?

Question
I'm wondering how different ExtendScript is from JavaScript? Could I theoretically hire a web developer who has JavaScript savvy to develop it without demanding an excessive amount of learning on their part?
Overview
I'm working on a media database (or a so-called "multimedia library") project and it is based on XMP (the eXtensible Metadata Platform). The logical tool for administering the metadata and keywording seems to be Adobe Bridge, however I need to contract out the development of a couple of scripts to add a few key functions to Bridge, mainly for interfacing with a server-stored controlled keyword vocabulary.
Upper management, in their infinite wisdom, has decided that putting a software alpha/beta tester and Adobe heavy-lifter [me] in charge of developing the project discovery is the best way to go about this. Whilst I know what I need done, I'm unsure who can actually do it.
Regrettably, my programming knowledge is limited to C++, XML, Apple Script and web languages (unfortunately not including JavaScript), so I'm way out in the weeds when it comes to questions about JavaScript.
Bridge Developer Center
Adobe has a handy SDK out there on the subject, but I can't really make much sense of the overall picture. Much of the Adobe user-to-user forum content is old or unrelated.
Project description
I need a menu added to the menu bar with three options. The three options would all use "Clear and Import" function possible in Bridge's Keywords panel to import 1 of 3 different tab-delimited text files from the database server using either the FTP or HTTP object.
The reading I've done in the Bridge SDK and JavaScript guide suggests that menu items can be added as I've shown in the image below for clarity. Additionally, I've managed to get a very rough version of the "Clear and Import" method to work as a startup script, however I'd like to be able to call them on the fly by clicking on the appropriate menu entry.
For a larger view of the image, click here
ExtendScript is very close to regular JavaScript. They've made a few extensions (e.g., operator overloading) but overall the two are very similar. Adobe products include an IDE called the "ExtendScript Toolkit" (ESTK) that provides a nice environment for writing scripts with an interactive debugger.
You can create new menu items in Bridge by creating instances of MenuElement. Set the onSelect property of the MenuElement object you create to be the function you want the menu item to perform when you select it. The Bridge CS4 JavaScript Reference guide has all the details.
If it's anything like the scripting used for the old Flash IDE, then I think it's just straight javascript/ECMAScript. The only real difference is the APIs you have avaialble. I expect anyone who's good with javascript would be able to pick it up fairly quickly.

Categories