Re: High-level use cases of editing TF, 2nd try

On Sat, Oct 24, 2015 at 8:54 PM, Koji Ishii <kojiishi@gmail.com> wrote:

> I failed to discuss high-level goals and use cases in my previous try.
> Allow me to try again so that we could discuss this next week. Without
> doing this properly, I think we waste a lot of time just to understand
> each other.
>
> Last year I heard that there are two different use cases of "editors
> on the web":
>
> 1. Online word processing service, such as Office Online or Google
> Docs. These are large JS, usually use its own model and editing HTML
> is not its primary target.
> 2. Editor framework, which web developers can plug it into their web
> pages and provide rich editing on, for example, forum pages.
>
> This TF primarily targets use case 2, because use case 1 is harder and
> takes longer. Also, most use case 1 products today are built without
> using contenteditable very much anyway, so we didn't hear much
> requests to work on.
>
> What I understand from Johaness's use case is that we're focusing on
> use case 1 now. It probably means that we'll disregard use case 2.
>
> I admit that I originally had a bit allergic response to the change.
> After some thoughts, the change looks ok to me if all TF members and
> editing framework developers are in consensus moving their framework
> to use case 1. It means that the use case 2 disappeared.
>
> So I'd like to confirm us that:
>
> 1. Are we changing our target use case from 2 to 1?
> 2. Are we in consensus that use case 2 is no longer important for this
> TF to work on?
>

Look at the use cases Ben outlined:

https://w3c.github.io/editing/editing-explainer.html#use-cases


I think all I did to that was to remove the word "Fidus Writer" a few
places that Ben had left in there.

The use cases all look like high end web apps to me.

As goals it says

   - Empower authors with the right set of baseline behavior to enable
   creating complex editors
   - Make it easy to implement custom behavior with appropriate APIs

So all in all, I don't think we are changing directions. This is what we
set out to do, and we are still going at it.

But I can see, if some of us were basing our work on these goals, and
others thought they would work primarily on enhancing contenteditable for
mini editors, then that could explain why we at times seem to have had
different objectives here.


>
> If yes to both, I'd like to hear more from Office Online and Google
> Docs people before we move on to discuss solutions. They have built
> it, so they should know problems and pitfalls better than we do.
>

Right, I had hoped that you guys at Google had had your Docs people
involved in the process. If that is not the case, I think it would be good
if you could engage them more. I have contacted and tried to engage just
about very editor project I came across that is not linked to one of the
browser makers.


>
> We did some in the past. I heard that the move from ce=events to
> ce=typing was a request from MS Office team because it's too hard for
> JS to handle IME correctly. But I didn't do it really seriously
> because I assumed that they're out of scope at least for the first
> level of the work in this TF. I would like to revisit them if our
> target use case was changed.
>

As said, nothing has changed. But if there are more people in the browser
makers organizations, this is a time as good as any to engage them.


>
> /koji
>
>


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org