Online WYSIWYG editors have frustrated us for a long time. We were fed up so we decided to scratch our own itch and build one from the bottom up. We talked to over two dozen developers to weed out the top problems and then implemented a solution. The result is SnapEditor.
We’re still in beta but we believe we’re stable enough to release a version out into the wild. It’s better to release early and be embarrassed right? Please let us know what you think.
Aloha is purely an in-place editor. However, there are times when you need an editor in a form. You either have to fudge it, or use two different editors. SnapEditor provides both, an in-place and form-based editor.
Aloha is currently sitting at over 1mb. I know that there are talks about cutting down the size, but SnapEditor is already small, coming in at around 180kb.
We have the utmost respect for the Aloha guys for making an open source editor, but it is still quite buggy. SnapEditor concentrates on providing a predictable experience with clean HTML. We built it from scratch to do this right.
- Can't actually provide link text (<a href="#">link text</a>).
- Can't insert images, videos, flash, etc.
- No way to set custom styling, change font size, change font itself, change the font itself.
- Tab doesn't insert tab, but rather removes the highlight.
- No justification.
Compared to other offerings on the market (my main comparison being TinyMCE), this simply offers a quick way to make very simple edits without necessitating the clicking of "save". This sounds like somewhat of a niche market.
1. Providing the link text and a much better interface for inserting links will be provided before production launch. Inserting links is definitely incomplete in the Beta.
2. Inserting images is also missing from the Beta but will be included in the production version. We wanted to show the insert image feature when it was implemented with automatic resizing of the actual image (i.e. not just changing the width/height but resampling the image as well). When it does get implemented, we also plan on releasing drag and drop abilities, auto-sharpening (if you like) and multi-image uploading. We have experience implementing all these features except drag and drop already (see Orbs.com).
3. We have a way to do styling changes using "Named Styles" which are element/class combinations. This is already implemented but not yet exposed because we want to get the interface for it right first.
4. Not sure which context you mean tabs don't work. Probably within the next few days though tab/shift-tab in lists and tables will work as expected. It is on our do very soon list.
5. Justification: Based on our interviews, we found that people were unsatisfied with their editors in 3 key areas that we address. It is probably true that in its Beta state, its usefulness is not all there yet. For a better idea of where SnapEditor will be going in the months ahead, see the "What's Coming" section.
TinyMCE is definitely a major competitor to us. One of the major differences is that TinyMCE cannot do In-Place editing. We don't believe that will be a niche market in the future. Many of the new editors focus only on In-Place editing.
Thank you for your comments Eykanal. We will continue to try and provide features that make SnapEditor the obvious choice of editor. :)
Thanks for the replies. For #4, I mean that when I hit the "tab" key, it doesn't insert a tab, but rather acts as forms normally do... focus moves to the next element on the page, which happens to be something different than the text editor I was working with.
Oh, I see. We'll have to think about that. Since HTML doesn't have the concept of tabstops or dynamic tab positions, this may not work very well in the context of an online WYSIWYG editor.
In the context of word processors, tabbing in a list usually indents and in a table cell usually moves to the next cell so we would probably adopt those for predictability.
What happens outside of that I'm not sure what would be the best. We can probably implement anything and we can also offer configurable options as well. That said, we'll probably have a recommended default based on what we think is best.
You're right in that it isn't cheap compared to an open source editor that you can get for free. It is cheaper than other paid competitors though and we believe it is superior in many important ways. For example, it's the only one that can do both In-Place and Form based editing. It also cleans the HTML very well: Try pasting in from Google Docs, or Word, or any random HTML page (I like using Slashdot because it's a mess of nested tags). We also fix a bunch of issues to do with browser differences. I think you will also like our roadmap which includes many more features not available anywhere else. We have experience implementing many of the things in the roadmap already so they will be coming.
If you are looking for low cost, there are a lot of alternatives. One of the goals with SnapEditor is actually to make it for people who are willing to pay for their editor. This obviously benefits us (since we want to make profit) but we believe the needs of people who are willing to pay will be different from people who are not.
Nice work! I think there is still more work to be done in the WYSIWYG world as all the current editors I've tried in my app seem to either be frustrating to use or too bloated (I love speedy scripts)
I have 2 suggestions:
1. Could you please release a version without jQuery baked into it, I really don't like it when plugins include jQuery in their source as it's a lot of unnecessary bloat added to the application (and most people have jQuery on their site already or can include it easy enough if they don't).
2. I'd love it if you could make each feature (additional options / controls etc) on top of this core an additional module and make sure they don't rely on each other like how jQuery-UI does it. I haven't found a single WYSIWYG editor that does this and it frustrates me because I have a need for an editor with some functionality and not others and would like the ability to not include unnecessary features to reduce file size and improve performance.
Then you could release a full version with every single feature baked in, or a minimal version which is just the core and you can add in other features by including the js files for the features you want and enabling them via a config file.
If you build the API well enough and snapeditor is popular enough you could even enlist the community help to build plugins for it for features they'd like to see, sublime text does this really well.
Thanks for the feedback. These are great suggestions and we already have plans for them.
1. Yes, we are planning on releasing two version later. Version 1 would have jQuery stripped except for the parts that we need which would be a lot smaller (I think we mainly use the measurement and positioning routines). Version 2 would be for if you already have jQuery in which case it would use your version of jQuery. We would, of course, have to run unit testing to make sure it worked on past versions of jQuery.
2. Actually, all of the features are already implemented this way, even fairly basic features like bold/italic and the Shutter focus. We will be creating an online Editor builder that will let you choose what you want and it will build you an optimized version that includes only those features. You won't have to do any of the work to create it. We will probably enable you to save multiple configurations under your account as well. It will also create sprites for you so that you get only one image and it will only contain the images that you need.
We already have an API that abstracts the differences between each browser but we want to make sure it is stable before releasing it.
Thanks LubuJackson, we put a lot of work into trying to figure out what speaks to developers. Wesley did a lot of research by interviewing over 2 dozen developers before we got really started which really helped us identify what developers needed.
Currently SnapEditor does not support the iPad yet though it will be there before production. We actually tried it out on Friday (when we officially launched the Beta site) and everything worked except for exiting the edit mode. We haven't run our unit tests on the iPad yet though. It will probably be very little work to get it to work on the iPad.
We also found that it seems to work on Android just fine though we haven't run our unit tests on either.
Finally, we will also be having support for Opera later. Currently it doesn't run at all on Opera but we have experience with making WYWISYWG editors for Opera so it should not be too difficult.
Definitely looks fantastic (assuming, of course, everything works as roadmapped).
Gotta say that the price is a bit of a turnoff (can't see paying double my yearly server cost for a text editor...), but I know you guys need to make money, so I can only say, "best of luck!"
I think you'd see a lot more traction with a much lower itch point (I'd pay $99 for the unlimited license, for instance). And what's with the users and developers thing? I'm not even sure how you'd track it, assuming it's a non-hosted script, and even then I can't see a justification for jacking the price up. Again, I know you need to make money, but c'mon....
Just my thoughts. The product itself looks fantastic. Just hope I can afford it....
Thanks for the comment and specifically for telling us what you would pay. I think that is the third comment on pricing so we will continue to evaluate.
Note that there is a $1 charitable license for people who want to use SnapEditor but can't afford it. It is a charitable license and not a license for charity by the way. Perhaps we should change the name...
Not for nothing, but if you converted your text editor into a commenting system or wiki type product for site visitors on certain pages it would make for a beautiful commenting system, but that would essentially force everyone to pay $299.
If I was you I might consider a wordpress plugin for $50 to replace the visual editor. A lot of non-technical people on wordpress would appreciate something cleaner.
I'm not quite sure I understanding what you mean by converting into a comment system or wiki type product. Are you saying we should implement the editor in a product and then sell it with the editor for $299?
I like your WordPress plugin idea and this is indeed something we are considering and at a similar price point. The target market for WordPress plugins is obviously a lot larger as well.
It's good to hear that people will pay for a good product, even with the availability of free alternatives. Of course, we would have to offer a superior product.
We already have the ability to add different classes than H1, H2, etc. and we can do this very elegantly. In fact, we support something called named styles. Here's a few definitions.
Title: div.title > Subtitle
Subtitle: div.subtitle > Normal
This tells us that we have a named style called "Title" that is represented by a DIV element with class "title" and that after you hit enter at the end of it, it will end up in the "Subtitle" named class. This is already implemented but not exposed because we haven't built the UI for selecting Named Styles as a dropdown in the beta. This will be in there for the production release though.
We will most likely have sets of "Named Styles" that are compatible with Twitter Bootstrap and other common frameworks at some point. You will also be able to easily create your own Named Styles, probably in an online UI that will build your editor for you.
Note that once you define the Named Styles, the editor whitelists to them so you can't get "illegal" element/class combinations which lets you (the developer) keep the HTML consistent for your needs instead of hoping your users won't break your styles.
We'll keep in mind the ability to add a target for links. We hadn't thought about the need for this until you mentioned it.
This is definitely on our short list and SnapEditor won't go to production without the image uploader. I'm going to guesstimate we'll have some sort of support in about a month along with some other got-to-have features.
We want to get this right and part of that is coming up with a great and simple server API to handle the uploads across all platforms/languages/frameworks.
Yeah, we wrote special code to fix cut and pasting of bullets in some browsers like Chrome; however, recent versions of Chrome seem to fix this so we removed that code. We'd like to take credit for being the only WYSIWYG editors that fixes the cut/paste bullet problem but WebKit seems to have fixed that for all editors now.
We do the pricing by developer to differentiate between small websites (with 1 or 2 developers) from companies that are building SAAS apps with perhaps a dozen or more developers.