Posts Tagged ‘brainstorm’


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.