<Innovimax/>

Aller au contenu | Aller au menu | Aller à la recherche

Sunday 16 July 2006

Start simple but stay human

Starting simple

It's interesting to see how a lot of people could follow you when you say something is easy.

So you start to do it simple, all the people come, take a look and then say "Ok, it's simple, i take it".

Then you face a lot of problems you underestimate, misconsidered or totally missed, intentionally or not, at the beginning.

And then you add more and more complexity, so that people who wish to do complex thing they want, could do it.

And then, people who at start were ok to agree to simplicity, begin to disagree.

This little story is the story of

  • HTML
  • Basic
  • Wiki
  • MS Windows
  • Cars (the thing you drive, not the movie!)
  • and so on...
Starting complex

Some start complex, and simplify so that more and more people come:

  • People are aware it is complex, so they accept easily complexity
  • But, you never reach the same audience as starting simple

This is the case of:

  • C
  • Linux
  • etc.
So what could be the good choice?

Starting simple IS a very good choice, but with taking into account at the beginning that it will become complex. And then you design it as an onion:

  • First level IS simple and STAY simple (stay conform to your first choice)
  • the more you go high in the levels, the more it will be complex (add complexity but control it)
  • higher levels MUST just be options to call from a lower level (no mix between levels)

This could be called "DESIGN BY LEVEL"

A lot of specifications, are now inclined to take this way (CSS, DOM, etc.), but haven't yet crossed the major point which is to strictly separate all this (NOMIX rule).

For example, for HTML, the level 0 has been put into XHTML and level 1 and more into CSS.

In CSS, we can imagine making those levels more visible

h1 {
  color: blue;
  -extension {
     // this is a hook for inserting in place CSS level 2 and higher
    font-stretch: ultra-expanded;
    -extension {
       // this is a hook for inserting in place CSS level 3 and higher
      font-effect: emboss;
    }
  } 
}

-extension {
  // this a hook for extending at the template level 
  h1:before { content: "Title :" }
}
A concrete example: Wiki

The wiki syntax was simpler than HTML and al. to edit page, and that's why Wikipedia contains now millions of pages in hundreds of languages. In Wikipedia, it is possible now to implement very complex thing.

So what could be a good way to handle this complexity.

First redefine what is the Wiki level 0 syntax:

  • this syntax will have to handle simple editing problems and accept hook for more complex things.
  • Then emit warning when one try to use more complex thing in a space where people are waiting for level 0 syntax, so that (s)he can move it to the appropriate place for that level of complexity

Example:

==Title==
blabla
blabla [[link]] etc.
{|
|table
|-
|blabla
|}

and hooks

{{complexTableForFooball|
Country1=France|
Country2=Italy|
Winner=2|
Date=July, 9 2006}}

And then define what are complex things:

  • defining color inside a table and a lot of extra information
{{|border="0" cellspacing="0" cellpadding="1"
|-
|colspan="10" style="background:#98A1B2;color:#FFFFFF"|'Groupe A'
|-bgcolor="#E4E4E4"
| {{evenMoreComplexThing|1998}}
...

and the evenMoreCompleThing could make a call to something programmatic like {{#expr: {{{1}}} + 2 div 4 }}.

Is it simple to do?

Of course it is not! The complexity must be handled by the main program to catch what could be considered as overcomplex to first class users.

Then in the complex level, you have to handle complexity level and it is less and less obvious, the more levels you want to have.

But, one explicit win is semantical:

to handle hook, you have to separate data from the design, so you have to give then more significance and that's AFAIK one of the goal of the Wikipedia!

Inspired by jy[B]log through <Glazblog/>, and Wikipedia of course!

Thursday 13 July 2006

Openness of Office Documents

There is a great buzz around the pseudo-support of OpenDocument just being announced by Microsoft.

What is it about ?

Let's go into the detail of this kitchen sink.A lot of names are often cited together, because they are highly interrelated.

OpenDocument, ODF, OpenOffice, ISO and OASIS

OpenOffice is an office suite, in which we can make documents.

Recently the format of documents OpenOffice handle natively, which is named OpenDocument, has been standardized by ISO just after being developed at the OASIS.

The extension of document in OpenDocument format is ODF.

OpenXML, DOCX, Office 12, ECMA

A lot of people already know Microsoft Office suite and the ability to open Word for making documents.

Next version of Office, Office 12, will be able the handle for import/export an XML format of document, named OpenXML, which is not yet standardized by ECMA

The extension of document in OpenXML format is DOCX.

So what's the point

The main part of the project will be around XSLT transformation from one XML format, DOCX a.k.a OpenXML and ODF a.k.a OpenDocument.

Of course, there is a legacy part of the project to support non-XML DOC format to OpenDocument, which is very important and we should look at it in a near future.

The bad point is that :

Office 12 will not have included support of OpenDocument

which translate to :

Microsoft will not have any responsibility for this support and will not include it by default. It will not be highly integrated so it might add a significant amount of processing time to load/save documents. And moreover, we have not any idea of the scheduled release of this module.

But good points are :

1.) The converter is in Open Source

so

It is not locked in principle and the community could take it and add new feature as they are needed, like a better math formula or forms supports. But, the development is based on DotNet so could difficultly be used directly.

2.) A french software company is involved

so

It's a good point for french software industry, in which Innovimax is involved

So what else could we wait for

This post is entitled "Openness", which is the key point for being interoperable. So that's what could be done :

  • OpenOffice.org community could act that it is a good point and that in return as soon as DOCX will become an ECMA standard, OpenOffice.org will launch a project to support import/export of this format. May be could they start immediately ?
  • The main point for legacy conversion is to handle all the specificities of those formats. We can imagine that in a near future, all the word documents could be converted to OpenXML (that's the aim of the ECMA specification). In those case, we could imagine that we will have
  DOC/RTF --------> DOCX <----------> ODF  
  non-XML           XML   with XSLT   XML

And then, let's the history say who will win, between DOCX and ODF

Monday 3 July 2006

Eclipse 3.2 (Callisto Release) is out !

This new release introduce a lot of really interesting feature to the plateform for java developper : here.

One of the most interesting, is the wizzard to help to Clean Up which will help you to convert your sources to Java 5.0 and benefit of all the novelties.

It already supports Java 6.0 which is still in beta for now.

A lot of tooltips are now included and fully functionnal and give very helpfull hints for coding.

Follow this link to download this pretty good piece of Open Source software

Update

A very good article from Ed Burnette could be found here.