thesunny

Thanks for the great comment,

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.

TheSunny

Thanks for the comments Scott,

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.

TheSunny

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.

TheSunny

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.

TheSunny

Thanks for the compliment.

Thanks Sdizier

Thanks for the frank response. It will certainly help us understand our customers better.

Sunny

Ahh... that makes more sense.

We'll put this on the roadmap. There are reasons why we left it off initially, it's easy to implement, but in retrospect we can see the demand for it.

TheSunny

Hi Tim,

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.

TheSunny

Hi FisaDev,

Thanks for the info.

I've been using SnapEditor almost exclusively on Chrome and haven't had problems. It's been tested in both Windows and Linux.

We'd love it if you could provide more information so we can make sure the experience is great for you.

TheSunny

Thanks for the comment. We hope you will consider us for your next project. I promise that there are many more fantastic features to come and that we are just scratching the surface.

We feel that the WYSIWYG editor has stagnated over the last 10 years and there is room for dramatic improvements.

TheSunny

Hi JFitzDela,

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...

TheSunny

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.

TheSunny

Hi Eykanal,

Thanks for your comments.

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. :)

TheSunny

Hi RichF,

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.

Hi Egypturnash,

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.

TheSunny

The article states that greater than 16 bit has value in recording, just not in playback. If you took your 24 bit recording and translated the best 16 bits of it than output it through your 24 bit DAC then they are saying you won't here a difference. I say output through your 24 bit DAC so you aren't simply hearing a better DAC.

Fusemail is a good solution and is only $2/month per mailbox.

We've built our own inline editor for Orbs, a website builder project which we posted to Hacker News last year. You can see it at http://www.orbs.com/. Basically, you just click on the content and the editor starts working in place. This version actually uses an iFrame but copies the CSS styles in so it works exactly like inline editing.

When we asked for feedback, there was a comment that was particularly interesting where the user said he'd pay for something like that if he could edit his regular website with it. Basically a CMS.

It was such a good idea that we built it and it's available at http://www.designhamster.com/. Basically, you just add a class="EDIT" attribute to any div you want to make editable. We plan on making a real post to Hacker News about it later. This version is actually making the DIV editable instead of an iFrame.

There is a live demo on that page where you can click on a box with some text in it and try it out on the DH home page; however, to get a real feel for it, I'd suggest using the free signup so you get an idea how it works in a page.

Note: DesignHamster is live and accepting customers but we aren't going to promote until we improve the interface. This will be done in 2 weeks. It is completely usable now though for projects.

So, you are using Aloha editor. It's kind of cool but still buggy (I'm sure this will be cleaned up) and I understand it's quite heavy. I think we did ours in 66KB + mootools.

If you are wondering, making an editor from scratch is HUGE work. To get bold, italic, headings, bullets, and everything else that is built into the browser's execCommand list for working with contenteditable gets you a lot of cool stuff for almost zero pain. It's fun, enjoyable and fast to build. This gives you the false impression that the rest will be just as easy. Unfortunately, not even close.

Every browser is different is just the beginning. There are bugs galore in each browser. Some of the worst offenders are from our favorite browsers like Chrome and Safari too. Try and backspace from a paragraph into a heading and you'll get these weird inline SPAN that fake the formatting of the H1/P tag without actually being one. In many instances, IE has the sanest behavior. To fix this, we override the handling of delete, backspace and enter depending on the browser. If the browser handles it correctly, we don't touch it. But if it doesn't, we modify the DOM directly.

In other areas like selecting an image, IE uses a completely different selection object type for images than text. This has to be handled specially too.

Many commands not built in require manipulation of the DOM. But unfortunately that kills your UNDO. So if you want to keep undo working, you have to build your own UNDO stack.

Then there are just plain weird bugs. I think there was one where if you have an image in a P tag with nothing else, in one of the browsers, your cursor can't move passed it. So to fix it, we had to insert an invisible space.

For us, the editor is one of the most valuable assets of the company which is why we have spend, probably over a man-year working and improving our editor. We are getting better at it but it's still not perfect. We want the editor to be a prime differentiator of our product so we are willing to put in the work; however, be warned that working directly on creating an editor is a lot of work.

We solved this problem for web development for orbs.com by doing the following:

Everyone has fast dev machines.

We access the site through a local domain name like orbs-sunny.com referring to my personal computer; however, this is routed through Nginx with throttling on to simulate a slower external connection.

If we need a faster connection for certain types of testing like uploading 100MB files, we use orbs-sunny-fast.com. This goes directly to our machine and skips nginx.

It is not perfect in that it doesn't simulate a slow computer; however, it's good enough to make everybody pay attention to speed.

We did this because speed related issues were often ignored at the time of original development. We found that the slowdown on execution hasn't slowed development since our app is supposed to be responsive anyway. If it's not responsive, it's much better to fix it while your head is in that space. This results in faster overall development.

Sunny

Don't know if you'll read this but we will be setting the lower limit to three characters and we may raise the upper limit as well.

I think this idea if quite compelling. We will consider this for a future project. I can think of some things we can do to make this a perfect hybrid of "complete control for the designer" and "completely simple for the designer's client."

Very interesting...

Sunny

Certainly Orbs is a good replacement for a wiki. We are playing with an idea to allow for moderated wikis. In other words, you can take content from other people and choose which stuff you want to let in.

On not using the username for lookup, will put this in as a bug.

Will put a higher priority on not emailing the password as we had several people mention this.

Sunny

Thanks. The image does a real resize as well on the server although you probably already knew that.

Thanks for the heads up on the "dialog box" popup. That's a bug that no one noticed. I'll add that to our list.

Sunny

Can't remember exactly but I think it was around $10,000. We bought it a long time ago.

How should we find out what your goal is? Little afraid of asking since that would add to our quick startup process.

Sunny

We were a little afraid of letting people choose arbitrary colors for text. One of our goals was to make it difficult to make a page ugly and easy to make it look good. We were considering that you could choose a highlight color though. The color would be part of your custom site design. Would this suit your purpose.

Currently, you can access the site through https: but that is not the default and it is not enforced. We might consider making an option to force the site to https:

Renaming the home page. Something I'm thinking about. Actually was thinking of removing the "home" part of the tree and just making the first real page the home page by default.

Image linking. I'll put that in a recommendation.

Embedding Stuff. This is in our plans already. We have a really cool implementation idea for this. :)

Sunny

Thanks. After asking around, it looks like we have done Safari testing on OSX but we haven't fully tested Firefox on OSX. We assumed if Firefox worked in Win/Linux that it would work in OSX but that seems like a wrong assumption. Our testers will go through and test Firefox on OSX now though

Again thanks.

Yes, that is correct. But we probably shouldn't email the password to the user. Just let them change it. Might consider a one-way hash instead of a two-way one though.