On Rich Text Editors

In the last couple of years I have found myself in a couple of projects using web based rich text editors. Since these projects were written using React, I primarily focused on libraries that worked with that framework but have been keeping an eye on other projects as well. This post is a braindump of my thoughts on the space

Many years prior to that a few friends of mine and I had tried building a web-based Evernote clone that would do smart things based on patterns we could define in Regular Expressions. So for example, if I typed in an email address in my document, the JavaScript would recognize that and convert it to a mailto: link. With the advent of contentEditable, we thought this would be easy to do

We were totally wrong. Turned out contentEditable is a terrible API as documented in this article by the Medium engineering team. Modifying the underlying document while the user was editing it was just impossible to get right even on one browser. And for bonus pain points, every browser wrote different underlying HTML when the user edited a contentEditable element.

DraftJS

About 3 years ago I was assigned to work on an online CMS for an internal portal at work and started looking at RTEs again. Since the rest of the project was going to be in React, I started looking closely at React libraries. React had one advantage that didn’t exist when we had tried our earlier adventure: Since React keeps the document structure in its Virtual DOM, it didn’t have to fight with the browser specific implementations of contentEditable as well as fight the browser for things like cursor position and selections.

DraftJS seemed like the best choice at the time. It was (and still is) actively developed by Facebook and is used by them for text editors on Facebook.com.

Generally it worked well enough. We could have used more documentation but were able to get a default experience working. Draft comes with very few extensions and really tries to sell its “toolkit” nature by having you code behavior I’d have expected as default. There is a different project called DraftJS-Plugins that gives you a lot of that. Weirdly, DraftJS-Plugins requires you to use its Editor which seems to be a modified version of the DraftJS editor. Ideally Draft should support plugins out of the box.

We did make a mistake with storing the document though. Our thinking was that the document in the database should be saved as HTML and Draft should just re-render the HTML when the document needs to be edited. Turns out Draft really prefers saving and loading a serialized state of the document. This does make some sense but makes any future migrations to a different editor much harder. This brings me to the next library I looked at

Ghost

Ghost is a pretty interesting CMS. Visually its very polished and the editor interface there is pretty amazing. Earlier versions of Ghost used an editor that really was centered around Markdown, which is awesome but not a fit for the target audience of our system. Ghost also had very limited database support: basically SQLite for development and MySQL for production. Since we didn’t want to use MySQL it was a deal breaker.

But from the point of view of Text Editors, Ghost 2.0 that was recently released shipped with a new and much nicer editor. The editor is now part of the main Ghost repo but I imagine can/should be extracted to its own project.

Whats really interesting about the Ghost Editor is that they also released a library for building WYSIWYG editors supporting rich content via cards called MobileDoc-Kit and an open source spec for these documents called MobileDoc.  This addresses my issue with storing a proprietary format for a document in the database. So yay!

WordPress Gutenburg

Meanwhile WordPress has also been working on their own new editor that just shipped as part of WordPress 5.0 today. In a big departure from previous PHP centric WordPress editors, Gutenburg is written in ReactJS. Additionally, unlike Draft (as well as Ghost 2.0 editor I think), Gutenburg works on mobile devices. My biggest issue is that I really hate WordPress’s “HTML comments as a data structure” approach. And I am not the only one. Using Gutenburg has so far been pretty okay. If you’d like to learn more about it, read Matt Mullenweg’s post on it today

CKEditor

Other projects also crossed my path during this project. CKEditor for example looks promising but I have’t dug into it. What makes it really interesting is its newly added support for collaborative editing out of the box, something I’d love to add to my project but its not a big ask (yet)

Trix

If Rails is your thing, Rails 6.0 will include a Rich Text Editor out of the box which is really cool. The editor itself, Trix, is out right now and can be added to your project if you need it. 

Final Thoughts: Blocks

One interesting thing is that almost all the editors are starting to move into the concept of a rich document as a group of content blocks. This is a departure from earlier architectures that gave you the entire document as a rich document with all the formatting. One reason for this is the ability to export the content blocks in a variety of formats besides simple HTML (like Markdown). 

Blocks also let you use non-text elements within the document. These can be things like media or even rich widgets like photo galleries etc. Given a well defined document data-structure, these can also be supplied by third-parties.

For example, Elementor has released a bunch of widgets for WordPress’s Gutenburg

Modern word processor centric startups are taking these ideas even further. For example,Notion takes the same block based approach to a person notes app

AirTable, which takes a similar block centric approach to spreadsheets, was recently valued at $1 billion 

Both Notion and AirTable measure usage and price their plans not on the basis of number of documents but rather the number of blocks used.

Announcing Artbook: An Android Client for Dribbble

I am a big fan of Dribbble. For the uninitiated, its a community for designers to share parts of their work and is pretty inspirational when you are thinking of designs for your own applications. When I released FreeFlow earlier this year, I included a sample Dribbble project as part of the release to showcase the power of layout system. Since then I recieved a couple of messages from a few folks to just complete that as an app since a lot of the work was already done anyway. It also didn’t seem like there were any really compelling Dribbbble apps on the Play Store (well none that I felt were very interesting anyway). So last week I worked a bit and finished the Artbook app

Like the original source that was included in FreeFlow, Artbook is completely open source and released under the Apache 2 license. The code for the app has some ugly parts but is generally okay. Having recently acquired a 10.1” Android tablet (the Galaxy Note 10.1 mostly for drawing), I really wanted to make sure it had a fantastic tablet experience. However unlike Google’s direction to use Fragments for multi device layouts, this app does it via just a few simple if-else blocks and conditionally loading layouts. I find this approach so much simpler than any elaborate Fragment based architectures.

Anyway, I hope you give it a shot and see if you like it. I find browsing Dribbble a lot more fun using it

 

Introducing Picscribe for Android

Picscribe screens

Here is a scenario: You are on a trip and taking a bunch of pictures. Usually there is some context to those pictures that you are trying to capture (what a building is for example or what this dish or drink is that you ate that day and if you liked it or not). While taking pictures is easy with our smartphones today, capturing your thoughts at the moment is much harder and so far I hadn’t found a good way of doing that. If you use a photo service like Flickr or Google Plus/Picasa, you can annotate your albums, but that usually happens much later and is a pain in the ass. Otherwise you have hard-drives full of photos that sit in some folder based albums and often elicit the “Wait, what was this?” face.

Marty-McFly-Confused-In-Back-To-The-Future-Gif

To solve this problem, last week I released Picscribe, a photo notes app available now on the Google Play Store for Android (iOS coming soon). Picscribe is a pretty simple app: It lets you take any photo in your phone and add a comment right into the EXIF metadata of the photo itself. Any comments you write are available in the photo forever and not in some proprietary database. The app itself is designed with the latest Android design guidelines in mind and while it took quite a bit of time and effort to get the animations working the way I wanted them to, I think the final result is pretty great :).

I have a bunch of features lined up for future iterations of the app (of course), but I am pretty proud of where the app is today already. If you have an Android phone or a tablet, get the app from Google Play (its FREE!) and let me know if you have any feedback or comments.

[Video] New Magazine View in EspressoReader: Your Google Reader feeds never looked so pretty

I am pretty proud of the new version of EspressoReader that was released yesterday. While the build included numerous bugfixes, the biggest change in the app is a much improved Magazine View that is centered around the images in a feed. Here is a screenshot +video of the new view:

Magazine View

The view is fully navigable via the keyboard via the directional keys which makes going through a bunch of feed items really easy.  By the way, I will be releasing the core library that does the image fetching under an Open Source license in my next post so stay tuned for that. In the meanwhile, if you are a Google Reader user, go download EspressoReader from the AIR marketplace and give it a shot.

Whats new in EspressoReader 0.8: Twitter profile “guesses”

I posted an update to EspressoReader on the Adobe AIR marketplace yesterday (if you are using an older version of the application, restart it to get the auto update message). While the application does have a number of features and bugfixes, the feature I am definitely most excited about is the Twitter profile guesses. Here is a screenshot of what that looks like when triggered:

Associated Twitter Profiles

The lookups work really well on feeds that talk about companies and products like Techcrunch, Mashable, etc. Besides guessing at the twitter names, the app also picks up twitter names if mentioned in the post. On some of the design blogs I follow its pretty amazing to find the profiles of designers mentioned in the posts.

Having it work brought interesting questions to mind. For example, if you find a Twitter profile, is their last status most important or the conversations they are having, or just searches based on the profile name (to see what people are saying about the product). And sometimes the guess is WAY off, for example Apple on Twitter is not the Apple Company we love to talk about ;).

The “guess” API call requires users to be signed in so you’ll need to sign in to Twitter when using the application to get it to work.

Besides that, a bunch of other features were added to the build:

  • Mark All Items as Read functionality
  • Moved to a certifed security certificate from a self signed one (thanks Adobe)
  • Font issue fixes for other languages (RTL languages are still an issue)
  • Fixes to the left hand side Subscriptions view
  • Feed Titles on story items
  • Bug fixes when calling more items in a Category view
  • Misc UI bug fixes

If you haven’t tried EspressoReader yet, give it a shot and let me know how it works. Most of the features on this release came from user feedback so feel free to send us more.

EspressoReader v0.7 now on Adobe AIR Marketplace

EspressoReader preview image

I am pretty excited to announce the first public release for EspressoReader is now on the Adobe AIR marketplace. Like I had mentioned in my last post, EspressoReader is a desktop client for Google Reader that I have been working with Alex for a while. While the application is pretty functional right now, there are a lot of cool features I have in my head that will make it truly a awesome experience.

There were a bunch of motivations that led me to work on this application:

  • I was pretty bored of the uninspiring (though functional) UI of Google Reader.
  • A lot of my feeds would contain duplicate content (say every time Facebook added a new feature, it would be reported by Mashable, Techcrunch, etc). So Espresso loads the feeds ahead of time in a local database and parses them to find duplicate content and shows them as related items in the related items sidebar (only if you are in the List view of the application though).
  • Navigating to the feed I wanted to read using the Tree control on GoogleReader was fairly tedious. Espresso also does a good job navigating a through your feeds using “quick jump”. At any point when you are using the application, you can hit the spacebar and bring up a textfield that’ll let you jump to any feed or folder you have in your subscriptions.
  • Sharing stories on Twitter was a chore in Google Reader. In Espresso, you can just hit the share on Twitter button and the twitter status field comes up immediately.

As with any “first look” release, this release is only about the core features and there are many things that still need to be added. For example:

  • The splash screen that you see when you launch the application needs a lot of work. Friends’ Feed doesnt currently show the person who shared the item and the links open in your default browser. Going forward this will be better integrated into the application itself.
  • Links right now open in your default browser. This will change and there will be an integrated web browser (with a setting to open links in your default web browser).
  • Photos in Magazine view
  • Offline access
  • Adding/Managing Feeds and Subscriptions (right now you cannot add new feeds or move them to different folders)

etc etc. If you have any other ideas/suggestions, please leave a comment on this post. I am really looking for feedback on this release.

Here is a quick video of the application in action (reposted from the previous post):

If you are on Twitter, you can follow me or espressoReader for details on updates etc. I have also started a wiki to list the features/todos/help which is pretty bare right now but will hopefully grow as time progresses.

[Update: version 0.8 released as well with Twitter Profile “Guesses”: More here]

Sneak peek: EspressoReader v2: A desktop client for Google Reader

I am a big Google Reader fan, even if I often find myself overwhelmed by the number of feeds I have to catch up on every time I fire up the the web app. For the last few months I have been working on an app that would help me manage my subscriptions. With the help of Alex, a friend and a fantastic designer, I have been working on V2 of EspressoReader: a desktop client for Google Reader.

I had released an earlier version a while back but back then I had limited knowledge of the (undocumented) Google Reader API. The new version has been written from ground up and includes a lot of interesting features like:

  • List view and Magazine view for feeds
  • Quick “jump to feed” shortcuts
  • Related feeds algorithm that scans your feeds for related content
  • Sharing options with Twitter and Google Reader

Here is a quick video of the application in action:

I will post the latest build of the application on my blog soon, but if you are interested in this build @ or dm me on Twitter.

Stay tuned for an update coming soon 🙂