Re: Amaya design

Today some people convinced me that CompoZer is a good alternative to
Amaya. I have take a check and a think that it is. Maybe is time to say
bye Amaya.

On Wed, 2011-12-28 at 11:30 -0300, Daniel Hernández wrote:
> I think that for some uses Amaya is the best HTML document editor. The
> advantage as HTML editor is that you can organize your documents in a
> non hierarchical way, navigate across them or share it with other people
> in the Web. That is better than editing single documents with
> OpenOffice. But it have some problems related with its architecture.
> The first problem is that in the Web we don't see documents as the
> building blocks for content. Even in content oriented CMS as Plone you
> see the emphasis in portlets and viewlets. That means that building
> blocks for sites are sub-documents that are combined and showed along
> the site. Also pages have more functionalities. You can filter documents
> by tags, select date ranges or find documents. That features are
> completely necessary for web sites today.
> I have wrote some sites using Amaya and running some scripts to
> reorganize documents, generate site structure and other thinks. Also I
> mix the static pages with content generated dynamically for some
> specific views. But it was to much work, and now I'm migrating sites to
> Plone. Now that I'm writing some documents in Plone I note that I really
> hate editing content in the Plone text editor and in any other web CMS.
> To edit documents Amaya is the best.
> Another interesting application to manage documents is Zim wiki. It is a
> desktop wiki that you can use to edit notes (as with Tom Boy) or to edit
> collaborative documentation using Bazar to manage versions and merge
> branches. I think that there are a lot of features of Zim that can be
> ported to Amaya. Some of them are:
> 1. Creating documents from links (as in a wiki).
> 2. Renaming or moving nodes updates all incoming references.
> 3. Attaching files also store that files.
> 4. Having several plugins.
> 5. Synchronization with versioning systems (now it only supports bzr).
> 6. Integrating several nodes in a same documentation project.
> I think that the most important difference between Amaya and other tools
> to develop content is the point 6. Amaya is a page editor. Zim and Plone
> are tools to develop sites. Today you need today a tool to develop
> sites, that means to edit several documents as a whole.
> I haven't see the code, but maybe the second problem is its monolithic
> architecture. It is necessary to get rid of the SVG editor for the core.
> We don't need to edit SVG in Amaya, we can do it in Inkscape, or other
> featured SVG editor. Maybe that kind of features must be implemented as
> plugins.
> I was experimenting with the Amaya template system, XTiger, and I have
> proposed an alternative template system in my engineering thesis. But
> now I think that we need tools to manage microformats in another Way.
> With XTiger microformats you have each document related with one
> template. Now that you needs is to write objects inside documents and
> that objects could be managed with several templates. This is the point
> where templates compete with JavaScript. In the current Web lot of
> content edition is made with JavaScript and server side processing. The
> question is: Where to implement that features? in a editor as Amaya or
> in JavaScript? You can implement several features of Amaya in JavaScript
> delegating the problem of rendering the HTML to common browsers, but in
> that case you lost the power to edit any document as you like, because
> the editor will be set in documents. For me the question is open.
> --
> Daniel Hernández

Received on Wednesday, 28 December 2011 20:48:44 UTC