The WYSIWYG work begins

March 16, 2009

Well it has been quite some time since I last wrote anything as you can see. and it is time for me and for that I am sorry. I will not make any attempts to promise more postings but I will continue and tell you how this WYSIWYG process have been doing and the results.

The WYSIWYG work went on ice for a long time to be restarted early this year. and the first work was to figure out how we are going to achieve this.

First step: First step is to just brainstorm and define what is needed. We had two brainstorm areas that was requirements and list of editors. We just made a big list of all requirements or just questions like “Do we have keyboard navigation as a requirement?”. And for the editors we made a list of all editors we could find that had a remote possibility to be considered. In the editorslist we posted the name of the editor and a link to where there are more information on the editor on the web.

Second step: First step is as always research. We had to get a first requirements list and also a list of all the possible editors we could think of. With the requirements work we first identified some areas on what to write requirements on before we got into the meaty parts. This was the results of our requirement areas:

  • License model, pricing and company/organizational aspects
    Legal stuff and such. Like if it is a part of some fancy CMS it might be a problem etc.
  • Platform , browser, script and language support
    To make sure we can use the editor where we want to and that our target group of users can use it
  • Customizability
    Make sure that the parts of editor that we want to customize can be customized
  • Documentation and Support
    Make sure there are good documentation and support for the editor
  • Accessibility of user interface
    Check accessibility parameters like keyboard navigation and such for the editor.
  • Plugin Support
    Make sure we can make plugins for the parts we need and maybe also make sure there are some public plugins we can use/look at.
  • CSS Support
    Make sure the editor has good CSS Support
  • Code Rendering and Content Creation
    Look at the code the editor renders with its default functionality and make sure it is of good quality
  • Formatting Options
    Detailed look at what elements the editor can create and what attributes it uses at default installation.
  • Specific Requirements
    All other requirements that does not fit under the above headings.

Next time we will dive a little deeper.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: