Roadmaps are among some of the most difficult things I do, mostly because I love to work "agile", meaning that our users gets to pick what we work on. At the same time they are also one of the most popular things to read for our users since they give them predictability in regards to what they can expect out of future versions of Gaia.
Screenshot taken from our
Dynamic Ajax Image sampleIf you work "agile" which means (oversimplified) that your users gets to choose the features they want you to work on, then obviously you don't know what your users are going to wish from you three months from now. But at the point we are in our development cycle now, a lot of work and research have been invested in the next version already and at least I can tell our users what we are working on and what we will try to give for our next version of
Gaia Ajax Widgets. And I guess that would resemble a "roadmap" enough for Stian to get happy (which always begs me for roadmaps ;)
Core
We have several issues currently with the "core" of Gaia, first of all Gaia in Q1 does not serialize "non-Gaia" controls. We have fixed this already which means that if you have a normal ASP.NET DropDownList and you change its value and afterwards trigger a Gaia Callback, then the new value of that DropDownList will be sent to the server and you will have access to the "selected value" of that control. Note that (of course) there is still no way we can update that value on the client-side if you change the values of "non-Gaia" controls in Gaia Ajax Callbacks.
Another thing we've worked extensively on within the core is the ability to change values of Gaia Controls in the Page_Load method or earlier in the page life cycle. Currently if you try to change a value in an Ajax Callbacks of a Gaia Control in Page_Load event or anywhere earlier than this in the page life cycle it just won't work. The reason is that Gaia currently does not start tracking changes to Gaia Controls before the Load event is triggered on the Gaia Controls which occur after the Load Event of the Page. This is also already fixed which means that among other things it is far easier to take an existing ASP.NET (postback) application and just port it to Gaia without having to do large structural changes to it.
Also we're researching the possibility of getting rid of the ForceAnUpdate method and track automatically whether or not changes have occured to the ControlCollection of Container Widgets (Gaia ones) that will "automagically" trigger a ForceAnUpdate call on the container widget. We're not sure if this is possible, but at least you know we are researching it and might come up with a solution for it in our Q2 - Glory Release ;)
Also we are working on integrating our Unit Tests far closer to our build cycle. The Unit Tests for Gaia have almost doubled and we're working on integrating them much more close into our build cycle which will create higher quality of code for us and for the users of Gaia.
Not to mention that we're working on making the DOM structure of Gaia Applications far more conforming to the XHTML standards.
Also we're working on getting cookie less session support in addition to having support for web farms. Both of these issues where suggested from users of Gaia. So if you have a feature request then please post it in our forums and the likelyhood of that feature being implemented is pretty huge ;)
More devices
We will also spend a lot of resources trying to get Gaia to run on as many platforms as possible. At the moment we are investigating giving Gaia
GrassHopper support. This means you will be able to run Gaia applications on J2EE platforms like
Tomcat or
JBoss.
Also we will spend a lot of resources trying to get Gaia applications to run on more CLIENTS which currently means we will try to give support for as many "phone browsers" as possible. At the moment we're supporting IE6, 7 and 8,
FireFox,
Opera and
Safari. But only (as far as we know) for desktop systems. When Q2 comes out we will try to at least support Opera and WebKit ("Safari") on devices too like
iPhone and
Android plus PocketPC phones running
Opera Mini.
Appearance out-of-the-box
We also believe strongly in that Gaia should appear out of the box really beautiful. This means that we are spending a lot of resources on making Gaia widgets have nice skins out of the box and also we're upgrading our design time experience by orders of magnitudes.
Also we're creating new skins and giving Gaia more flexibility in regards of how to skin your Gaia Applications. Window and Accordion will get Icon support and so on. Lots of new shiny things coming up :)
Conclusion
We have only two tasks in Gaiaware, one is to increase your freedom to choose. This is supported by the fact that we are Open Source and we try to keep as close as possible to Open Standards. And we also try to support as many devices and server back ends as possible.
The other task we have is to simplify your job. Gaia will not be "finished" before it can read your mind and know what you want to create before you yourself can know it and have it finished at the same second you think about it.
We believe in that by giving you great tools that simplifies your job and by also letting you have the option to choose whatever system you want to run Gaia on both at the backend and at the client-side you will be happy. And when you are happy our business will strive :)
Please correct me if my assumptions are wrong however, as I said we are working "agile" in close relationship with our users... :)
We have two "guide lines" for the upcoming release. One of them is that we should be able to create ANY application on stage live in less than an hour. The other is that we should be able to explain the entire core of Gaia to any developer in less than an hour. So as you can see, our ambitions are pretty huge for our Glory Release. The name was chosen for a reason after all ;)